What Cyber Incident Response Plans Must Contain to Satisfy Regulators

A cyber incident response plan is the documentation of a predetermined set of instructions or procedures to detect, respond to, and limit consequences of malicious cyber attacks against an organization's information systems. Regulators increasingly require these plans, audit them, and impose penalties when they are absent or inadequate. Yet many organizations lack clarity on what the plan must contain, who must approve it, and how to demonstrate it works.

1Why Incident Response Plans Matter to the Business

The consequences of an inadequate or missing incident response plan are operational and legal. Without a documented plan, an organization cannot demonstrate to regulators, insurers or boards that it has taken reasonable steps to prepare for inevitable incidents. The plan itself becomes evidence of due care.

When an incident occurs without a plan in place, response is improvisational. Critical decisions are made under pressure without clear authority, coordination fails across functions, evidence is lost, notification deadlines are missed, and recovery takes longer. Each of these failures expands liability.

Beyond the incident itself, regulators in finance, healthcare, energy and other sectors now audit incident response capabilities directly. The absence of a documented, tested plan is a finding in itself, separate from any breach that may trigger the audit.

2What Every Plan Must Include

NIST Special Publication 800-61 Revision 3, finalized in April 2025, provides the foundation for incident response planning in the United States. The publication supersedes Revision 2 and aligns incident response with the NIST Cybersecurity Framework 2.0.

The updated incident response life cycle model separates preparation activities from the response itself. Preparation includes the broader cybersecurity risk management activities of Govern, Identify and Protect. The incident response itself consists of Detect, Respond and Recover. Continuous improvement feeds lessons learned from all activities back into preparation.

An adequate incident response plan addresses each of these phases with specificity. It must answer who does what, when, and under what authority. Vague statements of intent do not satisfy this requirement.

Preparation and Governance

The plan must establish governance before an incident occurs. This includes designation of the incident response team, escalation paths, decision authority at each severity level, and the executive who owns the program. It must specify how the organization will determine that an incident has occurred and who has authority to declare one.

Preparation also requires identification of critical assets, dependencies, and acceptable risk levels. The plan must document what constitutes a reportable incident under applicable regulations, to whom reports must be made, and within what timeframes.

Detection and Response Procedures

The plan must specify how incidents will be detected, how alerts will be triaged, and what technical and procedural steps will be taken to contain, investigate and remediate. This includes procedures for preserving evidence, engaging law enforcement, and determining when outside assistance is required.

Response procedures must account for communication, both internal and external. The plan should specify who may speak on behalf of the organization, what information may be shared, and how regulatory notifications will be managed.

Recovery and Improvement

Recovery procedures must be documented, including how the organization will restore operations, validate that threat actors have been removed, and determine when normal operations may resume. The plan must also require post-incident review and specify how lessons learned will be incorporated into future preparation.

NIST emphasizes that incident response details change frequently and vary across technologies and environments. The plan itself need not prescribe every technical step, but it must establish the framework within which technical responders will operate and ensure that framework is kept current.

3Who Must Approve the Plan

Incident response plans are risk management documents, not IT procedures. Approval authority must rest with the executives accountable for the risks the plan addresses. In practice, this typically includes the general counsel, the chief compliance officer or equivalent regulatory function, the chief operating officer, and the chief financial officer where cyber insurance or financial reporting obligations are implicated.

The board or its audit or risk committee should receive regular reports on incident response readiness, including confirmation that a current plan exists, evidence that it has been tested, and summaries of any incidents that have occurred. Regulators increasingly expect boards to demonstrate active oversight of cyber risk, and incident response capability is a measurable element of that oversight.

Many organizations assign plan authorship to IT or information security, which is appropriate for technical content. However, the accountability for the plan's adequacy, currency and enforceability is an executive responsibility that cannot be delegated to technical staff. This distinction frequently causes confusion and delays.

4How Often Plans Must Be Tested

A documented plan that has not been tested provides no assurance that response will succeed. Regulators expect plans to be tested at regular intervals and updated based on test results. The frequency and rigor of testing vary by sector and specific regulation, but annual testing is a common baseline.

Testing may take several forms. Tabletop exercises walk key personnel through hypothetical scenarios to identify gaps in coordination, authority or procedure. Functional exercises test specific technical capabilities, such as restoring from backup or activating alternate communication channels. Full simulations test the entire plan under realistic conditions.

CISA provides tabletop exercise packages, cybersecurity scenarios, and after-action report templates to support testing. NIST Special Publication 800-84 provides guidance on test, training and exercise programs for IT plans and capabilities. The Software Engineering Institute offers an incident management capability assessment for organizations seeking structured evaluation.

Testing must produce documented results. An after-action report should identify what worked, what failed, and what changes are required. The plan must then be updated, and those updates must be approved through the same governance process that approved the original plan. A plan that is tested but never updated provides evidence of awareness without evidence of capability.

5Where Executive Ownership Typically Fails

The most common failure in incident response planning is the absence of a single executive owner. IT may maintain the technical procedures, legal may own regulatory notification, operations may control business continuity, and insurance may handle claims. Without an executive who owns the entire program, the plan becomes a collection of documents that do not connect.

This fragmentation creates measurable risk. When an incident occurs, authority is unclear, coordination is manual, and response time extends. When regulators audit, they find evidence of partial preparation in several departments but no coherent program.

The owner of incident response planning is accountable for ensuring the plan exists, is adequate, is approved, is tested, is updated, and is understood by everyone who has a role in it. This is a governance function, not a technical one. It requires someone who can compel coordination across legal, operations, technology and communications, and who reports directly to the CEO or board on the organization's state of readiness.

Many organizations lack an executive with this combination of authority, expertise and bandwidth. The chief information security officer, where one exists, may have the expertise but often lacks the cross-functional authority. General counsel has authority but may lack technical depth. The chief operating officer has authority and scope but may lack the time to own a specialized program.

This is the gap that virtual CISO leadership is designed to close. A vCISO provides the executive ownership of cybersecurity strategy and governance, including incident response planning, as a specific engagement with defined deliverables and accountability.

6How This Relates to Incident Readiness and Response Planning

Incident readiness is the state of preparation that allows effective response. It includes the documented plan, but also the training, tools, relationships and authority structures that make the plan executable. An organization may have a compliant plan on paper and still lack readiness if responders do not know their roles, if technical capabilities have not been validated, or if executive decision-making has not been rehearsed.

Response planning is the process of developing and maintaining the plan itself. It is cyclical, not linear. The plan is drafted, reviewed, approved, tested, updated based on tests and actual incidents, and approved again. NIST emphasizes continuous improvement, with lessons learned from all cybersecurity risk management activities feeding back into planning.

Organizations often confuse having a plan with being ready. The plan is necessary but not sufficient. Readiness requires that the plan be current, that people be trained in their roles, that technical capabilities be verified, and that governance be clear. These elements degrade over time through staff turnover, technology changes and organizational evolution. Maintaining readiness is an ongoing executive responsibility.

7What Leadership Should Do Next

If your organization does not have a documented, tested incident response plan, creating one is the immediate priority. If a plan exists, the priority is validating that it meets current regulatory requirements, that it has been tested in the past year, and that a specific executive owns it.

The following questions will identify the most urgent gaps:

• Does a documented incident response plan exist, and has it been approved by appropriate executives within the past year?
• Does the plan specify who has authority to declare an incident, at what thresholds, and what actions are automatically triggered?
• Does the plan identify all regulatory notification requirements applicable to your organization, with specific timeframes?
• Has the plan been tested in the past twelve months, and were the results documented in an after-action report?
• Is there a single executive accountable for the adequacy, currency and testing of the plan?
• Does the board or its audit committee receive regular reports on incident response readiness?

If the answer to any of these questions is no, the organization has a governance gap that audits will find and incidents will exploit. Closing this gap does not require new technology. It requires executive ownership, clear accountability and a structured approach to planning and testing.

For organizations that lack internal capacity to own this work, or where accountability is unclear across existing roles, virtual CISO services provide executive-level ownership on a flexible basis. This includes drafting or updating the plan, facilitating approval through appropriate governance channels, designing and conducting tests, and reporting readiness to the board. The deliverable is not a document but a state of verifiable readiness.

If you are uncertain where your organization stands, a confidential consultation can clarify your current position, identify specific gaps, and outline the sequence of work required to reach and maintain compliance. Heights Consulting Group offers this consultation without obligation to general counsel, chief compliance officers and operations leaders in regulated industries.