Prepare Salesforce evidence an ISO 27001 auditor can follow.
A configuration export can show how an org was set up on a date. It cannot show that access was reviewed, a change was approved or a recovery procedure worked. Build the evidence pack around the questions being assessed.
7 min readBy aprity editorial · Updated
Agree the Salesforce boundary with your information security and audit teams. For each selected control, connect the control owner, configuration evidence, dated operating records and any unresolved exceptions.
ISO/IEC 27001 concerns an information security management system. This article proposes a Salesforce evidence organisation method; it is not a control mapping, certification checklist or assurance opinion.
Resolve scope before collecting screenshots
Write down which production and non-production environments, business processes, identities, integrations and service providers are in the assessment boundary. A Salesforce org can depend on an identity provider, middleware, a deployment system and a document store. Decide who supplies evidence for each interface.
Ask the audit lead for the assessment period, applicable controls and sampling expectations. Use the organisation's risk assessment and Statement of Applicability as inputs. Do not infer that every control in a generic online list applies in the same way to your Salesforce implementation.
Separate evidence about the Salesforce service from evidence about your own configuration and operating practices. Provider assurance documents can inform supplier assessment; they do not prove that your team removed a departed user's access or reviewed a privileged permission assignment.
Organise evidence around a claim that can be challenged
Suggested evidence requests, to adapt with your auditor. These are not prescribed ISO control tests or actual audit findings.
| Claim being assessed | Configuration evidence | Operating evidence and limitation |
|---|---|---|
| Privileged access is reviewed | Relevant permissions and assignments at the snapshot date | Dated review, decisions and completed removals; a current list does not prove past review |
| Production changes are controlled | Deployed component version and environment identity | Change request, approval, validation and deployment record for selected changes |
| Integration responsibility is defined | Authentication mechanism and documented system boundary | Named owner, access review and response procedure; exclude secret values |
| Incidents can be investigated | Available logging configuration and retention settings | A traceable incident sample or exercise; distinguish configured from collected evidence |
| Recovery is operationally understood | Documented recovery dependencies | Authorised exercise results and unresolved actions; a runbook alone is insufficient |
Worked example: follow one permission change end to end
Consider an illustrative request to let a support team export a sensitive object. Begin with the request: who needs the capability, for what purpose and in which environment? Then identify the permission change actually deployed and the users or groups receiving it. Do not stop at the permission-set name.
Link the risk decision and approval to the exact change, then link the change to validation evidence. If the approval covers read access while the deployed permission allows a broader operation, the document chain is not coherent simply because every file exists.
Next, select evidence of operation during the assessment period. Was the assignment reviewed? Were departures or role changes reflected? Were identified exceptions closed? Record a missing item as a missing item. A screenshot captured today cannot retrospectively establish that a review happened last quarter.
Conclude with the narrow statement the evidence supports. For example: ‘The selected change has a matching approval and deployment record; the subsequent access-review record has not been supplied.’ This is more useful than an unsupported green status for ‘access control’.
Export time-limited evidence before the window closes
Salesforce's Setup Audit Trail help page describes a display of the 20 most recent setup changes and a downloadable history for the past 180 days. Records older than that window are deleted. Arrange collection according to your approved retention requirements before evidence ages out.
Setup Audit Trail describes setup changes. Do not treat it as a complete history of business-record activity, approval decisions or all security events. Identify the additional evidence each claim requires and whether the necessary service, licence and collection were actually enabled during the relevant period.
Keep the export date, environment, covered period and collection identity with each evidence file. Restrict access to the pack: it may expose usernames, architecture and security configuration even when it contains no business records. Link to secrets-management procedures instead of copying credentials into an audit document.
Use a small evidence index with explicit missing items
Original example record. Placeholder references identify the evidence you need to obtain; they do not represent completed audit work.
Evidence item: ACCESS-REVIEW-01
Claim: privileged assignments reviewed for the agreed period
Scope: [org ID / environment / population / dates]
Owner: [named control owner]
Configuration snapshot: [restricted evidence reference]
Review record: NOT SUPPLIED
Exceptions and closure: NOT ASSESSED
Collector and collection date: [complete on collection]
Reviewer and conclusion: [complete after review]
Retention and access: [approved policy reference]An evidence index should help a second reviewer find and interpret the same material. It should not hide an incomplete record behind a percentage-complete dashboard.
Run an internal evidence walkthrough
Select samples for reasons you can explain
Agree the sample with the audit lead: for example a routine release, an emergency change and a privileged-access change. This is a suggested preparation exercise, not a universal sampling prescription.
Follow each chain without the original author
Have another reviewer connect the request, decision, implementation and dated outcome. Note broken links, identity mismatches and records outside the assessment period.
Give exceptions an accountable next step
Record the missing evidence or control concern, owner, due date and agreed disposition. Do not manufacture historical records to make a pack look complete.
Freeze the delivered pack
Version the index and preserve the evidence references used for the assessment. Later configuration changes should not silently replace what the auditor actually reviewed.
Key terms in this guide: Field-level security (FLS), Permission set group.
Use org documentation as one part of the evidence pack
aprity can help organise descriptions of supported Salesforce metadata. Your security and audit teams still determine control applicability, collect operating records and assess whether the evidence is sufficient. Generated documentation does not confer certification or replace that assessment.
- Keep the observed org and snapshot identifiable.
- Link configuration explanations to the wider evidence index.
- Retain ownership, review records and exceptions separately.
Frequently asked questions
Does Salesforce documentation make an organisation ISO 27001 compliant?
No. Documentation can support an assessment, but the information security management system, risk treatment and operation of applicable controls require their own evidence and evaluation.
Can a current metadata export prove controls operated throughout the audit period?
No. It describes a snapshot. Use dated operating records for the relevant period and disclose missing history rather than extrapolating backwards from the current configuration.
Related guides
Audit whether your Salesforce documentation can support a real decision.
A documentation audit should uncover where a reader would make the wrong change, misunderstand a process or be unable to investigate a failure. Counting documented components is only the beginning.
Read the guide Operational handoverA Salesforce handover kit the receiving team can actually use.
A folder of diagrams can be delivered while the incoming team still cannot explain a failed order. Treat the handover as a transfer of operating responsibility, with a practical exercise that shows what has—and has not—been transferred.
Read the guideSee it on your own org, not on a slide.
A free 14-day trial documents your org from a computed dependency graph — read-only, no credit card, and you review the output before deciding anything.