If you already hold ISO 27001 and someone has just asked for a SOC 2 — or the reverse — the honest answer is that most of the underlying security work carries across, and a meaningful slice of the paperwork does not. Teams that plan for both from the start typically find the second framework costs materially less than the first. Teams that treat them as unrelated projects end up collecting the same evidence twice for two different audiences.
The useful way to think about it: the controls overlap heavily, the evidence overlaps almost completely, and the framework-specific artifacts overlap barely at all. Plan around that split and the combined programme is manageable.
The controls that serve both
ISO 27001 and SOC 2 rest on the same security fundamentals, and those fundamentals do not change because the framework does. Run these once, properly, and both examinations draw on them:
- Access management — provisioning tied to role, approval before grant, MFA, periodic access reviews with reviewer and date, prompt removal on termination
- Change management — code review, testing, approval before production, separation of duties, an auditable ticket trail
- Incident response — a documented plan, severity definitions, logged incidents with timelines, post-incident review
- Vendor and third-party risk — inventory, risk tiering, due diligence at onboarding, periodic reassessment
- Human resources security — background screening within legal limits, confidentiality agreements, security awareness training with completion records, offboarding checklist
- Vulnerability management — scanning cadence, remediation SLAs by severity, penetration testing, tracked closure
- Logging and monitoring — centralized logs, alerting on defined conditions, evidence that alerts were reviewed and acted on
- Business continuity and disaster recovery — plans, defined objectives, a test performed and documented
- Physical and environmental security — usually inherited from your cloud provider or data centre and handled through the subservice organization relationship
- Cryptography — encryption in transit and at rest, key management responsibilities
For SOC 2 these map to the trust services criteria. For ISO 27001 they map to Annex A controls recorded in your Statement of Applicability. Same control, two mappings.
The evidence overlaps almost completely
This is where the real saving lives. An access review performed in Q2, signed off by a named manager, with the list of users reviewed and the changes made, is evidence for both. So is a change ticket, a training completion export, a DR test report and a vendor reassessment record.
A few habits make one collection effort serve both:
Keep a single control register. One row per control, with columns for owner, frequency, evidence location, the trust services criteria it supports and the Annex A control it supports. Two mapping columns, one control. Adding a third framework later becomes another column rather than another project.
Date and attribute everything. Both auditors ask the same questions of an artifact: when did this happen, who did it, what did it cover. A screenshot with no timestamp fails for both.
Store evidence where it is generated, not in a compliance folder. Tickets in the ticketing system, reviews in the identity platform, tests in the runbook repository. Copies made specially for an audit go stale and diverge.
Think in populations. A SOC 2 Type 2 needs complete populations to sample from — every change in the period, every joiner and leaver. Being able to produce those lists on demand makes the SOC 2 fieldwork straightforward and answers ISO audit questions faster too.
Where the work genuinely does not overlap
Being clear-eyed here prevents unpleasant surprises in month four.
ISO requires management system machinery that SOC 2 does not. A defined ISMS scope statement. A documented risk assessment methodology applied consistently and repeatably. A risk treatment plan. A Statement of Applicability justifying inclusion or exclusion of each Annex A control. Measurable security objectives. An internal audit programme covering the ISMS. Management review at planned intervals, with records. Corrective action records. None of these are SOC 2 deliverables, although a mature risk assessment and monitoring programme certainly helps you demonstrate the risk assessment and monitoring criteria.
SOC 2 requires a description of the system that ISO does not. Section 3 of a SOC 2 report is a substantial piece of writing describing your services, infrastructure, software, people, procedures and data, plus your complementary user entity controls, your subservice organizations and the method used for them. It is drafted by management, reviewed by the auditor, and it takes longer than first-timers expect. There is no ISO equivalent to reuse.
SOC 2 requires a signed management assertion, and for a Type 2 it requires controls to have operated throughout a defined period with sampleable evidence for the whole window. ISO’s Stage 2 audit assesses the ISMS as implemented; it does not test a period the way a Type 2 does.
SOC 2 may take you beyond security. If you commit to uptime or handle personal data in ways that warrant it, Availability, Confidentiality, Processing Integrity or Privacy add criteria with no direct Annex A analogue.
Sequencing that works
There is no single right order, and the answer usually comes from your buyers rather than from the frameworks.
If a specific deal is blocked, do whichever one that buyer requires and start the other afterwards. Nothing else outranks this.
If neither is urgent and you are starting cold, many teams find it easier to build the ISMS first and run the SOC 2 observation window afterwards, because the ISO work forces the risk assessment, scope definition and control ownership decisions that a SOC 2 assumes you have already made. The certification audit and the Type 2 window can then overlap in time.
If you already hold ISO 27001, your SOC 2 gap is usually not controls — it is the system description, the assertion, mapping your existing controls to the criteria, and confirming you can evidence operation across a period rather than at a point.
If you already have a SOC 2 Type 2, your ISO gap is usually the management system layer: scope, methodology, Statement of Applicability, internal audit and management review. The controls are largely in place.
One scheduling note worth planning around: your ISO surveillance audits and your SOC 2 observation window both recur annually. Setting them so they do not collide with each other, or with your busiest quarter, saves more grief than any tooling decision.
Who can do what for you
Independence rules constrain the combinations. Only a licensed CPA firm can perform the SOC examination and sign the opinion. Certification bodies operate under their own impartiality requirements and generally cannot consult on an ISMS they then certify. And professional independence rules limit what other services your attest firm can provide you — outsourced internal audit, for instance, is an area to raise directly rather than assume.
The practical move is to ask each provider, before engaging: what exactly will you sign, and does anything you are proposing to do for me create a problem for anyone else’s independence. Firms answer this readily, and the answer occasionally reshapes the plan.
What to do next
Take your existing control documentation, whichever framework it was built for, and add one column: the mapping to the other framework. Work down the list and mark the rows you cannot map. That short list of unmapped rows — plus the framework-specific artifacts named above — is a fair first estimate of the additional work.
Then check whether your evidence has dates and owners on it, because that single property determines whether one collection effort can serve two audits. Assurion performs SOC examinations as a licensed CPA firm and supports ISO 27001 and 27701 programmes, and we are glad to look at your existing mapping before you commit to a sequence.