PCI DSS Compliance: 2026 Guide to Documentation and Incident Readiness

Date: 17 August 2026

PCI DSS is the global data security standard for any organisation that stores, processes, or transmits payment card data, currently governed by version 4.0.1 and built around 12 core requirements.

As of 31 March 2025, dozens of previously "future-dated" 4.0.1 requirements, including targeted risk analyses and expanded multi-factor authentication, became fully enforceable. Non-compliant organisations face monthly fines from card brands ranging from roughly $5,000 to $100,000, on top of forensic investigation costs if a breach occurs. Compliance validation and evidence live in two places: your Report on Compliance or Self-Assessment Questionnaire. The part most organisations underbuild is incident response documentation and readiness.

Here's what the 12 requirements demand in practice, where the 4.0.1 changes bite hardest, and why incident response documentation and trained people are the piece most PCI programmes treat as an afterthought until it's too late.

What PCI DSS Actually Is And Whom it Applies To

The Payment Card Industry Data Security Standard is not law. It's a contractual requirement enforced by the payment card brands (Visa, Mastercard, American Express, Discover, JCB) through your acquiring bank or payment processor. If your organisation stores, processes, or transmits cardholder data, or could affect the security of that data, PCI DSS applies to you regardless of your size or sector.

Your obligations scale with how much card data you handle, measured through merchant levels based on annual transaction volume:

A merchant's total transaction volume over a 12-month period determines the level and the exact validation route required. Visa Service providers (payment processors, hosting providers, and anyone else who touches cardholder data on a merchant's behalf) have their own, generally stricter, tiering. So if you provide services to merchants rather than selling directly to cardholders, check your processor's specific requirements rather than assuming merchant rules apply to you.

The 12 Requirements, and What "Documentation" Means for Each

PCI DSS organises its controls into 12 requirements across 6 control objectives. The table below is the one worth bookmarking. Every SAQ and every ROC ultimately traces back to this structure.

Requirement 12 is where most of the documentation load concentrates. It's also where the standard's newest mandatory obligation now lives.

PCI DSS 4.0.1: The Deadlines that Already Passed And What's Still Ahead

PCI DSS 4.0.1 is the current version of the standard, published as a limited revision addressing feedback and clarification requests raised since 4.0 was released. PCI Security Standards Council Its Report on Compliance and SAQ templates are now the only ones assessors accept. The 4.0 versions have been retired.

The critical date already behind most organisations: 31 March 2025, when a large batch of requirements that had been "future-dated" (meaning best practice until then, mandatory after) became fully enforceable. Two changes from that batch are worth calling out specifically because they carry real documentation weight:

• Requirement 12.3.1: Targeted risk analyses are now mandatory paperwork. Any requirement where the standard gives you flexibility on frequency or method now requires a documented, formal risk analysis justifying your chosen approach. This isn't a box-tick. Assessors expect to see the actual analysis, not a statement that one exists.
• Expanded multi-factor authentication requirements: MFA now needs to cover all access into the cardholder data environment, not just remote access, with documented evidence of implementation and configuration.

If your organisation hasn't produced the targeted risk analysis documentation for every requirement where you're using flexibility, that's very likely your single biggest open gap heading into your next assessment cycle — it's a new document type most PCI programmes haven't built a template for yet.

Where PCI DSS Non-Compliance Actually Costs You Money

The fines aren't set by PCI SSC directly. They're levied by card brands through your acquiring bank, and acquirers frequently pass them straight through to merchants. In practice, non-compliant organisations face:

• Monthly fines ranging from roughly $5,000 to $100,000, at the card brand's discretion, scaling with how long the organisation has been out of compliance.
• Elevated per-transaction processing fees imposed by the acquirer.
• Mandatory forensic investigation costs if a breach occurs while non-compliant. These regularly dwarf the monthly fines themselves.
• In persistent cases, suspension of card processing privileges entirely.

The forensic investigation point matters more than the headline fine figures: if a breach happens and you can't produce your required documentation, your risk analyses, your access logs, your incident response plan and evidence it was followed, the investigation takes longer, costs more, and the finding is far more likely to conclude you were non-compliant at the time of the breach, which is what actually triggers the largest exposure.

The Requirement Almost Everyone Underbuilds: Incident Response

Requirement 12.10 sits inside the "organisational policies and programs" bucket, and it's easy to treat as a formality next to the technical requirements around encryption and network segmentation. That's a mistake for two reasons.

First, a documented-but-untested incident response plan fails the same way a CAF response plan fails: the document exists, but nobody in the room can execute it under real pressure. An assessor (or a real breach) exposes that gap fast.

Second, PCI incident response has PCI-specific obligations layered on top of general good practice. Notification timelines to your acquirer and the card brands, preservation of forensic evidence in a way that satisfies a PCI Forensic Investigator, and a defined process for card brand-mandated post-breach validation. Generic incident response training and generic incident response plans don't cover this layer, because it isn't part of most general cyber security curricula.

This is exactly the gap that our NCSC Assured Cyber Incident Planning and Response (CIPR) course is built to close. It's one of the small number of courses that carries NCSC Assured Training status, meaning it's been independently reviewed against the National Cyber Security Centre's standards for training quality and content.

The course covers building a fit-for-purpose incident response plan, applying structured incident triage and decision-making models, and running the operational and communications side of a live incident — the exact skill set that turns a written PCI incident response plan into something your team can actually execute when a card data breach investigation is underway and the clock is running.

Pairing a properly built plan with people who've been trained to run it is the difference between Requirement 12.10 being a document you have and a capability you actually possess.

Building the Evidence Base Without Starting from a Blank Page

Between the 12 requirements, the SAQ or ROC you're validating against, and the new 4.0.1 documentation demands (targeted risk analyses especially), the volume of paperwork a PCI DSS programme needs to produce and keep current is substantial. And most of it needs to map cleanly to a specific requirement number, the same way CAF evidence needs to map to a contributing outcome.

To make that mapping exercise faster, we've put together two PCI DSS documents specifically for this: a PCI DSS requirement-to-evidence mapping guide, which walks through what documentation each of the 12 requirements actually expects an assessor to see, and a PCI DSS incident response and Requirement 12.10 documentation pack, which gives you the plan structure, escalation paths, and forensic-preservation checklist your response plan needs to hold up under both a card brand investigation and a PCI Forensic Investigator's scrutiny.

Between the documents and the CIPR training, you get both the paperwork and the practised capability an assessor and a real breach will each test in their own way.

Frequently Asked Questions About PCI DSS Compliance Requirements 

1. What is PCI DSS and who needs to comply with it?

PCI DSS (Payment Card Industry Data Security Standard) is a security standard enforced by the payment card brands for any organisation that stores, processes, or transmits cardholder data. It applies to merchants of all sizes and to service providers such as payment processors and hosting companies, with specific obligations scaling by transaction volume and merchant level.

2. What version of PCI DSS is currently in force?

PCI DSS 4.0.1 is the current version, a limited revision of 4.0 published to address stakeholder feedback. As of 31 March 2025, a large set of previously future-dated requirements, including mandatory targeted risk analyses and expanded multi-factor authentication, became fully enforceable, and assessors now use only the 4.0.1 Report on Compliance and SAQ templates.

3. What are the 12 PCI DSS requirements?

The 12 requirements cover network security controls, secure system configuration, protecting stored account data, encrypting data in transit, anti-malware protection, secure software development, access control by business need to know, user authentication, physical access restrictions, logging and monitoring, regular security testing, and organisational security policies including incident response.

4. What is a targeted risk analysis under PCI DSS 4.0.1, and why is it mandatory now?

A targeted risk analysis is a documented justification required under Requirement 12.3.1 whenever the standard gives you flexibility on how or how often to meet a specific control. Since March 2025, this analysis must exist in writing for every requirement where an organisation has chosen a flexible approach, rather than being assumed or left undocumented.

5. What happens if my organisation isn't PCI DSS compliant?

Card brands can levy monthly fines, typically ranging from around $5,000 to $100,000 depending on severity and duration, usually passed through by your acquiring bank. Non-compliance also brings elevated transaction fees and, if a breach occurs while non-compliant, significantly higher forensic investigation costs and a greater likelihood the investigation concludes the breach was preventable.

6. What incident response documentation does PCI DSS require under Requirement 12.10?

Requirement 12.10 requires a documented incident response plan covering roles, escalation paths, and communication procedures, along with evidence that the plan has been tested. For PCI specifically, this also needs to address card brand and acquirer notification timelines and forensic evidence preservation suitable for a PCI Forensic Investigator, which general incident response documentation often doesn't cover.

7. How is PCI DSS incident response training different from general cyber incident response training?

General incident response training covers detection, containment, and recovery broadly, but doesn't typically address the card-brand-specific obligations layered on top. Acquirer and brand notification timelines, forensic evidence handling standards, and the post-breach validation process card brands require are usually not covered. NCSC Assured training such as the CIPR course builds the structured incident planning and response skills that apply directly to executing a PCI-compliant incident response plan under real conditions.

8. What's the difference between an SAQ and a Report on Compliance (ROC)?

A Self-Assessment Questionnaire (SAQ) is a self-validation document used by most merchants, typically Levels 2 through 4, to confirm compliance against the requirements relevant to their environment. A Report on Compliance (ROC) is a formal assessment conducted by a Qualified Security Assessor, generally required for Level 1 merchants and larger service providers, and involves independent verification of evidence against all 12 requirements.