ISO 27001 vs PCI DSS: Which to Do First

ISO 27001 vs PCI DSS: which should you pursue first?

An ISO 27001 certificate does not count as PCI DSS validation, so the choice comes down to whether card data is your immediate obligation. If your payment brand or acquirer requires a PCI DSS assessment, that requirement comes first, and only official PCI SSC templates count as evidence: a Report on Compliance completed by a Qualified Security Assessor, or a Self-Assessment Questionnaire, each with an Attestation of Compliance. Certificates issued by vendors or consultants are not recognized. Confirm with your acquirer which validation type and reporting date apply, because the payment brands, not the PCI SSC, decide who must validate and run any enforcement.

Start with scope. Under PCI DSS, the cardholder data environment covers the systems, people and processes that store, process or transmit card data, plus anything with unrestricted connectivity to them. Requirement 12.5.2 makes you confirm that scope yourself at least every 12 months and after significant change, and the quarterly scans and periodic penetration and segmentation tests attach to that boundary. Protecting card data first lets you shrink that boundary, for example by removing stored card numbers or isolating payment systems, before you spend effort on the rest of the company. An ISO 27001 ISMS scope can be narrowed by location, business unit or service, but clauses 4 to 10 cannot be dropped, so a narrowed ISMS still has to be run as a full management system.

A whole-company ISMS makes more sense when card data is one of several sensitive assets, when customers or regulators ask for an independently certified management system rather than a card-specific report, or when you have no immediate payment brand deadline. Certification is issued by an accredited certification body, not by ISO, and the certificate is valid on a three-year cycle with at least one audit every calendar year. Doing both is sensible when the PCI cardholder data environment sits inside the ISMS scope, since the policies, risk assessment and access controls can serve both. Ask any certification body and QSA to confirm in writing which evidence each will accept from the other, because a QSA may reuse SOC 2 or SOC 3 evidence only after independent review, and the same logic applies to ISO evidence.

How ISO 27001 and PCI DSS differ on scope, proof and cadence

This table compares the two standards row by row on who requires them, what they govern, how scope is drawn, what proof each produces and how often testing is due. Read it to see which differences change your evidence work and which ones only change the paperwork.

Dimension	ISO/IEC 27001:2022	PCI DSS v4.0.1
Who requires it	No law or card brand mandates it. Organizations adopt it by choice or because customers, tenders or partners ask for it.	Entities that store, process or transmit cardholder data or sensitive authentication data, or that can affect the cardholder data environment. The payment brands decide who must validate.
What it governs	An information security management system: policy, risk assessment, risk treatment, measurement and continual improvement across the organization.	Technical and process controls that protect account data in the cardholder data environment, set out as prescriptive requirements.
Scope unit	The ISMS scope, which you can narrow by organization, location or service. Clause 1 bars excluding any requirement in clauses 4 to 10.	The cardholder data environment: people, processes and system components that store, process or transmit account data, plus connected components. Requirement 12.5.2 requires you to confirm scope at least every 12 months and on significant change.
Structure	Clauses 4 to 10 plus Annex A, which lists 93 controls in four themes (organizational, people, physical and technological).	12 principal requirements grouped under six goals, from network security to an information security policy.
Proof produced	An accredited certification body issues a certificate after audit. ISO does not certify organizations itself.	An official PCI SSC template: a Report on Compliance by a Qualified Security Assessor, or a Self-Assessment Questionnaire, each with an Attestation of Compliance. Certificates are not accepted as validation.
Version status	ISO/IEC 27001:2022 is the current edition, amended by Amd 1:2024 on climate action. Certifications to the 2013 edition had to expire or be withdrawn by 31 October 2025.	PCI DSS v4.0.1 is the only active version. v4.0 was retired on 31 December 2024. Confirm with your acquirer whether a new version is scheduled.
Fixed testing cadence	No fixed test frequency. Your own risk assessment and the certification body's audit cycle set the rhythm, with at least one audit each calendar year.	External ASV scans and internal scans at least every three months. Internal and external penetration tests at least every 12 months. Segmentation tests every 12 months, or six months for service providers.

Why an ISO 27001 certificate does not count as PCI DSS validation

PCI DSS validation exists only on official PCI SSC templates, and an ISO 27001 certificate is not one of them. A PCI DSS assessment is documented either in a Report on Compliance completed by a Qualified Security Assessor or in a Self-Assessment Questionnaire, and each route ends in an Attestation of Compliance. The PCI SSC states that certificates are not recognized as validation, which means a certificate from any body, including an accredited ISMS certification body, does not substitute for the ROC or SAQ and AOC. Before you budget, ask your acquirer or the payment brand which validation route applies to your merchant or service provider level, and which form they will accept.

The two certificates come from different machinery. An ISO/IEC 27001 certificate is issued by an accredited certification body that audits against ISO/IEC 17021-1:2015 and ISO/IEC 27006-1:2024, and ISO itself does not certify organizations. A PCI DSS validation is produced by a QSA or by the entity completing an SAQ under PCI SSC templates. Neither chain produces the other, so a team that holds the ISO certificate still needs a PCI-specific assessment if card data is in scope. Ask any consultant quoting a "PCI-ready" ISO engagement to state in writing which PCI DSS deliverable, if any, they will produce.

The PCI SSC does not enforce compliance or impose penalties. The individual payment brands decide which entities must comply and validate, and they run any enforcement programs, so the authority to require PCI validation sits with your card brands and acquirer rather than with the standards body. Confirm with your acquirer which requirements and deadlines apply to your organization, because an ISO certificate will not answer that question on their behalf.

How scope works in each framework

An ISO/IEC 27001 scope defines which parts of the organization the information security management system covers. You can narrow that boundary by organization unit, physical location or service, and the certification body will audit what you declare. The limit is clause-based: the standard says that excluding any requirement in clauses 4 to 10 is not acceptable for a conformity claim, so you cannot drop the context, leadership, planning, support, operation, evaluation or improvement requirements and still claim conformity. The scope statement is a document you write and the auditor tests, so it should name the boundary clearly.

Narrowing options: A scope can cover one business unit, one country site or one service line, while the rest of the company stays outside the certificate.
Clauses stay intact: Every clause from 4 to 10 applies to whatever is inside the boundary.
Interfaces matter: Shared services, suppliers and hosting providers that touch in-scope information need to be addressed in the risk assessment.
Annex A applies inside scope: The controls are selected through the risk treatment process for the in-scope assets, not for the whole company by default.
Scope change is a management decision: Expanding or shrinking the boundary later changes what the certificate covers, so it should be planned with the certification body.

Confirm with your certification body how it reviews scope statements and whether it expects a documented rationale for every exclusion.

Where ISO 27001 and PCI DSS work overlaps

ISO/IEC 27001 and PCI DSS share control themes such as access, asset inventory and vulnerability management, so evidence built for one can often be reused for the other. The overlap is in the controls and the evidence, not in the certificate or the validation, and each card below marks where that reuse stops.

Access control to system components

The CIS Controls Navigator maps Safeguard 1.1 to ISO/IEC 27001:2022 Annex A controls 5.9 and 8.8, which cover asset inventory and technical vulnerability management. The same safeguard links to PCI DSS v4.0 requirements 9.5.1 and 9.5.1.1 on protecting media and point-of-interaction devices. Treat these as starting points for building one asset register that serves both, and confirm with your QSA which assets count inside the cardholder data environment.

Vulnerability and testing evidence

The same mapping links Safeguard 1.1 to PCI DSS requirements 11.2, 11.2.1 and 11.2.2, which concern wireless and rogue device detection and related scanning. ISO 27001 treats vulnerability handling under its technological controls, so one scan program may feed both files. Note that PCI DSS sets its own scan and test cadences, which an ISMS review cycle does not replace.

Scope and asset ownership

PCI DSS requirement 12.5 covers the entity's security responsibilities, and the mapping links it to the same asset control family. Under ISO/IEC 27001, scope is set by the organization, location or service, but no clause can be dropped. Under PCI DSS, the cardholder data environment is defined by where card data flows. Those two boundaries rarely match, so confirm early which one your certificate and your validation each describe.

Reusing SOC 2 evidence with a QSA

A QSA cannot rely on a SOC 2 or SOC 3 report for a PCI DSS assessment. The QSA may, however, reuse evidence from those audits after independently reviewing it, which can reduce duplicated evidence work. An ISO 27001 certificate does not carry the same reuse right, so ask the QSA in writing which artifacts they will accept and how they will review them.

Mappings are not equivalence

NIST does not check the correctness of non-NIST mappings, and listing a mapping does not imply endorsement. ENISA states that its own mapping is not a measure of equivalence and does not show that a standard covers a regulation fully. Read the CIS and NIST mappings as pointers to where to look, not as proof that an ISO 27001 audit satisfies a PCI DSS requirement.

Confirm each mapping with the assessor

Before relying on any overlap, take the specific control and requirement pairs to your QSA and your ISO certification body. Ask each to state in writing which evidence they accept for each pair and whether the mapping satisfies their test. Record the answers in the evidence file so that both audits draw from the same documented decision.

What drives the cost of each path

The cost of an ISO 27001 path and a PCI DSS path comes from different payees, so start by separating who you pay. For ISO 27001, the certification body is paid for the certification audits, and it is the body that issues the certificate, not the implementation partner. Your internal team or an implementer carries the work of building the ISMS, writing the Statement of Applicability and closing gaps against the Annex A controls. For PCI DSS, the Qualified Security Assessor is paid to produce a Report on Compliance, or your internal assessor completes a Self-Assessment Questionnaire and its Attestation of Compliance. Scan vendors and penetration testers are separate contracts in both cases. Ask each provider which of these items its fee covers.

Most of the one-time spend sits in scoping, gap closure and the first assessment. For PCI DSS, scoping means documenting the cardholder data environment, data flows and third-party connections, and it also drives segmentation changes, which often need network engineering and retesting before the first assessment can start. For ISO 27001, the one-time work is defining the ISMS scope and closing gaps across the four Annex A themes. Recurring spend follows fixed frequencies. PCI DSS requires quarterly internal and external scans, annual penetration tests and segmentation tests, with six-month cadences for service providers, and scope confirmation at least every 12 months. ISO 27001 certificates run on a three-year cycle with an audit in each calendar year, so surveillance audits recur annually.

When requesting quotes, ask every bidder for the same written inputs: the scope statement, the list of systems and applications counted, the number of sites or locations, the data flows and third-party connections included, and the frequencies of scans, penetration tests and audits priced. Confirm whether a quote covers re-assessment after significant change and whether surveillance or recertification is included. No figures are given here because none are supplied for this comparison. Ask each certification body and QSA for its own fee basis, and confirm current PCI SSC requirements and the certification body guidance from ISO before budgeting.

Sequencing both frameworks without duplicated evidence

The sequence starts from the payment obligations that actually apply, shrinks the cardholder data environment before testing it, and only then extends an ISMS so that control evidence is written once and reused. The order shifts with your obligations, so treat it as a starting point to confirm with your acquirer and QSA.

Confirm which payment obligations apply
Establish which payment brands and acquirer agreements bind your company, since PCI DSS applies to every merchant regardless of size, but the brands decide which entities must validate and how. Ask your acquirer which validation type (ROC or SAQ, and which SAQ) and which quarterly and annual deliverables it expects. The step is done when you hold a written statement of the validation level and the deadline your acquirer or brand has set, with the named owner who receives it.
Define the cardholder data environment
Map every system, person and process that stores, processes or transmits account data or sensitive authentication data, plus any component with unrestricted connectivity to them. Because scope is defined by where card data lives and flows, this map is built from data flow diagrams and asset inventories rather than from the ISMS scope statement. The step closes with a CDE inventory that lists each component, owner and connection, reviewed by security and the team that runs payment operations.
Shrink the CDE through segmentation
Remove systems from the CDE where a sound design allows, using network segmentation, tokenization or outsourcing of card capture to a validated provider. Smaller scope reduces the number of controls and the number of systems that the recurring scans and penetration tests must cover. Confirm the segmentation controls with a segmentation test before you rely on them, and record each change in the inventory so the final scope statement can be traced back to it.
Complete the PCI scope confirmation
Document the scope confirmation that Requirement 12.5.2 requires: data flows, account data locations, connected components, segmentation controls and third-party connections. Your company performs this itself at least every 12 months and after significant change, and service providers do it every six months. The step is complete when the scope document is signed by the accountable owner and matches the inventory from the previous step, so the QSA or SAQ answers start from one agreed boundary.
Close gaps and validate with a ROC or SAQ
Work through the PCI DSS requirements that apply to your scope, using the defined approach or, where your risk management is robust enough, the customized approach. Schedule the ASV and internal scans, penetration tests and segmentation tests against the fixed frequencies in the standard. Validation is finished only when the official ROC or SAQ and its Attestation of Compliance are completed and accepted by your acquirer, because vendor or consultant certificates are not recognized as validation.
Extend the ISMS and reuse evidence
Once the card environment is validated, extend the ISMS to the wider company and map each Annex A control to the PCI requirements it already satisfies, using the CIS Controls Navigator and the NIST informative references as cross-checks rather than as proof. Ask your QSA which evidence it can reuse from ISMS audits after independent review, and record that answer in writing. The step is complete when one evidence register serves both assessments and the certification body accepts the scope you chose for the ISMS.

Questions buyers ask before hiring help

Does an ISO 27001 certificate satisfy PCI DSS?

No. An ISO/IEC 27001 certificate is issued to an information security management system after a certification body audits it, and it is not PCI DSS validation. PCI SSC accepts only its official templates (a Report on Compliance completed by a Qualified Security Assessor, or a Self-Assessment Questionnaire, each with an Attestation of Compliance), and it states that certificates are not recognized as validation. Some control evidence can overlap, and a QSA may reuse evidence from SOC 2 or SOC 3 reports after independently reviewing it, but the QSA still performs the PCI assessment. Confirm the exact evidence reuse rules with your QSA before you plan the work. See PCI SSC FAQ 1220.

Who must validate PCI DSS, and who decides?

PCI DSS applies to all merchants regardless of size or transaction volume, and volume and channel only change how validation is done. The PCI Security Standards Council owns the standard but does not enforce it or impose penalties. The individual payment brands decide which entities must validate, which validation type applies and how enforcement works. Ask your acquirer or payment brand which validation level and documents they expect, because that answer determines whether you need a QSA-led ROC or a self-assessment.

Can we narrow the ISMS to the card payment service?

Yes, within limits. ISO/IEC 27001:2022 lets you define scope by organization, location or service, so a certificate can cover only the card payment service. You cannot drop clauses 4 to 10 and still claim conformity. For PCI DSS, scope is set by the cardholder data environment, which includes systems that store, process or transmit card data plus systems with unrestricted connectivity to them. Requirement 12.5.2 requires you to confirm that scope at least every 12 months and after significant change. The two scopes often differ, so map them before you decide where the boundary sits. Confirm the boundary with your certification body and QSA together.

What does each framework need from our staff?

Both need named owners, documented policies and evidence that people follow them, but the work differs. An ISMS needs staff to run risk assessments, manage the statement of applicability, handle internal audits and management review, and keep records current through a three-year certification cycle. PCI DSS needs staff to maintain the cardholder data environment inventory, run the fixed testing schedule, manage access and change records and answer the QSA's evidence requests. Expect the PCI work to demand closer hands-on involvement from network, payment and operations teams. Ask your provider which roles they expect your staff to fill.

How long does the work take?

The supplied research does not give a duration for either project, so treat any timeline as unknown until a written scope exists. The durations that do matter are fixed. PCI DSS requires external ASV scans and internal scans at least every three months, penetration tests at least every 12 months, and segmentation tests every 12 months (every six months for service providers). An ISO 27001 certificate cycle lasts three years with at least one audit each calendar year. Ask for a schedule that lists the first assessment, evidence collection, remediation and each recurring test date.

What drives cost up or down, and what should a quote include?

Cost depends on how many systems and locations fall in scope, how much evidence already exists, how segmented the network is, and whether you need a full ROC or a self-assessment. For ISO 27001, the certification body is paid for the audit and the cycle, and an implementation partner is paid for the design work. For PCI DSS, the QSA or your own staff handles assessment, and ASV scanning and penetration testing recur. A useful quote lists scope boundaries, deliverables, named responsibilities, the fixed test cadence, what is one-time and what recurs, and what is excluded. DeployOpen does not publish prices, and its quotes follow from a written scope.

Can we run the work ourselves?

Yes, for many organizations, if the team has the time and skills. You can build the ISMS and the PCI evidence internally, but the assessments must come from independent parties: a certification body for ISO 27001, and a QSA or an eligible self-assessment for PCI DSS. Your ASV scans must come from an approved scanning vendor. Ask the payment brand whether a self-assessment is acceptable for your transaction profile, and ask your certification body which audit route it accepts. DeployOpen plans, implements, hardens and supports self-hosted platforms in your own environment, and its scope and deliverables are agreed in writing before work starts.

What DeployOpen prepares and what auditors decide

DeployOpen does not issue ISO 27001 certificates, PCI DSS Reports on Compliance, Self-Assessment Questionnaires or Attestations of Compliance. Accredited certification bodies issue ISO/IEC 27001 certificates, and a Qualified Security Assessor (QSA) completes a ROC or the SAQ is completed by the merchant or service provider with its own AOC. For both frameworks, DeployOpen works on the material that those assessors later review: the ISMS documentation and risk treatment records for ISO 27001, and the cardholder data environment (CDE) scope, network and segmentation design, configuration evidence and policies for PCI DSS. Your certification body or QSA decides whether that evidence is sufficient.

DeployOpen can also run the security testing that feeds PCI DSS evidence, including penetration testing and segmentation testing in the client's own cloud accounts, data centers or air-gapped networks. Before any test is scheduled, confirm with your QSA which test methodology, tester independence and reporting format they will accept. Some PCI testing requirements are performed by a qualified internal resource rather than an outside firm, so ask whether your assessor expects an external tester for each item. DeployOpen's testing results support the assessment; they do not replace the QSA's review or the ASV scan attestation.

Engagements are fixed-scope. Before work starts, the scope, deliverables and timelines are agreed in writing, and a quote follows from that written scope rather than from a published price list. When you request a quote, ask for the CDE and ISMS boundaries that the scope assumes, the assumed number of systems and sites, which artifacts are delivered and in what format, whether retesting is included, and what is excluded, such as ongoing support. Ongoing support, upgrades and continuous testing are available as retainers and are priced separately from the initial scope.

How DeployOpen scopes and supports both frameworks

DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside the client's own infrastructure, and prepares systems and evidence for compliance assessments. DeployOpen does not issue audit reports, attestations or certifications, so the ISMS certification body and the PCI DSS assessor remain the parties that issue proof.

How we scope

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
The written scope separates the ISMS boundary for ISO 27001 from the cardholder data environment for PCI DSS.
Scoping workshops map data flows, account data locations, connected components and third-party connections for each framework.

How we build

Controls, configurations and logging are implemented in the client's own cloud accounts, data centers or air-gapped networks.
Security testing of applications, APIs and infrastructure is scheduled against the PCI DSS testing cadences in the agreed scope.
Segmentation and access controls are built once and reused as evidence for both the ISMS and the card data environment.

How we hand over

Deliverables include system documentation, control evidence and records prepared for the client's assessor or certification body.
Official PCI SSC templates are completed by the client's QSA or the client, and DeployOpen does not complete the attestation itself.
Handover covers runbooks, backup and upgrade procedures, and a list of open items the client must confirm with its assessor.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the initial engagement.
Retainers can keep scope statements, asset inventories and evidence current across the ISMS cycle and PCI assessment dates.
Ask for a written quote that lists scope, deliverables, testing frequency and who is responsible for each assessor fee.

ISO 27001 vs PCI DSS