INCIDENT RESPONSE PLAN

Detection · Containment · Investigation · Notification · Recovery · Lessons Learned

ADJACENT FUNCTION — NOT A CERG-OWNED DOCUMENT

This artifact belongs to the standing Incident Response team, not to CERG. Per OM-001 §3.4, CERG is not responsible for Incident Response operations, the IR plan itself, regulatory notification clocks, or exercise management. CERG provides a liaison to the IR team and maintains this document in the repository for cross-functional integration only.

During an incident: the standing IR team’s procedures and the Incident Commander’s authority take precedence over any CERG workflow. CERG’s role during incidents is supporting (evidence, reporting, lessons-learned feedback per FLOW-001 F-06), not directing.

Ownership: This document is maintained by the standing IR team. CERG Governance reviews it for cross-reference accuracy only. Changes to IR procedures, notification timelines, or exercise schedules are the IR team’s responsibility.

Table of Contents

1. Purpose and Scope
2. Authority and Activation
3. Roles and the Incident Response Team
4. Incident Lifecycle
5. Severity Classification
6. Notification Obligations
7. Environment-Specific Considerations
8. Playbooks
9. Communications
10. Evidence, Forensics, and Legal Privilege
11. Exercises and Plan Maintenance
12. Regulatory and Framework Alignment Summary
13. Plan Control

1. Purpose and Scope

This plan operationalizes the incident response principle established in CERG-POL-001 Principle 10. It defines how the organization detects, contains, investigates, notifies, recovers from, and learns from cybersecurity events across all in-scope environments.

The plan is intentionally cross-environment. A single incident may span enterprise IT, cloud, SaaS, OT, and CUI environments simultaneously. The plan provides one structure of authority, classification, and notification, with environment-specific overlays that reflect the operational and regulatory reality of each domain.

1.1 Scope

This plan applies to:

• All confirmed and suspected cybersecurity events affecting organizational assets, data, or personnel
• All in-scope environments, owned data center, hybrid, cloud, SaaS, OT, BES Cyber Systems, CUI environments
• All third-party incidents that materially affect the organization (vendor compromises, software supply-chain compromises, shared-tenant impacts)
• All personnel involved in detection, response, decision-making, communication, and recovery

1.2 Definitions

1.3 Relationship to Parent Policy and Standards

This plan is subordinate to CERG-POL-001 and implements the response and recovery obligations of the peer standards. Where a peer standard imposes additional or more stringent notification, evidence, or recovery requirements, the more stringent requirement controls.

2. Authority and Activation

2.1 Authority

Single Decision Authority During Active Response

Incident response is not a consensus activity. The Incident Commander has single decision authority during active response. Containment and notification decisions are made by the IC after consultation with the appropriate Subject Matter Experts; they are not voted on. The IC remains accountable to the CISO and executive leadership and is briefed continuously.

The CISO is the standing Incident Commander. The CISO may delegate IC authority to a named deputy for a specific incident, with notification to executive leadership. Authority transitions are explicit and logged.

2.2 Activation Triggers

Activate this plan upon any of the following:

• Confirmed compromise of credentials with privileged access, or of a privileged identity platform
• Confirmed or strongly suspected unauthorized access to organizational systems or data
• Confirmed presence of ransomware, destructive malware, or unauthorized cryptographic activity on organizational systems
• Confirmed exfiltration or unauthorized disclosure of Confidential or Restricted-tier data
• Significant denial of service, integrity, or availability event affecting Tier 1 systems
• Any cyber event affecting BES Cyber Systems, CUI environments, SOX-relevant systems, or other regulated assets, where regulatory notification timelines may apply
• Vendor or supply-chain notification indicating the organization may be affected
• External notification (law enforcement, regulator, partner, customer) of a credible threat or breach

2.3 Activation Process

1. Triage. SOC / on-call analyst confirms the event meets activation criteria using documented triage criteria. When in doubt, activate.
2. Notify. Page the on-call IC and Lead Investigator. The IC confirms activation and assigns an incident identifier.
3. Establish. Open the incident channel (defined out-of-band communication path), open the incident record (ticketing system), and begin the timeline log.
4. Brief. Initial brief to the IC within 30 minutes of activation. The IC determines initial severity classification.
5. Mobilize. IC convenes the Incident Response Team appropriate to severity (Section 3).

3. Roles and the Incident Response Team

3.1 Standing Roles

3.2 Tier of Engagement

3.3 Third-Party Engagement

The CISO maintains the following pre-arranged external retainers, activated by the IC as needed:

• External forensics / digital investigation retainer: for surge capacity, specialized expertise, or independent investigation
• Breach coach / outside counsel: for privilege, multi-jurisdictional notification, and external communication
• Public relations / crisis communications partner: engaged at IC direction for material incidents
• Law enforcement / federal liaison contacts: FBI, CISA, sector ISAC, and DC3 (for CUI incidents)

Retainer contacts and activation procedures are maintained in the IRT contact roster, reviewed quarterly and distributed only to the standing IRT.

4. Incident Lifecycle

The lifecycle follows NIST 800-61r2 phases adapted for cross-environment operations.

4.1 Preparation (Continuous)

Preparation is the work performed before any specific incident. It includes maintaining this plan, training the IRT, exercising playbooks, validating tooling, maintaining external retainers, and ensuring detection telemetry is functioning. Preparation is not optional and is not “off the clock.”

4.2 Detection and Analysis

4.3 Containment

Containment objectives: stop ongoing harm, prevent lateral movement, preserve evidence, maintain operational integrity.

The “Don’t Tip Your Hand” Reminder

Premature containment can warn an adversary and accelerate destructive action, particularly in ransomware or supply-chain scenarios where the attacker may be actively monitoring response. Pace containment to scope, prefer reversible isolation, and coordinate with the Lead Investigator on telemetry implications before each major action.

4.4 Eradication

Eradication removes the adversary’s access and the means by which it was obtained. Eradication is declared complete only when:

• All identified persistence mechanisms (accounts, scheduled tasks, services, OAuth grants, IaC backdoors, malicious code) have been removed.
• Underlying vulnerabilities or misconfigurations have been remediated.
• Compensating controls are in place for issues that cannot be fully remediated immediately.
• Independent verification confirms the eradication actions.

4.5 Recovery

Recovery restores affected systems to operational service. Recovery is coordinated with operations, sequenced by business priority, and monitored for indications of recurrence.

4.6 Post-Incident Activity (Lessons Learned)

A post-incident review is mandatory for every P1 / Sev 1 and P2 / Sev 2 incident, and recommended for Sev 3. P1 / Sev 1 reviews occur within 14 calendar days of recovery; P2 / Sev 2 within 30 days.

The review produces:

• A factual timeline (detection, containment, eradication, recovery, notification milestones)
• A root-cause analysis (technical and process)
• A list of corrective actions categorized as Engineering, Risk, or Governance backlog items
• Updates to playbooks, detection rules, and this plan
• Lessons-learned briefing to leadership and to the IRT

Corrective actions are tracked to closure in the risk register with assigned owners and due dates.

5. Severity Classification

Severity drives engagement, communication cadence, and notification scrutiny. Severity may be revised at any time during response.

The IC may up- or down-grade severity at any time based on emerging information. Severity changes are logged on the incident timeline.

6. Notification Obligations

Notification is one of the highest-risk areas of incident response. Many obligations operate on clocks that begin at discovery, not at confirmation. The Incident Commander owns the notification-clock process for each in-flight incident, with Legal determining applicable obligations and Governance maintaining the supporting evidence and notification register at IC / Legal direction.

6.1 Internal Notification

6.2 External Notification (Regulator and Statutory)

6.3 Notification Decision Discipline

Two Failure Modes

The two notification failure modes are: notifying too early on incomplete information, or notifying too late after the regulatory clock has run. Both are damaging. The discipline is: (a) start the regulatory clock log at the moment of discovery, not at the moment of confirmation; (b) make notification decisions through the IC + Legal process, using Governance for evidence and regulatory-mapping support; (c) document the rationale at each decision point. If you would not be willing to defend the rationale to a regulator after the fact, do not adopt it during the incident.

7. Environment-Specific Considerations

7.1 Enterprise IT / Cloud / SaaS

Containment leverages cloud-native isolation (quarantine IAM, account suspension, security-group changes), conditional-access lockdowns, and SaaS admin-controlled session revocation. Forensic acquisition depends on provider-exposed artifacts; pre-staged acquisition procedures are maintained per CERG-STD-IT-001 §7.

7.2 OT / BES Cyber Systems

Operational Priority Rule

Response in OT environments evaluates every containment action for operational impact before execution. Isolation that would be routine in IT can produce a grid disturbance in OT. OT response actions require operations-team participation in the decision, not just notification.

OT incidents engage the operations liaison as a peer decision-maker on containment options. Containment defaults to least-disruptive options first (passive monitoring intensification, network-edge controls) before in-band actions. NERC-CIP CIP-008 reporting timelines run regardless of operational readiness; the IC owns the notification-clock process with Legal and OT Operations, while Governance supplies evidence and regulatory mapping support.

7.3 CUI Environments

CUI incidents trigger DFARS 252.204-7012 reporting via DC3 / DIBNet within 72 hours of discovery (Section 6.2). Evidence preservation requirements (90-day retention of images and malware) apply per CERG-STD-CUI-001 §7. The IC and Legal coordinate required contracting-officer engagement, with Governance providing evidence and contract-mapping support.

7.4 SOX-Relevant Systems

Incidents affecting SOX-relevant systems require Internal Audit and CFO designee engagement to assess ITGC control implications. Material control gaps may require disclosure considerations under SEC Item 1.05.

7.5 Third-Party / Supply-Chain Incidents

When the originating compromise is a third party (vendor, SaaS provider, software supplier), the IC owns the determination of whether the organization is itself affected, what containment actions are appropriate, and what onward notification is required. Vendor incident notifications are not a substitute for the organization’s own investigation.

8. Playbooks

The plan is supported by detailed playbooks maintained by the standing IR team as living artifacts in this repository for cross-functional integration. Each playbook follows a consistent structure: trigger criteria, immediate actions, investigation steps, containment options, recovery steps, evidence checklist, and notification triggers.

Currently maintained playbooks:

Playbooks are reviewed annually and updated upon material change to environment, tooling, or regulation. Playbook updates derived from post-incident reviews are tracked as Engineering / Risk / Governance backlog items.

9. Communications

9.1 Internal Communications

Internal communications channels for active response are pre-established and exercised. The plan assumes the possibility that organizational productivity systems (email, chat, ticketing) are compromised or unavailable.

9.2 External Communications

External communications during an active incident are owned by the IC, with content prepared by Communications and reviewed by Legal. The principles are:

• Say only what is established as fact. If a claim is not supported by current evidence, do not make it.
• Lead with the actions being taken and the protections in place for affected parties.
• Coordinate timing of public statements with regulatory and contractual notifications.
• Refer technical questions to the appropriate IRT spokesperson; refer regulatory questions to Legal, with Governance available for evidence and obligation-mapping support.
• Document every external statement in the incident timeline.

10. Evidence, Forensics, and Legal Privilege

10.1 Evidence Handling Principles

10.2 Privilege

The Legal Lead is involved at activation for all P1 / Sev 1 and P2 / Sev 2 events. Privileged work product is created under counsel direction and labeled accordingly. Whether and how privilege applies to forensic findings is a judgment of counsel; the IRT operates with privilege awareness from the outset.

10.3 Law Enforcement Engagement

Engagement with law enforcement is at the IC’s discretion in consultation with Legal, except where reporting is mandated. Law enforcement engagement may affect notification timing and content; the standing IR team maintains contact procedures for FBI Cyber, Secret Service, CISA, and DC3, with Governance repository support.

11. Exercises and Plan Maintenance

Exercise results, including identified gaps and corrective actions, are recorded in the risk register and tracked to closure.

12. Regulatory and Framework Alignment Summary

13. Plan Control

Revision History

Review Triggers

This plan shall be reviewed annually and upon any of the following:

• Any P1 / Sev 1 or P2 / Sev 2 incident affecting the organization
• Material change to applicable regulation (DFARS, CIP, SEC, breach laws, CIRCIA)
• Material change to the organization’s environments or tooling
• IRT structural change (CISO transition, new external retainer)
• Direction from the CISO, internal audit, or external examination

The standing IR team owns and maintains this plan. CERG Governance reviews repository links, metadata, and cross-references only. Updates to incident procedures, notification timelines, or exercise cadence require Incident Commander / CISO approval and IRT acknowledgment.

Related Documents

Source: plans/CERG-PLN-IR-001_Incident_Response_Plan.md · Download .md · View on GitHub