INCIDENT RESPONSE PLAYBOOK SET

CERG Inputs · IR Team Handoff · Scenario Checklists · Evidence and Recovery Support

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. Ownership Boundary
3. Common Playbook Structure
4. Playbook 1: Ransomware
5. Playbook 2: Business Email Compromise
6. Playbook 3: Data Breach or Exfiltration
7. Playbook 4: Phishing Campaign
8. Playbook 5: Distributed Denial of Service
9. Playbook 6: Insider Threat
10. Playbook 7: Cloud Account Compromise
11. Playbook 8: Supply Chain Compromise
12. Playbook 9: Web Application Attack
13. Playbook 10: Malware Outbreak
14. Playbook 11: Zero-Day Exploitation
15. Playbook 12: Cryptographic Compromise
16. Playbook 13: Social Engineering
17. Post-Incident CERG Actions
18. Roles and Responsibilities
19. Regulatory and Framework Alignment Summary
20. Document Control

1. Purpose and Scope

CERG-PLN-IR-001 establishes the Incident Response Plan. CERG-GOV-OM-001 §3.4 states that incident response is owned by a standing Incident Response team, not by CERG. That boundary is correct and must remain. At the same time, CERG owns many controls, records, and technical inputs the Incident Response team needs during an incident.

This document provides CERG-facing incident playbooks: what CERG prepares, what CERG hands to the Incident Response team, what CERG supports during containment, eradication, recovery, communications, and evidence preservation, and what CERG does after the incident to turn lessons into risks, controls, and evidence.

This is not a SOC procedure, forensics manual, or replacement Incident Response Plan. It is a support and handoff playbook set for CERG-managed systems and controls.

CERG Does Not Command the Incident. CERG Makes the Incident Runnable.

During an active incident, the Incident Commander commands. CERG does not create a parallel command structure. CERG brings the material the Incident Response team needs: asset context, data classification, control evidence, logging posture, recovery dependencies, risk history, vendor context, and the owners who can change the environment safely. The boundary is simple: the IR team runs the incident; CERG makes sure the IR team is not guessing.

2. Ownership Boundary

The standing IR team owns and maintains this playbook set. CERG Governance provides repository, cross-reference, and evidence-integration support only. Scenario execution during an active incident is under the Incident Commander.

2.1 Integration with the Incident Response Plan

This playbook set operates under CERG-PLN-IR-001 (the IR Plan), which is owned by the standing Incident Response team. The following defines how the two documents connect operationally.

Activation Flow

Information Flow

• The Incident Commander provides CERG with: incident declaration, severity, affected scope, and status updates
• CERG provides the Incident Commander with: asset inventory, data classification, control evidence, risk history, vendor context, and recovery dependencies
• CERG actions taken during the incident are documented in the IR record by the Evidence Librarian

2.2 Playbook Testing and Exercise Program

Playbooks are tested to validate that they work as intended and that CERG personnel can execute them under pressure.

Testing Cadence

Exercise Design

• Exercises are designed and owned by the Incident Commander / standing IR team; Governance and Risk provide CERG support scenarios and evidence objectives
• Each exercise has defined objectives, success criteria, and an after-action review
• Exercises test the playbook, not the individuals; the goal is to find gaps, not to evaluate performance

Success Criteria

Exercise Findings

Exercise findings feed into CERG-PRC-LL-001 as lesson artifacts when they affect CERG controls, evidence, risk, or support procedures. The standing IR team approves playbook updates based on exercise findings; CERG Governance updates repository links and CERG-facing support language within 30 days of the after-action review.

3. Common Playbook Structure

Each scenario uses the same structure so teams can move quickly.

3.1 Playbook Selection Guide

When an incident is reported, use the following decision tree to select the appropriate playbook. For multi-vector incidents, activate the highest-severity playbook first, then supplement with relevant sections from other playbooks as the incident scope clarifies.

If none of the above match, or if the incident type is unclear, activate the playbook that most closely matches the observed indicators and consult the Incident Commander for direction. The Incident Commander may override playbook selection at any time.

3.2 Incident Severity Classification

All incidents are classified by severity to determine response priority, escalation requirements, and notification obligations. This playbook set uses the P1–P4 severity scale aligned with the Incident Response Plan (CERG-PLN-IR-001 §5, which defines the authoritative Sev 1–4 classification). The mapping is: P1 = Sev 1 (Critical), P2 = Sev 2 (Significant), P3 = Sev 3 (Moderate), P4 = Sev 4 (Minor).

Escalation Thresholds

• Any P1 / Sev 1 or P2 / Sev 2 incident: CISO is notified immediately. The Incident Commander and Legal determine regulatory notification obligations; Governance supplies evidence and obligation-mapping support.
• Any incident involving PII, CUI, or BCSI: The relevant compliance manager (CMMC / NERC-CIP) is engaged within the first hour.
• Any incident with potential customer impact: Account Management and Legal are engaged per the Incident Response Plan.
• Any incident lasting > 24 hours: Severity is re-evaluated; a P2 / Sev 2 that persists > 24 hours may be elevated to P1 / Sev 1 at the Incident Commander’s discretion.

4. Playbook 1: Ransomware

4.1 Triage

CERG supports the Incident Response team by rapidly identifying:

• affected assets and asset owners from the inventory;
• criticality and recovery priority from CERG-STD-AM-001;
• data classification and regulated data exposure from CERG-STD-DG-001;
• backup status and last known good recovery point from CERG-STD-RES-001;
• identity paths and privileged sessions that may be involved;
• relevant vulnerabilities, open risks, or exceptions.

4.2 Containment

CERG-supported containment may include: disabling compromised identities, isolating affected network segments or endpoints, blocking command-and-control indicators, freezing risky privileged access, pausing affected automation, and preserving backup systems from contamination.

4.3 Eradication and Recovery

CERG supports eradication by identifying the likely control failure: exposed remote access, missing MFA, vulnerable service, endpoint control gap, credential theft, misconfiguration, or vendor path. Recovery support includes baseline validation, restore validation, vulnerability remediation, and logging confirmation before production return.

4.4 Evidence and Communications Inputs

CERG preserves asset inventory snapshots, backup evidence, affected-data classification, security-control status, risk-register history, exception history, and relevant logs. Governance supplies regulatory mapping and evidence for customer, regulator, or executive communication.

5. Playbook 2: Business Email Compromise

5.1 Triage

CERG identifies the compromised mailbox or identity, MFA status, sign-in history, mailbox rules, forwarding rules, suspicious OAuth grants, sent mail volume, external recipients, and whether payments, regulated data, or executive impersonation are involved.

5.2 Containment

CERG support may include: disabling the account, revoking sessions and tokens, removing malicious mailbox rules, disabling external forwarding, resetting credentials, blocking indicators, quarantining related messages, and identifying other recipients or compromised accounts.

5.3 Eradication and Recovery

CERG validates that the mailbox, identity, OAuth grants, rules, and recovery methods are clean before returning access. Email and messaging control gaps are tracked under CERG-STD-MSG-001.

5.4 Evidence and Communications Inputs

CERG preserves sign-in logs, mailbox audit logs, message traces, rule changes, MFA status, external forwarding evidence, DLP alerts, and related risk or exception records. Governance supplies SOX, privacy, and customer-scope implications where relevant.

6. Playbook 3: Data Breach or Exfiltration

6.1 Triage

CERG determines what data may be involved, its classification, the affected systems, the likely exfiltration path, volume, time window, data owner, and regulated or contractual obligations. Restricted data, CUI, BES Cyber System Information, personal data, and financial reporting data receive immediate Governance involvement.

6.2 Containment

Containment may include blocking exfiltration paths, disabling identities, revoking vendor access, suspending risky integrations, enforcing DLP blocks, rotating exposed secrets, and isolating affected repositories or storage locations.

6.3 Eradication and Recovery

CERG identifies and remediates the control gap: access failure, DLP failure, storage exposure, vendor path, compromised credential, misconfiguration, or logging gap. Recovery includes validating access, storage, DLP, and monitoring controls before normal operations resume.

6.4 Evidence and Communications Inputs

CERG preserves data classification records, data-owner confirmation, access logs, DLP events, storage configuration, vendor access logs, risk-register entries, and evidence of containment actions.

7. Playbook 4: Phishing Campaign

7.1 Triage

CERG identifies reported messages, sender infrastructure, subject and lure, affected users, clicked users, credential submissions, malicious links or attachments, and whether the campaign targets executives, privileged users, finance, or regulated environments.

7.2 Containment

Containment may include message purge, URL or attachment blocking, credential resets, session revocation, OAuth grant removal, mailbox rule review, and user notification. Employee reporting remains blame-free under CERG-STD-MSG-001.

7.3 Eradication and Recovery

CERG supports control tuning: email filtering, DMARC/SPF/DKIM review, user-reporting workflow, DLP, mailbox auditing, and detection content. If the phish leads to account compromise, Playbook 2 also applies.

7.4 Evidence and Communications Inputs

CERG preserves reported messages, message trace, user-report timestamps, click and submission evidence, containment actions, and affected-account actions.

8. Playbook 5: Distributed Denial of Service

8.1 Triage

CERG identifies affected services, customer or operational impact, upstream providers, DDoS protection status, network paths, service dependencies, and whether the incident masks another attack.

8.2 Containment

Containment support may include activating DDoS protection, coordinating with providers, changing routing or filtering, scaling resilient services, protecting management interfaces, and preserving logs showing attack characteristics.

8.3 Eradication and Recovery

DDoS is rarely eradicated in the traditional sense. CERG supports service restoration, resilience validation, provider review, and permanent control improvements after the attack subsides.

8.4 Evidence and Communications Inputs

CERG preserves traffic metrics, provider tickets, protection activation evidence, affected-service timelines, customer-impact timeline, and recovery evidence.

9. Playbook 6: Insider Threat

9.1 Triage

CERG supports the Incident Response team carefully and discreetly. Triage identifies affected systems, data classification, access history, anomalous behavior, DLP events, privileged activity, and risk to investigation integrity. Access to information is strictly need-to-know.

9.2 Containment

Containment may include access suspension, privilege reduction, session revocation, monitoring preservation, device preservation, and targeted control changes. Actions are coordinated with the Incident Commander and appropriate legal, HR, or executive process outside CERG.

9.3 Eradication and Recovery

CERG identifies control improvements: access review gaps, segregation-of-duties gaps, logging gaps, DLP gaps, privileged access gaps, or data governance failures. Recovery may include access recertification and control strengthening.

9.4 Evidence and Communications Inputs

CERG preserves access logs, DLP events, privileged activity, data classification, asset ownership, risk records, and evidence-chain notes as directed by the Incident Commander and Lead Investigator.

10. Playbook 7: Cloud Account Compromise

10.1 Triage

CERG identifies the affected tenant, account, subscription, project, workload, identity, access keys, service principals, secrets, exposed data, privilege level, and recent control-plane activity. Cloud account compromise is treated as both identity and platform compromise.

10.2 Containment

Containment may include disabling or isolating identities, revoking sessions, rotating keys and secrets, blocking suspicious IPs, quarantining workloads, snapshotting evidence, disabling risky automation, and preserving control-plane logs.

10.3 Eradication and Recovery

CERG identifies the root path: credential theft, exposed secret, misconfigured federation, over-privileged role, vulnerable workload, or malicious OAuth or service principal. Recovery requires validation of IAM, logging, network controls, baseline conformance, and secrets rotation.

10.4 Evidence and Communications Inputs

CERG preserves cloud audit logs, IAM history, key and secret rotation records, workload inventory, network flows, storage access logs, risk-register records, and affected-data classification.

11. Playbook 8: Supply Chain Compromise

11.1 Triage

CERG supports the Incident Response team by rapidly identifying: - affected vendor, service, or software component from the TPRM records and asset inventory; - data classifications and regulated data potentially exposed through the vendor; - vendor tier and criticality from CERG-PRC-TPRM-001; - the organization’s usage of the affected service (direct, embedded, transitive); - any IOCs or threat intelligence from CERG-PRC-TI-001; - affected systems, identities, or data paths that integrate with the compromised vendor.

11.2 Containment

CERG-supported containment may include: disabling vendor access and integrations, revoking vendor API keys and service accounts, blocking vendor IP ranges, isolating systems that consume the affected service, suspending data flows to/from the vendor, and preserving evidence of the vendor relationship for investigation. If the vendor compromise is confirmed, the SCCT is activated per CERG-PRC-TPRM-001 Section 15.

11.3 Eradication and Recovery

CERG identifies the vendor dependency path: direct integration, embedded library, transitive dependency, or shared infrastructure. Recovery may require vendor remediation, service replacement, or architectural decoupling. CERG validates that replacement or remediated services meet control requirements before restoration. Vendor risk records are updated to reflect the incident and any tier, evidence, or monitoring changes.

11.4 Evidence and Communications Inputs

CERG preserves: vendor contract and security obligations, TPRM assessment records, vendor access logs, data flow documentation, integration architecture, and evidence of containment and recovery actions. Governance supplies regulatory mapping for any regulated data exposed through the vendor.

12. Playbook 9: Web Application Attack

12.1 Triage

CERG identifies: the affected application, its data classification, authentication mechanism, hosting environment (cloud, on-prem, SaaS), whether it processes regulated data (CUI, SOX, PII), the likely attack vector (SQLi, XSS, CSRF, SSRF, IDOR, auth bypass, API abuse), and whether WAF or other protective controls were in place and functioning per CERG-GOV-CB-001.

12.2 Containment

Containment may include: taking the affected application or endpoint offline, blocking the attack source IPs, enabling WAF blocking rules, disabling the vulnerable function, revoking compromised sessions and tokens, rotating application secrets, and quarantining affected application servers for forensic imaging.

12.3 Eradication and Recovery

CERG supports the application team in identifying and fixing the vulnerability: code fix, configuration change, WAF rule, or architectural change. Recovery includes validating the fix, re-scanning per the application penetration test checklist in CERG-PRC-AV-001 Section 8, and confirming detection rules are updated for the observed attack pattern.

12.4 Evidence and Communications Inputs

CERG preserves: application logs, WAF logs, authentication logs, database audit logs, attack payloads, vulnerability scan results, fix evidence, and retest results. If the application handles regulated data, the Incident Commander and Legal determine notification obligations; Governance supplies evidence and obligation-mapping support.

13. Playbook 10: Malware Outbreak (Non-Ransomware)

13.1 Triage

CERG identifies: affected endpoints and servers, malware type (infostealer, RAT, botnet, cryptominer, wiper - differentiated from ransomware per Playbook 1), command-and-control infrastructure, initial infection vector, scope of compromise (which systems, what data accessed), and whether the malware has credential-theft or lateral-movement capability.

13.2 Containment

Containment may include: isolating affected systems, blocking C2 indicators at the network edge, disabling compromised accounts, forcing credential resets, quarantining affected mailboxes or file shares, and suspending automation or scheduled tasks that could propagate the malware.

13.3 Eradication and Recovery

CERG supports eradication by identifying the infection vector: email attachment, drive-by download, removable media, software supply chain, or exploited vulnerability. Recovery includes: re-imaging affected systems from known-good baselines, restoring data from clean backups, validating EDR coverage, and confirming that C2 indicators are blocked and detection rules are active.

13.4 Evidence and Communications Inputs

CERG preserves: malware samples, C2 logs, affected system inventory, infection timeline, containment actions, and recovery evidence. If the malware accessed regulated data, the Incident Commander and Legal determine notification obligations; Governance supplies evidence and obligation-mapping support.

14. Playbook 11: Zero-Day Exploitation

14.1 Triage

CERG identifies: the affected software, version, vendor, and patch status; whether the vulnerability is publicly disclosed or actively exploited in the wild; which organizational assets are vulnerable; the exploit vector (remote, local, authenticated); and whether the vulnerability affects regulated systems (SOX, CUI, NERC-CIP). Threat intelligence from CERG-PRC-TI-001 is consulted for IOCs and TTPs.

14.2 Containment

Containment may include: disabling the affected service or feature, applying vendor-provided mitigation (if available before a patch), implementing network-level blocking rules, isolating vulnerable systems, increasing monitoring on vulnerable but not-yet-compromised systems, and communicating the threat to system owners per the exposure management procedure.

14.3 Eradication and Recovery

CERG tracks the vendor patch release and coordinates with Engineering for emergency patch deployment per CERG-PRC-VM-001 §5.2. If compromise is confirmed, eradication follows the relevant playbook for the post-exploitation activity (Data Breach, Cloud Compromise, etc.). Recovery validates that the patch is applied, the vulnerability is remediated, and compensating controls are in place for any systems that cannot be immediately patched.

14.4 Evidence and Communications Inputs

CERG preserves: vulnerability advisory or CVE, affected asset inventory, patch deployment evidence, containment actions, and any compromise evidence. For vulnerabilities affecting regulated systems, the Incident Commander and Legal determine regulatory notification obligations; Governance supplies evidence and obligation-mapping support.

15. Playbook 12: Cryptographic Compromise

15.1 Triage

CERG identifies: the compromised cryptographic material (certificate, private key, signing key, API key, secret), its scope of use (which systems, services, or identities depend on it), whether it protects regulated data or authentication, the likely compromise vector (exposed secret, insider, CA compromise, weak algorithm, side-channel), and the blast radius if the key is actively exploited.

15.2 Containment

Containment may include: revoking the compromised certificate or key, rotating all secrets in the same scope, invalidating sessions and tokens signed with the compromised key, blocking authentication paths that relied on the compromised material, and preserving forensic evidence of the compromise for root cause analysis. Emergency rotation follows CERG-STD-CR-001 Section 8.

15.3 Eradication and Recovery

CERG coordinates with the Cryptography Engineer to: identify how the material was compromised (exposed in repository, weak generation, insider action, CA breach), remediate the root cause, issue replacement material through the approved PKI or secrets management process, deploy replacement material to all dependent systems, and validate that no system continues to trust the compromised material.

15.4 Evidence and Communications Inputs

CERG preserves: certificate or key metadata, revocation records, rotation evidence, affected system inventory, and timeline of compromise and recovery. If the compromised material protected regulated data or authentication to regulated systems, the Incident Commander and Legal determine notification obligations; Governance supplies evidence and obligation-mapping support. Certificate Transparency logs are monitored for 30 days post-incident for anomalous issuance.

16. Playbook 13: Social Engineering (Vishing / Smishing)

16.1 Triage

CERG identifies: the social engineering vector (phone call, SMS, messaging app), the pretext used, targeted individuals and their roles (executive, finance, IT admin, privileged user), what information or access was obtained, whether credentials were disclosed or MFA was bypassed, and whether the attack led to account compromise, financial transfer, or data disclosure.

16.2 Containment

Containment may include: disabling affected accounts, revoking sessions, resetting credentials, blocking the attacker’s phone number or messaging account, quarantining related messages, identifying and protecting other potential targets briefed on the pretext, and notifying the telecom provider or messaging platform if account takeover is suspected.

16.3 Eradication and Recovery

CERG supports eradication by identifying the control gap: lack of verification procedure for sensitive requests, MFA bypass, absence of out-of-band confirmation for financial transfers, or training gap. Recovery includes: updating awareness content, implementing verification procedures for high-risk requests (financial, credential, data), and confirming that affected individuals receive targeted follow-up training.

16.4 Evidence and Communications Inputs

CERG preserves: call or message records, pretext details (sanitized for distribution), affected account logs, containment actions, and awareness recommendations. Social engineering findings are reported separately from technical findings. No disciplinary action shall result from an employee falling for a social engineering attack; the incident informs program improvement, not individual performance management.

17. Post-Incident CERG Actions

After the Incident Commander closes active response, CERG completes its own post-incident work.

18. Roles and Responsibilities

Roles below are canonical role names from CERG-GOV-OM-001 §6.1.

18.1 CERG On-Call and Activation

CERG maintains an on-call rotation for incident support. The rotation schedule is maintained in the incident response tooling and is not duplicated here to avoid staleness. The following defines the activation procedure and escalation contacts.

Activation Procedure

1. Declaration: The Incident Commander (or delegate) declares an incident and determines severity per Section 3.2.
2. CERG Notification: The Incident Commander or SOC notifies the CERG on-call contact through the designated channel (secure messaging, phone).
3. Pillar Activation: - P1 / Sev 1 and P2 / Sev 2: Engineering Pillar Leader and Risk Pillar Leader are activated immediately. Governance Pillar Leader is activated for evidence support and regulatory mapping at IC / Legal direction. - P3 / Sev 3: Relevant pillar leader(s) activated as needed. - P4 / Sev 4: CERG monitors; no activation unless escalated.
4. Acknowledgment: Activated CERG roles acknowledge within 30 minutes (P1 / Sev 1), 1 hour (P2 / Sev 2), or 4 hours (P3 / Sev 3).
5. Stand-down: The Incident Commander declares stand-down; CERG returns to normal operations and begins post-incident actions per Section 17.

Escalation Contacts

19. Regulatory and Framework Alignment Summary

19.1 Communication Templates

The following templates support incident communications. Templates are populated during the Communications phase of each playbook. All templates are marked with the incident’s classification level.

Initial Incident Notification (Internal)

INCIDENT NOTIFICATION - IR-YYYY-NNNN
Classification: [per incident classification]
Date/Time: [declaration timestamp]
Severity: [P1 / Sev 1 / P2 / Sev 2 / P3 / Sev 3 / P4 / Sev 4]

Incident Commander: [name]
CERG Lead: [name]

Incident Type: [Ransomware / BEC / Data Breach / etc.]
Affected Systems: [list]
Affected Data: [classifications, if known]
Current Status: [Triage / Containment / Eradication / Recovery]
Next Update Expected: [time]

Actions Requested:
- [Any specific actions needed from recipients]
- [Do not take independent action without Incident Commander approval]

Contact: [Incident Commander contact]

Status Update Template

INCIDENT STATUS UPDATE - IR-YYYY-NNNN
Update #: [N]
Date/Time: [timestamp]
Classification: [per incident classification]

Status Change Since Last Update:
- [What changed]
- [New findings]
- [Containment actions completed]
- [Recovery progress]

Current Assessment:
- [Current state of the incident]
- [Remaining actions]

Estimated Time to Resolution: [estimate]
Next Update Expected: [time]

Regulatory Breach Notification Template

REGULATORY NOTIFICATION - IR-YYYY-NNNN
Classification: CONFIDENTIAL - REGULATORY
Date/Time: [timestamp]

To: [Regulatory body / contact]
From: [Organization representative]

Incident Type: [description]
Date of Discovery: [date]
Affected Data Subjects: [count and jurisdictions]
Data Types Affected: [PII / CUI / BCSI / etc.]
Description of Incident: [factual, concise]
Measures Taken: [containment, investigation, remediation]
Measures Planned: [next steps]
Contact for Follow-up: [name, role, contact]

Attachments: [list]

Customer / Partner Communication Template

INCIDENT NOTICE - IR-YYYY-NNNN
Classification: [as approved by Legal and Incident Commander]
Date: [date]

To: [Customer / Partner contact]

[Organization] is writing to inform you of a security incident that may affect [the service / data / system] we provide to you.

What Happened: [factual description, approved by Legal]
What Data Was Affected: [if applicable, approved by Legal]
What We Have Done: [containment and remediation actions]
What We Are Doing: [ongoing actions]
What You Should Do: [any recommended customer actions]

We will provide additional information as it becomes available. If you have questions, please contact [name / role / contact].

[Signature block]

Post-Incident Summary Template

POST-INCIDENT SUMMARY - IR-YYYY-NNNN
Classification: [per incident classification]
Date Closed: [date]

Incident Overview: [type, severity, timeline]
Root Cause: [determined or suspected]
Affected Systems and Data: [list]
Containment and Eradication Actions: [summary]
Recovery Actions: [summary]
Evidence Preserved: [list of evidence artifacts]
Residual Risk: [risk register entries created]
Lessons Learned: [key findings for program improvement per CERG-PRC-LL-001]
Action Items: [owner, action, due date]

Prepared by: [Standing IR Team / CERG support contributor]
Reviewed by: [Incident Commander, CISO]

20. Document Control

Revision History

Review Triggers

• Significant incident or exercise finding
• Change to CERG-PLN-IR-001
• Material change to logging, resilience, data governance, email, or cloud security standards
• Change to legal, regulatory, or contractual incident-notification obligations
• Direction from the CISO or Incident Commander

The standing IR team owns and maintains this playbook set. CERG Governance reviews repository links, metadata, cross-references, and CERG-facing evidence/support language only. Changes to incident procedures, notification timelines, exercise cadence, or scenario execution require Incident Commander / CISO approval and IRT acknowledgment.

Related Documents

Source: procedures/CERG-PRC-IR-002_Incident_Response_Playbook_Set.md · Download .md · View on GitHub