📋 GRC compliance for CMMC 2.0, CPCSC, CPA Canada, IIROC…SaaS discovery for data governanceFree enriched web chat widget🚀 Enriched remote support without your laptop

Incident Response

Build an incident response plan with every reporting deadline and contact your rules require, track a live incident against those deadlines, and rehearse the plan with tabletop exercises.

Open Incident Response in your console

Where to find it
Compliance › Incident Response, or Resilience › Incident Response. Also under More in the Compliance bar.
Who can use it
Anyone whose compliance (GRC) role includes viewing; building plans, recording incidents and exercises, approving, and deleting each need the matching compliance permission
For
Incident leads, compliance and privacy officers, IT teams, and managed service providers
Plan
GRC Compliance Platform (included in Complete), or Resilience: Vendor Risk & Business Impact. Either one opens this page. See pricing

What the page is for

When something goes wrong, the hardest part is often not the technical fix. It is knowing who has to be told, and by when. Visa expects to hear within three calendar days, American Express within 72 hours, NYDFS within 72 hours of determining an incident occurred, a NIS2 entity within 24 hours, and a DORA financial entity within four hours of classifying an incident as major. Each deadline starts from a different moment.

The page has three tabs:

  • Plans: a plan builder that adds every regulator's and card brand's reporting deadline and contact for the rules you follow, and prints a complete plan.
  • Incident log: a record of each incident with a timeline and a reporting clock for every report that applies, counting down from the times you record.
  • Tabletop exercises: facilitator guides built from your plan, recorded in Continuity Tests.

An approved plan counts as evidence for the incident response controls, such as IR-001 Incident Response Plan, IR-003 Incident Response Testing, and REG-001 Regulatory Cybersecurity Incident Reporting, in every framework that maps them.

Checked at the source. Every deadline and contact comes from the regulator's or card brand's own published text, names its section, and links its source. They were last checked on 7 October 2026. Where a brand does not publish a deadline (Discover, JCB, and UnionPay), the plan says so and tells you to confirm with your acquirer. The plan is a tool, not legal advice.

Rules the plan covers

  • Payment cards: PCI DSS v4.0.1 requirement 12.10, with incident contacts and deadlines for Visa, Mastercard, American Express, Discover, JCB, and UnionPay, and your acquirer.
  • Canada: PIPEDA, the proposed PPCDA (Bill C-36), Quebec Law 25, Alberta PIPA, CIRO's three-day rule for investment dealers, the Canadian Securities Administrators (Staff Notice 33-322 and marketplace rules), the Critical Cyber Systems Protection Act (enacted, not yet in force), and voluntary reports to the Canadian Centre for Cyber Security.
  • European Union: NIS2, DORA, and the GDPR.
  • United States: the FTC Safeguards Rule, NYDFS Part 500, CJIS Security Policy v6.1, TSA pipeline security directives, NERC CIP-008 and DOE Form OE-417, HIPAA with Health Sector Coordinating Council guidance, Iowa public sector and Iowa breach law, IRS Publication 1075, and voluntary reports to CISA.
  • Frameworks: CIS Controls v8.1 Control 17 and the Cloud Security Alliance Cloud Controls Matrix.

Proposed and not-yet-in-force rules are marked as such. Including them now means the plan is ready the day they take effect.

What you see

  1. Record an incident and Build a plan: the two buttons at the top of the page.
  2. Plans tab: Plan, Rules covered, Status, Last tested (with Test due when it is overdue), Next review, and Updated.
  3. Incident log tab: Incident, Severity, Status, Discovered, Next deadline (with a countdown), and Lead.
  4. Tabletop exercises tab: Plan to exercise, six scenarios with Open the facilitator guide, and Recent tabletop exercises.

How to build a plan

  1. Select Build a plan.
  2. Tick what describes your organization, for example We accept or process payment cards or We operate in Canada, and select Next.
  3. Check the rules the plan will cover. Rules from your selected frameworks and your answers are already ticked, marked selected framework where a framework put them there. Select Next.
  4. If PCI DSS is ticked, tick the card brands you accept and enter your acquirer's incident contact. Select Next.
  5. Enter the plan name, the Incident lead, Deputy incident lead, Technical lead, and Executive sponsor, and your cyber insurer and forensic firm if you have them. Select Create plan. The plan opens as a Draft.

How to complete a plan

  1. Under Incident response team, fill in every role with a phone number that works at 2 a.m. Select Add a person for anyone else, and Remove for a role you do not use.
  2. Under Other contacts, add your insurer, forensic firm, legal counsel, and police. Under More people to tell, add anyone your contracts or other rules require you to notify, such as a large customer.
  3. Under How the plan works, edit the sections and tick the Playbooks to include.
  4. Enter the Plan owner and Next review date, and select Save. If you changed the rules, the Who must be told, and how fast table updates.
  5. Select Send for review, then someone with approval rights selects Approve. The incident lead's name and phone number must be filled in first.
  6. Select Printable plan and use your browser's print dialog to save it as a PDF. Keep a printed copy where you can reach it if your systems are down.

What the printed plan contains

Purpose and scope, the team, how to activate the plan and the severity levels, a table of every report with its recipient, deadline, and contacts, a payment card section with each brand's rules and forensic investigation requirements, other contacts, the playbooks, communications, evidence and records, recovery, testing and lessons learned, what each set of rules expects of the plan, and the sources.

How to record an incident

  1. Select Record an incident as soon as you suspect one. You can change everything later.
  2. Enter a short name, the Kind of incident, the Severity, and when it was Discovered. Add when it was Determined to be an incident if that has happened.
  3. Choose the Plan, tick what is involved as far as you know, and select Record incident.
  4. The incident opens with Reporting clocks at the top. Work down the list: the soonest deadline is first.

How the reporting clocks work

  • Each row shows the report, who receives it, when it is due in your time zone, and a countdown. Open the row to see the rule's wording, its section, how to file, and the contacts.
  • To file means the report applies. Check means it depends on a fact you have not recorded yet, such as whether personal information is involved or how many people are affected. Does not apply means the facts rule it out.
  • Some clocks wait for a time you have not recorded, such as Determined to be an incident, or for an earlier report to be filed. The row says what it is waiting for.
  • Times are entered in your time zone and stored in Coordinated Universal Time (UTC), so everyone sees the same deadline.

How to mark a report filed

  1. Select Mark filed on the row.
  2. Check When it was filed, add a reference number if you have one, and select Record. The report shows Filed, and any report that depends on it starts its own clock.
  3. If you marked the wrong report, select Withdraw and say why. Both entries stay on the timeline.

How to keep the record up to date

  1. Under What we know, update the times, the facts, the status, the summary, and the lessons learned, and select Save. A change to a time or to the severity is written to the timeline automatically.
  2. Under Timeline, add each action, decision, or note as it happens. Leave When blank for now, or enter an earlier time.
  3. Follow the Playbook for the kind of incident, and use Who to call for the plan's contacts.
  4. Set the status to Closed when the incident is over, and record the lessons learned.

How to run a tabletop exercise

A tabletop is a discussion, not a test of systems: the team talks through a realistic incident using the plan. PCI DSS, NYDFS, DORA, CJIS, IRS Publication 1075, and CIRO all expect one at least once a year, and NERC CIP-008 every 15 months. The six scenarios are ransomware, card skimming on a checkout page, a redirected supplier payment, a breach at a cloud provider, a stolen laptop, and a denial of service with an extortion demand.

  1. Open the Tabletop exercises tab, choose the Plan to exercise, and select Open the facilitator guide on a scenario.
  2. Read Before the exercise, and select Printable guide for the facilitator.
  3. Run the exercise, revealing each development at about the minute shown. The guide adds questions and the deadlines the scenario would set off for the rules in your plan.
  4. Under Record the exercise, enter the date, How it went, Who took part, and the Findings, owners and dates. Select Record in Continuity Tests. The plan's last tested date updates, and the next exercise is due when your strictest rule requires.

Where else it appears

  • Controls: the incident response controls show an Incident response panel with your plans, when each was last tested, and the incident log's counts. See Control Detail.
  • Continuity Tests: recorded tabletop exercises appear with your other tests. See Continuity Tests.
  • Plans & Docs: the Incident Response Plan card links here for deadlines, contacts, and tabletops. See Plans & Documents.

Tips

  • Record the incident first and investigate second. Several clocks start at discovery, not when you are sure.
  • Write down who determined it was an incident, and when. NYDFS, NERC CIP-008, and DORA clocks start from that decision.
  • Do not paste card numbers, passwords, or other sensitive data into the incident record. Describe them instead.
  • For a card data compromise, isolate the affected systems rather than turning them off or rebuilding them, so a forensic investigator can examine them.
  • Changing an approved plan sends it back to In review, so an approval always matches the plan.

Troubleshooting

"Incident response is not set up yet."
Your organization's update to this feature has not finished. Ask your administrator, or contact our support team.
"Name the incident lead and give a phone number, and save, before approving."
Fill in the Incident lead row under Incident response team, select Save, then approve.
"You wrote this, so someone else has to approve it."
Ask a colleague whose compliance role includes approving. An administrator can allow self-approval with a reason in Compliance Settings.
"Incidents were recorded under this plan, so it stays on record."
Select Retire instead of deleting it.
A report shows "Check" instead of "To file".
Record the fact it depends on under What we know, such as whether personal information is involved or how many people are affected, and select Save.
A deadline is not shown.
The rule sets no fixed time ("as soon as feasible"), or the clock is waiting for a time you have not recorded. The row says which.

Still need help?

Search the support centre, or contact our support team and tell us which page you were on:

Names, companies, devices and figures in the pictures are examples. Other product and company names are trademarks of their respective owners.

We use privacy-friendly, cookieless analytics to count visits, and one cookie to run our live chat. Both load only if you accept. We do not use advertising trackers, and we do not profile you across other websites. The essential cookies that keep the site working are always on. See our privacy policy.