How to prepare for a Salesforce security audit

Let's cut to the chase: Salesforce security audits don't care about your good intentions. They demand proof. I've managed audits for healthcare, finance, and manufacturing orgs—where a single misconfigured sharing rule can trigger compliance fines. Here’s how to actually prepare, not just check boxes.

Start with User Access—Not Just the Obvious

Don't just check "System Administrator" roles. Run this SOQL to find hidden risks:

SELECT Id, Name, Profile.Name, UserPermissionsMacroAdmin, UserPermissionsSelfReg 
FROM User 
WHERE UserPermissionsMacroAdmin = true OR UserPermissionsSelfReg = true

Example: At a healthcare client, we found 23 users with UserPermissionsMacroAdmin (enabling self-service admin tools) despite being sales reps. This violated HIPAA’s least-privilege principle. Cleaned it up before the audit.

Crush Sharing Rule Chaos

Sharing rules are a mess in 80% of orgs. Audit these two critical areas first:

• Public Read/Write on sensitive objects: At a financial client, a "public" sharing rule on Loan_Appliance__c exposed customer SSNs. We moved to "Private" sharing + sharing sets for required teams.
• Role Hierarchy gaps: In a manufacturing org, the "Plant Manager" role could access all sites. We added a custom Site__c field to restrict visibility using OwnerId = :UserInfo.getUserId() in Apex triggers.

Third-Party Integrations: The Silent Risk

OAuth apps and API keys are audit goldmines for security teams. Check:

• Setup > Security > API Access: Remove unused apps (e.g., old marketing tools with "Full Access" scope)
• Review all Custom Permissions assigned to non-admin users (e.g., "Allow Marketing API" given to a sales rep)

Example: A retail client’s "Inventory Sync" app had Full Access to Product__c. We scoped it to Read and added IP whitelisting. Audit team gave a pass.

Your 24-Hour Pre-Audit Checklist

Don’t wait for the auditor’s email. Before they arrive:

• Revoke all temporary access: Delete "temporary" admin accounts used for past projects (I’ve seen these linger for years).
• Verify password policies: Ensure Minimum Password Length is ≥12, Maximum Age ≤90 days (non-negotiable for SOC 2).
• Check login history: Use Setup > Security > Login History to flag logins from unexpected locations (e.g., "New York" at 3 AM for a user based in London).
• Document justifications: For every exception (e.g., "Admin access for Finance Controller"), have a signed business case on file.

The Bottom Line

Security audits aren’t about perfection—they’re about showing you’ve systematically managed risk. If you can’t answer "Why does this user need this access?" in 10 seconds, you’re not ready. I’ve seen orgs fail because they spent weeks on documentation but couldn’t prove their sharing rules actually worked. Start with the SOQL, fix the obvious, and document the why.

Still unsure if your org is audit-ready? Run a free security health scan with OrgScanner—it flags misconfigurations in 2 minutes and gives actionable fixes. No fluff, just the gaps that will get you flagged.