Technology organizations operating in global markets routinely encounter three security frameworks: SOC 2, ISO 27001, and PCI DSS. Each originated from a different regulatory tradition, serves a different primary market, and is administered by different bodies with different audit methodologies. Understanding how they relate — and how to run them efficiently in combination — is one of the most practically important questions in compliance program design.
The mistake most organizations make is treating these frameworks as alternatives: pick one, implement it, and decide later whether to add the others. The reality is that the control overlap between SOC 2 and ISO 27001 is substantial — an organization that implements one framework thoughtfully can achieve the second with significantly less incremental effort. This article provides the comparative analysis needed to make that decision well.
Core Characteristics Compared
| Dimension | SOC 2 | ISO 27001 | PCI DSS |
|---|---|---|---|
| Origin | AICPA (American Institute of CPAs), USA | ISO / IEC, Geneva — international standard | PCI Security Standards Council — payment card industry body |
| Type of output | Attestation report (private) | Certificate (public, verifiable) | Certificate (public, verifiable) |
| Who conducts the assessment | Licensed US CPA firm (SOC examination competency) | Accredited certification body (e.g., KAN in Indonesia, UKAS in UK) | Qualified Security Assessor (QSA) firm |
| Approach | Criteria-based: test whether controls meet Trust Services Criteria | Risk-based: organization selects controls based on risk assessment | Prescriptive: specific controls are required regardless of risk profile |
| Scope flexibility | High — you define the system boundary | High — you define the ISMS scope | Low — any system that stores, processes, or transmits cardholder data is in scope |
| Controls prescribed | No — Trust Services Criteria specify outcomes, not control implementations | Partially — Annex A lists 93 controls, applicability determined by risk assessment | Yes — 12 requirements with specific technical controls prescribed |
| Renewal | Annual re-audit (observation period restarts) | Annual surveillance audits + 3-year recertification cycle | Annual reassessment |
| Indonesian regulatory reference | Not referenced in OJK, BI, or UU PDP | Referenced in POJK, PBI regulations, and UU PDP No. 27/2022 | Referenced in BI payment system regulations for payment operators |
Control Overlap: Where SOC 2 and ISO 27001 Share Ground
Despite different origins and methodologies, SOC 2 and ISO 27001 address much of the same substantive territory. Both frameworks require risk assessment, access control, incident management, change management, vendor risk management, business continuity, and security monitoring. The difference is in how they prescribe these requirements: SOC 2 defines outcomes (the Trust Services Criteria), while ISO 27001 defines a management system with an Annex A controls reference.
| KEY IDEA | Organizations that implement SOC 2 Security criteria (CC1–CC9) will find they have addressed approximately 60–70% of ISO 27001’s Annex A control requirements. The incremental effort to achieve ISO 27001 after SOC 2 is primarily in formalizing the ISMS management system (scope, objectives, risk methodology, Statement of Applicability) and addressing the ISO 27001 controls that have no SOC 2 equivalent (primarily physical security for non-data-center environments and a few people security controls). |
| Control Domain | SOC 2 Coverage | ISO 27001 Coverage | Overlap Level |
|---|---|---|---|
| Risk Assessment | CC3 — risk identification, analysis, fraud risk | Clause 6.1 + ISO 27005 — full risk treatment lifecycle | High — methodology and documentation requirements similar |
| Access Control | CC6 — comprehensive logical and physical access | A.5.15–A.5.18, A.8.2–A.8.5 — identity, authentication, access rights | Very High — substantially identical requirements |
| Incident Management | CC7 — detection, response, post-incident review | A.5.24–A.5.28 — full incident lifecycle | High — ISO 27001 adds more explicit notification requirements |
| Change Management | CC8 — change authorization, testing, deployment | A.8.32 — change management | High — SOC 2 evidence requirements are more extensive |
| Vendor Risk | CC9 — supplier relationships and monitoring | A.5.19–A.5.22 — supplier security | High — both require due diligence and contract requirements |
| Business Continuity | CC9 (Availability TSC) — recovery objectives | A.5.29–A.5.30 — BCP and ICT continuity | High — ISO 27001 more explicit on BCP testing |
| Security Governance | CC1 — control environment, board oversight | Clauses 4, 5 — context, leadership, policy | Moderate — ISO 27001 requires more formal ISMS management artifacts |
| Physical Security (non-DC) | Limited — data center physical access only | A.7.1–A.7.14 — extensive physical controls | Low — ISO 27001 significantly broader for office and facility security |
Which Framework First? The Sequencing Decision
For Indonesian technology companies, the sequencing question has a clear answer in most cases: the market you are selling to determines which framework to pursue first. If your immediate revenue priority is US enterprise clients, start with SOC 2. If your priority is Indonesian regulated sector clients (financial services, healthcare, government), or European enterprise clients, start with ISO 27001.
| BITLION INSIGHT | The most efficient path for organizations with both US and non-US enterprise ambitions: implement SOC 2 controls first (they are more prescriptive about evidence and therefore easier to implement in a defined sequence), achieve SOC 2 Type II, then layer ISO 27001 on top by adding the ISMS management artifacts and closing the Annex A gaps. Total incremental effort for ISO 27001 after SOC 2 is typically 30–40% of a standalone ISO 27001 implementation. |
| Scenario | Recommended First Framework | Reason |
|---|---|---|
| SaaS company with US enterprise pipeline | SOC 2 Type I then Type II | US enterprise buyers require SOC 2; ISO 27001 can follow once SOC 2 is in place |
| Fintech regulated by OJK / Bank Indonesia | ISO 27001 | OJK and BI regulations reference ISO 27001 directly; compliance cannot wait for SOC 2 |
| Payment processor handling card data | PCI DSS first, then SOC 2 or ISO 27001 | PCI DSS is legally required for card data handling; other frameworks are supplemental |
| Technology company seeking both US and EU clients | SOC 2 + ISO 27001 concurrently | Shared controls justify running both programs simultaneously with a unified evidence library |
| Healthcare technology (US market) | SOC 2 with Privacy TSC + HIPAA BAA | HIPAA compliance is required; SOC 2 Privacy TSC aligns with HIPAA safeguards |
Running SOC 2 and ISO 27001 Simultaneously
For organizations that need both frameworks, running them simultaneously — rather than sequentially — is both practical and efficient. The key is building a unified evidence library from the start: evidence collected for SOC 2 (access review records, incident tickets, change management documentation, training records) maps directly to ISO 27001 Annex A controls. With the right GRC platform and evidence tagging, the same artifact satisfies both frameworks.
The primary incremental work for ISO 27001 beyond SOC 2 is the ISMS management documentation: a formal scope statement, an information security policy signed by leadership, a Statement of Applicability (SoA) covering all 93 Annex A controls, and formal management review records. These documents are ISMS-specific and do not have direct SOC 2 equivalents, but they can typically be produced in four to six weeks once the SOC 2 control environment is in place.