TL;DR
Requirement 12.10.1 is printed in the v4.0.1 SAQ A, A-EP, B-IP and D for Merchants. On A, A-EP and B-IP, the completion guidance says the plan can be a simple back-office document listing who to call, reviewed annually. Simple is allowed. Empty is not. It has to be ready to activate and cover notifying payment brands and acquirers, at a minimum. SAQ D adds 12.10.2 through 12.10.7. PCI DSS Dashboard can hold the plan and chase the review. It does not write the plan or decide whether your acquirer accepts the package.
Saturday evening. Two customers email: their cards were used somewhere strange the day after they ordered from you.
Who do we call? The developer wants to restore from backup and change every password. The owner wants to email every customer tonight. Nobody has the acquirer's incident contact. The 12.10.1 row on last year's SAQ says In Place.
That is the common failure on 12.10.1. The box was ticked. The plan was never written in a form anyone can use at 11pm.
What 12.10.1 actually says
PCI DSS v4.0.1 (June 2024): an incident response plan exists and is ready to be activated in the event of a suspected or confirmed security incident. The plan includes, but is not limited to:
- Roles, responsibilities, and communication and contact strategies, including notification of payment brands and acquirers, at a minimum.
- Incident response procedures with specific containment and mitigation activities for different types of incidents.
- Business recovery and continuity procedures.
- Data backup processes.
- Analysis of legal requirements for reporting compromises.
- Coverage and responses of all critical system components.
- Reference or inclusion of incident response procedures from the payment brands.
"Ready to be activated" is the phrase that matters. A plan in someone's inbox with last year's phone numbers is not ready.
The guidance column's examples of legal reporting requirements include the EU GDPR. If you sell in the EU, the legal-analysis bullet is not a formality.
What your SAQ actually prints
Same requirement number, different rows around it:
- SAQ A r1 (January 2025). 12.10.1 with all seven bullets, plus completion guidance. No other 12.10 rows.
- SAQ A-EP (October 2024). 12.10.1 with the bullets and the same guidance, plus 12.10.3: specific personnel designated to be available on a 24/7 basis to respond to suspected or confirmed incidents.
- SAQ B-IP (October 2024). 12.10.1 as the one-sentence requirement, without the bullet list, and the same completion guidance. The bullets still sit in PCI DSS itself. My advice is to write them into the plan anyway. A terminal merchant still needs to know who calls the acquirer. Terminals versus dial-out: SAQ B vs SAQ B-IP.
- SAQ D for Merchants (October 2024). 12.10.1 through 12.10.7. More on that below.
The completion guidance on A, A-EP and B-IP is the most useful sentence here. Selecting In Place means the merchant has documented an incident response and escalation plan, "consistent with the size and complexity of the merchant's operations." It can be "a simple document posted in the back office that lists who to call in the event of various situations with an annual review to confirm it is still accurate," up to a full plan with backup facilities and thorough annual testing. It "should be readily available to all personnel."
A small merchant does not need a forty-page template. I would rather see one accurate page than a binder nobody opened.
One page that stands up
Map the page to the bullets. For a small merchant:
- Who decides. One named person and a backup. Not "IT."
- Who we call, checked this cycle. Whoever holds your merchant agreement: the acquirer, or your payment provider if that is who you contract with. Payment page provider. Web host or developer. For B-IP, the terminal provider. Legal and data protection.
- What we do, by incident type. Payment page changed without a change request. A terminal that looks tampered with or swapped. An admin account used by the wrong person. Paper with card numbers gone missing. Three or four containment steps each, not a paragraph about cyber risk.
- How we keep trading. What you stop, what you keep, and who decides when to switch back.
- Backups. Where they are, who can restore, and the order of operations. Evidence first, restore second.
- Legal reporting. What the law requires you to report, and to whom. Written down.
- Critical systems. For many SAQ A merchants a short list: the site that redirects to, or embeds, the payment page, and the admin accounts that can change it.
- Payment brand procedures. A reference to the brands' incident procedures, or the procedures themselves.
Then date it. Phone numbers go stale first, which is what the annual review is for.
Evidence first, cleanup second
The Saturday instinct is the wrong one. The Council's guidance, Responding to a Cardholder Data Breach, is guidance, not a requirement line, but it is the best plain-language list for step 3:
- Unless your PCI Forensic Investigator (PFI) instructs otherwise, do not log onto compromised systems or change passwords on them.
- Unless your PFI instructs otherwise, do not turn compromised systems off. Isolate them from the network.
- Preserve all evidence and logs.
- Document every action, with dates, times, and the people involved.
The same guide says acquirers and the payment brands each set their own thresholds for when a PFI must be engaged, so contact them to make that call. That is why the acquirer line matters. The investigator has to be independent and listed on the Council's website. Your web developer is not your forensic investigator.
The guide also expects an investigator may need access to third parties that can affect your environment, such as your host. If your contracts never mention incident cooperation, that is a Requirement 12.8 conversation for before the bad Saturday.
SAQ D: more than a phone list
SAQ D for Merchants prints the full set:
- 12.10.2. At least once every 12 months, the plan is reviewed and updated as needed, and tested, including all elements listed in 12.10.1.
- 12.10.3. Designated 24/7 personnel.
- 12.10.4 and 12.10.4.1. Incident responders are trained, at a frequency set by a targeted risk analysis done according to 12.3.1.
- 12.10.5. Responding to security monitoring alerts, including the change- and tamper-detection mechanism for payment pages.
- 12.10.6. Lessons learned and industry developments.
- 12.10.7. Stored PAN found where it is not expected.
The best-practice period on 12.10.4.1, the payment-page bullet in 12.10.5, and 12.10.7 ended 31 March 2025. As with every printed row, they apply where they apply to your environment.
A book of merchants
For an MSP or ISO, the common failure is one template sent to every merchant with the MSP's number at the top. The merchant signs In Place and never adds its own acquirer contact. On the bad day everyone calls the MSP, which is not the party the requirement names.
The plan is per merchant. PCI DSS Dashboard can push an announcement down the hierarchy with read tracking ("check your incident contacts"), and the signed PDF goes up the parent chain when a merchant finishes. We do not fill in the merchant's acquirer on the way. More on running a portfolio: stop chasing SAQs in spreadsheets.
What the platform does, and what it does not
Wizards are live for SAQ A, A-EP, B-IP and D. You answer the 12.10.1 row in plain language, save as you go, sign, and download a signed, dated SAQ + AOC PDF. SAQ A and B-IP are €99. SAQ A-EP is €699. Payment gates the download.
The plan can live in the evidence repository, or in connected Google Drive. The annual review can be a scheduled task with evidence on each completion, and chasing when it slips. The full ROC dashboard has its own incidents and governance sections.
What it will not do: write your plan, pick your contacts, or make In Place true. The plan sits beside the PDF, not inside it, and the wizard does not decide whether the acquirer accepts the package. What the acquirer actually wants is still a signed, dated SAQ + AOC.
Unsure of your SAQ? Which SAQ Am I? first, then write the page. Specific setup: contact.
