Incident Declaration

To meet the incident declaration requirement, you must define and document clear criteria that tell your teams exactly when an event becomes a “cybersecurity incident,” who can declare it, and what immediate actions (escalation, communications, and tracking) must follow. C2M2 v2.1 expects consistent, timely declarations based on established triggers, not ad hoc judgment. ¹

Key takeaways:

• Write objective declaration criteria tied to impact, scope, and confidence, then map each trigger to an escalation path.
• Assign decision rights (who declares, who is consulted, who is informed) and bake them into your incident response playbooks and tooling.
• Prove it works with exercises or after-action reviews, and retain evidence that declarations happened per criteria. ¹

“Incident declaration” is the moment your organization formally decides: this is no longer routine security operations, this is an incident that requires an incident-response cadence, executive visibility, and controlled communications. If you do not define that moment, you get predictable failure modes: delayed escalation, inconsistent decisions across shifts or sites, confusion about who is in charge, and weak auditability when customers or regulators ask why you did (or did not) treat something as an incident.

C2M2 v2.1 RESPONSE-2.A (MIL1) is a baseline maturity expectation: establish criteria for declaring cybersecurity incidents. ¹ For a CCO or GRC lead, the fastest path is to treat this as a control-design exercise with operational hooks: define triggers, define decision authority, define the workflow that starts at declaration, and define the evidence trail you will produce every time.

This page gives you requirement-level implementation guidance you can hand to IR, SOC, and OT operations, with artifacts that stand up to internal control testing and third-party due diligence.

Regulatory text

Requirement (C2M2 v2.1 RESPONSE-2.A, MIL1): “Criteria for declaring cybersecurity incidents are established.” ¹

What the operator must do

You need documented, organization-approved criteria that:

1. distinguish “event” from “incident,”
2. define who is authorized to declare an incident, and
3. enable consistent and timely declarations across the scoped environment (IT, OT, or both). ¹

C2M2 is a capability maturity model used heavily in critical infrastructure contexts, including energy. The practical expectation is repeatability: two different responders reviewing the same facts should reach the same declaration decision most of the time because the criteria are explicit.

Plain-English interpretation

Declare an incident based on defined triggers, not on intuition or seniority. Your criteria should answer:

• What happened? (malware, unauthorized access, data exposure, service disruption, safety impact, integrity loss)
• How bad is it? (material impact thresholds that fit your environment)
• How confident are we? (suspected vs confirmed, and what evidence is needed to move between states)
• Where is it? (IT vs OT, corporate vs plant network, cloud vs on-prem)
• Who decides? (SOC lead, IR manager, on-call incident commander, OT duty officer)

The goal is speed with control: quick escalation when it matters, and disciplined non-escalation when it does not.

Who it applies to

Entities

Organizations using C2M2 v2.1 to assess or improve cybersecurity maturity, particularly energy sector organizations and other critical infrastructure operators. ¹

Operational context (where this breaks in practice)

• Hybrid IT/OT environments: OT engineers may treat availability as paramount; IT may focus on confidentiality. Declaration criteria must reconcile both.
• 24/7 operations: shift handoffs create inconsistent calls unless criteria are explicit and logged.
• Third parties: managed service providers (MSPs), OEMs, and integrators often detect issues first. Your criteria must state how third-party signals can trigger declaration and who validates.

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

Step 1: Define your declaration decision matrix (write it down)

Build a one-page matrix that responders can use in minutes. Include:

A. Trigger categories (examples)

• Access compromise indicators: confirmed unauthorized access, credential theft with evidence of use, privileged account misuse.
• Malware and ransomware indicators: encryption activity, confirmed lateral movement, execution on critical hosts.
• Service impact: sustained outage or degradation of a critical service/system (define what “critical” means in your scope).
• Data impact: confirmed exfiltration, exposure, or integrity compromise of sensitive data sets.
• OT-specific impact: loss of view/control, unsafe state, unexpected changes to logic/configuration, safety system involvement.

B. Severity levels Use a small set (for example: low/medium/high/critical) with plain definitions. Keep it actionable. Your criteria should say what level requires formal incident declaration versus internal ticket handling.

C. Confidence states Define “suspected incident” vs “confirmed incident,” and what evidence moves a case between them (EDR alert plus corroborating logs, for example). This prevents paralysis when signals are strong but incomplete.

Deliverable: Incident Declaration Criteria v1.0 (document + quick-reference page).

Step 2: Assign decision rights and escalation paths

Write a RACI-style table:

• Incident Declaring Authority (IDA): specific roles (not names) authorized to declare.
• Incident Commander (IC): who runs response after declaration.
• Consulted: legal, privacy, OT operations, comms, third-party management, risk.
• Informed: CIO/CISO, business owners, affected site leaders.

Define backup coverage for after-hours and plant/site contexts.

Deliverables:

• RACI + on-call roster linkage
• Escalation path diagram (who calls whom, and how fast your internal expectations are)

Step 3: Hardwire declaration into the incident response workflow

Declaration is only useful if it triggers a standard workflow. Minimum workflow elements:

1. Open an incident record in your system of record (IR platform, ticketing, or GRC tool).
2. Timestamp the declaration (start of incident clock).
3. Assign incident owner/IC and responders.
4. Start a communications workflow (internal notifications, third-party notifications if applicable, and rules for outbound comms).
5. Preserve evidence (log retention holds, snapshots, chain-of-custody steps if your environment needs it).
6. Set a cadence for updates (e.g., operational briefings) appropriate to severity.

C2M2’s requirement is “criteria established,” but audits will test operational reality: criteria that do not connect to a workflow are paper controls. ¹

Deliverables:

• IR playbook section: “Incident Declaration”
• Ticket/IR form fields mapped to your criteria (trigger type, severity, confidence, declaring authority)

Step 4: Integrate third-party detection and reporting paths

If an MSP, cloud provider, or OEM notifies you of suspicious activity, your criteria should state:

• what minimum information you need to declare (or to declare “suspected incident”),
• who receives third-party notices (not a shared mailbox only),
• how you validate third-party assertions,
• how you log third-party-originated declarations.

This matters for critical infrastructure operations where third-party remote access and maintenance is common.

Deliverables:

• Third-party incident intake procedure (including contacts and routing)
• Contract/SLA hooks (notification obligations aligned to your declaration workflow, where feasible)

Step 5: Prove it works: exercises and after-action improvements

Run periodic exercises or post-incident reviews and retain after-action items showing the process was tested and improved. ¹ Your evidence should show:

• responders used the criteria,
• a declaration decision occurred,
• improvements were captured and tracked to closure.

Deliverables:

• Tabletop or functional exercise report
• After-action review (AAR) with corrective actions
• Change log showing updates to criteria/playbooks

Step 6: Operationalize in tooling (so you can answer auditors quickly)

If you use Daydream for control management and evidence collection, map “Incident Declaration” to:

• the approved criteria document,
• the RACI and playbook,
• sample incident records showing declared/not-declared decisions,
• exercise/AAR artifacts and remediation tracking.

The audit win: one control, one evidence package, consistent refresh cadence.

Required evidence and artifacts to retain (exam-ready)

Keep these in a single evidence folder or GRC control record:

1. Approved Incident Declaration Criteria (versioned, with owner and approval date) ¹
2. Incident Response Playbook section that references the criteria and describes the declaration workflow ¹
3. RACI / decision authority documentation (roles authorized to declare, escalation contacts)
4. Incident records (sanitized if needed) that show:
   • trigger observed,
   • declaration decision,
   • timestamp,
   • severity/confidence,
   • who declared
5. Exercise or AAR documentation with action items and closure evidence ¹
6. Training/enablement proof (SOC/OT runbook distribution, acknowledgment, or training attendance)

Common exam/audit questions and hangups

Auditors, assessors, and customer diligence teams tend to focus on repeatability and proof:

• “Show me your criteria.” They expect documented triggers, not “we know it when we see it.”
• “Who can declare an incident?” If it is unclear, decisions drift upward and slow down.
• “Prove you followed your criteria on real cases.” Provide incident records, including borderline events that were not declared and why.
• “How do third parties report incidents to you?” They will probe whether MSP alerts get lost or delayed.
• “How do you validate and improve the criteria?” Exercises and AARs are the cleanest evidence. ¹

Hangup to anticipate: teams confuse severity classification with incident declaration. You need both: declaration is the gate; severity is a property once declared.

Frequent implementation mistakes (and how to avoid them)

1. Criteria that read like a policy, not a decision tool.
   Fix: build a one-page matrix with triggers and examples, then reference it in the policy.

2. “Only the CISO can declare.”
   Fix: delegate to on-call operational roles with defined escalation to executives.

3. No “suspected incident” state.
   Fix: allow declaration at reasonable confidence, with a clear path to confirm or downgrade.

4. OT excluded.
   Fix: add OT-specific triggers and route to OT duty leadership. Align on safety/availability impacts.

5. Evidence scattered across tools.
   Fix: centralize artifacts in your GRC system (or a controlled repository) and tie them to the requirement.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. Operationally, the risk is still concrete: without rehearsed and documented declaration criteria, organizations respond inconsistently, lose time during escalation, and struggle to prove required actions during internal control testing, audits, customer diligence, or regulator review. ¹

Practical 30/60/90-day execution plan

First 30 days (design and alignment)

• Name an owner for incident declaration criteria (often IR lead with GRC support).
• Draft the decision matrix (triggers, severity bands, confidence states).
• Define declaring authority and escalation contacts; align with SOC and OT operations.
• Update the IR playbook to include the declaration step and required fields in the incident record.

Days 31–60 (implement and train)

• Configure ticketing/IR tooling to capture declaration fields (trigger, severity, confidence, declaring authority, timestamp).
• Publish quick-reference guidance for on-call staff.
• Run a tabletop focused only on “declare vs don’t declare” decisions and escalation speed.
• Collect initial evidence: the signed criteria, playbook excerpt, and exercise artifacts. ¹

Days 61–90 (validate, refine, and operationalize evidence)

• Perform a focused review of recent security events to confirm the criteria produce consistent decisions.
• Update criteria based on lessons learned; version the document and record approvals.
• Add third-party intake routing and test it (MSP notification simulation).
• Build an audit-ready evidence pack in Daydream (or your GRC repository) that stays current with minimal manual effort.

Frequently Asked Questions

Who should be allowed to declare a cybersecurity incident?

Assign declaring authority to specific operational roles with on-call coverage, then require notification/escalation to leadership based on severity. Keep the decision rights in a RACI so declarations do not stall during nights, weekends, or site events.

How do we handle “suspected” incidents without over-escalating everything?

Define a “suspected incident” declaration state with minimum evidence thresholds and a time-boxed validation workflow. Your criteria should allow downgrades with documented rationale in the incident record.

Do we need different declaration criteria for IT and OT?

Yes, in most critical infrastructure environments. Add OT-specific triggers (loss of view/control, unsafe states, unexpected logic changes) and define joint escalation so OT operations is engaged immediately when criteria hit.

What evidence is strongest for auditors assessing incident declaration?

A version-controlled criteria document plus real incident records that show the criteria being applied consistently. Exercises or after-action reviews that led to tracked improvements are also strong evidence. ¹

How should third-party incidents feed into our declaration process?

Treat third-party notifications as potential triggers and define who receives them, what validation is required, and how the incident is logged. Make sure the workflow works even if the third party’s report is incomplete.

We already have an incident response plan. Why do we need separate “declaration criteria”?

Many IR plans describe what to do after an incident exists, but not how the organization decides an incident exists. Declaration criteria are the gate that makes IR consistent and auditable across teams and shifts. ¹

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