Two Auditors, One Company, and a $3.2 Million Renewal Sitting on Hold
Priya Anand had two browser tabs open that she'd learned to dread. One was the portal for Corvanta Systems' ISO 27001 certification body, flagging seven pieces of missing evidence ahead of the upcoming Stage 2 audit. The other was the evidence request list from the CPA firm running Corvanta's SOC 2 Type II examination, flagging nine pieces of missing evidence for the same six-month period. Four of the sixteen items were, as far as Priya could tell, asking for exactly the same thing — a screenshot of MFA enforcement in the identity provider, a signed quarterly access review, a change-log export — just formatted for two auditors who had never spoken to each other.
Corvanta Systems builds workforce-scheduling software for hospital networks and logistics companies. Two years earlier, a single SOC 2 Type II report had been enough to close deals. Then a $3.2 million renewal with a European logistics group came up for its annual security review, and procurement asked a new question: was Corvanta ISO 27001 certified? Meanwhile the company's US-based enterprise customers still wanted the SOC 2 report every renewal cycle without exception. The path Corvanta took, for a while, was to run two entirely separate compliance tracks — different consultants, different spreadsheets, different evidence folders, and, inevitably, different answers to what should have been the same question about the same control.
By the time Priya added it up, Corvanta was paying for two risk assessments that covered the same assets, two access-review cycles pulling the same user list, two vendor-security questionnaire processes built from two different templates, and roughly 640 hours a year of internal staff time split across two audit-preparation cycles that overlapped by more than 80% in substance. The certification body and the CPA firm were, in effect, independently re-verifying the same control environment through two different lenses — one built around a certifiable management system, the other built around an attestation over a period of time.
What changed the trajectory wasn't a new tool or a bigger budget. It was a decision to stop treating ISO 27001 and SOC 2 as two programs and start treating them as two outputs of one control environment. Corvanta rebuilt its compliance program around a single shared control set — one policy library, one risk register, one evidence repository, one control owner per control area — and mapped that shared set forward into both the ISO 27001 Annex A structure and the SOC 2 Trust Services Criteria. The Stage 2 audit and the SOC 2 Type II examination still happened separately, run by different independent parties for good reason, but the preparation work collapsed from two tracks into one. Nineteen months later, Corvanta held both an ISO 27001 certificate and a clean SOC 2 Type II report, and Priya's team was spending roughly 40% fewer hours a year maintaining both than it had spent maintaining SOC 2 alone the year before.
This article is about how to build that shared control set — not as a theoretical alignment exercise, but as an operating model: what to combine, what has to stay separate, how to map Annex A to the Trust Services Criteria in practice, how to sequence the two audits, and where companies most often waste money running "two programs that happen to overlap" instead of one program that produces two outputs.
Who This Is For (and What You'll Walk Away With)
This is written for security, compliance, and GRC leaders — usually at SaaS or technology-enabled service companies — who have already concluded they need both ISO 27001 certification and a SOC 2 report, typically because they serve both US enterprise buyers (who default to asking for SOC 2) and international, regulated, or public-sector buyers (who default to asking for ISO 27001). It assumes you've made the "do we need both" decision already; if you haven't, that's an earlier conversation. What you'll walk away with here is a practical shared-control-set model, a working map between Annex A controls and the SOC 2 Trust Services Criteria, a combined evidence and audit strategy, and a sequencing plan for running the two audit tracks without duplicating most of the underlying work.
One thing this article will not do is claim the two frameworks are the same thing wearing different labels. They're not. ISO 27001 is a certifiable management system standard — Clauses 4 through 10 plus 93 Annex A controls — audited and certified by an accredited certification body, valid for three years with annual surveillance audits. SOC 2 is an attestation engagement: a licensed CPA firm examines your controls against the AICPA's Trust Services Criteria and issues an opinion (a report, not a certificate) covering either a point in time or a period of time — Type I versus Type II, typically three to twelve months for a Type II examination. A shared control set makes both efficient to run side by side. (If any of the terminology in this article is unfamiliar, ISO 27001 Terminology and Glossary: Key Terms Every Practitioner Should Know is worth keeping open alongside it — this piece assumes familiarity with core ISMS vocabulary.) It does not make them interchangeable, and you still need ISO's management-system elements — risk assessment methodology, Statement of Applicability, internal audit programme, management review — that SOC 2 simply does not require, plus SOC 2's period-of-time evidence model that ISO does not require.
Why Companies End Up Needing Both
The pattern that puts a company in Priya's position is remarkably consistent across the SaaS companies I've worked with. It usually starts with SOC 2, because that's the report US enterprise security teams default to asking for during vendor due diligence — it's comparatively fast to obtain, familiar to US procurement and legal teams, and doesn't require the multi-year management-system maturity ISO 27001 implicitly expects. Then the company starts closing deals with European, Middle Eastern, or Asia-Pacific customers, or with public-sector and regulated buyers almost anywhere, and those buyers ask for something SOC 2 doesn't provide: an internationally recognized, accredited third-party certification against a globally adopted standard. ISO 27001 fills that gap in a way a SOC 2 report — which is, by AICPA design, a restricted-use report intended for a specific audience of existing and prospective customers who understand its scope — often can't.
The reverse pattern happens too. Companies that build their ISMS first, usually because a European parent company or an early enterprise EU customer required certification, later find that a US-based investor, acquirer, or hyperscale cloud marketplace listing wants a SOC 2 report specifically, because that's what US audit committees and security teams are trained to evaluate. Cloud marketplaces in particular frequently expect a SOC 2 report as part of certain listing tiers, independent of what other certifications a vendor already holds.
Either direction, the business case is the same: sales velocity. A missing SOC 2 report stalls US enterprise deals in security review. A missing ISO 27001 certificate stalls international and regulated deals in procurement. Companies selling into both markets eventually need both, and the cost of not having both shows up as slipped close dates and lost competitive deals rather than as a line item anyone budgets for upfront.
Trigger | Which Framework Gets Requested First | Typical Follow-On Need |
|---|---|---|
US enterprise security review (SaaS, fintech, healthtech) | SOC 2 Type II | ISO 27001 as the company expands internationally |
EU, UK, or APAC enterprise procurement | ISO 27001 certification | SOC 2 as the company grows its US enterprise pipeline |
Cloud marketplace listing (major hyperscalers) | SOC 2 Type II (often a listing prerequisite) | ISO 27001 for government or regulated marketplace tiers |
Public sector or government-adjacent contracts | ISO 27001 (or a national derivative) | SOC 2 if the buyer also has US commercial operations |
Private equity or acquisition due diligence | Either, depending on the acquirer's home market | The other, once integration planning starts |
Parent company or investor mandate | Whichever the parent/investor's home market defaults to | The other, driven by the subsidiary's own customer base |
For a deeper look at the decision itself — including when one framework alone is genuinely sufficient — see ISO 27001 vs SOC 2: Which One Do You Need? and the broader comparison in ISO 27001 vs Other Security Frameworks: NIST, SOC 2, and PCI DSS Compared. This article picks up from "we're doing both" and focuses entirely on how to execute that efficiently. If your company is specifically a SaaS business, the implementation nuances are covered in ISO 27001 for SaaS Companies: A Practical Implementation Guide, and once you're ready to go a layer deeper on control mapping across a third framework, ISO 27001, SOC 2 & NIST CSF Crosswalk: Control Mapping Guide extends the same logic used here.
"The mistake I see most often isn't choosing the wrong framework — it's building two compliance programs when the underlying control environment is 85% identical. You end up paying twice for the same access review, just formatted two different ways." — Priya Anand, Head of Trust & Security, Corvanta Systems
Where ISO 27001 and SOC 2 Overlap — and Where They Genuinely Diverge
The overlap between ISO 27001's Annex A controls and the SOC 2 Trust Services Criteria is substantial enough that most of the technical and operational controls — access control, encryption, logging, vulnerability management, change management, incident response, vendor risk — can be designed, operated, and evidenced once and mapped to both frameworks. The divergence is concentrated almost entirely in the management-system layer that ISO requires and SOC 2 doesn't, and in the attestation mechanics that SOC 2 requires and ISO doesn't.
Dimension | ISO 27001 | SOC 2 | Shared or Distinct |
|---|---|---|---|
What it is | Certifiable management system standard (ISO/IEC 27001:2022) | Attestation engagement under AICPA standards | Distinct legal/structural nature |
Governing body | International Organization for Standardization | American Institute of CPAs (AICPA) | Distinct |
Who performs the assessment | Accredited certification body (CB) — trained auditors | Licensed CPA firm | Distinct |
Output | Certificate, valid 3 years, annual surveillance audits | Report with CPA opinion (Type I or Type II) | Distinct |
Scope structure | Clauses 4–10 (management system) + Annex A (93 controls, applicability via SoA) | Trust Services Criteria — Security (mandatory) plus optional Availability, Confidentiality, Processing Integrity, Privacy | Different structures, heavy content overlap |
Risk assessment methodology | Formal, documented, repeatable risk assessment and treatment plan required | Risk assessment expected (CC3) but methodology not prescribed | Shared underlying activity, different documentation depth |
Access control, encryption, logging, vulnerability mgmt, malware, backup, SDLC | Explicit Annex A controls (5.x, 8.x) | Covered under CC6–CC9 and category-specific criteria | Heavily shared |
Policy and awareness requirements | Explicit (5.1 policies, 6.3 awareness) | Covered under CC1–CC2 | Heavily shared |
Internal audit program | Mandatory (Clause 9.2) | Not required by SOC 2 itself (though often run anyway) | ISO-specific |
Management review | Mandatory (Clause 9.3) | Not required | ISO-specific |
Statement of Applicability | Mandatory deliverable | No equivalent | ISO-specific |
Evidence period | Point-in-time at Stage 2, then annual surveillance | Type I: point in time. Type II: continuous evidence over 3–12 months | SOC 2 Type II demands deeper time-series evidence |
Report/certificate audience | Public-facing (certificate can be broadly shared or marketed) | Restricted-use report (shared under NDA with specific parties) | Distinct distribution model |
Renewal cycle | 3-year certification, annual surveillance audits | New engagement each period (typically annual) | Distinct cadence |
The practical takeaway: don't try to force a single audit or a single deliverable. Try to force a single evidence base that both auditors draw from.
The Shared Control Set: A Different Way to Think About Compliance
The core idea is simple to state and harder to execute: instead of building "an ISO 27001 program" and "a SOC 2 program" as two separate initiatives with separate policy sets, separate risk registers, and separate evidence trackers, you build one control environment — a shared control set — and then map that environment outward into two compliance outputs. The control set answers "how do we actually run security here." The mapping layer answers "how does that map to what our certification body wants to see" and "how does that map to what our SOC 2 auditor wants to see," independently, without changing how the underlying control operates.
Concretely, a shared control set usually consists of:
One policy library covering information security, access control, acceptable use, incident response, business continuity, vendor risk, secure development, and so on — written once, then cross-referenced (not duplicated) into both an Annex A structure and a Trust Services Criteria structure.
One risk register and risk assessment methodology, satisfying ISO's Clause 6 requirement for a documented, repeatable process, and simultaneously providing the risk assessment evidence SOC 2's CC3 criteria expect — even though SOC 2 doesn't mandate the same methodology.
One control inventory, where each control has a single owner, a single description of how it operates, and a single evidence-collection cadence, tagged to both the relevant Annex A control number(s) and the relevant Trust Services Criteria.
One evidence repository, ideally in a GRC or compliance automation platform, where a piece of evidence (an access review, a penetration test report, a change ticket) is captured once and tagged to every framework requirement it satisfies.
One internal audit and testing calendar that produces evidence usable by both the ISO internal audit program and as ongoing control-testing evidence for the SOC 2 examination period.
What stays separate, deliberately: the ISO Statement of Applicability, the ISO management review minutes, the SOC 2 system description, the CPA firm's testing workpapers, and — critically — the two independent audits themselves. You are not trying to merge the audits into one; you're trying to make sure both audits draw from the same well.
Building the Shared Control Set: A Five-Step Approach
Step 1 — Inventory both frameworks' requirements side by side. Before touching a single policy, lay out the full Annex A control list next to the full Trust Services Criteria list (Security/Common Criteria plus whichever optional categories apply — most SaaS companies pursue Security plus Availability, sometimes Confidentiality). This is the mapping exercise covered in detail in the next section, and it's the single highest-leverage hour you'll spend on this project.
Step 2 — Design controls at the strictest common denominator. Where ISO and SOC 2 both touch a control area but one framework expects more (say, ISO's explicit documented-procedure expectation under 5.37 versus SOC 2's less prescriptive documentation norms), design the control to meet the stricter requirement once. It costs almost nothing extra to document a procedure thoroughly if you were going to run it anyway, and it eliminates the need for a "light" version and a "heavy" version of the same control.
Step 3 — Assign one control owner per control, not one per framework. The single most common structural mistake is having an "ISO control owner" and a "SOC 2 control owner" for the same underlying activity — for example, two different people responsible for evidencing quarterly access reviews to two different auditors. Collapse this to one owner who understands both frameworks care about the same evidence and produces it once.
Step 4 — Build the evidence repository around control activity, not around audit requests. Evidence should be collected on a cadence driven by how often the control actually needs to be verified (monthly access reviews, quarterly vendor risk reviews, continuous vulnerability scanning), tagged to both frameworks at the point of collection, not reconstructed retroactively when an auditor asks for it.
Step 5 — Run one internal governance cadence. A single steering committee and a single risk-treatment tracking process should feed both the ISO management review (Clause 9.3, mandatory) and whatever governance evidence the SOC 2 auditor expects to see under CC1 and CC4. You are not required to hold two separate governance meetings just because you're pursuing two frameworks.
"We stopped asking 'what does ISO need' and 'what does SOC 2 need' as two separate questions. We started asking 'what does this control actually require to operate well,' and then mapped the answer to both frameworks after the fact. It sounds obvious in hindsight, but almost nobody builds it that way from the start." — David Okoye, Lead Consultant, Meridian Assurance Partners
Mapping Annex A to the SOC 2 Trust Services Criteria
This is the piece most teams either skip or half-do, and it's the foundation everything else in this article depends on. If you need the full breakdown of how the SOC 2 Trust Services Criteria are structured before diving into the mapping, it's worth a detour first. In short: they're organized very differently from Annex A — around COSO-aligned Common Criteria (CC1–CC9, mandatory for every SOC 2 engagement because "Security" is a required category) plus optional category-specific criteria for Availability, Confidentiality, Processing Integrity, and Privacy. Annex A is organized around four control themes — Organizational, People, Physical, Technological — with no direct COSO lineage. The mapping between them is many-to-many, not one-to-one: a single Annex A control often supports several Common Criteria, and a single Common Criterion is often satisfied by evidence drawn from several Annex A controls.
Start with the quick-reference view, then work down into the detailed control-level mapping.
Quick Reference: Annex A Theme to Primary TSC Alignment
Annex A Theme | # of Controls | Primary TSC Alignment | Notes |
|---|---|---|---|
A.5 Organizational (5.1–5.37) | 37 | CC1, CC2, CC5, CC9 | Policy, governance, supplier, and incident-management controls map broadly across the Common Criteria |
A.6 People (6.1–6.8) | 8 | CC1.4, CC1.5 | Screening, training, and termination controls sit under the "control environment" criteria |
A.7 Physical (7.1–7.14) | 14 | CC6.4, CC6.5 | Physical access and equipment controls map into the logical-and-physical-access criterion family |
A.8 Technological (8.1–8.34) | 34 | CC6, CC7, CC8, plus A1 / C1 / PI1 where applicable | The largest and most technically detailed overlap zone |
Common Criteria (CC1–CC9) Mapped to Annex A Controls
SOC 2 Common Criterion | Focus Area | Primary Mapped Annex A Controls | Related ISO Clause | Shared Evidence Artifact |
|---|---|---|---|---|
CC1 — Control Environment | Tone at the top, integrity, org structure, competence, accountability | 5.1, 5.2, 5.3, 5.4, 6.1, 6.2, 6.4 | Clause 5 (Leadership) | Org chart, security policy sign-off, HR screening records |
CC2 — Communication & Information | Internal/external communication of security objectives and responsibilities | 5.1, 5.36, 6.3, 6.8 | Clause 7 (Support) | Policy distribution records, awareness training completion logs |
CC3 — Risk Assessment | Identification and analysis of risk to objectives | Clause 6 risk assessment process, 5.7 | Clause 6 (Planning) | Risk register, risk assessment methodology document |
CC4 — Monitoring Activities | Ongoing evaluation of control effectiveness | 5.35, 8.16, Clause 9 internal audit | Clause 9 (Performance Evaluation) | Internal audit reports, management review minutes |
CC5 — Control Activities | Policies and procedures that mitigate risk | 5.1, 5.3, 8.32 | Clause 8 (Operation) | Approved policy set, segregation-of-duties matrix |
CC6 — Logical and Physical Access Controls | Identity, authentication, authorization, physical entry | 5.15–5.18, 8.1–8.5, 7.1–7.6 | Annex A themes 5, 7, 8 | Access review exports, MFA configuration screenshots, badge logs |
CC7 — System Operations | Detection and response to processing deviations/incidents | 5.24–5.28, 8.7, 8.8, 8.15, 8.16 | Annex A theme 8 | SIEM alert logs, incident tickets, vulnerability scan reports |
CC8 — Change Management | Authorized, tested, documented changes | 8.32, 8.25–8.31 | Annex A theme 8 | Change tickets, CAB approval records, deployment logs |
CC9 — Risk Mitigation | Vendor risk and business disruption mitigation | 5.19–5.23, 5.29, 5.30 | Annex A theme 5 | Vendor risk assessments, BC/DR test results |
Category-Specific Criteria Mapped to Annex A Controls
Beyond the mandatory Common Criteria, most SaaS companies also pursue one or more optional TSC categories. These map cleanly to specific Annex A control clusters:
SOC 2 Category | Focus | Primary Mapped Annex A Controls | Shared Evidence Artifact |
|---|---|---|---|
Availability (A1) | System uptime, capacity, recovery commitments | 5.29, 5.30, 8.6, 8.13, 8.14 | Capacity monitoring dashboards, backup test logs, DR test reports |
Confidentiality (C1) | Protection of information designated confidential | 5.12, 5.13, 5.14, 8.10, 8.11, 8.12, 8.24 | Data classification schema, encryption configuration, DLP alerts |
Processing Integrity (PI1) | Complete, accurate, timely, authorized processing | 8.25–8.29, 8.32, 8.33 | SDLC testing records, QA sign-offs, change validation logs |
Privacy (P1–P8) | Collection, use, retention, and disposal of personal information | 5.34, 8.10 | Privacy notice, data retention schedule, deletion records |
Not every company pursuing SOC 2 needs every optional category — Availability is common for SaaS, Confidentiality is common where customer data sensitivity is high, and Privacy is comparatively rare as a standalone TSC category (most companies handle privacy through separate regulatory work rather than a SOC 2 Privacy examination). Scope the categories you actually need against real customer requirements, not against what looks most complete on paper — every additional category adds testing scope and cost to the SOC 2 engagement.
Where the Mapping Breaks Down
A control-level map is a planning tool, not a guarantee. Three limits matter in practice. First, the mapping is directional guidance, not a certified crosswalk — no official body publishes a binding Annex A-to-TSC translation table, so any mapping (including the one above) reflects practitioner judgment about where the substance of a control overlaps, and your certification body and CPA firm may draw the lines slightly differently. Second, "mapped" doesn't mean "automatically satisfied for both" — an Annex A control can be marked "implemented" in your SoA based on a policy and a point-in-time check, while the same control area under SOC 2 Type II requires you to prove it operated consistently for the entire examination period; the underlying control might be identical, but the evidence bar for SOC 2 Type II is usually higher because it's about operating effectiveness over time, not existence. Third, some ISO requirements have no TSC analog at all (the Statement of Applicability, formal management review, the internal audit programme) and some SOC 2 mechanics have no ISO analog (period selection, sampling, complementary user entity controls). Treat the map as the 80% that's genuinely shared, and treat the sections below as the 20% you still have to build twice, differently, on purpose.
Mapping Limitation | Practical Implication |
|---|---|
No official binding crosswalk exists | Your CB and CPA firm may interpret control boundaries differently — confirm early, don't assume |
Many-to-many, not one-to-one | A single evidence artifact often supports multiple criteria on both sides; a single Annex A control may need several artifacts |
Different evidence depth (point-in-time vs. period-of-time) | Meeting the Annex A control on paper does not automatically satisfy SOC 2 Type II operating-effectiveness testing |
Some requirements have no counterpart | Budget separate effort for ISO-only (SoA, management review) and SOC 2-only (period evidence, sampling) work |
Shared Evidence and How to Operate Controls Once
Mapping controls on paper is the easy half. The harder half is changing how evidence actually gets collected so that a single artifact serves both audits without anyone doing the work twice. The habit to build is tagging evidence at the moment it's created, not reconstructing it retroactively when an auditor asks. A quarterly access review, for example, should be run once, on one cadence, by one owner — and the resulting export should be filed with metadata noting it satisfies Annex A 5.18 (Access rights) and 8.2 (Privileged access rights) for the ISO side, and CC6.1–CC6.3 for the SOC 2 side, at the point the review is completed.
Most compliance automation platforms now support this natively — a single "evidence" object with multiple framework tags attached — but the underlying discipline matters more than the tool. Even a well-organized shared drive with a consistent tagging convention beats a sophisticated platform used to run two separate, untagged evidence folders.
Control Activity | Recommended Cadence | Owner | ISO Evidence Use | SOC 2 Evidence Use |
|---|---|---|---|---|
User access review | Quarterly | IT/Security Ops | Supports 5.18, 8.2, 8.3 | Supports CC6.1–CC6.3, tested across the full examination period |
Vulnerability scanning | Continuous / weekly | Security Engineering | Supports 8.8 | Supports CC7.1, sampled across the period |
Vendor risk assessment | Annually per vendor, on onboarding | Vendor Management/Procurement | Supports 5.19–5.22 | Supports CC9.2 |
Change management approval | Per change | Engineering/Change Manager | Supports 8.32 | Supports CC8.1, sampled across the period |
Security awareness training | Annually + on hire | People Ops/Security | Supports 6.3 | Supports CC1.4, CC2.2 |
Incident response test/tabletop | Annually | Security/IR Lead | Supports 5.24–5.28 | Supports CC7.3–CC7.5 |
Backup restoration test | Quarterly | Infrastructure | Supports 8.13 | Supports A1.2, sampled across the period |
Penetration test | Annually | Security, external vendor | Supports 8.8, 8.29 | Supports CC4.1, CC7.1 |
Risk register review | Quarterly | Risk Owner/CISO | Supports Clause 6, 5.7 | Supports CC3.1–CC3.4 |
Management/security review meeting | Quarterly | Leadership | Supports Clause 9.3 (mandatory) | Supports CC1.2, CC4.2 (evidence of oversight) |
The most important operational shift is cadence design. ISO's Stage 2 audit is largely a point-in-time check of whether the ISMS is designed and operating — the certification body wants to see that the process exists, runs, and produced a recent result. SOC 2 Type II wants to see that same control operating consistently across the entire examination window, typically sampled at multiple points. If you only run a control once a year to satisfy ISO's annual surveillance cadence, that same control will almost certainly fail SOC 2 Type II sampling, which expects to see it operating on a schedule the auditor can test — monthly or quarterly, not annually. Design cadence for the more demanding of the two frameworks, and both audits get satisfied by the same operational rhythm.
"SOC 2 Type II auditors don't take your word for it — they sample. If your access review happened once, six months ago, that's a design check, not an operating-effectiveness check. Build the cadence for sampling from day one and ISO's annual expectations take care of themselves." — Sana Patel, SOC 2 Engagement Partner, Whitcombe & Reyes CPAs
What ISO 27001 Still Needs That SOC 2 Doesn't
However well you unify the underlying control set, ISO 27001 carries a set of management-system obligations that have no SOC 2 equivalent at all. These aren't optional extras — they're mandatory clauses under ISO/IEC 27001:2022, and skipping them (because "SOC 2 doesn't ask for this") is the single fastest way to fail a Stage 1 or Stage 2 audit even when your technical controls are excellent.
ISO-Only Requirement | Clause | Why SOC 2 Doesn't Require It |
|---|---|---|
Context of the organization (internal/external issues, interested parties) | Clause 4 | SOC 2 scopes to a system description, not an organizational context analysis |
Documented ISMS scope statement | Clause 4.3 | SOC 2 defines scope via the system description and TSC category selection, not a formal scope document |
Formal risk assessment methodology and risk treatment plan | Clause 6.1, 6.2 | SOC 2's CC3 expects risk assessment activity but doesn't prescribe a documented methodology |
Statement of Applicability (SoA) | Clause 6.1.3(d) | No equivalent deliverable exists under the AICPA framework |
Resource, competence, and awareness records tied to the ISMS | Clause 7 | SOC 2 expects training evidence under CC1/CC2 but not a formal competence-management system |
Internal audit programme | Clause 9.2 | Not a SOC 2 requirement (though many companies run one anyway as good practice) |
Management review, with defined inputs/outputs | Clause 9.3 | No equivalent mandatory forum under SOC 2 |
Nonconformity and corrective action process | Clause 10.1 | SOC 2 identifies exceptions in the report; it doesn't mandate a formal CAPA system |
If you want the full detail on any of these, the Statement of Applicability process is covered in ISO 27001 Statement of Applicability (SoA): How to Create One, and the internal audit programme is covered in ISO 27001 Internal Audit: Planning, Execution, and Reporting. Both are worth building even if you were SOC 2-only, because they're the mechanisms that catch control drift before an external auditor does — but under ISO 27001 they are not optional.
What SOC 2 Still Needs That ISO Doesn't
The reverse is equally true. A company that has only ever run ISO 27001 tends to underestimate how different the SOC 2 attestation mechanics are, even when the underlying controls are identical.
SOC 2-Only Requirement | Why ISO Doesn't Require It |
|---|---|
Engagement with a licensed CPA firm | ISO uses an accredited certification body, not a CPA firm — different qualification, different governing body |
Selection of a Type I vs. Type II report | ISO has no point-in-time/period-of-time report distinction — Stage 2 is effectively a design-and-implementation check, with ongoing operation verified through annual surveillance |
Definition of the examination period (typically 3–12 months for Type II) | ISO's certification cycle is a fixed 3-year period with annual surveillance, not a selectable window |
System description, written and asserted by management | ISO has no equivalent narrative document describing the system for an external audience |
Sampling methodology across the examination period | ISO auditors sample too, but SOC 2's period-of-time testing model is built around statistically defensible sampling across months, not a single audit visit |
Complementary User Entity Controls (CUECs) | ISO has no formal concept of controls the customer must operate for the vendor's controls to be effective |
Trust Services Criteria category selection (Security plus optional categories) | ISO's scope is set by the SoA and applicability decisions, not by selecting from a fixed criteria menu |
A restricted-use report rather than a public certificate | ISO certificates are commonly published/marketed; SOC 2 reports are shared under NDA with specific parties |
Neither list is a reason to avoid running both — they're the reason a shared control set still needs two distinct project tracks layered on top of it. The efficiency gain is in the 80% that's genuinely common; the remaining 20% on each side simply has to be planned, staffed, and budgeted as framework-specific work.
Sequencing: Which Framework Do You Build First?
There's no universally correct order — it depends on which framework a live deal is blocking, how mature your control environment already is, and how much internal bandwidth you have. But the three common sequencing strategies have distinct trade-offs worth naming explicitly before you pick one.
Sequencing Strategy | How It Works | Best For | Trade-off |
|---|---|---|---|
SOC 2 first, ISO second | Stand up SOC 2 Type I quickly (often 2–4 months), convert to Type II after a 6–12 month observation period, then layer ISO's management-system clauses on top of the now-mature control set | Companies where a near-term US deal is blocked on SOC 2 | ISO's management-system elements (SoA, internal audit, management review) get built late, sometimes rushed |
ISO first, SOC 2 second | Build the full ISMS, complete Stage 1 and Stage 2, then map the resulting mature control set into the TSC and run SOC 2 Type I followed by Type II | Companies where an international/regulated deal is the near-term driver, or where a parent company mandates ISO first | SOC 2 report takes longer to obtain because ISO's typical timeline is longer end-to-end |
Parallel build, staggered audits | Build the shared control set once, targeting both frameworks' requirements simultaneously; run SOC 2 Type I and ISO Stage 1 close together, then Type II and Stage 2 on a coordinated (not identical) calendar | Companies with real bandwidth and a shared-control mindset from day one — usually the most efficient long-term, hardest to execute under deal pressure | Requires more upfront planning discipline; harder to compress if a single deal creates urgency for just one framework |
In practice, most companies in Priya's position land on a variant of "SOC 2 first, ISO second" simply because SOC 2 Type I can be obtained faster and unblocks near-term US revenue, while the ISO certification timeline — typically nine to eighteen months from kickoff to certificate, depending on company size and existing maturity — gets built in parallel once the SOC 2 track is stable. The trap to avoid is treating SOC 2 as "done" and only then starting to think about ISO's management-system requirements from scratch; if you built the shared control set correctly from Step 1, the ISO-specific layer (SoA, risk treatment plan, internal audit programme, management review) is additive work on an existing foundation, not a second full program.
Can You Combine the Audits Themselves?
No — and it's worth being direct about this, because "combined audit" is a phrase that gets thrown around loosely. The ISO 27001 Stage 1/Stage 2 audit and the SOC 2 examination are legally and procedurally distinct engagements, run by different types of independent parties (an accredited certification body versus a licensed CPA firm), governed by different standards bodies, and producing different deliverables. You cannot have one auditor issue both an ISO certificate and a SOC 2 opinion in a single engagement, and you should be skeptical of any vendor who implies otherwise.
What you can combine is everything up to the audit itself: the readiness assessment, the gap analysis, the evidence collection, and — with careful calendar planning — the scheduling of the two audits close enough together that you're not re-entering "audit mode" twice a year. Some certification bodies and CPA firms are part of the same larger professional services group and can coordinate scheduling and even share a lead point of contact on your side, but the audits remain separate reports with separate scopes, separate opinions, and separate fee structures. Budget and staff them as two audits that happen to draw from one evidence base — not as one audit with two names.
A Sample 18-Month Combined Program Timeline
Phase | Months | ISO 27001 Milestone | SOC 2 Milestone | Shared Work |
|---|---|---|---|---|
Foundation | 1–3 | Scope definition, gap analysis | TSC category selection, readiness assessment | Shared control inventory built, policy library drafted |
Build | 3–7 | Risk assessment, SoA v1, policy rollout | Control design finalized, system description drafted | Shared risk register, shared evidence repository stood up |
Operate & Evidence | 6–12 | Internal audit #1, management review #1 | Type I readiness check, evidence collection begins for Type II window | Access reviews, vulnerability scans, change logs collected on shared cadence |
Pre-Audit | 9–12 | Stage 1 audit | SOC 2 Type I engagement and report issued | Consolidated evidence package assembled |
Certification/Attestation | 12–15 | Stage 2 audit → certificate issued | Type II examination period continues (3–12 months) | Shared corrective-action tracking for any findings |
Sustain | 15–18+ | First surveillance audit prep | Type II report issued | Continuous monitoring, unified governance cadence |
Your actual timeline will compress or stretch based on company size, existing control maturity, and how much of the shared control set was already in place before you started — but the sequencing logic (build the shared foundation first, then layer framework-specific deliverables, then let the audits run on their own independent clocks) holds regardless of scale. For a more detailed ISO-only timeline reference, see ISO 27001 Certification Process: A Complete Step-by-Step Roadmap and How Long Does ISO 27001 Certification Take? Realistic Timelines.
Tooling and GRC Platforms for Dual Programs
Running a shared control set without automation is possible for very small companies but becomes painful quickly once you're maintaining evidence across two audit cycles. Most GRC and compliance automation platforms built for SaaS companies now support multi-framework mapping natively — you configure a control once and tag it to both ISO 27001 Annex A and SOC 2 TSC, and the platform tracks evidence freshness and testing cadence against both simultaneously.
Capability | Why It Matters for Dual Programs | What to Evaluate |
|---|---|---|
Multi-framework control mapping | Avoids maintaining two separate control libraries | Does it support Annex A's exact 93-control structure, not just a generic "ISO" template? |
Continuous evidence collection (API integrations to cloud, IdP, HR, ticketing systems) | Reduces manual screenshot-gathering for both audits | Coverage of your actual tech stack, not just the vendor's flagship integrations |
Evidence freshness/staleness alerts | Flags controls whose evidence is aging out of SOC 2's sampling window before the auditor does | Configurable cadence per control, not a fixed default |
Policy management with version control | Supports both ISO's document-control requirements and SOC 2 policy evidence | Approval workflows, distribution tracking, acknowledgment logs |
Risk register with treatment tracking | Satisfies ISO Clause 6 while feeding SOC 2 CC3 evidence | Support for risk owners, treatment plans, residual risk scoring |
Auditor collaboration portal | Lets both the CB and the CPA firm pull evidence directly, reducing back-and-forth | Separate, permissioned access per auditor; audit trail of what each auditor viewed |
Internal audit workflow | Satisfies ISO's mandatory internal audit programme | Findings tracking, corrective action workflow tied back to the shared control inventory |
Tooling is an accelerant, not a substitute for the underlying design work. A platform configured with a single control library correctly mapped to both frameworks will save enormous time; the same platform configured with two separate, siloed control libraries just automates the duplication you were trying to eliminate. For a broader look at whether your organization needs a GRC platform at all versus a well-run spreadsheet-based program, see ISO 27001 Software and GRC Tools: Do You Need One?, and if you're specifically shortlisting a platform for dual-framework evidence reuse, our comparison of the best compliance automation / GRC platforms evaluates multi-framework mapping as a core criterion.
Cost and Effort Savings of a Shared Program
The figures below are illustrative — drawn from the pattern Corvanta and similar mid-market SaaS companies experienced, not from a published industry study — but they reflect the order of magnitude teams typically see when moving from two siloed compliance tracks to one shared control set feeding both frameworks.
Cost Category | Two Separate Programs (Illustrative, Annual) | One Shared Control Set (Illustrative, Annual) | Approx. Savings |
|---|---|---|---|
Internal compliance staff time | ~640 hours | ~380 hours | ~40% |
External consulting/advisory fees | ~$95,000 | ~$62,000 | ~35% |
Risk assessment and gap analysis | Run twice (once per framework) | Run once, mapped to both | ~50% of this line item |
Evidence collection tooling | Two subscriptions or two configurations | One multi-framework platform configuration | ~30–45% |
Access review / vendor review cycles | Duplicated per auditor request | Single cycle, dual-tagged | ~50% of this line item |
Certification body + CPA firm fees | Unaffected — both engagements still required | Unaffected — both engagements still required | Minimal direct savings (indirect: less rework during fieldwork) |
Total estimated annual program cost | ~$310,000 | ~$205,000 | ~34% |
Notice what doesn't shrink: the audit and attestation fees themselves. You're still paying an accredited certification body for Stage 1, Stage 2, and annual surveillance audits, and you're still paying a CPA firm for the SOC 2 engagement. The savings live almost entirely in the preparation and evidence-collection work that precedes both — which is exactly where duplication was happening in the first place.
"Boards ask about the audit fees because that's the line item they can see on an invoice. The real money was in the 600-plus hours a year my team spent re-answering the same questions for two different portals. Cutting that in half funded two additional security engineering headcount without a budget increase." — Priya Anand, Head of Trust & Security, Corvanta Systems
One Control Set, Two Outputs: Visualizing the Model
The diagram below is the mental model to hold onto through every decision described in this article: one risk-driven control set feeds policies, technical controls, and an evidence repository, which in turn feed two entirely independent audit processes producing two entirely different deliverables.
flowchart LR
A[Risk Assessment & Business Requirements] --> B["Shared Control Set<br/>(~90 unified controls, one owner each)"]
B --> C[Policies & Procedures]
B --> D[Technical Controls]
B --> E[Evidence Repository]
C --> F["ISO 27001 ISMS<br/>Clauses 4-10 + Annex A + SoA"]
D --> F
E --> F
C --> G["SOC 2 Trust Services Criteria<br/>Security + selected categories"]
D --> G
E --> G
F --> H[Accredited Certification Body Audit]
G --> I[Independent CPA Firm Examination]
H --> J[ISO 27001 Certificate — 3yr cycle]
I --> K[SOC 2 Type I / Type II Report]Everything left of the split — risk assessment, the control set, policies, technical controls, evidence — is where the shared-program discipline lives and where the cost savings shown earlier come from. Everything right of the split is independent by design and should stay that way.
Common Mistakes When Running Both
The failure modes in dual-framework programs are predictable enough to list, and every one of them shows up in the compliance postmortems I get asked to review.
Mistake | Why It Happens | Fix |
|---|---|---|
Building two separate policy sets with slightly different wording | Different consultants or teams handled ISO and SOC 2 independently at different times | Consolidate into one policy library, cross-referenced to both frameworks, owned by one team |
Running two access reviews on two different cadences | No single control owner; each auditor's request handled reactively | Design cadence for SOC 2's sampling needs (the stricter requirement); ISO's needs are then automatically met |
Treating the Annex A/TSC mapping as static and never revisiting it | Mapping done once at kickoff, never updated as controls or TSC scope change | Review the mapping at least annually and whenever TSC category selection or Annex A applicability (SoA) changes |
Skipping ISO's management-system elements because "SOC 2 didn't require them" | Teams that started with SOC 2 underestimate how much of ISO is genuinely additive, not just technical controls | Budget explicit time and ownership for SoA, internal audit programme, and management review from the start |
Assuming a mapped control automatically satisfies both auditors | Confusing "related control area" with "identical evidence requirement" | Confirm with both the CB and the CPA firm early which specific evidence they expect, even for mapped controls |
Scoping every optional TSC category "just in case" | Desire to look maximally complete to prospects | Scope Availability, Confidentiality, Processing Integrity, and Privacy against actual customer requirements — each adds real testing cost |
Letting evidence go stale between audit cycles | No dedicated evidence-freshness monitoring between formal audit windows | Automate staleness alerts tied to each control's required cadence, not just to audit-prep season |
Running the two audits back-to-back with no recovery time | Poor calendar planning, or reactive scheduling driven by deal pressure | Plan the combined timeline (see the 18-month model above) with intentional gaps for remediation between engagements |
"The companies that struggle aren't the ones with weak controls — they're the ones with good controls and bad coordination. Two spreadsheets, two owners, two versions of the truth. That's a project management failure wearing a compliance costume." — Elena Roskova, Director of Compliance, Nimbus Freight
Case Study: Corvanta Systems — From Two Tracks to One Program
Corvanta Systems, the workforce-scheduling SaaS company from this article's opening, held a SOC 2 Type II report for three years before pursuing ISO 27001. When the $3.2 million European renewal made ISO certification a hard requirement, Priya Anand's team initially scoped ISO as a standalone project — new consultant, new risk register, new policy set — running in parallel with the existing SOC 2 program. Six months in, the duplication became impossible to ignore: two access-review processes, two vendor questionnaires, two versions of the incident response policy with subtly different escalation thresholds.
The team paused the ISO build for six weeks to consolidate. They mapped Corvanta's existing SOC 2 control set against Annex A, identified that roughly 78 of the 93 Annex A controls had a direct or near-direct equivalent already operating under SOC 2, rebuilt the remaining gap (mostly ISO's management-system layer — SoA, formal risk treatment plan, internal audit programme, management review) as additive work, and consolidated evidence collection into a single repository with dual tagging.
Metric | Before Consolidation | After Consolidation |
|---|---|---|
Annual internal compliance hours | ~640 | ~385 |
Number of separate access-review cycles | 2 | 1 |
Number of policy documents (security domain) | 34 (across two libraries) | 19 (single library) |
Time from ISO kickoff to Stage 2 certification | Projected 22 months (standalone track) | 14 months (post-consolidation) |
Outcome | — | ISO 27001 certified; SOC 2 Type II renewed on the same evidence cycle; $3.2M renewal closed |
Case Study: Fieldstone Health Tech — ISO First, SOC 2 Layered On
Fieldstone Health Tech, a clinical scheduling platform, took the opposite path. Its majority investor was a European healthcare group that required ISO 27001 as a condition of continued funding, so Fieldstone built its ISMS first, achieving certification in eleven months. A year later, a major US hospital network — Fieldstone's largest prospective account — made a SOC 2 Type II report a non-negotiable procurement requirement.
CISO Marcus Whitfield's team approached the SOC 2 build by mapping the existing ISMS control set forward into the Trust Services Criteria rather than starting evidence collection from zero. Because the ISO risk assessment, access control policy, and incident management processes were already mature and well-documented, the SOC 2 readiness assessment identified far fewer control gaps than a cold start would have — mainly around SOC 2-specific mechanics (system description drafting, TSC category selection, examination period definition) rather than substantive control gaps.
Metric | Result |
|---|---|
SOC 2 readiness assessment gaps identified | 6 (all attestation-mechanics gaps, zero substantive control gaps) |
Time from SOC 2 kickoff to Type I report | 3 months |
Time from Type I to Type II report | 9 months (standard observation period) |
Consultant hours spent on control design (vs. mapping existing ISO controls) | ~40 hours, versus an estimated ~220 hours for a cold-start SOC 2 build |
"Coming from ISO, the hardest part of SOC 2 wasn't the controls — it was learning to think in terms of an examination period and sampling instead of a single audit date. Once that clicked, the rest was mostly paperwork we'd already done." — Marcus Whitfield, CISO, Fieldstone Health Tech
Case Study: Nimbus Freight — Parallel Build From Day One
Nimbus Freight, a logistics-visibility SaaS company, is the outlier: it decided to pursue both frameworks simultaneously from the start of its formal compliance program, rather than adding one to an existing certification. Director of Compliance Elena Roskova built the shared control set as the first deliverable, before either framework's audit was scheduled, explicitly designing every control to the stricter of ISO's and SOC 2's expectations.
The parallel approach required more upfront coordination — Nimbus ran its SOC 2 Type I engagement and ISO Stage 1 audit within six weeks of each other, deliberately, to keep both auditors working from the same evidence snapshot — but it avoided the retrofit work Corvanta had to do and the sequencing lag Fieldstone experienced.
Metric | Result |
|---|---|
Time from program kickoff to both Stage 1 (ISO) and Type I (SOC 2) complete | 7 months |
Time to both ISO certification and SOC 2 Type II report | 16 months |
Duplicate policy documents created | 0 (single library from inception) |
Estimated cost avoidance vs. sequential builds (illustrative) | ~$140,000 in consulting/retrofit fees |
Roles and Governance for a Combined Program
A shared control set needs clear ownership, especially across the boundary between "one control, operated once" and "two auditors, evaluated independently."
Role | ISO 27001 Responsibility | SOC 2 Responsibility | Shared Responsibility |
|---|---|---|---|
CISO / Head of Security | ISMS owner, management review chair | Primary liaison to CPA firm | Owns the shared control set and risk register |
Compliance/GRC Manager | Maintains SoA, coordinates internal audit | Maintains system description, coordinates evidence for examination period | Owns the evidence repository and mapping documentation |
Control Owners (per domain) | Evidences Annex A controls in their domain | Evidences mapped TSC criteria in their domain | Operate the control once, tag evidence to both frameworks |
Internal Auditor | Runs the mandatory ISO internal audit programme | Not a SOC 2 requirement, but findings feed SOC 2 evidence | Internal audit findings inform both certification readiness and attestation readiness |
Executive Leadership | Attends management review (Clause 9.3, mandatory) | Signs the SOC 2 management assertion | Approves risk treatment decisions affecting both programs |
External Certification Body Auditor | Conducts Stage 1/Stage 2 and surveillance audits | Not involved | Independent of the SOC 2 engagement |
External CPA Firm | Not involved | Conducts the SOC 2 examination and issues the opinion | Independent of the ISO audit |
For more on structuring this kind of cross-functional ownership, see Building a Security RACI: Roles and Responsibilities Guide and Building an ISO 27001 Project Team: Roles and Governance — both apply directly to a combined-framework program, not just a single-framework build.
Working With Your Certification Body and CPA Firm Together
You don't need the certification body and the CPA firm to talk to each other — they're independent by design, and most won't coordinate directly beyond basic scheduling logistics. (If you haven't engaged a CPA firm yet, the process is different enough from selecting an ISO certification body that it's worth reading up on how to choose a SOC 2 auditor separately rather than assuming the same vendor-selection criteria apply.) What you do need is to manage both relationships with the same shared context. In practice, that means briefing both parties early on the fact that you're running a shared control set mapped to both frameworks, sharing your Annex A-to-TSC mapping documentation with both auditors (most auditors on either side find this genuinely useful context, even though they'll still test independently), and being explicit with each auditor about what evidence originated from the shared repository versus what's framework-specific.
Some accredited certification bodies and CPA firms sit inside the same larger professional services network and can offer light coordination — aligned fieldwork weeks, a single point of contact for scheduling — but don't assume this is available or rely on it; treat it as a convenience if it exists, not a requirement for the shared-control-set approach to work. The approach described in this article is designed to function regardless of whether your two auditors have ever heard of each other.
The Strategic Opportunity: Turning Two Audits Into One Sales Advantage
It's easy to frame running ISO 27001 and SOC 2 together as a cost-avoidance exercise — and the savings are real — but the more durable value is competitive. A company that can hand a European procurement team an ISO 27001 certificate and a US enterprise security team a SOC 2 Type II report, both drawn from the same well-documented, continuously operated control environment, is signaling something beyond "we passed two audits." It's signaling operational maturity: one control environment, understood well enough internally to be evidenced credibly to two different audiences using two different professional standards. That's a harder thing for a competitor with a single certification to match, and it shortens security-review cycles on both sides of the Atlantic simultaneously.
The same shared-control discipline scales forward, too. Many of the companies that build this model for ISO 27001 and SOC 2 find themselves reusing it when a third framework enters the picture — a NIST CSF-aligned questionnaire from a large enterprise customer, a PCI DSS requirement if payment processing enters scope, or a sector-specific standard tied to a new vertical. The mapping discipline described in this article — one control set, multiple outward-facing frameworks — is the same discipline that makes a third or fourth framework additive rather than another full rebuild.
If you're ready to move from concept to execution, PentesterWorld's ISO 27001 vs SOC 2 vs NIST CSF Comparison Guide eBook walks through the framework-selection and mapping logic in more depth, and the ISO 27001 Gap Analysis Tool is a practical starting point for identifying exactly which of your existing SOC 2 controls already satisfy Annex A requirements before you scope a formal ISO project. If you're building the shared control set from scratch, the Statement of Applicability (SoA) Template and The Complete ISO 27001 Implementation Guide eBook are worth pairing with your SOC 2 readiness assessment rather than treating them as separate workstreams. And once you're ready to budget the combined program realistically, the ISO 27001 Certification Cost Calculator can help model the audit-fee side of the equation described in the cost table above.
Running ISO 27001 and SOC 2 together isn't twice the work if you build it right from the start. It's one well-run control environment, evidenced twice, to two audiences who both need to trust it independently — and that's a genuinely achievable target for almost any SaaS company with the discipline to build the shared foundation before chasing either certificate.