How to Prepare for a Salesforce Security Review

A practical checklist for your Salesforce security review: permission documentation, connected app audit, change history exports, and monitoring best practices.

A Salesforce security review is coming. It might be an internal IT audit, a compliance assessment for SOC 2 or GDPR, an AppExchange submission review, or an enterprise customer asking you to demonstrate that your Salesforce environment is properly secured before they sign a deal.

Whatever the trigger, the experience of most admins is the same: they know Salesforce reasonably well, but they have never thought systematically about security documentation, and the review surfaces gaps they did not know existed.

This guide walks through what reviewers actually look for, how to prepare your org's documentation, and the specific questions you need to be able to answer before anyone starts asking them.

What Security Reviews Are Looking For

Security reviewers are not trying to find every conceivable vulnerability in your Salesforce configuration. They are looking for evidence of three things:

1. Deliberate access controls: Can you demonstrate that each user has access only to what they need for their job? Can you explain how access decisions are made and who authorizes them?

2. Visible change history: Can you show who changed what, and when? If a security-relevant configuration was modified six months ago, do you have a record of it, and can you explain whether the change was authorized?

3. Ongoing monitoring: Is security an active practice in your org, or a set of one-time decisions made when the org was first configured? Do you have a process for reviewing changes and catching problems before they become incidents?

The third point is where most orgs struggle. Access controls are usually documented at implementation and then drift. Change history exists in the Setup Audit Trail but is rarely reviewed. Monitoring, if it exists at all, is manual and inconsistent.

Preparing for a security review is largely an exercise in making the current reality of your org legible to an outside observer.

Step 1: Run Salesforce Health Check

Before doing anything else, run Health Check. It is in Setup under Quick Find "Health Check." It produces a score from 0-100 based on your org's security settings compared to Salesforce's recommended baseline.

Health Check evaluates:

  • Password policies (complexity, lockout settings, expiration)
  • Session settings (timeout, IP restriction, HTTPS requirements)
  • Network access settings
  • Certificate and identity configuration

Any item flagged as "Meets Standard" is fine. Any item flagged as "Fails Standard" needs either remediation or a documented risk acceptance that explains why you deviate from the baseline.

Print or export the Health Check results before your review. Reviewers will often ask for this report as evidence of your self-assessment process.

Important: Health Check shows your current state, not your history. A perfect Health Check score tells a reviewer that your settings are correct today. It does not tell them whether those settings were different last month. Change history documentation (covered below) fills that gap.

Step 2: Document Your Permission Model

This is the most time-consuming part of security review preparation and the part that causes the most surprises.

Profiles: Export a list of all active profiles and what each profile's key permissions are. At minimum: Can Edit All Data, View All Data, Modify All Data, API Enabled, Manage Users. Tools like the Salesforce Permission Explorer or SOQL queries against the Profile and ObjectPermissions objects can help generate this.

Permission Sets: List all permission sets and their purpose. The question reviewers ask: "What business requirement does each permission set serve?" If you cannot answer that for a permission set, it may be orphaned and should be reviewed for removal.

Permission Set Groups: If you use Permission Set Groups, document the constituent permission sets and which user types they are assigned to.

The principle of least privilege check: For each profile and permission set group, ask: "Does this give access to anything the user does not strictly need for their job?" Permission creep is one of the most common findings in Salesforce security reviews. Access that was granted "just for this project" in 2023 is often still in place in 2026.

Recommendation: use the FieldPermissions and ObjectPermissions objects in SOQL to export current permission state as a CSV. This becomes an audit artifact and a baseline for future reviews.

SELECT Parent.Name, Field, PermissionsRead, PermissionsEdit
FROM FieldPermissions
WHERE SobjectType = 'Account'
ORDER BY Parent.Name

Step 3: Audit Connected Apps and Integrations

Every connected app in your org represents an integration point with an external system. Security reviewers will ask about each one.

For each connected app, document:

  • What system it connects to
  • What OAuth scopes it uses (read, write, full access, specific objects)
  • Who authorized it and when
  • Whether it is still actively used

The Salesforce recommendation is to use the minimum necessary OAuth scope for each integration. "Full" scope on a connected app that only needs to read Account records is an unnecessary risk. If the third-party system is compromised, the impact is proportional to the OAuth scope granted.

Connected apps that are no longer in use should be disabled or deleted. A dormant connected app with active credentials is a persistent attack surface that provides no business value.

To review connected apps: Setup, Quick Find, "Connected Apps OAuth Usage." This shows which connected apps have active OAuth tokens and how many users have authorized them.

Step 4: Review Data Classification and Field-Level Security

Reviewers focused on data compliance (GDPR, CCPA, HIPAA, or SOC 2 Type II) will ask about your data classification approach.

Salesforce includes a Data Classification feature that allows you to tag fields as containing Personally Identifiable Information (PII), Protected Health Information (PHI), or other sensitive data categories. If you have not used this feature, set aside time to tag your sensitive fields before the review.

After tagging, the question becomes: does field-level security match the data sensitivity? Fields tagged as PII should not be visible to roles that do not need them. The Salesforce Security Guide (Spring '26, available as a PDF from Salesforce documentation) covers field-level security implementation in detail.

The reviewer's verification process: log in as a typical user from each major user segment and confirm that PII fields are either invisible or read-only as appropriate. This manual verification, documented with screenshots, is standard evidence for compliance audits.

Step 5: Prepare Your Change History Documentation

This is the step that separates orgs that can answer "what changed and when?" from those that cannot.

Reviewers frequently ask:

  • "When was MFA last configured, and who configured it?"
  • "Were there any changes to profiles or permissions in the last 90 days?"
  • "Has anyone accessed or modified your session security settings recently?"

The Setup Audit Trail answers these questions, but only if you have been maintaining it. The native retention is 180 days. Records older than that are purged.

Before your review:

  1. Export your Setup Audit Trail for the full 180-day window as a CSV
  2. Filter and document the significant changes: any Security Controls changes, any profile modifications, any connected app additions or modifications
  3. For each significant change, note whether it was authorized (and by whom), and what the business justification was

This documentation turns the raw Audit Trail into a narrative: "Here are the security configuration changes in the last 6 months, each of them was authorized, and here is why they were made."

If you cannot account for a change in the Audit Trail, that is a finding you should investigate before the review rather than during it. Reviewers are significantly more concerned by changes that the current admin cannot explain than by intentional changes with clear business justification.

Going forward: Archive your Setup Audit Trail exports monthly. After 180 days, the native Salesforce retention window closes and those records are gone. An ongoing archive gives you the evidence trail you need for future reviews without having to scramble.

Step 6: Review Your Monitoring and Alerting Practices

The question reviewers are increasingly asking: "How do you find out when a security configuration changes?" For a full breakdown of which changes carry the most risk, see The 5 Salesforce Security Changes You Need to Monitor.

The honest answer for most orgs is: "We check the Audit Trail periodically, or we find out when something breaks."

That answer is acceptable at a basic level, but it will prompt follow-up questions about frequency, ownership, and what happens when the admin responsible is on vacation.

A stronger answer: "We have daily automated monitoring of our Setup Audit Trail. Changes are classified by severity and delivered in a morning digest. Critical security changes trigger an immediate notification."

To get to that stronger answer, you need a process for continuous change monitoring. This can be built manually (scheduled SOQL queries, email alerts via Flow) or with a purpose-built tool. AuditForce provides this layer directly: every Setup Audit Trail change is ingested daily, classified by severity, and delivered in a digest. Critical security changes generate real-time alerts. Every change shows the matched rule so you can explain why a particular event was flagged as Critical versus Medium.

When a reviewer asks how you monitor for unauthorized security changes, the answer "we receive a daily classified digest and immediate alerts for Critical changes" closes the question. The follow-up is usually "can we see a sample?" — and you can show them.

The Documentation Package You Should Have Ready

Going into a security review, you should be able to produce:

  1. Health Check export (dated within 30 days of the review)
  2. Permission model documentation (profiles, permission sets, who has what and why)
  3. Connected apps inventory (what each app is, its OAuth scope, whether it is still active)
  4. Field data classification summary (PII/sensitive fields and their field-level security configuration)
  5. Setup Audit Trail export for the last 90-180 days, filtered to security-relevant sections
  6. Change log for significant changes (a plain-English summary of authorized changes in the review period)
  7. Monitoring process documentation (how you detect and respond to security configuration changes)

This package does not need to be a formal report. A shared folder with labeled spreadsheets and a one-page summary memo is entirely sufficient for most reviews.

The goal is to demonstrate that your Salesforce environment is managed with intention: that access is deliberate, that changes are tracked, and that someone is watching.