SOC 2 vs PCI DSS: Which audit to run first

Should a payment-facing company pursue SOC 2 vs PCI DSS first?

If a customer or payment brand asks for both, the order depends on who asks first and what they will accept. PCI DSS is a payment brand obligation validated by a Report on Compliance from a Qualified Security Assessor or a Self-Assessment Questionnaire, each with an Attestation of Compliance. A SOC 2 is a CPA report on the trust services criteria you chose, and it is usually requested by buyers in procurement. Start by writing down which party is asking, which document they expect, and whether their deadline falls before or after your next audit window. A QSA cannot rely on a SOC 2 report for a PCI DSS assessment, so a SOC 2 never replaces the ROC or SAQ. It can, however, supply evidence the QSA may reuse after independently reviewing it, as described in PCI SSC FAQ 1567.

In most cases the practical answer is to pursue both on one shared evidence base rather than treating either as a substitute. Map your PCI DSS requirements to the controls you already test for SOC 2, especially access management, logging, change management and vendor oversight, and keep one evidence repository with named owners. Confirm early with your QSA and your CPA firm that they will share workpapers under agreement, and that the QSA keeps ultimate responsibility for the ROC even when another auditor at the same firm collects evidence, per PCI SSC FAQ 1566. Check which PCI DSS testing cadences you must meet, such as quarterly scans and annual penetration tests, because those recurring tasks drive the effort you will repeat each year.

Plan for the restrictions on distribution. Use of a SOC 2 report is generally restricted, so confirm with each recipient that they are entitled to receive it, and ask whether a SOC 3 general use report will satisfy the first request. Ask your QSA which PCI DSS version and approach will apply at your next assessment, because PCI DSS v4.0.1 is the only active version and the PCI SSC has announced no release date for a successor. Your quote from each firm should separate the one-time readiness work from the recurring audit fees, and should state whether shared evidence reduces the scope of each engagement.

SOC 2 vs PCI DSS: side by side on scope and proof

This table compares who requires each framework, what is tested, the proof each one produces, whether a certificate counts, and who enforces it. Read it as a scope and evidence check before deciding which audit to fund first.

Factor	SOC 2	PCI DSS
Who requires it	No regulator. Customers, partners and procurement teams request it, usually as part of vendor review	Payment brands decide which entities must validate. Applies to merchants, processors, acquirers, issuers and service providers that store, process, transmit or could affect cardholder data
Governing body or standard	AICPA attestation standards and the 2017 Trust Services Criteria, with revised points of focus published in 2022	PCI Security Standards Council owns and maintains PCI DSS. PCI DSS v4.0.1 is the only active version
What is tested	Security common criteria CC1 to CC9 plus any of availability, processing integrity, confidentiality and privacy that you choose to include in scope	The 12 principal PCI DSS requirements, grouped under six goals, with fixed testing cadences for scans and penetration tests
Proof produced	A CPA report: Type 1 covers system description and control design as of a date, Type 2 adds an opinion on operating effectiveness over a period	A Report on Compliance completed by a QSA, or a Self-Assessment Questionnaire, each with an Attestation of Compliance
Is a certificate recognized?	No certificate. The report is the deliverable, and its use is generally restricted to parties the report covers	No. PCI SSC states that certificates are not recognized as validation
Who enforces	Nobody by law. Consequences arrive through contracts and customer decisions	PCI SSC does not enforce or impose penalties. The individual payment brands run enforcement programs
Can one audit reuse the other?	A SOC 2 report is not accepted as PCI DSS validation	A QSA cannot rely on a SOC 2 report but may reuse its evidence after independent review. Confirm scope with your QSA

Who must validate PCI DSS and who simply gets asked for SOC 2

Whether PCI DSS validation is mandatory depends on your role in payment flows, not on your size or your SOC 2 status. The cards below cover the situations that decide scope, and the one question that connects them: does your environment touch cardholder data, or could your service affect its security?

Merchant or processor under a brand rule

Your obligation comes from the payment brands and your acquirer or processor contract, not from PCI SSC. The brands decide which entities must validate and run any enforcement, so ask your acquirer or card brand which validation type applies to you. A SOC 2 report does not satisfy that requirement, and a QSA cannot rely on one for the assessment. Check the validation level and whether an annual ROC or SAQ with quarterly ASV scans is expected.

Service provider that can affect the CDE

A service provider can fall in scope even when it never stores, processes or transmits card data. PCI SSC's FAQ on service providers that can affect security covers providers with access to a customer's cardholder data environment. Hosting, remote administration, managed firewalls and support access are typical examples to review. Map every administrative path into the customer's CDE, because that path, not the data flow, often decides scope.

Provider meeting a requirement for a customer

Some providers meet specific PCI DSS requirements on a customer's behalf, such as log management, key handling or vulnerability scanning. In that case the provider's controls become part of the customer's assessment, and the customer will ask for evidence. Agree in writing which requirements you cover, which remain the customer's, and what evidence you will hand over. A SOC 2 can show control design and operation, but it does not map one to one onto those requirements.

SaaS with no payment role

A SaaS company that never touches cardholder data and has no CDE access usually sits outside PCI DSS. Its customers still ask for SOC 2 because a vendor review needs assurance over security, availability and confidentiality. Confirm the boundary in writing: if a payment flow is built on your platform, or a customer proposes you host a payment page, the scope question returns. Keep the boundary documented so the SOC 2 system description and any PCI analysis agree.

Shared scope with a payment customer

When your customer runs PCI DSS, they will often ask for both a SOC 2 and responsibility evidence covering the services you provide. A SOC 2 gives them an independent view of your controls, but the QSA still performs the assessment and keeps responsibility for the ROC. Ask your customer which PCI DSS requirements they expect you to evidence and whether they accept reuse of SOC 2 testing evidence after their QSA reviews it.

Why a QSA cannot rely on SOC 2 but can reuse its evidence

A QSA cannot rely on a SOC 2 or SOC 3 report for a PCI DSS assessment, but the QSA may reuse evidence gathered during those audits, provided the QSA reviews that evidence independently. The distinction matters for budgeting and sequencing. A SOC 2 report tells the QSA what a CPA concluded about your controls against the Trust Services Criteria. It does not tell the QSA whether each PCI DSS requirement is met in the cardholder data environment, so the QSA still has to test against the PCI DSS requirements themselves. Before the audits start, confirm with your QSA which SOC 2 evidence they are willing to consider and how they will document their review.

The QSA keeps ultimate responsibility for the Report on Compliance and its workpapers, even when a SOC 2 auditor at the same firm collected the evidence. Another team's collection does not transfer accountability. In practice, ask who at the firm signs the ROC, how evidence collected for the SOC 2 is labeled and stored, and whether the SOC 2 engagement team will share sampling populations, system descriptions and change records in a form the QSA can trace. Those items are the ones that determine whether reused evidence survives the QSA's review.

Reviewing reused evidence means the QSA examines each item and decides whether it actually covers the PCI DSS requirement under assessment. A SOC 2 control over access reviews, for example, may cover a different population, period or system boundary than the requirement in scope, so the QSA checks scope, timing and sample size before accepting it. The reviewer must be satisfied that the evidence covers the requirement, and anything that does not will be tested again. Any reduction in duplicated work depends on how closely your SOC 2 scope matches the cardholder data environment, so get that mapping in writing before fees are discussed.

How often PCI DSS testing repeats for each service provider path

Visa Level 1 service providers handle more than 300,000 transactions a year and must complete an annual Report on Compliance (ROC) led by a Qualified Security Assessor (QSA). The ROC is the annual anchor, but the scan and testing cadences below repeat between assessments, so the calendar matters as much as the report. Confirm the tier and its requirements with Visa's compliance validation guidance and your acquirer.

Annual ROC by a QSA: The QSA keeps ultimate responsibility for the ROC and its workpapers, even when a SOC 2 auditor at the same firm collects evidence.
Quarterly ASV scans: External scans by an Approved Scanning Vendor run at least every three months.
Internal scans every three months: Internal vulnerability scans also repeat at least every three months.
Penetration tests every 12 months: Internal and external penetration tests each repeat at least once every 12 months.
Segmentation tests every six months: Service providers test segmentation every six months, twice the 12-month interval that applies to merchants.

A SOC 2 report sets no fixed testing frequency, so its observation period is set by your engagement. Check whether your QSA's ROC calendar and your SOC 2 observation window can draw on the same quarterly evidence.

What each assessment issues and how often it repeats

This table compares who performs each assessment, what document it produces, how often it repeats and who may receive that document. Read it to see which report a customer can actually ask you for and which one a payment brand expects. The main takeaway is that a SOC 2 report is restricted in use, while a PCI DSS Attestation of Compliance is designed to be shared with customers on request.

Aspect	SOC 2	PCI DSS
Who performs the assessment	A CPA firm acting as service auditor under AICPA attestation standards	A Qualified Security Assessor for a ROC, or the entity itself for an SAQ
What is issued	An opinion report on the system description and controls against chosen trust services criteria	A Report on Compliance or Self-Assessment Questionnaire, each with an Attestation of Compliance
Point in time or period	Type 1 covers control design as of a date; Type 2 adds operating effectiveness over a period	Assessed against the requirements in force at the assessment, with the AOC stating the result
Who may receive the report	Use of a SOC 2 report is generally restricted, so confirm each recipient's permitted use with the auditor	The AOC is expected to be given to customers on request; customers may also ask for relevant ROC or SAQ D sections
Certificate or validation	A report, not a certificate; the auditor's opinion covers the period or date tested	Certificates are not recognized as validation; the ROC or AOC is the proof
Recurring cycle	Set by the agreed reporting period; customers usually expect a current Type 2 and a bridge letter for gaps	Annual ROC or SAQ, plus scans and tests at fixed frequencies such as quarterly external ASV scans
Who decides the cycle	The service organization and its auditor agree the period in the engagement letter	The payment brands set validation levels and timing; Visa Level 1 providers need an annual ROC by a QSA
Confirm before you commit	Distribution terms, period length and whether a SOC 3 summary is needed for public use	Which validation level and document your payment brand requires for your service provider role

Where SOC 2 and PCI DSS work overlaps

SOC 2 and PCI DSS both test access, change, logging and vendor oversight, so one body of evidence can often serve both audits. The overlap is in the evidence, not in the verdict: each assessor still judges each framework on its own terms.

Logical access control

Both frameworks test who can reach systems and data, how accounts are approved, reviewed and removed, and how privileged access is controlled. A single access review export can feed a SOC 2 common criteria test and a PCI DSS requirement on access to the cardholder data environment. Check that the population covers every system in the CDE and in the SOC 2 system description, since a QSA will sample from the payment scope, not from your broader estate.

Change management

Change approval, testing and separation of duties appear in SOC 2 under the change management criteria and in PCI DSS under its secure development and change control requirements. Tickets, peer review records and deployment logs can serve both, provided they show which changes touched payment systems. Confirm with your assessor which change records they will accept as sufficient for the period under review.

Logging and monitoring

Both audits look for audit logs that record user activity, administrative actions and security events, and for evidence that someone reviews them. Retention, time synchronization and log integrity are the details that differ in practice. Confirm the retention period and review cadence each assessor expects before you design one log pipeline for both.

Vendor and service provider management

A SOC 2 system description often lists subservice organizations, and PCI DSS applies to service providers that can affect cardholder data security, even without storing it. Vendor inventories, contracts and periodic reviews of third-party attestations therefore serve both audits. Verify whether each supplier must be covered by your PCI DSS responsibility matrix and whether your SOC 2 carve-out or inclusive method applies.

Security policy and risk review

Both frameworks expect a documented information security policy, approved by management and reviewed on a schedule, plus a risk assessment that drives control selection. One approved policy set with clear ownership can satisfy the governance expectations of each audit. Ask your assessor whether they want the policy mapped to PCI DSS requirement numbers and to the SOC 2 criteria you selected.

Mapping sources and their limits

The CIS Controls Navigator for v8.1 publishes mappings to both SOC 2 and PCI DSS v4.0, and NIST's informative references list PCI DSS. These mappings help you find shared evidence, but they are not equivalence findings, and NIST does not check the correctness of non-NIST mappings. Confirm each control pairing against the current PCI DSS v4.0.1 text and the SOC 2 criteria you chose, with your QSA and CPA.

How to sequence SOC 2 and PCI DSS audits without duplicating evidence

This sequence settles which validation applies, fixes the scope both auditors test, and agrees in advance which SOC 2 evidence the QSA may review and reuse, so one set of controls serves both reports.

Confirm which PCI DSS validation applies
Ask your payment brand or acquirer which validation route and level apply to your service provider role, since the brands decide which entities must validate and run any enforcement programs. For Visa service providers, the level sets whether an annual ROC by a QSA or an annual SAQ is required, with quarterly ASV scans at both levels. Done when the answer is in writing, naming the validation type, the level and the deadline the acquirer or brand has set.
Define the in-scope system and cardholder data environment
Map every system, network segment, administrative path and third party that stores, processes, transmits or could affect cardholder data, including service provider access to a customer's cardholder data environment. Document the segmentation boundary and the systems that will be inside the SOC 2 system description. Done when one scope diagram and inventory are signed off by engineering, security and the QSA-facing owner, and both boundaries match or the differences are recorded.
Decide the SOC 2 criteria and period
Choose the trust services categories to include, Security as the baseline with the common criteria and any added categories only where in scope, and set the report type and the observation period. A Type 1 report covers control design as of a date, while a Type 2 report adds an opinion on operating effectiveness over a period. Done when the system description and the period are agreed with the SOC 2 auditor, and you have confirmed whether the period can start before the PCI DSS scope is final.
Agree with the QSA which SOC 2 evidence it will reuse
Before testing starts, give the QSA a written list of SOC 2 control descriptions, populations, samples and test results it may review. The QSA cannot rely on a SOC 2 report for the PCI DSS assessment, but may reuse evidence after independently reviewing it, and it keeps ultimate responsibility for the ROC and workpapers even when another auditor at the same firm collected the evidence. Done when the QSA confirms in writing which items it will review, which it will retest, and which PCI DSS requirements need evidence the SOC 2 does not cover.
Map a shared control set to both audits
Build one control matrix that links each internal control to the SOC 2 criteria it supports and to the PCI DSS requirements it satisfies. Flag PCI DSS testing that SOC 2 does not reach, such as cardholder data flow evidence and the fixed cadences for scans and penetration tests, which recur on their own schedule. Done when every PCI DSS requirement in scope points to an owner, a control and a named evidence source, and gaps have a remediation owner before the observation period starts.
Run the SOC 2 observation and PCI DSS assessment together
Run control operation over the SOC 2 period while the QSA performs its assessment against the shared matrix, so that access reviews, change records, log samples and vulnerability scan results are collected once and tagged for both auditors. Keep the PCI DSS recurring tests (quarterly scans, penetration tests and segmentation tests at their fixed frequencies) inside the same calendar. Done when each auditor has its requests answered from the same records and the recurring test results are on schedule.
Keep evidence in one register for both auditors
Store every artifact in a single evidence register with a control ID, the SOC 2 criteria and PCI DSS requirement it supports, the owner, the collection date and the reviewer's sign-off. Give customers the Attestation of Compliance on request and share relevant ROC or SAQ sections as allowed, while SOC 2 reports stay restricted to the parties permitted to receive them. Done when both audit teams work from the same register, and any evidence shared outside the audit is traceable to its source.

SOC 2 vs PCI DSS questions buyers ask before hiring help

Does a SOC 2 report satisfy PCI DSS?

No. A QSA cannot rely on a SOC 2 or SOC 3 report for a PCI DSS assessment. PCI DSS validation is documented on official PCI SSC templates: a Report on Compliance (ROC) completed by a QSA, or a Self-Assessment Questionnaire (SAQ), each with an Attestation of Compliance (AOC). A SOC 2 is an attestation by a CPA on chosen trust services criteria, so it answers a different question. Whether you need a ROC or an SAQ depends on your service provider level and how the payment brands classify you, which you should confirm with your acquirer or the relevant brand before scoping. The PCI SSC FAQ on relying on SOC 2 reports sets out the rule.

Can a QSA reuse evidence from a SOC 2 audit?

Yes, in part. A QSA may reuse evidence from a SOC 2 or SOC 3 audit, but only after independently reviewing it, which can reduce duplicated evidence work. The QSA still has to test each PCI DSS requirement in scope and reach its own conclusions. The QSA also keeps ultimate responsibility for the ROC and workpapers, even when another auditor at the same firm, such as a SOC 2 auditor, collects the evidence. Ask early whether your SOC 2 auditor and QSA are the same firm, because that affects how the handoff is documented. See the PCI SSC FAQ on evidence collected by other auditors.

What drives the cost and effort of each audit?

Cost follows the work each audit needs, and the two audits share few drivers. For PCI DSS, the main drivers are the number of systems in the cardholder data environment (CDE), how far your scope is reduced by segmentation, the number of third parties that touch cardholder data, and how well your controls already produce evidence. PCI DSS also fixes recurring testing frequencies: external and internal vulnerability scans at least every three months, internal and external penetration tests at least every 12 months, and segmentation tests every 12 months or six months for service providers (PCI DSS v4.x, SAQ D). For SOC 2, the drivers are the number of trust services categories in scope, the system boundary, and whether you need a Type 1 or a Type 2 report. Ask each firm for a fee built from a written scope, and ask which costs recur each year.

How long does the work take and what does it need from our staff?

No supplied fact gives a duration for either audit, so confirm timelines with each firm against your written scope. Expect staff time from engineering, operations, security, HR and the finance or compliance owner. For PCI DSS, the heaviest asks are a current network and data flow diagram, an inventory of systems in the CDE, scan and penetration test records, and evidence that segmentation holds. For SOC 2, the heaviest asks are a clear system description, a population of change records and access reviews, and evidence that controls operated across the observation period for a Type 2. Ask each firm which staff roles it needs, how many interview sessions it plans, and what evidence it will request in the first week.

Can we prepare the evidence ourselves before engaging a QSA or CPA firm?

Yes, and it is often the cheapest way to shorten the audit. Build the inventory of systems, data flows, network diagrams, access review records, change records, scan results and penetration test reports before the auditor arrives, and map them to the requirements or criteria each audit uses. Preparation does not replace the assessment. A QSA must independently review evidence before reusing it, and a CPA must test controls over the period. Do not share your preparation as if it were an attestation. DeployOpen prepares systems, controls and evidence for compliance assessments but does not issue audit reports, attestations or certifications, so the QSA or CPA firm still performs and signs the assessment.

Which PCI DSS version applies to our assessment?

PCI DSS v4.0.1 is the only active version. It was published on 11 June 2024 as a limited revision of v4.0 with no added or deleted requirements. PCI DSS v4.0 was retired on 31 December 2024, and v3.2.1 was retired on 31 March 2024. The PCI SSC ran a request for comments on v4.0.1 from 3 June to 20 July 2026 to begin the next iteration, but as of October 2026 it had announced no release date for a new version. Confirm the current version on the PCI SSC standards page before you start, and ask your QSA which future-dated requirements apply to you, since most of the 64 new v4.0 requirements became effective on 31 March 2025 (PCI SSC blog, August 2024).

What should we ask for in a written quote?

Ask each firm to state the scope in writing before quoting: which systems, locations, teams and services are in or out, and which assessment type applies (ROC or SAQ for PCI DSS, Type 1 or Type 2 for SOC 2). Ask for the fee split between assessment, readiness support, remediation help and any penetration testing or scanning vendor. Ask which costs are one-time and which recur each year, including scan and penetration test cadences and the next observation period. Ask who signs the report or attestation, what evidence you must provide, what happens if scope changes, and what the payment terms are. DeployOpen does not publish a price list, and its engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

How DeployOpen prepares SOC 2 and PCI DSS evidence

DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own infrastructure, and prepares systems and evidence for compliance assessments. We do not issue audit reports, attestations or certifications, so the CPA firm for your SOC 2 and the QSA for your PCI DSS assessment remain the parties that conclude on compliance.

How we scope

We agree scope in writing before work starts, covering systems, environments and the SOC 2 criteria or PCI DSS assessment type in play.
The written scope names which cardholder data environment or service boundary is in view, and which shared controls a SOC 2 report would also cover.
Engagements are fixed-scope, with deliverables and timelines confirmed in writing, and ongoing support available as a retainer.

How we build

We configure logging, access control, change management and backup controls so the same evidence can serve both SOC 2 and PCI DSS reviewers.
We map each control to the relevant SOC 2 criterion and PCI DSS requirement, so one control record supports both assessments.
We test controls and scans on the cadences the assessment requires, and record results in a form the assessor can review independently.

How we hand over

You receive control documentation, system descriptions and evidence packages organized for your CPA firm or QSA to review.
We document how evidence was collected, who owns each control and where the assessor must independently verify what we prepared.
Handover includes runbooks for operating the platform, so your own team can keep the controls running after the engagement ends.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, keeping evidence current between assessment periods.
We help you confirm with your QSA or CPA which evidence they will accept before we collect it, to avoid duplicated work.
Ask any provider to confirm how they handle ownership of the ROC or SOC 2 report, which stays with the assessing firm.

SOC 2 vs PCI DSS