How to pass a sales-data audit

Sales data audits used to be sporadic. They are increasingly routine: SOC 2, ISO 27001, sector-specific regulators in financial services and healthcare, internal audit teams at customers that demand the same controls from their suppliers. The volume of "please complete our security questionnaire" is rising.

A well-prepared sales-data operation can pass these audits in days. A poorly-prepared one spends weeks chasing evidence. The difference is preparation, not heroics.

What auditors actually ask

In conversations with auditors across SOC 2, ISO 27001, GDPR-related audits, and financial-services-specific reviews, the questions cluster into four:

1. Who can see what? Demonstrate that your access control limits each user to the data they are authorized to see. Not just in the UI, but in the underlying data store.

2. Who did what, and when? Demonstrate that every consequential action is recorded with actor, target, timestamp, and result.

3. Can you prove the records are intact? Demonstrate that the audit log has not been tampered with since events were recorded.

4. Can you reproduce this evidence next year, after staff turnover and platform changes? Demonstrate that the controls are structural, not dependent on a specific individual or version.

The first two are common. The third is where most CRMs fail. The fourth is where most organizations fail, regardless of platform.

Question 1: who can see what

The auditor wants to verify that territorial separation, role separation, and team separation hold. The acceptable evidence is:

• A test, not a configuration screenshot. Authenticate as a user scoped to one market. Issue an API call for another market's data. Show the response is empty.
• The test runs on every CI build. The auditor wants to know that the enforcement does not silently break.
• The enforcement is at the data layer. Show the row-level security policy, the WHERE clause that filters every query. Not the UI filter; the database.

If your evidence for territorial separation is "our UI hides those records," the auditor (correctly) downgrades the finding. The acceptable answer is "our database refuses to return them."

Question 2: who did what

The auditor wants to see the audit log. They expect:

• Coverage. Every state change, every permission decision, every authentication event, every admin action, every data export. Not just data changes; the meta-actions matter too.
• Required fields. Actor (user ID and email), action (what happened), target (entity type and ID), before/after snapshots for data changes, source IP, user agent, request ID, timestamp.
• Searchability. You can filter the log by user, time range, action type, and target type. A log you cannot query is a log you cannot use.

Most CRMs ship a usable audit log for this question. The next question is where they fall down.

Question 3: can you prove the records are intact

The auditor wants to verify that the audit log itself has not been altered. Two acceptable forms of evidence:

• Hash-chained log. Each entry contains a hash computed from its content plus the previous entry's hash. Any modification breaks the chain. The auditor downloads the chain and verifies it offline using a standard procedure.
• Append-only by database design. The audit table has no DELETE or UPDATE permissions for any role except a separate audit-admin role with auditable use.

The hash-chained log is the stronger property and the one that matters for serious compliance regimes. The append-only model is acceptable for some audits but assumes the auditor trusts your operational controls; the hash chain does not require that trust.

If your platform ships only a queryable audit table without integrity guarantees, the auditor records this as a finding. If your platform ships a hash-chained log with documented verification, the finding goes away.

Question 4: can you reproduce next year

The most overlooked question. The auditor wants to know that the controls are structural, not dependent on specific people or specific moments in your platform's history.

Three properties that matter:

• Configuration as code. Your access rules, your audit policies, your retention settings are in version control, not in someone's head. A new admin in two years can read the configuration and understand the controls.
• Documented verification procedures. "How do you prove the audit log is intact" has a written answer with steps. "How do you verify that territorial separation holds" has a written test. Anyone can execute the procedure.
• Retention guarantees in the contract. Your platform vendor commits, in writing, to keep audit logs for the period you committed to auditors. Not "best effort"; a contractual obligation.

Without these, your audit two years from now is going to involve a lot of staring at code looking for clues. With them, the audit is "run these verification procedures, here are the results."

What to prepare before the audit kickoff

A short list of artifacts to have ready:

• Access control diagram. One page. Shows the five layers (UI, API gateway, policy engine, data access layer, database roles) and which one is the enforcement boundary. Auditors love this.
• Audit log sample. A few representative entries showing the field coverage, hash chain values, and the actions captured.
• Verification procedure document. Steps to verify the audit log. Steps to verify the access boundary. Anyone can run them.
• Retention policy. Written, signed, and consistent with your vendor's commitment.
• Test suite excerpt. Show the integration tests that verify access boundaries. Show that they run in CI.

These artifacts together answer 80% of the audit questions before the auditor asks. The remaining 20% is specific to the auditor's framework and is usually answered with a screen-share session.

What to fix if you do not have these today

If reading this list made you wince, here is the order of investment:

1. Audit log with required fields. If your current logging does not capture actor, action, target, and timestamp on every consequential action, fix this first. Cannot pass an audit without it.
2. Data-layer access enforcement. If your enforcement is in the UI, move it to the data layer. This is the single highest-leverage investment.
3. Hash-chained audit log. If your audit log is just a table, add the chain. Each entry's hash depends on the previous one.
4. Documented verification. Write the procedure. Anyone should be able to run it.
5. Retention contract. Get your platform vendor to commit in writing.

This sequence is also approximately the order auditors care about. Skipping ahead is rarely a good idea.

For how MegatronLead delivers all five structurally, see security and compliance. For the access-control architecture specifically, see market-based access control.