ISO 27001 tests your policy as an artefact, and then tests whether you do what it says. SOC 2 mostly tests whether the control operated. That difference is small on paper and it's what catches teams who've already passed SOC 2. They arrive with good access-event evidence, and a Statement of Applicability describing a more thorough programme than the one they run.
The access-event half carries over almost completely. The management-system half doesn't carry over at all.
The four controls
Annex A in the 2022 revision. These four are the access set, and two more get pulled in.
- A.5.15 Access control. Your documented policy for granting and restricting access, based on business and information-security requirements. Evidence: the policy itself, plus proof it's reviewed and approved on the cadence the policy claims.
- A.5.16 Identity management. The full lifecycle of identities. Evidence: joiner, mover and leaver records tied to a source of truth, and the register of identities that aren't people, because this control isn't limited to employees.
- A.5.17 Authentication information. How credentials are allocated, managed and protected. Evidence: password policy as configured, MFA enforcement with its exemptions named, initial-credential issue process, and how system secrets are stored.
- A.5.18 Access rights. Provisioning, review and removal of access rights. Evidence: review cycles at the interval your own policy states, per-entitlement decisions, and removals that completed.
- A.8.2 Privileged access rights. Who holds elevated access, how it's approved, and how it's reviewed separately from ordinary access.
- A.8.3 Information access restriction. Restriction at the data layer, not just the account layer. Which roles can reach which classifications.
Then the management-system layer, which is the part SOC 2 doesn't prepare you for.
- Statement of Applicability naming these controls as applicable, with a justification, and describing what you actually do rather than what you intend to.
- Risk assessment that connects each control to an identified risk, so the control exists for a stated reason.
- Internal audit covering the access controls at least once in the cycle, with findings and corrective actions closed out.
- Management review minutes showing access risks were considered.
The two things that catch people
Your policy becomes the standard you're held to. If your access control policy says reviews run quarterly and you ran two, that's a nonconformity against your own documented system. It would not have been a finding had the policy said twice yearly. Teams write aspirational policies during implementation and then get audited against them, which is a self-inflicted wound and an extremely common one.
The Statement of Applicability is read before anything is tested. An auditor reads what you claim to do, then goes looking for it. An SoA that describes continuous review, fine-grained entitlement management and full non-human identity coverage sets the bar you'll be measured at. Describing what you run is not weakness. It's the whole point of the document.
A SOC 2 review of one app. Two rows are flagged because the employee is Inactive in HR and still holds access, and three of the rows are not people.
The evidence A.5.18 wants is a decision per entitlement with a reviewer attached, and a removal that completed. A campaign that recorded decisions and never fired the revocations satisfies the first half and fails the second. SOC 2 CC6.3 tests the same gap from the other direction.
Patterns that break it
- Copying the SOC 2 evidence pack over. The access events transfer. The SoA, the risk linkage and the internal audit don't exist in SOC 2 at all.
- An aspirational policy. Every sentence in it is a commitment you'll be tested on.
- Covering employees only under A.5.16. The control covers identities, not people, and the service-account gap is a reliable finding.
- Treating A.8.3 as done because A.5.18 is done. Account-level access and data-classification access are different questions, and most teams have an answer to the first only.
- No internal audit on access. The standard requires internal audit, and access is the area most likely to be skipped in favour of easier clauses.
- Review interval defined and not met. The single most avoidable nonconformity available.
Doing this without a tool
The management-system half is documentation work with no tooling requirement, and it's where the risk sits.
- Read your own access control policy and cut every sentence you can't currently evidence. Do this before your first internal audit, not after the external one.
- Set the review interval to what you'll genuinely sustain. Twice yearly, met twice, beats quarterly met twice.
- Reconcile the Statement of Applicability against reality, control by control, and edit the SoA rather than the ambition.
- Keep one evidence register mapping each control to its artefact, the system it came from, and the date it was pulled. The same metadata discipline the SOC 2 checklist describes applies here.
- Put non-human identities in the A.5.16 scope explicitly, even if the register is a spreadsheet.
- Run an internal audit on the four access controls and close the findings. An audit with open findings and no corrective actions is worse than none.
Budget 2 to 3 days for steps 1 to 3 and a day for the internal audit. Steps 1 and 3 cost nothing and remove more nonconformities than any amount of evidence gathering, because they stop you being measured against a programme you don't run.
What still needs a person
Scope and applicability. Which controls apply, and the justification for any exclusion, is a judgment made with your auditor. It's the first thing read and the last thing a tool can decide.
The policy itself. Somebody has to write what you'll actually do and then defend that it's proportionate to the risk, which is a management decision rather than a configuration.
And the internal audit. It has to be done by somebody independent of the work, which in a small company is genuinely hard to arrange and is not a problem software solves.
Where Iden fits
Step 4 above, standing rather than assembled, and step 5 by construction.
Every provisioning, modification and revocation writes an evidence row as it happens, mapped to the control it satisfies, so A.5.16 and A.5.18 are exports rather than reconstructions. Reviews carry a decision per entitlement with the reviewer named, and the removal that followed, which is the pairing A.5.18 tests.
Non-human identities sit in the same list as people, with the same lifecycle states, so A.5.16 covers them without a separate register and separate discipline to maintain it. What no tool does is write your policy or run your internal audit, and those are where first-time ISO implementations actually fail.