A Salesforce security audit answers a simple question with a complicated evidence trail: can the wrong person or system see, change or remove something important?
The answer changes whenever a user joins, a permission set is assigned, a flow is activated, an integration is connected, a sharing rule is edited or a release introduces a new setting. That is why an annual audit on its own is not a security programme. It is a photograph of a system that keeps moving.
Most teams need several review rhythms: continuous alerts for urgent changes, a short monthly access review, a deeper quarterly configuration audit and a periodic independent assessment for high-risk environments.
Salesforce security is shared responsibility
Salesforce secures the underlying service. Each customer remains responsible for how its own org is configured and who can access its data.
Salesforce Health Check is a useful baseline. It compares selected security settings with the Salesforce Baseline Standard or a custom baseline and produces a score. A lower score can reveal weak session or password settings, but a high score is not proof that the entire org is safe.
Health Check does not answer every question about object permissions, field-level security, sharing, guest access, Apex, integrations or stale privileged users. Salesforce's own auditing guidance says audit features do not secure the org by themselves and recommends regular review for unexpected changes or usage patterns.
Treat the score as one signal inside a wider review, not the finish line.
A practical audit cadence
There is no universal timetable. A small internal org and a public Experience Cloud implementation handling sensitive data have different risk. The following cadence is a sensible starting point that can be tightened for regulated or high-change environments.
Continuously: detect changes that cannot wait
Continuous monitoring should focus on events where waiting for the next monthly meeting creates unacceptable exposure.
Examples include:
- new assignments of powerful system permissions;
- login anomalies or repeated failures;
- changes to authentication, session or network settings;
- new integrations and connected apps;
- guest-user or external-sharing changes;
- disabled logging or monitoring controls;
- unexpected data exports or API activity, where the required event data is available.
Not every org licenses the same monitoring capabilities. Build the process around what your edition provides, then decide whether risk justifies additional Salesforce products or another monitoring service.
Monthly: review people and privileged access
Once a month, review the access most likely to drift:
- active users who have left or changed roles;
- dormant users and integration accounts;
- users with Modify All Data, View All Data, Manage Users or comparable high-impact permissions;
- permission-set assignments added during projects or incident work;
- delegated administrators;
- connected apps, OAuth grants and credentials with unclear owners;
- failed logins and unusual login locations;
- recent Setup Audit Trail entries.
The point is not to export a spreadsheet and file it away. Every exception needs an owner and a decision: remove, reduce, accept temporarily with an expiry date, or investigate.
Quarterly: run the full configuration audit
A quarterly review should cover the system, not only user accounts. Use the 14-point Salesforce security-review checklist as the detailed scope, then compare results with the previous quarter.
At minimum, examine:
- org-wide defaults, role hierarchy and sharing rules;
- profiles, permission sets, permission-set groups and field access;
- authentication, SSO, MFA and session controls;
- external and guest-user access;
- Apex sharing and data-access enforcement;
- flows and automation that operate with elevated context;
- integrations, connected apps and named credentials;
- installed packages;
- files, reports, exports and data-egress paths;
- logging, audit trails and incident-readiness controls.
Quarterly is also the right interval to ask whether previously accepted risks are still justified. An exception approved for a six-week implementation should not survive for two years because nobody reopened the ticket.
After defined events: audit the change, not the calendar
Run an additional review after events that materially change access or architecture:
- an acquisition, business-unit restructure or large user migration;
- a new Experience Cloud site;
- a major managed package or integration;
- an identity-provider or SSO change;
- a large permission redesign;
- a security incident or suspected exposure;
- handover to a new administrator or consulting partner;
- a significant Salesforce release feature you decide to enable.
Event-triggered reviews catch risk while the people who made the change still remember why it was made.
Annually or when risk demands it: seek independent challenge
An internal team can automate evidence collection and still miss assumptions it has normalised. An external assessor can challenge the design, test documentation and compare the controls with contractual or regulatory obligations.
The frequency depends on data sensitivity, customer commitments, industry obligations and change volume. Automation reduces the cost of repeat checks; it does not turn a product scan into an independent assurance opinion or compliance certification.
What a useful audit produces
A list of settings is inventory. An audit becomes useful when it connects each finding to evidence, risk, ownership and a decision.
For each finding, record:
- What was observed. Name the user, permission, setting, class, integration or sharing rule.
- Why it matters. Describe the realistic data or business impact.
- Evidence. Preserve the configuration value, effective access or source reference.
- Severity and confidence. Separate a confirmed exposure from a candidate requiring manual review.
- Owner and due date. A finding with no owner is a future repeat finding.
- Disposition. Resolved, accepted with rationale and expiry, or false positive with evidence.
- Verification. Re-run the relevant check after remediation.
This structure also makes trends visible. If the same permission keeps returning, the problem may be the access-request process rather than the individuals receiving it.
Avoid the three common audit failures
Chasing a perfect score
A baseline score is useful, but blindly applying every stricter setting can break integrations or legitimate workflows. Understand the risk and business context, test changes in a sandbox and document necessary exceptions.
Reviewing assigned access without effective access
Looking at profiles alone misses permission sets, groups, sharing and other paths. Review the combined access a user receives and the records or fields it exposes.
Producing a report without a remediation loop
Security work stalls when a large report arrives with no prioritisation. Triage critical exposures immediately, schedule lower-risk improvements and make accepted risks visible with review dates.
Making the review repeatable with orgadmin.ai
The orgadmin.ai Security Review runs fourteen modules across privileged access, permissions, object and field security, sharing, guest access, Apex, automation, integrations, packages, data egress and monitoring.
Deterministic checks collect facts, while AI analysis can group and explain evidence. Findings retain severity, evidence and shared triage state, and the review can be exported for stakeholders. The audit is read-only: remediation remains a separate, reviewed action.
That makes it practical to establish a baseline, rerun the same scope quarterly and see whether the security posture is improving. It does not remove the need for manual judgement, testing, legal advice or independent assurance where those are required.
Make the next audit the start of a rhythm
If your org has never had a full review, begin with a baseline rather than waiting for a perfect programme. Run the audit, fix the few highest-risk findings, assign the rest and put the next review on the calendar.
Start a free orgadmin.ai trial to run a read-only security review against a connected org and turn the findings into a repeatable remediation list.