Free PCI incident response plan template

What a PCI incident response plan is

It is the page your team reaches for when card data may have been exposed: who leads, who gets called, what to unplug and what to leave alone. Under PCI DSS 12.10.1, an incident response plan “exists and is ready to be activated,” covering roles and contacts (including notifying the payment brands and acquirers), containment steps, business recovery, data backups, legal reporting duties, critical systems, and the payment brands' own procedures. The receipt above the plan checks your copy against that list.

The plan is not your security policy. The policy states the rules your business keeps, including that a plan like this one exists; build that with the PCI policy template generator. Where 12.10 sits among the other requirements is in the PCI DSS 4.0 requirements explained.

How to use this template

1. 01Type your business name and tick every way you take cards. Each one adds its own warning signs, steps and contacts.
2. 02Press Edit on section 1 and fill in real names and numbers, starting with your acquirer's risk or fraud line and your merchant ID.
3. 03Read sections 2 to 6 aloud with whoever would be on shift. Change any line that does not match how your shop works.
4. 04Print it, or save it as a PDF from the print dialog. Keep one copy by the terminal and one at home.
5. 05Walk through a made-up incident once a year, write the date in section 8, and fix what the walk-through showed.

The plan saves itself in this browser and nowhere else; clearing your browser data clears it, so keep the PDF. Put the yearly walk-through on the same list as your other dates with the PCI deadline calendar.

Worked example: the bakery's first three days

The example plan, put to use. Each row is a clock a card brand sets, from Visa's What To Do If Compromised and the American Express Data Security Operating Policy.

Not every incident ends with a forensic investigator; Visa can ask for one, or for an independent investigation instead. Your acquirer tells you which, and Mastercard or Discover steps come through them too.

Where the rule says so

Requirement 12.10 opens with one line: suspected and confirmed security incidents that could affect the cardholder data environment are responded to immediately. Its sub-points, in plain words, and where this template answers each:

• Req. 12.10.1Sections 1 to 7

  A plan that is ready to be activated, with roles and contacts (brands and acquirers at a minimum), containment for different kinds of incident, business recovery, data backups, legal reporting, critical systems and the brands' own procedures.

• Req. 12.10.2Section 8

  At least once every 12 months the plan is reviewed, updated as needed, and tested, including every element of 12.10.1.

• Req. 12.10.3Section 1

  Named people are available 24/7 to respond to a suspected or confirmed incident.

• Req. 12.10.4Your training records

  The people who respond are trained on their incident duties, as often as your targeted risk analysis sets (12.10.4.1).

• Req. 12.10.5Section 2

  The plan covers responding to alerts from your security monitoring, including the change- and tamper-detection on payment pages.

• Req. 12.10.6Section 8

  The plan changes with lessons learned and industry developments.

• Req. 12.10.7Sections 2 and 3

  Steps for when stored card numbers turn up where they are not expected: retrieve, delete or move them, check for security codes stored with them, trace where they came from, and close the leak.

Requirement text from the PCI SSC Prioritized Approach Tool for PCI DSS v4.0.1, read on 2026-10-22.

Which of these lines your self-assessment asks about depends on your SAQ type; the SAQ form has the final list, and the SAQ type finder tells you which form is yours. The training under 12.10.4 can ride on your yearly security awareness training. For 12.10.7, the rules on which card data you may keep at all are in how to store credit card information under PCI rules, and the PCI compliance checklist tracks the rest of the year's work.