The most expensive way to run SOC 2 and ISO 27001 is as two separate projects. The second most expensive is to run one, finish it, then run the other. The cheapest — and the one almost nobody defaults to — is to run them as a single combined programme that produces two reports from one underlying management system.
This article is the combined-programme plan for the specific case of SOC 2 plus ISO 27001. The general logic applies to most dual-certification efforts, but the specific crosswalk, the sequencing decision, and the audit timing are particular to this pairing. Built for organisations that are already running a SOC 2 Type II programme and now face an ISO 27001 ask from international customers, or — less commonly — organisations starting both frameworks from scratch.
Why both SOC 2 and ISO 27001
Three scenarios produce the dual-framework question. Scenario one: a US SaaS company running SOC 2 picks up European or Asian enterprise customers who ask for ISO 27001 as baseline evidence of security posture. Scenario two: an international company pursuing ISO 27001 expands into the US market and discovers that US buyers treat SOC 2 as the baseline instead. Scenario three, less common but growing: a company preparing to sell into both markets decides to build the certification posture before the customer pipeline demands it.
In all three cases, the honest commercial answer is the same: run both, and run them as one programme. The commercial cost of maintaining two separate compliance postures is substantial. The structural cost of a combined programme is lower than most organisations expect because the control overlap is high and the management system overlap is higher.
The caveat worth flagging up front: SOC 2 and ISO 27001 are structurally different artefacts. SOC 2 is a US attestation report issued by a CPA firm under AICPA standards; ISO 27001 is an international certification issued by an accredited certification body. You cannot merge them into one deliverable. What you can do is run one management system — a single ISMS — that produces evidence for both audits with minimal duplication.
The dual-track programme at a glance
A combined first-time programme at a mid-sized SaaS runs about 14 months. Organisations adding ISO 27001 to an existing mature SOC 2 Type II programme compress to 8–10 months. Running both from scratch with no ISMS foundation extends to 16–18 months.
Phase 1: Scope alignment and planning Months 1–2
Phase 2: Risk assessment + ISO-specific work Months 2–4
Phase 3: Control implementation (shared) Months 3–10
Phase 4: SOC 2 observation + ISO prep Months 6–12
Phase 5: Audit sequencing Months 12–14The defining feature of the shape: Phase 4 runs the SOC 2 observation period (typically 6 months) and the ISO 27001 internal audit and management review in parallel. The evidence your controls produce during the observation period is the evidence the ISO internal audit inspects. One body of work, two audiences.
Trust Services Criteria × Annex A crosswalk
The core asset of the combined programme is a crosswalk mapping SOC 2 Trust Services Criteria to ISO 27001 Annex A controls. Here’s a high-level view:
| SOC 2 TSC | ISO 27001:2022 Annex A overlap | Coverage |
|---|---|---|
| CC1 Control Environment | A.5.1 Policies, A.5.2 Roles, A.6.1–6.3 Human resources | Near-complete overlap |
| CC2 Communication and Information | A.5.1 Policies, A.5.10 Acceptable use, A.5.14 Information transfer | Strong overlap |
| CC3 Risk Assessment | A.5.4 Management responsibilities + ISO 27001 Clause 6.1 | ISO adds formal risk methodology |
| CC4 Monitoring Activities | A.5.29 Disruption continuity, A.5.36 Compliance, A.8.15 Logging, A.8.16 Monitoring | Strong overlap |
| CC5 Control Activities | Spans all of Annex A | Near-complete overlap |
| CC6 Logical and Physical Access | A.5.15–5.19 Access control, A.7.1–7.14 Physical security, A.8.2–8.5 Authentication | Near-complete overlap |
| CC7 System Operations | A.8.6–8.16 Operational controls | Near-complete overlap |
| CC8 Change Management | A.8.32 Change management, A.8.25 Secure development | Near-complete overlap |
| CC9 Risk Mitigation | A.5.7 Threat intelligence, A.5.29 Continuity, A.5.30 ICT readiness | Strong overlap |
| A1 Availability (optional) | A.5.29–5.30 Continuity controls, A.8.13–8.14 Backup/redundancy | Near-complete overlap |
| C1 Confidentiality (optional) | A.5.13 Labelling, A.8.10–8.12 Data management | Near-complete overlap |
| PI1 Processing Integrity (optional) | A.8.29 Security testing, A.8.32 Change management | Partial overlap |
| P1–P8 Privacy (optional) | A.5.34 Privacy, limited otherwise | Partial — GDPR/privacy adds detail |
The pattern worth noticing: SOC 2’s Common Criteria (CC1–CC9) overlap extensively with ISO 27001 Annex A, but ISO 27001 adds structural requirements SOC 2 doesn’t explicitly require — particularly the formal risk methodology, the Statement of Applicability, and the documented management review. These are additive, not conflicting.
The optional SOC 2 criteria (Availability, Confidentiality, Processing Integrity, Privacy) selected based on customer requirements — overlap similarly well with ISO 27001. Privacy is the one where SOC 2’s P1–P8 criteria require GDPR or similar privacy programme work to satisfy fully.
Phase 1: Scope alignment and planning (months 1–2)
Two months to decide what you’re auditing and how the two scopes relate.
Scope alignment. SOC 2 scope is defined by services and by Trust Services Criteria selected. ISO 27001 scope is defined by the ISMS boundary — organisational units, services, information assets. The pragmatic approach: make the ISO 27001 scope match or encompass the SOC 2 scope. Narrower scopes in either direction produce audit findings about the relationship between the two; aligned scopes produce clean reports.
Criteria and control selection. SOC 2 TSC selection drives control requirements for SOC 2. ISO 27001 SoA development selects applicable Annex A controls. Do these in parallel, using the crosswalk. Where a TSC and an Annex A control clearly cover the same territory, a single implementation satisfies both.
Auditor selection — two decisions. SOC 2 auditor (a CPA firm) and ISO 27001 certification body (an accredited CB). These are different entities. Book both in Phase 1. Ask each if they have established relationships or reference patterns with the other — some CPA firms have sister relationships with certification bodies that can reduce coordination overhead.
Integrated management system design. One ISMS covering both audit targets. Single policy suite, single risk register, single internal audit function, single management review. Where SOC 2 or ISO 27001 require specific artefacts (SOC 2 management assertion, ISO 27001 SoA), produce those as outputs from the shared system rather than as standalone work.
Phase 2: Risk assessment plus ISO-specific work (months 2–4)
Two months. SOC 2 doesn’t require a formal risk assessment methodology in the way ISO 27001 does. ISO 27001 Clause 6.1 and Annex A.5.4 demand a documented risk assessment, a documented risk treatment process, and the SoA as the output artefact.
The pragmatic structure: a shared risk assessment that satisfies ISO 27001’s formality requirements and produces findings useful for SOC 2. The output is an ISO-compliant risk register and risk treatment plan, an ISO-compliant SoA, and a risk-based prioritisation of control implementation work that serves both audits. SOC 2 auditors will read the SoA and the risk register too — they’re happy to have them; they’re not required to demand them.
Phase 3: Control implementation (months 3–10)
Seven months overlapping with Phase 2’s tail. Most of the control work is directly shared between the two frameworks. Genuine gaps concentrate in four areas:
Formal documentation. SOC 2 tolerates informal processes if they operate effectively; ISO 27001 requires documented procedures. If you’re coming from a light-documentation SOC 2 culture, expect to produce substantially more written policy and procedure in Phase 3.
Physical security. ISO 27001 Annex A.7 is a full set of 14 physical controls. SOC 2 Security-only scope often under-emphasises physical controls where cloud-native organisations inherit them from providers. Document the shared responsibility boundary and the residual controls you’re running.
Cryptography management. ISO 27001 A.8.24 requires documented cryptography policies, key management processes, and cryptographic suite lifecycle management. SOC 2 cares about encryption but doesn’t formalise cryptography management to the same level.
Secure development. ISO 27001 A.8.25–8.32 cover a structured set of secure development requirements. Well-run SOC 2 programmes cover most of this territory but may not document it in the structured way ISO 27001 expects.
Phase 4: SOC 2 observation period plus ISO audit prep (months 6–12)
The key structural decision: run the SOC 2 observation period and the ISO 27001 internal audit in parallel. Six months of observation running from month 6 to month 12, with the internal audit landing late in that window (say month 11), followed by management review in month 12.
The evidence the observation period generates feeds the internal audit directly. The internal audit findings feed both the SOC 2 fieldwork preparation and the ISO 27001 Stage 1 preparation. The management review at month 12 is an ISO 27001 artefact but nothing prevents the SOC 2 auditor from reading it as evidence of governance maturity.
Phase 5: Audit sequencing (months 12–14)
Two months for the certification events. Two reasonable sequencing options:
Option A: ISO 27001 Stage 1 and Stage 2 before SOC 2 fieldwork. Advantages: ISO certification issues before the SOC 2 report, giving you the international-market credential first. Fits if ISO 27001 is the commercially higher-value artefact. Disadvantages: the team is running ISO audits while completing SOC 2 observation evidence.
Option B: SOC 2 fieldwork first, then ISO 27001 Stage 1 and Stage 2. Advantages: SOC 2 report ships promptly at the end of the observation period; ISO 27001 audits can draw on the fresh evidence body and the recent management review. Fits if SOC 2 is commercially higher-value or if the US market is the primary channel. Disadvantages: ISO 27001 certification arrives later.
The sequencing decision is commercial, not structural. Both orderings work. What matters is committing to an order in Phase 1 and sequencing subsequent work around it, not pretending the sequencing is an operational detail to decide in Phase 4.
Where combined programmes trip up
Four failure patterns specific to the SOC 2 + ISO 27001 combination.
SOC 2 habit applied to ISO 27001 documentation. Teams familiar with SOC 2’s “evidence beats documentation” culture under-invest in ISO 27001’s documented-process requirements. The internal audit or Stage 1 finds the documentation gaps late. Mitigation: treat documentation as a first-class Phase 3 workstream, not a Phase 4 deliverable.
Scope boundaries that aren’t truly aligned. SOC 2 scope and ISO 27001 scope drift apart in small ways — a service included in one and not the other, a business unit in scope differently, a system included differently. Mitigation: define scope explicitly for both in Phase 1 with documented intersection mapping.
Risk assessment done once for ISO 27001 and ignored for SOC 2. SOC 2 auditors will read a good risk register with interest; teams sometimes produce an ISO-compliant risk assessment and then don’t reference it in SOC 2 preparation, missing an easy credibility signal. Mitigation: treat the risk register as a first-class programme artefact referenced in both audits.
Internal audit and management review scoped too narrowly. The internal audit covers ISO 27001 only; the management review covers ISO 27001 only. Both could meaningfully cover the combined programme — and should, because the underlying management system is combined. Mitigation: scope internal audit and management review to cover the ISMS as a whole, including any SOC 2-specific artefacts.
FAQ
Should I do SOC 2 or ISO 27001 first?
Depends on your market. If your revenue is US-centric, SOC 2 is usually the higher-priority first certification. If international or EU revenue is material, ISO 27001 often takes precedence. Running them as a combined programme from the start is more efficient than sequential certification regardless of order.
How much does a combined SOC 2 + ISO 27001 programme cost?
For a mid-sized SaaS with no existing compliance posture, combined first-year programme costs typically run $75,000–$200,000 (auditor fees, certification body fees, consulting where used, internal effort) — roughly 65–75% of the cost of running both separately.
Are SOC 2 and ISO 27001 recognised equivalently by customers?
Not interchangeably. Enterprise buyers increasingly want both: SOC 2 as the US-market baseline and ISO 27001 as the international baseline. Some customers accept one as evidence of the other; many don’t. Check with your specific customer base before assuming substitutability.
Can the same auditor do both?
No — SOC 2 is attested by a CPA firm, ISO 27001 is certified by an accredited certification body. These are different entities under different regulatory regimes. Some firms have both capabilities under one roof, which can reduce coordination overhead but doesn’t make the audits mergeable.
What is the Trust Services Criteria × Annex A crosswalk?
A mapping between SOC 2’s Trust Services Criteria and ISO 27001:2022’s Annex A controls, showing where a single control implementation satisfies both frameworks. It’s the core reference artefact for any combined programme.
Can I use one control implementation for both audits?
Yes, for most controls. The crosswalk identifies where controls map across frameworks. Where the mapping is clean, a single control implementation with evidence collected once satisfies both. Where the mapping is partial (e.g., ISO 27001 adds formality ISO specifically expects), the control needs the extra structure to satisfy ISO 27001.
Does SOC 2 have a Statement of Applicability?
No. SOC 2’s equivalent is the management’s description of the service organisation’s system, which identifies which TSCs apply and how controls address them. Looser in structure than the ISO SoA but serves a related purpose.
Do I need to do the SOC 2 observation period and ISO Stage 2 in the same quarter?
No, and usually shouldn’t. Stagger them so your team isn’t simultaneously producing observation-period evidence and Stage 2 audit evidence. Most combined programmes run SOC 2 observation through months 6–12, ISO internal audit at month 11, and ISO Stage 2 at month 13–14.
How does ISO 42001 fit in?
If your organisation has AI systems material to the product, ISO 42001 layers on top. The underlying ISMS supports all three programmes (SOC 2, ISO 27001, ISO 42001). See the ISO 27001 + ISO 42001 combined programme guide for the triple-framework logic.
What if a customer only wants SOC 2?
Run SOC 2 only. Don’t pursue ISO 27001 purely on speculation. The combined programme is efficient when you need both; running ISO 27001 for its own sake without customer demand is expensive.