How to Prepare Your Salesforce Org for an Audit

Short answer: an auditor does not want a tour of your org. They want three evidence packs: who had access and who approved it, what changed in production and who signed it off, and how long you keep records before deleting them. If those three exports are routine, an audit is a meeting. If they are not, it is a two-week fire drill.

What does an auditor actually ask a Salesforce team for?

Most Salesforce audit advice describes an internal health check: dead fields, unused reports, storage cleanup. That is useful housekeeping, but it is not what an external auditor tests. Under SOX, SOC 2 or ISO 27001, they sample and ask you to prove a control:

• Access evidence. A user list with profiles, permission sets and roles, plus who approved each grant and when it was last reviewed.
• Change evidence. For a sample of production changes: the request, the approval, the test result and the deployment record.
• Retention and deletion evidence. What personal data you hold, how long you keep it, and proof that deletion requests were honoured.

Almost every finding we have seen comes from one of those three, not from a messy page layout.

What is in scope, and who decides?

You decide first, then defend it. Scope follows risk, not the org chart:

• Financial reporting (SOX): quoting, orders, billing, revenue objects and any automation that can change those values, including integration users.
• Personal data (GDPR and similar): Contact, Lead, Case, Person Account, chat transcripts and every sandbox copy.
• Privileged access: Modify All Data, View All Data, Manage Users, Author Apex, and anyone who can deploy.

Write this down as a one-page scope memo before the kickoff call. An auditor who has to define scope for you will define it generously.

How do you produce access evidence without screenshots?

Screenshots age badly and prove nothing about the other 51 weeks of the year. Export instead, on a schedule:

1. Query the permission objects. PermissionSetAssignment, ObjectPermissions and FieldPermissions give you the real picture, including everything granted through permission set groups.
2. Export Login History. Salesforce keeps six months online and lets you download it as CSV. Dormant accounts with live privileges are the classic finding.
3. Run Security Health Check and Optimizer and keep the output. Auditors accept a dated self-assessment as evidence that monitoring exists.
4. Do the review quarterly, with a named approver. An access review nobody signed is not a control. Record the reviewer, the date and the exceptions.

Integration users deserve their own line. They usually carry the widest permissions and the least scrutiny, and auditors have learned to look there first.

How do you produce change evidence?

This is where change sets hurt. They cannot separate the person who builds from the person who deploys, and they leave no linked approval. A pipeline answers with links: the work item and its business reason, the commit showing exactly which metadata moved, the pull request with a reviewer who is not the author, the test result, and the deployment record.

Two properties decide whether it passes. The evidence must be immutable, and it must be complete, meaning there is no route to production that bypasses it. A process covering most changes still fails, because the sample can land on the exception.

Native history helps but does not carry the whole load. Setup Audit Trail holds 180 days and is queryable through the SetupAuditTrail object before it is purged. Field History Tracking keeps roughly 18 months in the UI and 24 through the API, unless you licence Field Audit Trail with Salesforce Shield and set a retention policy. Audit cycles are annual, so keep your own copy in Git and your DevOps platform.

How do you prove retention and deletion?

Retention is the question teams answer worst, because nobody owns it. Three artefacts settle it:

• A data map: which objects and fields hold personal data, and the lawful basis for each.
• A retention schedule per object, with the deletion mechanism named (scheduled job, archive, hard delete).
• A deletion log showing that erasure requests were executed, including in sandboxes and backups.

The sandbox line is the one that surprises people. A full sandbox refreshed from production is a copy of the same personal data in a less controlled environment. Seed a subset and mask personal fields as part of the refresh job, so the control evidences itself.

How do you prepare in two weeks instead of two months?

1. Days 1-2: write the scope memo and name an owner per evidence pack.
2. Days 3-5: export access data, run Health Check, list every integration user and privileged profile.
3. Days 6-8: pull 10 recent production changes at random and walk each one end to end. Whatever you cannot trace is your real finding.
4. Days 9-10: write the retention schedule and check sandbox data handling.
5. Then automate what you just did by hand, so next year is an export rather than a project.

That last step is the whole game. Teams that pass cleanly are not the ones with the tidiest org, they are the ones whose controls run on their own and leave a trail. Tekunda builds Salesforce this way as a certified SI, ISV and PDO, and we have taken managed packages through AppExchange security review in healthcare, logistics and manufacturing, where the evidence bar is set by someone else.

FAQ

How long does Salesforce keep setup change history?

Setup Audit Trail retains 180 days, then purges. Export it on a schedule or keep the equivalent record in your DevOps platform.

Do we need Salesforce Shield to pass an audit?

Not necessarily. Shield extends field history retention and adds Event Monitoring, which helps, but the controls and their evidence matter more than the licence.

How often should we run user access reviews?

Quarterly for privileged and integration users, at least annually for everyone else, with a named approver recorded each time.

Is a full sandbox with production data a problem?

It can be. Treat it as a processing activity: seed a subset instead of cloning, mask personal fields during the refresh, and restrict access as you would in production.