Preparing a Salesforce org for an ISO 27001 audit
The certificate is for your information security management system, not for your org. What the auditor wants from Salesforce is narrower and more awkward: evidence that access, change and logging work the way your policy says they do.
10 min readISO 27001 certifies a management system, not a platform. Salesforce's own certifications cover Salesforce's side of the shared responsibility model; they say nothing about how your org is configured, and no tool can grant your organisation the certificate.
What an auditor asks of the org falls into four areas: who can access what and how that was decided, how changes reach production, what is logged and for how long, and whether your documented picture of the org matches the org. The fourth is where most of the preparation time goes, because the documentation is almost always older than the configuration.
What is actually being audited
ISO/IEC 27001 certifies an information security management system — the set of policies, risk assessments, controls and review cycles your organisation operates. Salesforce is in scope as an asset that system governs, not as the subject of the certificate.
That distinction changes what the auditor asks for. They are not looking to be told that Salesforce is secure; Salesforce publishes its own attestations for the parts it runs. They are looking for evidence that the controls you claim to apply to your org are the controls actually in force, and that you can demonstrate it on a date they choose rather than on a date you prepared for.
Practically, the Annex A themes that land hardest on a CRM are access control and access rights, privileged access, change management, and logging. Everything below is organised around producing evidence for those.
What the auditor wants from the org, and where it lives
Who can access what
The effective permission picture: profiles, permission sets and permission set groups, the sharing model and its rules, field-level security on anything sensitive, and how those combine for a real user. The configuration is all in Setup; the hard part is stating the result rather than the ingredients, because permissions compose in ways an org chart does not show.
How access was decided
Evidence that grants follow a documented process — joiner, mover and leaver handling, periodic review of who holds elevated rights, and a reason on record for each administrative account. Salesforce records the state; your process records the justification, and the auditor will ask to reconcile the two.
How changes reach production
Setup Audit Trail for configuration changes, deployment history for the ones that came through a release process, and the gap between them — the changes made directly in production. That gap is a finding waiting to happen, and it is better to measure it yourself first.
What is logged, and kept
Login History, Setup Audit Trail and, where licensed, Event Monitoring and Field Audit Trail. Know the retention period for each, because the auditor's sample window may be longer than the platform's default and that is a control gap you want to discover now rather than in the room.
The sequence that avoids the last-minute archaeology
Establish a current baseline of the org
Before anything else, produce an accurate description of how the org is configured today: objects, automations, validation rules, permissions, integrations. Almost every audit that runs long runs long here, because the existing documentation describes an org that has moved on and nobody knows by how much.
Reconcile the permission picture
Work out effective access for real user populations, not for profiles in isolation. Permission set groups, muting, sharing rules and field-level security compose, and the composed result is what the auditor tests. Write down the answer for each population and note where an exception exists and why.
Measure the change-control gap
Compare what Setup Audit Trail shows against what your deployment records show for the same period. Direct-in-production changes are not automatically a failure, but undocumented ones are. Knowing the number before the audit lets you present a remediation rather than a surprise.
Check retention against the sample window
Confirm how far back each log actually reaches and compare it with the period the auditor will sample. Where the platform's retention is shorter than your policy claims, either the retention or the policy has to change, and both take longer than the notice period for an audit.
Keep the baseline current until the audit date
A baseline produced two months out is a description of the past by the time anyone reads it. Refresh it on a schedule and keep a diff between refreshes, so you can show what changed in the interval instead of asserting that nothing did.
Where aprity fits
aprity does not grant or hold ISO 27001, SOC 2 or HDS certification, and no tool can. What it addresses is the first and last step above: producing a current, source-traceable picture of the org, and keeping it current.
It documents objects, business rules, automations, permissions and integrations from a deterministic reading of the metadata, in business language, with a confidence score and a link back to the metadata behind each claim — so an auditor can trace a statement rather than accept it. A weekly scan means the baseline can be refreshed right before the audit, and the scan-to-scan diff shows exactly which business rules changed between two dates.
- Security baseline and permissions visibility from the metadata
- Every claim traceable back to the source it came from
- Business-rule change history between any two scans
- Read-only access, metadata purged after each scan, EU or US residency
Preparing a Salesforce org for an ISO 27001 audit — FAQ
Does using aprity make my organisation ISO 27001 certified?
No. aprity does not grant or hold that certification, and no product can. Certification is awarded to your information security management system by an accredited body. aprity produces the current, source-traceable documentation the framework expects you to maintain, so preparation starts from evidence rather than from a blank page.
Isn't Salesforce already ISO 27001 certified?
Salesforce holds certifications covering the infrastructure and services it operates. That is one side of a shared responsibility model and it says nothing about how your org is configured — your access model, your automations, your integrations and your change control are yours to evidence.
What is the single biggest time sink in preparing a Salesforce org for audit?
Rebuilding an accurate picture of the org. The controls themselves are usually in reasonable shape; what is missing is a current description of the configuration that a third party can verify. Teams tend to reconstruct that description from scratch every cycle, which is both the longest task and the one most likely to contain errors.
How current does the documentation have to be?
Current enough that an auditor sampling on a date of their choosing finds the org matching the document. In practice that means generating it from the org rather than maintaining it by hand, and being able to show what changed between two points in time — an assertion that nothing changed is not evidence.
Does an audit require write access to the org?
Nothing about producing the documentation does. aprity's connector is strictly read-only and reads metadata rather than the business data in your records; raw metadata is purged after every scan and only the derived documentation is retained, encrypted in the region you choose.
Related guides
How to find everywhere a Salesforce field is used
Salesforce will tell you most of the places a field is referenced. The dangerous part of the answer is the remainder — the references no static check can see, which is exactly where deletions go wrong.
Read the guide GuideHow to document a Salesforce Flow
Flow Builder shows you the canvas. It does not tell you what the Flow changes, what it depends on, or what breaks when you edit it — and those are the three things anyone reading the documentation actually needs.
Read the guideSee it on your own org, not on a slide.
A free 14-day evaluation documents your org from a computed dependency graph — read-only, no credit card, and you review the output before deciding anything.