SOC 2 vs ISO 27001 vs PCI DSS: Which Attestations a SaaS Company Needs

SaaS companies are routinely asked for a SOC 2 report, an ISO 27001 certificate and PCI DSS compliance in the same quarter, and treating the three as interchangeable leads to wasted audits, duplicated evidence and payment scope that quietly swallows the whole platform. They answer different questions for different audiences: SOC 2 is a CPA attestation report on controls, ISO/IEC 27001:2022 certifies a management system, and PCI DSS is a prescriptive data security standard whose obligations follow card data wherever it goes. This guide is about sequencing and scope: which to pursue first given your customers, geography and data, where PCI DSS is far more prescriptive than the other two, and how to run one evidence plan that serves all three. It is written for founders, security leads and compliance owners at SaaS providers. For a wider map of attestation schemes see the Third-Party Attestation Comparison Map; for clause-level overlap see the SOC 2 to ISO 27001 Mapping Guide.

Key takeaways

• They are not substitutes. SOC 2 and ISO 27001 are chosen by your sales motion; PCI DSS is triggered by your data flows, and no SOC 2 report or ISO certificate replaces it when you store, process or transmit cardholder data.
• Customer geography decides SOC 2 versus ISO 27001 first. North American enterprise buyers usually ask for a SOC 2 Type 2 report; European, UK, Middle Eastern and Asian buyers and public sector frameworks more often ask for an ISO 27001 certificate.
• PCI DSS scope is the differentiator. The cheapest PCI DSS programme is the one designed out of your platform through hosted payment pages, tokenisation and a payment provider, so architecture decisions come before any audit.
• PCI DSS is prescriptive where the others are principle based. Key management, system and application accounts, multi-factor authentication into the cardholder data environment and testing cadences are specified in detail, so controls that satisfy a SOC 2 auditor can still fail a PCI assessment.
• Build one control set and one evidence calendar. Map each control once to the Trust Services Criteria, ISO/IEC 27001 Annex A and PCI DSS requirements, collect evidence once, and align audit windows so the same samples serve every assessor.

The short answer

If you sell mainly to North American companies, start with SOC 2 (a Type 1 to unblock early deals, then a Type 2 covering an operating period). If your pipeline is mainly in Europe, the UK or regulated international markets, start with ISO 27001 certification. If any part of your product touches primary account numbers, decide your PCI DSS scope before either audit, because the answer changes your architecture, your logging and your access model. Most SaaS companies selling globally end up with SOC 2 and ISO 27001 within two to three years, and a PCI DSS validation only if they are a service provider in the payment flow.

What each actually assures, and to whom

• SOC 2: the AICPA describes SOC as a suite of services CPAs provide so that users can "assess and address the risks associated with outsourcing services". A SOC 2 report is about a defined system and its controls against the Trust Services Criteria categories (Security, Availability, Processing Integrity, Confidentiality and Privacy). A Type 1 report covers the design of controls at a point in time; a Type 2 report also tests operating effectiveness across a period, which is what most enterprise buyers want. See the SOC 2 Type 1 vs Type 2 and the SOC 2 Guide.
• ISO/IEC 27001: ISO calls it the best-known standard for information security management systems and their requirements. It certifies that you run a working management system: scope, risk assessment, risk treatment, a Statement of Applicability, internal audit and management review. The 93 controls in Annex A (guidance in ISO/IEC 27002:2022) are selected through risk treatment, not applied wholesale. See the ISO 27001 Certification Guide.
• PCI DSS: PCI SSC states the standard applies to entities that store, process or transmit cardholder data or sensitive authentication data, and to entities that could affect the security of the cardholder data environment. Whether and how you must validate is set by the organisations that manage compliance programmes, such as payment brands and acquirers. Visa, for example, states that issuers and acquirers must ensure all their service providers demonstrate PCI DSS compliance at least every 12 months. See the PCI DSS 4.0 Guide.

The practical difference: a SOC 2 opinion and an ISO certificate say your security programme is designed and operating as described. A PCI DSS Attestation of Compliance says a specific environment meets every applicable requirement in a prescriptive standard. A buyer's procurement team accepts the first two as evidence of good practice; an acquirer or a merchant customer needs the third because their own compliance depends on it.

Decision criteria: which to pursue first

Size matters too: a 30-person company can run SOC 2 and ISO 27001 from one control owner and a compliance platform, but PCI DSS service provider validation at Level 1 brings a Qualified Security Assessor, quarterly external scans by an Approved Scanning Vendor and a twice-yearly scope review, which is a step change in effort. Large organisations usually separate a payment platform team and its environment precisely so that the rest of the estate stays out of PCI DSS scope.

PCI DSS scope: the real differentiator

SOC 2 and ISO 27001 let you draw the boundary: you can define the system or ISMS scope around one product. PCI DSS does not. Scope is every system component that stores, processes or transmits account data plus anything connected to it or able to affect its security, including identity providers, CI/CD pipelines, jump hosts, logging and the people who administer them. Requirement 12.5.2 requires a documented scope confirmation at least annually, and PCI SSC described it as a new obligation to "undertake an annual scope confirmation exercise". Service providers must repeat it every six months and after significant change (12.5.2.1).

Scope reduction options, in order of impact:

1. Never receive the card number: use the payment provider's hosted payment page or redirect, so card data goes from the cardholder's browser to the provider. Your payment page scripts may still be in scope for e-commerce merchants; see the PCI DSS for E-commerce Payment Page Scripts Guide.
2. Tokenise at the edge: receive a provider token instead of the account number, so your databases hold tokens only. See the Network Tokenisation for Payments Guide.
3. Isolate what remains: a dedicated account, VPC or cluster for the cardholder data environment with segmentation that is tested, separate identity groups and separate pipelines. See the PCI DSS Scoping and Network Segmentation Guide.
4. Document shared responsibility: if you are a service provider, publish a responsibility matrix per requirement so merchant customers can scope their own assessments. See the PCI DSS for Service Providers and Responsibility Matrix Guide.

Do the scoping before the SOC 2 or ISO 27001 audit, not after. If you certify an ISMS that includes a flat production network and later need PCI DSS, you will either rebuild the network or pull the whole estate into PCI scope.

Control overlap, and where PCI DSS is prescriptive

The three share most control themes: access management, change management, logging, vulnerability management, incident response, supplier management and security awareness. The difference is precision. A SOC 2 auditor tests whether your control meets the criterion as you described it; an ISO auditor tests whether your control addresses your assessed risk; a PCI assessor tests a stated requirement with stated testing procedures. The areas that most often fail when a SOC 2 or ISO control set is reused for PCI DSS are below. Requirement numbers refer to PCI DSS v4.0.1.

For the full SOC 2 to ISO picture use the SOC 2 to ISO 27001 Mapping Guide, and for PCI DSS against Annex A the PCI DSS 4.0 to ISO 27001 Mapping Guide.

Where identity fits

Machine identities are where PCI DSS bites hardest on SaaS platforms. A SOC 2 control such as "service account credentials are stored in a secrets manager" often passes as written. PCI DSS 8.6.2 goes further: passwords and passphrases for any system or application account that can be used for interactive login must not be hard coded in scripts, configuration or source code, and 8.6.3 requires a risk-based rotation frequency and complexity. CI/CD runners, database service users and integration API keys that reach the cardholder data environment all fall into the inventory. Map each to an owner, a vault path and a rotation record once, and the same evidence serves CC6.1, A.5.17 and 8.6. See the Secrets Management Guide.

Failure modes of running all three

• Scope creep through shared services: a single identity provider tenant, shared CI/CD or a shared logging pipeline connected to the cardholder data environment pulls those systems, and everything they administer, into PCI DSS scope. Isolate or accept and document.
• Duplicated evidence: three audit teams sampling different months of access reviews, three versions of the risk register and three policy sets. Each assessor finds inconsistencies the others did not.
• Misaligned audit windows: a SOC 2 Type 2 period ending in March, an ISO surveillance audit in June and a PCI assessment in October means control owners never stop preparing. Align them so evidence collected once covers all three.
• Treating the SOC 2 report as PCI evidence: merchant customers and acquirers need an Attestation of Compliance and a responsibility matrix for a payment service provider; a SOC 2 report that mentions encryption does not satisfy them.
• ISMS scope that excludes the hard parts: certifying ISO 27001 for "the corporate office" while the product runs elsewhere satisfies nobody who reads the scope statement, and buyers do read it.
• Generic MFA and rotation policies: "MFA for administrators" and "rotate keys annually" pass SOC 2 but fail PCI DSS 8.4.2 and 8.6.3 when applied to the cardholder data environment.

A combined evidence plan

1. Scope first (month 0 to 1): draw data flow diagrams, decide whether card data enters your systems, and agree the SOC 2 system boundary, ISMS scope and PCI DSS scope together. Record the decision.
2. One control framework (month 1 to 2): write each control once with an owner, frequency and evidence artefact, mapped to TSC criteria, Annex A controls and PCI DSS requirements. Where PCI is stricter, adopt the PCI wording for in-scope systems. See the Control Mapping Guide.
3. Risk assessment and Statement of Applicability (month 2): one risk register drives ISO risk treatment, SOC 2 CC3 risk assessment and the PCI DSS targeted risk analyses for flexible frequencies (12.3.1).
4. Automate evidence (month 2 to 4): pull access reviews, change tickets, vulnerability scan results and configuration states into one repository on a fixed calendar. See the Compliance Automation Guide.
5. First artefact (month 3 to 6): SOC 2 Type 1 or ISO 27001 Stage 1 and Stage 2, depending on geography.
6. Operating period (month 6 to 12): SOC 2 Type 2 observation period running while ISO surveillance and any PCI readiness assessment use the same samples.
7. Align the calendar: set the SOC 2 period end, ISO surveillance audit and PCI assessment within the same quarter, with internal audit testing the combined control set before each.
8. Roll back gracefully: if PCI scope proves too broad, pause validation, re-architect toward hosted payment pages or tokenisation, and agree interim compliance status with your acquirer or payment brand contacts rather than certifying a fragile scope.

Worked scenario

A 120-person B2B SaaS company sells subscription billing software to US and UK customers. Its platform stores customer card numbers to run recurring charges. US prospects ask for SOC 2 Type 2, UK prospects ask for ISO 27001, and a large merchant customer asks for a PCI DSS Attestation of Compliance and responsibility matrix. The company first moves card capture to a payment provider's hosted fields and stores provider tokens, shrinking the cardholder data environment to a token vault integration and the payment service. It runs PCI DSS scoping, segmentation and service account remediation (8.6) on that small environment, writes a single control framework, completes SOC 2 Type 1 at month five and ISO 27001 certification at month nine, and starts the SOC 2 Type 2 observation period with the PCI assessment scheduled in the same quarter. Each control owner provides one evidence set per period.

Measuring that it is working

• Evidence reuse rate: share of evidence artefacts accepted by two or more assessors; aim to rise each cycle.
• PCI DSS scope size: number of system components in the cardholder data environment and connected systems, tracked at each 12.5.2 scope confirmation.
• Audit findings by framework: exceptions in the SOC 2 report, ISO nonconformities and PCI requirements not in place; repeat findings signal a control designed for one framework only.
• Sales cycle impact: security review time for deals where the report or certificate was provided up front.
• Machine identity hygiene in scope: share of in-scope service accounts with an owner, vaulted credential and rotation within the risk-defined frequency.

Practitioner checklist

• Map customer geography and contract language to decide whether SOC 2 or ISO 27001 comes first.
• Draw card data flows and decide whether account data ever enters your systems before any audit planning.
• Prefer hosted payment pages or tokenisation to keep account numbers out of the platform.
• Agree the SOC 2 system boundary, ISMS scope and PCI DSS scope in one decision record.
• Write one control framework mapped to TSC, Annex A and PCI DSS requirements, adopting PCI wording for in-scope systems.
• Inventory service accounts and keys that reach the cardholder data environment against 8.6 and 3.6 to 3.7.
• Align SOC 2 periods, ISO audits and PCI assessments within the same quarter.
• Publish a PCI DSS responsibility matrix if you are a service provider.
• Track the proposed 2027 SOC 2 Trust Services Criteria and plan the transition.

Standards and references

• PCI Security Standards Council: PCI DSS
• PCI Security Standards Council: Just Published, PCI DSS v4.0.1
• PCI Security Standards Council: Adopt the Future-Dated Requirements of PCI DSS v4.x
• ISO: ISO/IEC 27001 Information Security Management Systems
• AICPA and CIMA: System and Organization Controls, SOC Suite of Services
• AICPA and CIMA: 2017 Trust Services Criteria (Revised Points of Focus, 2022)
• AICPA and CIMA: Proposed Update of SOC 2 Trust Services Criteria
• Visa: Security Compliance

Related NHI Mgmt Group resources: Third-Party Attestation Comparison Map · SOC 2 to ISO 27001 Mapping Guide · Audit, Assurance and Compliance Guide · SOC 1 vs SOC 2 vs SOC 3