Companies with no written plan
You handle incidents as they come, through whoever happens to be online. A plan turns that goodwill into named roles, clear decision rights and a contact list that still works when email doesn’t.
Risk & security programs
Incident response planning & tabletop exercises
Your insurer’s renewal form asks whether you have a tested incident response plan, an enterprise customer’s security questionnaire asks the same, and your board wants to know who decides whether to take the business offline. Incident response readiness gives you a plan written for your company, playbooks for the attacks you are most likely to face, and leaders who have worked through a realistic incident together before a real one tests them.
Formal outcome from
No certificate — the result is a plan your team has rehearsed
Who asks for it
Cyber insurers and brokers · Enterprise customers’ security reviews
Our role
Readiness — we help you build it and prove it
Your organization — readiness viewEvery requirement, an owner and its evidence
Readiness- SCOPEScope and system boundaryReady
- RISKRisk assessment and registerReady
- ACCESSAccess reviews, with evidenceGap · owner set
- CHANGEChange managementClosing
- VENDORVendor managementGap · owner set
- TESTPenetration test evidenceReport in hand
Handed to the assessor you choose — the opinion is theirs
Gaps found before the audit
Who it’s for
Why Incident response lands on your desk.
An incident response plan is the document everyone wishes they had read before the bad night. It names who leads, who decides, who talks to whom, which outside parties get called, and how evidence is kept intact while systems are restored. NIST SP 800-61 Rev 3, now written as a Community Profile of the NIST Cybersecurity Framework 2.0, treats incident response as part of everyday cybersecurity risk management rather than a binder on a shelf: preparation lives under Govern, Identify and Protect, and detection, response and recovery build on it.
Teams come to this work for concrete reasons. PCI DSS requirement 12.10 expects an incident response plan that is tested at least annually. SOC 2 common criteria CC7.3 through CC7.5 ask how you evaluate, respond to and recover from security incidents. ISO/IEC 27001 Annex A controls 5.24 to 5.28 cover incident planning, assessment, response, learning and the collection of evidence. The HIPAA Security Rule requires security incident procedures, NYDFS Part 500 requires a written plan, and the CMMC and NIST SP 800-171 incident response family asks you to test the capability. Public companies face SEC disclosure obligations once an incident is judged material, and cyber insurers increasingly underwrite on whether a plan exists and has been exercised.
A plan only works if people have used it. Tabletop exercises put your executives and your technical responders into a realistic scenario — a ransom note on a holiday weekend, a fraudulent wire request from a compromised mailbox, an attacker holding your cloud administrator account — and surface the decisions nobody has made yet: who can authorize taking systems offline, when legal counsel is brought in, who calls the insurer, and what you tell customers.
Who asks for it
Cyber insurers and brokersEnterprise customers’ security reviewsSOC 2, PCI DSS and ISO 27001 auditorsBoards and audit committeesRegulators such as the SEC, HHS and NYDFS
Teams whose plan has gone stale
Your plan was written for an on-premises network and a leadership team that has since changed. It needs to reflect your cloud estate, your SaaS tools, your current vendors and the people who actually make decisions today.
Public companies and regulated firms
You carry disclosure and notification obligations — SEC materiality determinations, state breach laws, HIPAA, NYDFS, DORA for EU financial operations — and need the plan to route those decisions to the right people with the right facts.
Leadership teams that have never rehearsed
Your security team knows the technical playbook, but your CEO, CFO, general counsel and communications lead have never worked an incident together. An executive tabletop is where they find the gaps safely.
Who certifies
No certificate exists. The proof is yours to build.
Formal outcome from
No certificate — the result is a plan your team has rehearsed
What they produce
A written incident response plan, scenario playbooks and exercise records that you own, ready for auditors, insurers and customers to review
Where readiness fits
No body certifies an incident response plan. The proof that matters is the plan itself and the record of exercises against it, which is exactly what a SOC 2 auditor, a PCI DSS assessor, an ISO 27001 certification body or an insurance underwriter asks to see.
NIST SP 800-61 Rev 3 — Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile NIST Cybersecurity Framework (CSF) 2.0 ISO/IEC 27035 — Information security incident management CISA Tabletop Exercise Packages (CTEPs) PCI DSS v4.0.1 — Requirement 12.10 SEC Form 8-K Item 1.05 and Regulation S-K Item 106 HIPAA Security Rule — 45 CFR 164.308(a)(6), security incident procedures NYDFS 23 NYCRR Part 500 — Section 500.16 DORA, Regulation (EU) 2022/2554 — ICT-related incident management and reporting
What it covers
What Incident response readiness covers.
- Incident response policy, scope and severity classification
- Roles, responsibilities and a RACI across security, IT, legal, communications, HR and leadership
- Decision rights for taking systems offline, engaging outside parties and answering extortion demands
- Ransomware playbook: containment, backup integrity checks and restoration decisions
- Business email compromise and payment-fraud playbook
- Cloud account and identity-provider takeover playbook
- Insider threat playbook coordinated with HR and legal
- Data breach playbook: establishing what data was affected and whose it was
- Legal and regulatory notification mapping: SEC cyber disclosure, state breach-notification laws, HIPAA, DORA and contractual commitments
- Internal and external communications for employees, customers, media and regulators
- Evidence preservation and chain of custody for forensic and legal needs
- Third-party coordination: cyber insurer, breach counsel, forensic firm and law enforcement
- Out-of-band communication for when email or chat may be compromised
- After-action reviews and ongoing plan maintenance
What you receive
What you have in hand when readiness is done.
Incident response plan
A plan written for your organization: scope, severity levels, roles, escalation paths, decision rights and the contact list, kept short enough that people will read it under pressure.
Scenario playbooks
Playbooks for ransomware, business email compromise, cloud account takeover, insider activity and data breach, each with first actions, decision points and the person who owns each decision.
RACI and decision-rights matrix
Who is responsible, accountable, consulted and informed for each major decision, including who can authorize shutting down production, engaging outside counsel or contacting law enforcement.
Notification obligations map
A reference of the notification and disclosure obligations that may apply to you — regulators, state laws, contracts and your insurance policy — with the trigger and the internal owner for each, prepared for review with your counsel.
Executive tabletop exercise
A facilitated, discussion-based exercise for leadership, built around a scenario that fits your business, testing decisions on disclosure, customer communication, extortion demands and business priorities.
Technical tabletop exercise
A scenario for your IT and security responders that tests detection, containment, evidence handling and restoration against your real tools, logs and runbooks.
After-action report
What worked, what stalled, which decisions had no owner, and a prioritized list of improvements to the plan, tooling and training, in a form your auditors and insurer can review.
Communication templates
Draft holding statements, employee notices, customer notices and regulator contact scripts, prepared in advance for your counsel to approve and adapt when it counts.
Common gaps
What a Incident response readiness review tends to surface.
Better found now, by people on your side, than by your assessor.
A plan that names roles but not the people who hold them, or names people who have left
No one with clear authority to take a revenue-generating system offline
The plan and contact list stored only on systems an attacker would encrypt
No out-of-band channel for responders once email and chat are untrusted
Insurer notice requirements and panel-vendor rules discovered only when the claim is filed
Backups that exist but have never been restored under ransomware conditions
Logs that are not centralized or not retained long enough to establish what an attacker touched
No defined process for assessing materiality for SEC disclosure or for bringing counsel in early
Where testing fits
The tests Incident response calls for, from the same team.
Red team engagement
A red team engagement tests whether your detection and response hold up against a realistic adversary — the live counterpart to a tabletop, and evidence that the plan works outside the conference room.
What the test coversSocial engineering
Phishing and pretexting campaigns test the front door most incidents come through, and show whether staff report suspicious messages to the people your plan says should receive them.
What the test covers Questions
What buyers ask about Incident response.
Do we need an incident response plan if we already have a managed detection and response provider?
Yes. A detection provider watches your environment and may contain threats, but it can’t decide whether to shut down your order system, notify customers, involve law enforcement or speak to the press. Those decisions belong to your leadership, and the plan says who makes them. A good plan also defines how your provider hands off to your people and what your contract with them actually covers.
What is the difference between an executive tabletop and a technical tabletop?
An executive tabletop works through business decisions: disclosure, customer and regulator communication, extortion demands, operational priorities and spending authority. A technical tabletop works through detection, containment, evidence handling and restoration with the people who run your systems. Most organizations benefit from both, because the hand-off between the two groups is where real incidents tend to stall.
How often should we exercise the plan?
At least annually, and whenever something significant changes — a new leadership team, an acquisition, a move to a new cloud platform or a new regulatory obligation. PCI DSS expects testing at least annually, CISA publishes free Tabletop Exercise Packages that set a useful baseline, and insurers and enterprise customers increasingly ask for the date and outcome of your most recent exercise.
Will the plan tell us exactly when we have to notify regulators?
The plan maps the obligations that may apply — SEC disclosure for public companies, state breach-notification laws, HIPAA, DORA, NYDFS and your contracts — and assigns who tracks each one. The deadlines and the legal judgments, such as whether an incident is material or a breach is reportable, belong with your counsel; the plan makes sure counsel is engaged early and has the facts they need.
How does our cyber insurance fit in?
Many policies require prompt notice to the insurer and the use of the insurer’s approved breach counsel and forensic firms for costs to be covered. Your plan should list those requirements, the claims hotline and policy number, and the order in which calls happen, so a well-meaning call to the wrong vendor doesn’t put coverage at risk.
Does a tabletop exercise touch our production systems?
No. A tabletop is discussion-based: participants talk through what they would do as the scenario unfolds, and nothing in your environment is changed. If you want to test detection and response against real activity, that is what a red team engagement or a social engineering campaign is for, and those are scoped and authorized separately.
Is Incident response on your desk?
One conversation with someone who does this work. You leave knowing where you likely stand and what readiness would involve for you.