Incident Response

To meet the C2M2 incident response requirement, you need documented, approved incident response procedures and you must be able to prove your team follows them whenever an incident is formally declared within scope. Operationalize this by defining what “declared” means, assigning roles, running a consistent response workflow, and retaining evidence from real incidents that maps back to the procedure ¹.

Key takeaways:

• Write and approve incident response procedures that specify roles, responsibilities, and response actions ¹.
• Define the “declare an incident” trigger so you can show consistent, repeatable activation of the process ¹.
• Keep operating artifacts (tickets, timelines, comms, approvals, lessons learned) that demonstrate the procedure was followed in day-to-day work ¹.

This requirement is deceptively narrow: it does not ask you to prove your program is “excellent,” only that declared cybersecurity incidents are responded to according to defined procedures. In audits and maturity assessments, teams fail this control less because they lack tools and more because they cannot show a repeatable operating standard: who declares, what steps happen next, who approves containment actions, what gets documented, and where the evidence lives.

C2M2 is commonly used in critical infrastructure and energy-sector environments to assess cybersecurity capability within a defined scope, often including operational technology (OT) and supporting IT. That context matters because response actions can affect safety, reliability, and regulated operations. Your procedures must match the environment you operate: an IT-only playbook that ignores OT constraints will read as “defined” but won’t be followed in practice.

The fastest path to compliance is to treat this as an “evidence first” requirement. Write procedures that your team will actually execute under pressure, then set up a lightweight evidence package that you can produce on demand: the approved procedure, the version history, and a small set of incident records that clearly map to the steps ¹.

Requirement summary (C2M2 RESPONSE-2.B)

Requirement (plain English): When you declare a cybersecurity incident, your team must respond by following documented procedures that define roles, responsibilities, and response actions, and you must be able to demonstrate that you did so ¹.

Why examiners and assessors care

This control is a proxy for two things:

1. Control design: procedures exist, are approved, and describe a workable response model.
2. Control operation: the procedures are actually used when it counts, with artifacts that show consistent execution.

If your incident response procedure is outdated, unapproved, or ignored, response becomes ad hoc. That increases operational risk and also creates an audit problem because you cannot show a defined operating standard during testing, customer diligence, or regulator review ¹.

Who it applies to

Entities

This applies to organizations using C2M2 for cybersecurity capability maturity assessments, commonly including energy sector organizations and critical infrastructure operators ¹.

Operational context and scope

Apply it to the specific business unit, function, or environment that is in scope for your C2M2 assessment (for example, a control center network, generation site OT, corporate IT supporting operations, or a shared services SOC) ¹.

A practical scoping rule: if an event impacts systems in scope, or the response team in scope is expected to act, then the incident response procedures must govern the response.

Regulatory text

C2M2 v2.1 RESPONSE-2.B (MIL1): “Declared cybersecurity incidents are responded to according to defined procedures.” ¹

Operator interpretation: what you must do

You must be able to show, with documentation and operating records, that:

• You have defined procedures for incident response.
• The procedures identify roles and responsibilities (who does what) and response actions (what steps occur).
• For each declared incident, the team follows the procedures in a consistent way ¹.

This requirement lives or dies on one operational definition: what qualifies as “declared.” If you cannot show the decision point that converts an event into a declared incident, assessors will treat your process as informal.

What you actually need to do (step-by-step)

Step 1: Define “declared incident” and the trigger path

Create a short definition and include it in the procedure:

• What inputs can trigger declaration (SOC alert triage outcome, OT anomaly escalation, third party notification, physical security report, law enforcement contact).
• Who can declare (SOC lead, Incident Commander, OT Ops lead, CISO delegate).
• Where declaration is recorded (ticket state change, incident channel creation, incident record in GRC system).

Evidence goal: one clear record that shows “declared” occurred (timestamp + decision owner).

Step 2: Publish incident response procedures with approvals and ownership

Your incident response procedure should include, at minimum:

• Document owner and accountable executive.
• Roles: Incident Commander, Technical Lead, Communications Lead, Legal/Privacy liaison (if applicable), OT authority (if applicable), IT operations, third party coordinator.
• High-level workflow: identification → declaration → containment → eradication → recovery → closure and lessons learned.
• Decision points: containment approvals, system isolation authority, production/OT shutdown escalation.
• Communications: internal escalation, external notifications, coordination with third parties when they are involved.
• Review cadence and version control approach.

This aligns with the practical control expectation to publish approved procedures with an owner, review cadence, approval history, and the personnel who must follow them ¹.

Step 3: Operationalize the workflow in the systems people already use

Procedures that live only in a policy repository are rarely followed during high-pressure response. Make the procedure executable:

• Create an incident ticket template that mirrors your workflow steps.
• Create a standard incident timeline format (who/what/when, including key decisions).
• Pre-create communication templates (internal exec update, impacted ops team note, third party outreach script).
• Define severity levels if you use them, but keep the procedure valid even if severity classification changes.

Tip for audit-readiness: map each major step in the procedure to a field, checklist item, or required attachment in the incident record.

Step 4: Assign and train roles (lightweight, role-based)

You do not need a large program to satisfy this requirement, but you do need role clarity:

• Name primary and backup role-holders.
• Confirm on-call and escalation coverage for the scoped environment.
• Ensure OT and IT decision authority conflicts are resolved in advance.

Training evidence can be simple: a roster of role-holders who acknowledged the procedure, plus meeting notes for a tabletop or internal walkthrough. Keep it practical and tied to the defined procedure ¹.

Step 5: Run the process on real declared incidents and retain operating artifacts

This is the most common failure point. The requirement expects you to retain operating artifacts that show incident response is used in day-to-day work, including version history and approvals ¹.

For each declared incident, retain a compact “incident evidence packet”:

• Declaration record (who declared, when, why).
• Incident ticket with status changes and assignments.
• Timeline of actions aligned to procedure steps.
• Containment and recovery actions with approvals.
• Communications log (internal and third party, as applicable).
• Post-incident review notes and tracked corrective actions.

Step 6: Close the loop: lessons learned become controlled changes

A declared incident response that ends without changes often looks performative. Track follow-ups:

• Procedure update (if gaps were found).
• Detection tuning or logging improvements.
• Third-party remediation requests and follow-up verification where third parties were involved.

Daydream can help here by centralizing incident artifacts, approvals, and version history so your evidence packet is consistent across teams and easy to produce during an assessment.

Required evidence and artifacts to retain (audit-ready checklist)

Use this as your minimum evidence set for RESPONSE-2.B ¹:

Procedure and governance

• Approved incident response procedure document (current version).
• Approval record and version history.
• Role assignments and escalation contacts for the scoped environment.
• Review cadence record (for example, a task or meeting minutes showing periodic review).

Operational records (from actual declared incidents)

• Incident declaration record (timestamp, owner, severity/impact if used).
• Incident ticket(s) and linked investigation notes.
• Action log mapped to procedure steps.
• Containment/eradication/recovery approvals where required.
• Closure summary and lessons learned.
• Corrective action tracking record.

Consistency proof

• A mapping document that shows where each procedure step is evidenced in your ticketing/IR tooling.

Common exam/audit questions and hangups

Expect these questions in a C2M2-aligned assessment:

• “Show me the defined procedures and who approved them.” ¹
• “How do you decide an event becomes a declared incident? Who has that authority?”
• “Pick a recent declared incident and walk me through evidence that you followed the procedure step-by-step.”
• “Where is the version history? How do you ensure responders follow the current procedure?” ¹
• “How do you handle incidents involving third parties that support scoped systems?”

Common hangup: teams present a policy, not a procedure. The assessor will look for operational steps, roles, and proof of execution.

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails	Fix
“Incident declared” is informal (Slack message, hallway decision)	You cannot prove consistent activation	Require a declaration field/state in the incident record and a named decision owner
Procedures exist but are unapproved or outdated	Control design gap; no accountable owner	Add owner, review cadence, and approval history 1
Evidence is scattered across tools and can’t be reconstructed	Control operation can’t be demonstrated	Standardize an incident evidence packet and link artifacts from the ticket
OT response is missing or unrealistic	Teams won’t follow the procedure	Include OT decision authority, safety/reliability escalation, and constraints
No proof the procedure is used day-to-day	Fails the “follow defined procedures” test	Retain operating artifacts from real incidents 1

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this specific C2M2 requirement. Treat the risk as operational and assurance-driven: inconsistent response increases outage and safety risk, and weak evidence fails customer diligence and maturity assessments ¹.

Practical execution plan (30/60/90)

You asked for speed. Use this phased plan; treat the timeboxes as targets and adjust to your environment.

First 30 days (stabilize the minimum)

• Confirm C2M2 scope (systems, teams, locations).
• Draft or update the incident response procedure with: declaration definition, roles, workflow, approvals, communications.
• Route for approval and publish in the controlled repository with version history ¹.
• Implement the incident ticket template and required fields that capture declaration and key actions.

Days 31–60 (make it executable)

• Assign named role-holders and backups; publish escalation contacts.
• Run an internal walkthrough using a realistic scenario in scope; capture notes as training evidence.
• Stand up the “incident evidence packet” standard and test it on one closed incident (or a simulated declared incident if you have no recent ones).
• Validate third party coordination steps for incidents where a third party system/service is involved.

Days 61–90 (prove consistency)

• Sample multiple declared incidents and confirm each has complete evidence mapped to the procedure.
• Fix gaps by adjusting the ticket template, required attachments, or approvals flow.
• Add a lightweight management review: periodic reporting on declared incidents and corrective actions.
• If you need to scale evidence and approvals, configure Daydream to standardize artifacts and maintain a clean audit trail across teams.

Frequently Asked Questions

What counts as a “declared cybersecurity incident” for this requirement?

The requirement does not define it for you; you must define it in your procedure and show a consistent decision point. Auditors will look for a recorded declaration event tied to a responsible role ¹.

Do we need a full NIST-style incident response program to satisfy C2M2 RESPONSE-2.B?

No specific external framework is mandated by this requirement. You do need defined procedures with roles, responsibilities, and response actions, plus evidence that declared incidents follow those procedures ¹.

What’s the minimum evidence to pass an assessment?

An approved incident response procedure with version history and approvals, and incident records that show declaration, actions taken, and closure mapped to the procedure steps. Operating artifacts matter as much as the document ¹.

How do we handle incidents involving a third party (cloud, MSSP, SaaS) in scope?

Your procedure should specify who coordinates with third parties, how communications are logged, and how you confirm remediation. Keep third party communications and tickets as part of the incident evidence packet.

What if we had no declared incidents during the assessment period?

Keep the approved procedure and show operational readiness through workflow configuration, role assignments, and a documented walkthrough or simulation tied to the procedure. If an incident is later declared, capture artifacts immediately to demonstrate day-to-day operation ¹.

How do we prove the procedure is followed if responders work in multiple tools?

Use a single system of record (often the incident ticket) and link out to supporting artifacts, then standardize an evidence packet per incident. Daydream can help consolidate approvals, version history, and artifacts so the mapping stays consistent across incidents.

What you actually need to do

Use the cited implementation guidance when translating the requirement into day-to-day operating steps. ²

Footnotes

1. Cybersecurity Capability Maturity Model v2.1

2. DOE C2M2 program