PCI DSS v4.0.1 vs NIS2: What Your Card-Data Programme Already Covers — and the 6 Gaps Outside the CDE

A PCI DSS v4.0.1 programme covers a good share of the control types NIS2 asks for: multi-factor authentication, logging, encryption, vulnerability scanning, awareness training and a tested incident response plan. It covers them inside one boundary, the cardholder data environment (CDE). Article 21(1) of NIS2 draws a different boundary: every network and information system the entity uses “for their operations or for the provision of their services”. That difference produces six gaps, and none of them closes by itself when you pass your next assessment.

There is no official crosswalk to lean on, either. We searched ENISA’s 170-page NIS2 Technical Implementation Guidance, its v1.2 mapping table and the NIS Cooperation Group’s June 2026 reference document with its mapping annex. PCI DSS appears zero times. The EU mappings cover ISO 27001, NIST CSF 2.0, ETSI EN 319 401, CEN/TS 18026 and IEC 62443, with a warning that a mapping “should not be interpreted as a measure of equivalency”. Every PCI-to-NIS2 mapping, including this one, is someone’s own analysis.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Does NIS2 apply to your PCI-scoped business?

In plain terms: PCI DSS follows the card, so anyone who stores, processes or transmits card data is in. NIS2 follows sector and size, so most card-accepting businesses are out, and banks mostly answer to DORA.

NIS2 applies to entities of a type listed in Annex I or II that are at least medium-sized (Article 2(1)), with some size-independent exceptions. Retail is not an Annex sector, and the food sector covers only “wholesale distribution and industrial production and processing” (Annex II, sector 4), so a supermarket chain is usually outside NIS2. The overlap sits here:

Business type	PCI DSS role	NIS2 position	What this means
Credit institutions (banks that issue or acquire cards)	Issuer and/or acquirer	Listed in Annex I (sector 3), but DORA Article 1(2) makes DORA the sector-specific act under NIS2 Article 4	DORA governs most obligations; see what DORA leaves for NIS2 in banking
Payment and e-money institutions	Service provider	Not listed in Annex I or II	In scope of DORA (Article 2(1)(b) and (d)), not NIS2; see the fintech scope map
Cloud, data centre, managed service and managed security providers hosting card environments	Third-party service provider	Annex I, sectors 8 and 9	The CIR’s detailed annex binds you directly; see NIS2 for MSPs and MSSPs
Online marketplaces taking card payments	Merchant	Annex II, sector 6	The CIR binds you directly; see online marketplaces
Airlines, railways, energy suppliers, hospitals, postal and courier firms	Merchant	Annex I or II by sector	Article 21 applies through national law, not the CIR
Retailers, hotels, restaurants	Merchant	Usually out of scope	PCI only, unless another activity puts you in an Annex sector

Quick check, in order:

1. Is your activity in a sector listed in Annex I or II? If no, NIS2 almost certainly does not apply, whatever your card volumes.
2. Are you at least a medium-sized enterprise under Commission Recommendation 2003/361/EC (50 or more staff, or both turnover and balance sheet above €10 million)? If no, check the size-independent cases in Article 2(2)–(4).
3. Are you one of the eleven digital provider types in Article 1 of the Commission Implementing Regulation (EU) 2024/2690 (the CIR)? Then the annex points cited below bind you directly. Everyone else gets the detail from national law.

For the full applicability test, see the NIS2 scope guide.

PCI DSS and NIS2 at a glance: a contract and a law

In plain terms: PCI DSS is a private standard you accept by contract. NIS2 is EU law, enforced by national authorities, with fines and management accountability.

PCI DSS v4.0.1 was published on 11 June 2024 as a limited revision with “no additional or deleted requirements”, and it became the only active version when v4.0 retired on 31 December 2024, according to the PCI Security Standards Council. The Council writes the standard but does not police it. Its own At a Glance overview states that enforcement and “determination of any non-compliance penalties are carried out by the individual payment brands”.

Dimension	PCI DSS v4.0.1	NIS2
Legal nature	Industry standard, imposed by contract	EU directive, transposed into national law
Who enforces	Payment brands, through acquirers	National competent authorities
What is protected	Account data	The services the entity provides
Scope boundary	CDE plus connected and security-impacting systems	All network and information systems used for operations or services
Validation	Assessment (ROC or SAQ) as the brands and acquirer require; quarterly ASV scans	Supervision by the competent authority under Articles 32 and 33, including on-site inspections and security audits
Incident notification	Payment brands and acquirers	CSIRT or competent authority: 24 hours, 72 hours, one month
Maximum penalties	Contractual; set by the payment brands, no public EU-wide schedule	At least €10M or 2% of worldwide turnover (essential); at least €7M or 1.4% (important), whichever is higher (Article 34(4)-(5))

A 2026 preprint from Dakota State University, Weak Enforcement and Low Compliance in PCI DSS, estimates card-brand penalties at $5,000 to $100,000 per month, “orders of magnitude smaller” than NIS2 fines. It is not peer-reviewed and brand fines are not published centrally, so treat that as an indication. NIS2 sets floors for the maximum fines; national law sets the caps (see the NIS2 penalties guide).

Requirement by requirement: where PCI evidence carries over

In plain terms: most of the ten Article 21(2) measures have a PCI counterpart, strong for technical controls and weak for governance, continuity and reporting. In every row, the evidence stops at the CDE boundary.

NIS2 measure	Closest PCI DSS v4.0.1 requirement	Reuse verdict
21(2)(a) Risk analysis and security policies	12.1 policy, reviewed every 12 months (12.1.2); 12.3.1 targeted risk analyses	Partial. Policy reusable once widened; CIR 1.1.2 wants the management body to review it. Risk analysis is Gap 2
21(2)(b) Incident handling (incl. CIR 3.2 logging)	12.10.1 plan, reviewed and tested every 12 months (12.10.2); Requirement 10 logging, 12-month retention (10.5.1)	Strong for handling and logging. Authority reporting is Gap 5
21(2)(c) Business continuity, backup, disaster recovery, crisis management	Two bullets inside 12.10.1: “business recovery and continuity procedures” and “data backup processes”	Weak. Gap 3
21(2)(d) Supply chain security	12.8.1–12.8.5 third-party service providers (TPSPs); 12.9 for service providers	Partial. Gap 4
21(2)(e) Acquisition, development, maintenance, vulnerability handling and disclosure	Requirement 6 (incl. 6.4.3 payment page scripts); 11.3.2 quarterly ASV scans; 11.4.3 annual external penetration test	Strong for handling. Add a disclosure procedure (CIR 6.10.2(e))
21(2)(f) Assessing effectiveness	Periodic ROC or SAQ assessment; Requirement 11 testing	Partial. CIR 7 wants your own policy, informed by risk results and past incidents
21(2)(g) Cyber hygiene and training	12.6.3 training on hire and every 12 months; 12.6.3.1 phishing and social engineering	Strong for staff. Management-body training is separate (Article 20(2))
21(2)(h) Cryptography	Requirements 3 and 4	Strong for account data. Extend to other data classes
21(2)(i) HR security, access control, asset management	Requirements 7 and 8; 12.5.1 inventory of in-scope components	Strong inside the CDE. The inventory must cover the whole estate
21(2)(j) Multi-factor authentication	8.4.2 MFA for all non-console access into the CDE	Strong inside the CDE. CIR 11.7.1 sets MFA by asset classification across the entity

In three places PCI is stricter than NIS2. It fixes numbers where NIS2 does not: quarterly scans by an Approved Scanning Vendor, log retention of at least 12 months with three months immediately available, and a scope re-confirmation every 12 months (every six for service providers). The CIR asks only for scans “at planned intervals” (6.10.2(b)) and logs kept “for a predefined period” (3.2.5). PCI also regulates payment page scripts (6.4.3), which the CIR never names. In short: PCI tells you how often, NIS2 tells you how far.

Treat vendor mappings with care. One presented at the PCI SSC Europe Community Meeting pairs “Business Continuity/Resilience” with Requirement 12.10.1 alone and cites the NIS2 MFA measure as Article 21(1)(j); it is 21(2)(j). The same pattern shows up in the SOC 2 comparison and the ISO 27001 and NIST CSF comparison: a framework can map to every measure heading and still miss the obligation underneath.

The six gaps outside the CDE

In plain terms: six things a supervisor can ask for that PCI DSS evidence cannot answer, however good your last assessment was.

Gap 1: Everything outside the cardholder data environment

PCI scope is designed to be small. Requirement 12.5.2 asks you to confirm “all system components in the CDE, connected to the CDE, or that could impact security of the CDE”, and tokenisation, segmentation and hosted payment pages exist to shrink that set. NIS2 runs the other way. An airline’s crew scheduling system never touches a card number, yet it supports the services Article 21(1) protects.

The paradox: the better you have reduced PCI scope, the less of your NIS2 estate your PCI evidence describes. A merchant on a hosted payment page may have an almost empty CDE and an untouched NIS2 workload.

Gap 2: An entity-wide risk assessment, not targeted risk analyses

PCI v4 introduced targeted risk analyses (12.3.1), but each one exists “for each PCI DSS requirement that specifies completion of a targeted risk analysis”, usually to justify a control frequency. CIR 2.1.1 wants a risk management framework covering all network and information systems, a documented risk treatment plan, and residual risks accepted by the management body (or by accountable persons who report to it). CIR 2.1.2(d) adds an all-hazards approach, so third-party failures and threats to the physical environment of your systems belong in the register too. Your targeted risk analyses are inputs, not the assessment.

Gap 3: Business continuity, disaster recovery and crisis management

Requirement 12.10.1 asks for “business recovery and continuity procedures” and “data backup processes” as bullets inside the incident response plan. CIR section 4 asks for a business impact analysis (4.1.3), a business continuity and disaster recovery plan (4.1.1), backup plans with recovery times, off-network storage and retention periods (4.2.2), and a crisis management process (4.3.1). PCI is built to protect account data, not to keep services running, which is why practitioner mappings point continuity back to 12.10.1. NIS2 asks how long each service can run without its systems. See the business continuity guide.

Gap 4: Suppliers that never touch card data

Requirement 12.8.1 covers TPSPs “with which account data is shared or that could affect the security of account data”. NIS2 Article 21(2)(d) covers all direct suppliers and service providers, and Article 21(3) asks you to weigh the vulnerabilities specific to each. The CIR adds selection criteria PCI has no equivalent for, including the ability “to diversify sources of supply and limit vendor lock-in” (5.1.2(d)), and contracts that oblige suppliers to report incidents (5.1.4(d)). Your PCI responsibility matrix (12.8.5) covers the card-facing slice of the supplier register.

Gap 5: Reporting to a CSIRT, not to the card brands

Requirement 12.10.1 requires “notification of payment brands and acquirers, at a minimum” and an “analysis of legal requirements for reporting compromises”. That second bullet is where NIS2 belongs, but PCI leaves the content to you. Article 23(4) sets the clock: an early warning within 24 hours of becoming aware of a significant incident, a notification within 72 hours, and a final report within one month of the notification. The trigger is different too. Article 23(3) asks whether an incident caused, or could cause, severe operational disruption, financial loss or considerable damage to others; a card brand asks whether account data was compromised. A ransomware outage on systems outside the CDE can be reportable under NIS2 without ever touching your PCI process. A card data breach can trigger both, and often GDPR as well (see NIS2 vs GDPR).

Gap 6: Management-body approval, oversight and training

PCI’s governance requirement, 12.4.1, assigns executive responsibility for a PCI compliance programme and applies to service providers only. Article 20(1) requires management bodies to approve the risk-management measures, oversee their implementation, and provides that they “can be held liable” for the entity’s infringements of Article 21. Article 20(2) requires members of the management body to follow training. Merchants have no equivalent of 12.4.1, so board involvement in PCI is a choice. Under NIS2 it is a legal duty. See board liability under Article 20.

Who does what when you run both

Role	Reuse from PCI	Build for NIS2
CISO / IT security	MFA, logging, scanning, crypto and hardening standards	Extend those standards to non-CDE systems; full asset inventory; disclosure procedure
Compliance officer	Policy set, TPSP matrix, annual review cycle, assessment evidence	Entity-wide risk register and treatment plan; national registration; authority reporting procedure
SME owner	Your SAQ routine	Check scope first: many card-accepting SMEs are not NIS2 entities
Board / C-suite	Little: 12.4.1 applies to service providers only	Approve measures, oversee them, attend training, accept residual risks

Closing the gaps: a six-step plan

1. Map the scope delta (Medium effort). List the systems behind your NIS2-relevant services and mark which sit inside PCI scope. The rest is new work.
2. Widen the policy set and the risk assessment (High). Lift PCI policies to entity level and run a full risk assessment, with residual risks accepted by management.
3. Build continuity from the business impact analysis outward (High). BIA, then continuity and recovery plans, backup plans and a crisis process, tested.
4. Extend the supplier register beyond TPSPs (Medium). Add non-card suppliers, rate them, and add security and incident-notification clauses.
5. Add an authority track to the incident plan (Low to Medium). A significance test based on Article 23(3), the 24-hour, 72-hour and one-month templates, and your CSIRT contact details next to the acquirer’s.
6. Bring the board in (Low). Formal approval of the measures, a training record and a standing oversight agenda item.

Frequently asked questions

Does PCI DSS compliance count as NIS2 compliance?
No. NIS2 Article 4 can switch off NIS2 obligations only where a sector-specific Union legal act imposes equivalent ones. PCI DSS is a private industry standard, and neither ENISA nor the NIS Cooperation Group maps it. Your PCI evidence supports NIS2 compliance for the systems it covers.

Do we have to report a card data breach under NIS2?
Only if it is a significant incident under Article 23(3), which looks at operational disruption, financial loss and damage to others. Many card breaches will meet that test; some won’t. The brand and acquirer notification under PCI applies either way.

We are a bank. Which applies?
For most obligations, DORA. DORA Article 1(2) makes it the sector-specific act for financial entities that are NIS2 entities, and payment and e-money institutions are not in the NIS2 annexes at all. PCI applies alongside both through your card scheme agreements.

Sources

• Directive (EU) 2022/2555 (NIS2), EUR-Lex: Articles 2(1)–(4), 4(1), 20(1)–(2), 21(1)–(3), 23(3)–(4), 32(2), 33(2), 34(4)–(5); Annex I sectors 3, 8 and 9; Annex II sectors 4 and 6.
• Commission Implementing Regulation (EU) 2024/2690, EUR-Lex: Article 1; Annex points 1.1.2, 2.1.1, 2.1.2(d), 3.2.5, 4.1.1, 4.1.3, 4.2.2, 4.3.1, 5.1.2(d), 5.1.4(d), 6.10.2(b) and (e), 7, 11.7.1.
• Regulation (EU) 2022/2554 (DORA), EUR-Lex: Articles 1(2) and 2(1).
• Commission Recommendation 2003/361/EC concerning the definition of micro, small and medium-sized enterprises, EUR-Lex: Annex, Article 2.
• PCI Security Standards Council, “Just Published: PCI DSS v4.0.1”, PCI Perspectives blog, 11 June 2024.
• PCI Security Standards Council, At a Glance: PCI Security Standards Council, February 2021.
• PCI Security Standards Council, FAQ 1212: the Council’s involvement in compliance validation.
• PCI DSS v4.0.1 requirement text (Requirements 6.4.3, 8.4.2, 10.5.1, 11.3.2, 11.4.3, 12.1.2, 12.3.1, 12.4.1, 12.5.1, 12.5.2, 12.5.2.1, 12.6.3, 12.6.3.1, 12.8.1–12.8.5, 12.9.1, 12.10.1–12.10.2), checked against the Cloudaware compliance-policies mirror. The official standard is available from the PCI SSC Document Library under licence.
• ENISA, NIS2 Technical Implementation Guidance, version 1.0, June 2025, and its mapping table, version 1.2, September 2025. Non-binding.
• NIS Cooperation Group, Reference document on security measures for entities under NIS2, version 1.0, June 2026, and its mapping annex. Non-binding.
• Olivier Takam (ControlCase), “Bridging the Gap Between PCI DSS and EU Regulations”, PCI SSC Europe Community Meeting presentation.
• Soonwon Park and John D. Hastings, “Weak Enforcement and Low Compliance in PCI DSS: A Comparative Security Study”, arXiv:2512.13430v2, February 2026. Preprint, not peer-reviewed.

Verification note: NIS2, CIR and DORA citations were checked against the official English texts on EUR-Lex. PCI DSS requirement numbers and wording were checked against a v4.0.1 text mirror, because the official standard is licence-gated. “Zero mentions” refers to full-text searches of ENISA’s 170-page guidance, ENISA’s v1.2 mapping table and the NIS Cooperation Group’s June 2026 document and mapping annex.