Running PCI DSS and ISO 27001 Together: One Program, Not Two

An SMB that accepts card payments and also pursues ISO 27001 certification often ends up running two compliance programs: a PCI track for the acquirer and an ISMS track for the certificate. The expensive part is not either standard — it is the duplication. Most of the work is the same work, written down twice.

PCI DSS v4.0.1 and ISO/IEC 27001:2022 are different instruments. PCI DSS is a prescriptive, payment-scoped technical standard validated annually against a single card-data environment. ISO 27001 is a management-system standard — define scope, run a risk assessment, pick controls, operate the system, audit it. They are not the same, but they share a large evidence surface: access control, logging, vulnerability management, incident response, network segmentation, crypto, secure development, vendor management. An SMB that merges them into one operating program pays for that surface once.

This article maps the overlap, names where the standards genuinely diverge, and gives the evidence-sharing pattern. It is the cross-pillar companion to the PCI DSS pillar and the ISO 27001 pillar.

Why an SMB ends up with both

The triggers are independent. Card acceptance pulls in PCI DSS whether you want it or not — your acquirer requires it. ISO 27001 is a choice, usually pulled in by a customer security questionnaire, a public-sector or enterprise contract requirement, or a genuine internal decision to build a security program. An SMB that hits both within a year or two rarely plans the overlap; it acquires each as a separate project and discovers the duplicate cost in the second year of evidence collection.

The fix is to treat the two as one program with two reporting outputs, designed from the start.

Scope: the ISMS scope contains the CDE

ISO 27001 lets you define the ISMS scope (clause 4.3). PCI DSS defines the cardholder data environment (CDE) scope by where card data flows. The efficient shape is to make the CDE a sub-scope inside the ISMS: the ISMS covers the whole organization (or the in-scope business unit), and the CDE is the higher-assurance zone within it. The PCI scope reduction work shrinks the CDE; the ISMS scope holds the broader perimeter. One network diagram serves both — the CDE boundary is marked on it.

This is also where segmentation earns twice. PCI DSS segmentation (requirement 4) isolates the CDE from the rest of the network; ISO 27001 Annex A.8.22 segregation of networks is the same control. Build it once, cite it in both audits.

Risk assessment: one assessment, two cuts

ISO 27001 mandates a risk assessment (clauses 6.1.2, 6.1.3) covering the ISMS scope — identify assets, threats, vulnerabilities, evaluate risk, select controls, produce a Statement of Applicability. The ISO 27001 risk assessment is the broad artifact.

PCI DSS does not require a full ISMS risk assessment, but it does require targeted risk analyses (requirement 12.3.1) wherever a control’s frequency is flexible, and an annual risk assessment for the CDE under requirement 12.3.1.1. The TRA template is a narrow, frequency-focused slice.

The merge: run the ISO 27001 risk assessment once at ISMS scope, then carve the CDE-relevant risks into PCI TRA entries. Same asset register, same threat list, two report cuts. The PCI assessor sees the TRA rows; the ISO 27001 auditor sees the full register and SoA. One analysis, two documents generated from it.

Control mapping: Annex A meets the PCI requirements

ISO 27001:2022 Annex A and the PCI DSS requirement set overlap on the operational controls. A combined control matrix (one row per control, two columns: PCI requirement number + Annex A control) saves the duplicate policy writing:

Write each control once (one policy, one procedure, one evidence routine) and map it to both standards. The payment-page specifics — 6.4.3 script management and 11.6.1 tamper detection — are PCI-only; everything else on the table above is shared.

Where the standards genuinely diverge

Not everything merges. The pieces that stay separate:

• **Payment-specific technical controls.** 6.4.3, 11.6.1, P2PE, POI device handling, CHD storage prohibition (3.2/3.4). ISO 27001 has no analog. These are the PCI-only work.
• **The Statement of Applicability.** ISO 27001 produces an SoA justifying each Annex A control included or excluded. PCI DSS has no SoA concept. The SoA template is an ISO 27001-only artifact.
• **Management-system clauses.** ISO 27001 clauses 5 (leadership), 9 (performance evaluation, internal audit 9.2, management review 9.3), 10 (continual improvement) are the ISMS machinery. PCI DSS has no management-system requirement; it has a single annual assessment. These clauses are ISO 27001-only work.
• **Audit cadence.** PCI DSS = annual assessment (SAQ or QSA RoC). ISO 27001 = internal audit at least annually (9.2), management review (9.3), surveillance audits during the three-year certification cycle. Schedule them so the internal audit feeds both.

The rule: operational controls merge; payment-specific controls and ISMS management clauses do not.

The evidence-sharing pattern

The practical merge is an evidence folder organized by control topic, not by standard:

evidence/
  access-control/        # policy + access reviews → PCI 7,8 + A.5.15
  logging/               # log config + review records → PCI 10 + A.8.15
  vuln-mgmt/             # scan reports + remediation → PCI 6.3,11.3 + A.8.8
  segmentation/          # network diagram + rules → PCI 4 + A.8.22
  incident-response/     # IRP + test records → PCI 12.10 + A.5.24
  payment-page/          # script inventory, CSP, SRI, tamper → PCI 6.4.3, 11.6.1
  risk/                  # full register + TRA rows cut from it
  soa/                   # Statement of Applicability (ISO only)
  isms-governance/       # mgmt review, internal audit minutes (ISO only)

When the PCI assessor asks for incident-response evidence, you point at incident-response/. When the ISO 27001 auditor asks the same, the same folder. The payment-page/ and soa/ and isms-governance/ folders are the single-standard work — isolated so the shared controls stay clean.

The cadence: align the years

Run the two cycles on a single annual heartbeat:

1. Risk refresh — update the ISO 27001 risk assessment; cut the new TRA rows for PCI. 2. Control review — walk the combined matrix; update policies; record evidence. 3. Internal audit (ISO 27001 9.2) — audit the merged program against both standards’ control expectations. 4. Management review (9.3) — present results, including PCI compliance status. 5. PCI assessment — file the SAQ or host the QSA using the same evidence folders.

Staggering them so the internal audit lands a few weeks before the PCI assessment gives you a dry run: gaps found internally get fixed before the assessor sees them.

What this saves

The duplicate cost of running two programs is mostly people time — two risk assessments, two sets of policies, two evidence-gathering sprints, two audit prep cycles. Merging collapses that to one of each, plus the single-standard work (payment-page controls, SoA, ISMS governance). For an SMB, the merge is typically the difference between compliance being a full-time distraction and compliance being a maintained operating state.

How this fits the series

This is the cross-pillar bridge between the PCI DSS pillar and the ISO 27001 pillar. It assumes you have read the ISO 27001 risk assessment and the PCI scope reduction pieces, because the merge rests on a single risk assessment and a CDE nested inside the ISMS scope. The TRA template and SAQ guide are the PCI-side outputs; the SoA template is the ISO 27001-side output.

What to do next

If you are running both standards as separate projects, the first move is the combined control matrix — one row per topic, the PCI requirement and Annex A control side by side. That single document shows you the overlap and the single-standard tails in one view. Reorganize your evidence folders by control topic, not by standard. Schedule the internal audit ahead of the PCI assessment so the same evidence gets reviewed twice for free.

Running PCI DSS and ISO 27001 as separate projects and paying for it twice? Book a **joint-program design session** — we build the combined control matrix, map your existing evidence to both standards, and sequence the audit cadence so one internal audit feeds both. Bilingual EN/FR, no obligation.

→ /pci-dss-assessment/ · /iso-27001-assessment/