Incident response that satisfies SOC 2, PCI, and ISO at once

By Sam Rivera, Founder, SentinelPanda · June 17, 2026 · 1 min read · SOC 2

You do not need three incident response plans. You need one good one, tested, that every framework can credit.

One plan, three frameworks

PCI DSS Requirement 12.10 wants an incident response plan and annual testing. SOC 2 Common Criteria CC7.3-CC7.5 want detection, evaluation, response, and recovery. ISO 27001 Annex A 5.24-5.26 want planning, assessment, and response. These are the same capability described three ways — build it once.

The backbone every framework expects

• Defined roles and an on-call chain, with a single incident commander per event.
• A severity classification scheme that drives response time and escalation.
• Detection and reporting paths — how an incident gets raised, by humans and by alerts.
• Containment, eradication, and recovery steps appropriate to your environment.
• Notification obligations: customers, acquirers (for card data), and regulators, with timelines.
• A post-incident review that feeds fixes back into controls.

Testing is the control

The most common finding is a plan that has never been run. A tabletop exercise once a year — walking the team through a realistic scenario and recording what happened — satisfies the testing requirement in all three frameworks and surfaces the gaps a document review never will. Keep the exercise notes; that record is the evidence.

Card-data specifics

For PCI environments, the plan must add the card-brand and acquirer notification path and the steps for a suspected account-data compromise. Bolt these onto the shared plan as a payment-specific appendix rather than maintaining a separate document.