Document Version: 1.0 Classification: Internal - Incident Response Use Last Updated: 2026-03-22 Approval Required From: CISO, VP Engineering, Chief Legal Officer Drill Frequency: Quarterly
1. Executive Summary
This playbook provides step-by-step procedures for responding to supply chain security incidents affecting CleanStart-managed container infrastructure. Supply chain incidents differ from typical application security incidents in scope, severity, and remediation complexity.
Types Covered: Compromised container images (malware, backdoor, trojan). Compromised dependencies (npm, pip, Go modules with vulnerabilities). Compromised build infrastructure (signing key theft, build system compromise). Upstream vendor compromise (Docker, Kubernetes, compiler compromise). Registry breach (attacker pushes malicious images).
Critical Difference: Supply chain incidents can affect multiple customers simultaneously, triggering regulatory notification obligations and requiring coordinated response across product, infrastructure, and legal teams.
graph TB Detect["Detect Incident<br/>Vulnerability scan<br/>Behavior anomaly<br/>Customer report"] Triage["Triage<br/>Classify severity<br/>Scope impact<br/>Customers affected"] Contain["Contain<br/>Quarantine images<br/>Revoke creds<br/>Block builds"] Eradicate["Eradicate<br/>Remove artifacts<br/>Patch source<br/>Rebuild clean"] Recover["Recover<br/>Verify patches<br/>Redeploy<br/>Test"] Communicate["Communicate<br/>Notify customers<br/>File reports<br/>Legal review"] Detect --> Triage Triage --> Contain Contain --> Eradicate Eradicate --> Recover Recover --> Communicate style Detect fill:#ffe0b2 style Communicate fill:#fff9c42. Incident Classification and Triage
The following diagram illustrates the supply chain incident response decision tree and escalation flow:
graph TD A["Supply Chain<br/>Incident<br/>Detected"] -->|Assess| B{Incident<br/>Severity?} B -->|P1: CRITICAL| C["P1 CRITICAL<br/>0-30 min declare<br/>4 hours containment"] B -->|P2: HIGH| D["P2 HIGH<br/>1-4 hours assess<br/>8 hours decision"] B -->|P3: MEDIUM| E["P3 MEDIUM<br/>1-2 days assess"] C -->|Criteria| C1["Malware/Backdoor<br/>OR Key Compromised<br/>OR Active Exploit<br/>OR Multiple Customers"] D -->|Criteria| D1["CVSS ≥9.0<br/>OR Known Exploit<br/>OR Suspicious<br/>Package"] E -->|Criteria| E1["Low CVSS<br/>OR Unconfirmed<br/>OR Single Customer<br/>OR Patch Available"] C1 -->|Escalate| C2["CISO<br/>VP Engineering<br/>Legal<br/>CFO/CPO"] D1 -->|Escalate| D2["VP Engineering<br/>CSO<br/>Product Manager"] E1 -->|Escalate| E2["Security Team<br/>Product Manager"] C2 -->|Contain| C3["Revoke Keys<br/>Quarantine Image<br/>Issue Bulletin<br/>Forensic Analysis"] D2 -->|Contain| D3["Prepare Patch<br/>Notify Customers<br/>Draft Communication"] E2 -->|Contain| E3["Patch Planning<br/>Customer Advisory"] C3 -->|Response| C4["Hour 4:<br/>Customer Notify<br/>Hour 24:<br/>Detailed Report"] D3 -->|Response| D4["Hour 4:<br/>Impacted Notify<br/>Hour 8:<br/>Root Cause"] E3 -->|Response| E4["Hour 48:<br/>Remediation<br/>Plan"] C4 -->|Post-Incident| F["Root Cause<br/>Analysis<br/>Report"] D4 -->|Post-Incident| F E4 -->|Post-Incident| F F -->|Review| G["Document<br/>Lessons<br/>Learned"] G -->|Improve| H["Update<br/>Incident<br/>Response<br/>Procedures"] H -->|Test| I["Quarterly Drill<br/>Tabletop<br/>Exercise"] I -->|Prepare| J["Next Incident<br/>Ready"] style A fill:#ffcccc style C fill:#ff9999 style D fill:#ffcccc style E fill:#fff9cc style C3 fill:#ff6666 style F fill:#ccffcc style J fill:#99ff992.1 Supply Chain Incident Severity Levels
P1 - CRITICAL (0-30 minutes to declare, containment decision within 4 hours)
Criteria: Malware/backdoor detected in production image (confirmed via sandbox, reverse engineering, or threat intel). Container signing key compromised (attacker can forge images). Supply chain attack with active exploitation (e.g., CVE-2024-XXXXX with public exploit + image deployed). Multiple customers affected OR C-level customer affected. Attacker has capability to exfiltrate ePHI/PII (if healthcare/finance org).
Examples: Cosign signing key leaked; attacker pushing registry.cleanstart.com/app:latest with backdoor. Log4Shell vulnerability discovered in base image; proof-of-concept RCE exploit published; actively being exploited. Kubernetes supply chain attack (e.g., breach in upstream Kubernetes repository); CleanStart images potentially compromised. npm dependency (uuid v5.x) contains malware; image includes uuid v5.4.0.
Escalation: CISO, VP Engineering, General Counsel, CFO (for customer communication costs), VP Product (for customer impact planning), Chief Product Officer (for market response)
SLA: Declare incident and begin containment assessment within 15 minutes. Initial customer notification within 4 hours.
Containment Actions: Revoke compromised signing key (if applicable). Disable or quarantine affected image (if safe to do so). Issue security bulletin with preliminary impact assessment. Begin forensic analysis (preserve evidence). Notify customers of suspected compromise.
P2 - HIGH (1-4 hours to assessment, decision within 8 hours)
Criteria: Vulnerability in production image, not yet exploited but exploitable (CVSS ≥9.0 or known active exploitation reports). Dependency with published exploit in production image. Suspicious package detected in build (malware signature flagged by security tools, but unconfirmed). Single critical customer affected; no widespread exposure. Patch exists or workaround available.
Examples: CVE-2024-XXXXX (CVSS 9.5 RCE) published Tuesday; CleanStart image built Monday contains vulnerable library. GitHub Actions workflow logged unusual behavior (excessive resource usage, external network calls); suspected compromise. Snyk flags npm dependency as having malware; investigation suggests false positive but unconfirmed. TLS certificate expired; customers report image pull failures (not security incident, but urgent).
Escalation: VP Engineering, Chief Security Officer, Product Manager
SLA: Provide assessment and containment plan within 2 hours. Communicate to impacted customers within 4 hours.
Containment Actions: Prepare patched image (if patch available). Notify affected customers of vulnerability and timeline for patch. Prepare communication (draft blog post, customer email). Conduct brief forensic analysis to rule out active exploitation.
P3 - MEDIUM (1-3 days to remediation decision)
Criteria: Vulnerability in image with CVSS 7.0-8.9. Dependency update needed (no active exploitation, but update recommended). Policy violation detected (e.g., image missing SBOM, missing signature). Potential but unconfirmed compromise (alert triggered; investigation ongoing).
Examples: High-severity vulnerability in Go standard library; patch available; no active exploitation. SBOM generation failed for 5 images; images deployed but compliance evidence incomplete. Falco alert: unusual network connection from container (investigation may reveal false positive).
Escalation: Product Manager, Security Engineer
SLA: Triage and prioritization within 24 hours. Remediation decision within 3 days.
P4 - LOW (Standard backlog)
Criteria: Vulnerability with CVSS <7.0. Non-critical development/staging image affected. Documentation or process improvement needed. Lessons learned from previous incidents.
Examples: Low-severity dependency update available; no urgency. Test image has expired certificate; not used in production. Missing audit logging in development environment.
2.2 Triage Decision Tree
When triaging a suspected supply chain incident, start by determining whether malware has been confirmed through sandbox analysis, reverse engineering, or threat intelligence. If yes, escalate to P1 (CRITICAL). If no malware, check whether the signing key is compromised or an attacker can forge images. If yes, this is also P1 (CRITICAL). If the key is secure, determine whether exploitation is active, confirmed through honeypot detection or verified customer reports. Active exploitation is P1 (CRITICAL).
If none of these critical conditions exist, check the CVSS score. If CVSS is 9.0 or higher, or if there is a public exploit available and the image is already deployed, escalate to P2 (HIGH). If neither condition is met, assess the CVSS score again. If CVSS is 7.0-8.9 or a patch is available within 7 days, assign P3 (MEDIUM). Otherwise, assign P4 (LOW).
3. Detection Triggers
3.1 How Supply Chain Incidents Are Detected
Detection Source | How It Works | Response |
|---|---|---|
CleanStart Automated Monitoring | Daily scan of base images for new CVEs; alert if CVSS ≥7.0 | Triage within 4 hours |
Third-party Threat Intelligence | Security vendor (Snyk, GitHub, CVE/NVD) reports vulnerability in image components | Triage within 8 hours |
Customer Report | Customer detects incident; reports to support | URGENT - triage within 1 hour |
Falco Runtime Alert | Shell spawned in distroless container; suspicious process; network anomaly | Automatic evidence collection; triage within 30 min |
Upstream Vendor Advisory | Docker, Kubernetes, npm registry, etc. reports compromise | Assess impact; triage within 2 hours |
Internal Code Review | Security engineer spots suspicious change in build process | Triage immediately |
3.2 Automated Detection Rules
# CleanStart automated scanningdetection_rules: - name: CVE_discovered_in_base_image trigger: NVD publishes CVE affecting component in CleanStart base image cvss_threshold: 7.0 action: Create ticket, notify security team sla: Triage within 4 hours - name: Malware_detected_in_image_layer trigger: ClamAV or other AV detects malware signature action: Immediately quarantine image, declare P1 sla: Containment within 30 minutes - name: Signature_verification_fails trigger: cosign verify fails on recently deployed image action: Alert immediately, investigate tampering sla: Investigation within 15 minutes - name: Falco_shell_in_distroless trigger: Falco detects /bin/bash spawned in container action: Kill pod, capture forensics, correlate with image sla: Evidence collection within 5 minutes4. Response Procedures by Incident Type
4.1 Type A: Malware in Image
Scenario: Malware (or suspected malware) discovered in production container image.
Timeline:
T+0:00 Malware detected (threat intel, sandbox analysis, or customer report)T+0:05 Incident declared P1; incident commander assignedT+0:15 Initial containment decision (revoke image? isolate customers?)T+0:30 Evidence collection beginsT+1:00 Customer notification (preliminary)T+4:00 Full forensic analysis availableT+24:00 RCA and remediation planT+72:00 Communication to all customersContainment Decision Tree:
When malware is detected in an image, first determine whether it is currently deployed in production. If yes, assess whether the malware is actively exploiting. If active exploitation is confirmed, kill all affected containers immediately (zero tolerance policy). If the malware is not actively exploiting, the CISO and VP Engineering must assess the risk and make a containment decision. In either case, revoke the image from the registry to prevent new pulls, issue a security advisory, and prepare a patched image if the source code is available.
If the malware is only in a staging image, quarantine it for forensic analysis and continue the investigation.
Next, determine the scope of customer impact: for 1-10 customers, perform direct outreach with phone calls. For 11-100 customers, use email notification, webinars, and a support hotline. For more than 100 customers or if public data was breached, issue a press release and CEO statement.
Finally, assess whether the malware exfiltrated data. If yes, regulatory notification is required (HIPAA 60 days, others vary by region). If it is unknown whether data was exfiltrated, assume yes and notify regulators and customers. If no data was exfiltrated, use standard notification procedures.
Containment Actions:
#!/bin/bash IMAGE="registry.cleanstart.com/app:v1.2.3"INCIDENT_ID="INC-$(date +%Y%m%d-$(date +%H%M%S))" # 1. Revoke image (make unpullable)kubectl delete secret image-secret -n kube-system # Prevent pullsdocker config set-registry-auth.revoked=true $IMAGE # 2. Find all deployments using this imagekubectl get pods -A -o jsonpath='{range .items[*]}{.spec.containers[*].image}{"\n"}{end}' | \ grep $IMAGE > affected-pods.txt # 3. Kill affected pods (graceful termination, then force)while IFS= read -r pod_ref; do POD=$(echo $pod_ref | cut -d' ' -f1) NS=$(echo $pod_ref | cut -d' ' -f2) echo "[$(date)] Killing pod $POD in namespace $NS" kubectl delete pod $POD -n $NS --grace-period=30 # Wait for graceful termination sleep 31 # Force kill if still running kubectl delete pod $POD -n $NS --grace-period=0 2>/dev/null || truedone < affected-pods.txt # 4. Archive incident evidencetar czf incident-${INCIDENT_ID}-evidence.tar.gz \ affected-pods.txt pod-metadata.* logs/* forensics/* # 5. Upload to immutable storagegsutil cp incident-${INCIDENT_ID}-evidence.tar.gz gs://incident-archive-immutable/ # 6. Create incident ticketcat > incident-${INCIDENT_ID}.md <<EOF# Supply Chain Incident: Malware in Image **Incident ID**: $INCIDENT_ID**Severity**: P1 (CRITICAL)**Declared**: $(date -u)**Image**: $IMAGE ## Action Items- [ ] Revoke image- [ ] Kill affected pods- [ ] Notify customers- [ ] Forensic analysis- [ ] Prepare patch- [ ] RCA reportEOFCustomer Notification (Template):
Subject: [CRITICAL] Security Incident: Malware in Container Image Dear [Customer Name], We are notifying you of a critical security incident that may affect your environment. **Incident Summary**:- We discovered potential malware in container image [image:tag]- This image was released on [date] as part of [product/service]- Deployment blast radius: [X] customers potentially affected **What We're Doing**:- We have revoked the malicious image to prevent further deployment- All containers running this image should be killed and replaced with patched version [new_tag]- Our security team is conducting forensic analysis to determine scope- We will provide detailed forensic findings within 24 hours **What You Should Do**:1. IMMEDIATELY: Kill all containers running image [image:tag]2. Review your deployment logs for when this image was pulled3. Assume any container that ran this image was compromised4. Rotate all secrets/keys that may have been exposed5. Review your audit logs for suspicious activity between [start_date] and [end_date]6. Contact us if you need assistance: [incident-support@company.com](mailto:incident-support@company.com) **Timeline**:- T+0h: Incident detected and contained- T+4h: Detailed forensic report will be available- T+24h: Patch released and tested- T+72h: Full RCA available **Support**:- Incident hotline: +1-555-INCIDENT- Email: [incident-support@company.com](mailto:incident-support@company.com)- Status page: [status.company.com](https://status.company.com) We take this incident very seriously and are committed to transparency and rapid remediation. Sincerely,[CISO Name]Chief Information Security OfficerCompany Name4.2 Type B: Compromised Dependency
Scenario: Malicious version of npm/pip/Go package discovered; images built with that package are affected.
Timeline:
T+0:00 Threat intel/researcher reports malicious package versionT+0:30 Determine which CleanStart images include this packageT+0:45 Assess if compromise affects production deploymentT+2:00 Decision: revoke old images, rebuild with clean dependencyT+4:00 Patch available and testedT+8:00 Customer notificationT+24:00 All customers updatedContainment Procedure:
#!/bin/bash MALICIOUS_PACKAGE="uuid"MALICIOUS_VERSION="5.4.0"INCIDENT_ID="INC-2026-DEP-001" # 1. Find all images that include the malicious package# (Query SBOMs in registry)for image in $(gcloud container images list --repository-url registry.cleanstart.com); do cosign download sbom $image > /tmp/sbom.json if jq ".components[] | select(.name==\"$MALICIOUS_PACKAGE\" and .version==\"$MALICIOUS_VERSION\")" /tmp/sbom.json > /dev/null; then echo "AFFECTED: $image" echo "$image" >> affected-images.txt fidone # 2. For each affected image, rebuild with clean dependency versionwhile IFS= read -r image; do echo "[$(date)] Rebuilding: $image" # Trigger rebuild (via CI/CD pipeline with fixed dependency) curl -X POST https://ci.cleanstart.com/rebuild \ -H "Authorization: Bearer $CI_TOKEN" \ -d "{\"image\": \"$image\", \"dependency_fix\": \"$MALICIOUS_PACKAGE@>=5.4.1\"}" # Wait for build to complete sleep 300 # Verify SBOM no longer contains malicious version cosign download sbom $image | jq ".components[] | select(.name==\"$MALICIOUS_PACKAGE\")"done < affected-images.txt # 3. Document remediationcat > remediation-${INCIDENT_ID}.md <<EOF# Dependency Remediation Report **Incident**: Malicious package $MALICIOUS_PACKAGE v$MALICIOUS_VERSION**Date**: $(date) ## Affected Images$(cat affected-images.txt) ## RemediationAll affected images have been rebuilt with $MALICIOUS_PACKAGE@>=5.4.1 ## SBOM Verification$(for img in $(cat affected-images.txt); do echo "Image: $img" cosign download sbom $img | jq '.metadata.timestamp'done) ## Customer Action RequiredRedeploy to new image versions.EOF4.3 Type C: Build System Compromise
Scenario: Attacker compromises the build system (CI/CD pipeline, signing key, or build server).
Immediate Actions (within 5 minutes):
#!/bin/bash # 1. Disable all image builds immediately (prevent building more malware)kubectl set env deployment/ci-builder BUILD_ENABLED=false -n ci-cd # 2. Revoke signing key (if compromised)gcloud kms versions disable 1 --key=cosign-key --keyring=security # 3. Preserve build logs for forensicsgsutil cp gs://ci-logs/build-2026-03-22.log gs://incident-evidence/build-logs/ # 4. List all images signed in past 24 hours (may be malicious)kubectl logs -n ci-cd deployment/ci-builder | grep "cosign sign" > suspect-signatures.txt # 5. Alert: Any image signed in past 24 hours is suspectecho "ALERT: All images built in past 24 hours are under suspicion"echo "Revoke immediately or quarantine for analysis"Investigation (4-8 hours):
# 1. Audit CI/CD logs for unusual activitygcloud logging read "resource.type=cloud_build" --limit=10000 > ci-audit.log # 2. Check for:# - Builds triggered by unknown user# - Builds with unusual dependencies# - Builds with exfiltration attempts (curl to external IP) grep -E "(suspicious_user|unusual_dep|exfil)" ci-audit.log > malicious-builds.txt # 3. For each malicious build, identify the images created# and revoke themRecovery:
# 1. Rotate signing keygcloud kms keys create cosign-key-v2 --location global # 2. Audit and harden build pipeline# - Enable MFA for all build approvals# - Restrict who can trigger builds# - Enable build attestation verification before deployment# - Add code review requirement for all build changes # 3. Rebuild all images from clean sourcefor image in $(gcloud container images list --repository-url registry.cleanstart.com); do gcloud builds submit --config=cloudbuild.yaml \ --rebuild-image=$image \ --signing-key=cosign-key-v2done5. Communication Plan
5.1 Internal Communication
Channels: Slack #incident: Real-time updates (every 30 minutes or major milestones). Email to leadership: Major milestones (declared, assessment complete, customer notification sent). All-hands meeting: Post-incident (>24 hours after resolution).
Message Template (#incident channel):
🚨 **INCIDENT DECLARED: Supply Chain - Malware in Image** **ID**: INC-2026-0322-001**Severity**: P1 (CRITICAL)**Declared**: 2026-03-22 14:35 UTC**Incident Commander**: [Name], Security Team **Status**: CONTAINING- Image revoked: registry.cleanstart.com/auth:v2.4.1- Affected containers: ~45 across 8 customers- Current action: Killing compromised pods **Next Update**: 15:05 UTC (forensic findings) **Slack Thread**: [link to thread]**Incident Doc**: [link to shared doc]5.2 Customer Communication
Tiers:
- Direct Outreach (<10 affected customers) Phone call from CISO. Personalized email with guidance. Dedicated support resource assigned.
- Webinar (10-100 customers) Scheduled for T+2 hours. CISO presents findings. Q&A with security team. Recording available.
- Public Notification (>100 customers or press coverage) Press release (drafted by Communications + Legal). Blog post (by CISO). Status page banner. Email to all customers.
6. Post-Incident Procedures
6.1 Forensic Investigation (24-72 hours)
Objectives: Determine how the compromise occurred. Determine scope (how many images affected). Determine impact (did attacker exfiltrate data?). Collect evidence for legal/regulatory proceedings.
Procedures:
# 1. Extract and analyze malicious container layersdocker export compromised_container | tar -xzf - -C /analysis/ # 2. Reverse engineer malware (if present)strings /analysis/bin/suspicious-binary > strings-output.txtobjdump -d /analysis/bin/suspicious-binary > disassembly.txtstrace -f -e trace=network /analysis/bin/suspicious-binary > execution-trace.txt # 3. Network forensics: What did malware communicate with?strings /analysis/etc/ld.so.cache | grep -E "^(http|ftp)://" # 4. Determine infection vector# - Was it in SBOM? (indicates build-time compromise)# - Was it injected at runtime? (indicates runtime vulnerability)# - Was it a signed legitimate image? (indicates supply chain attack) cosign verify registry.cleanstart.com/malware-image:tagcosign download sbom registry.cleanstart.com/malware-image:tag | jq '.components[] | .name' | grep malicious # 5. Timeline# - When was malicious code introduced?# - When was image first deployed?# - When was it discovered? git log --all --grep="dependency" -- Dockerfile | head -206.2 Root Cause Analysis (RCA)
RCA Report Structure:
# Root Cause Analysis: Supply Chain Incident INC-2026-0322-001 ## Executive Summary- **Date**: 2026-03-22- **Incident**: Malicious npm package in production image- **Root Cause**: Insufficient dependency pinning in build process ## Timeline[Detailed timeline from discovery to resolution] ## Technical Analysis- **Attack Vector**: Typosquatting in package.json (attacker published malicious "uuiid" package)- **Detection Gap**: No automated scanning of package.json for typos/suspicious names- **Impact**: 3 customers, 12 containers, 0 confirmed data exfiltration ## Why It Happened1. Build process didn't pin exact versions (used `@latest`)2. No review of new dependencies pulled at build time3. npm registry not scanned for package name spoofing ## Lessons Learned1. Always pin exact versions (uuid@5.3.1 not @latest)2. Implement advisory board review for any new dependencies3. Enable npm security audits in CI/CD4. Scan for package name spoofing/typosquatting ## Preventive Actions (Why This Won't Happen Again)1. **Immediate**: All images rebuilt with pinned dependency versions2. **Week 1**: Implement SBOMdiff alerting (notify if SBOM changes unexpectedly)3. **Week 2**: Add npm advisor board to build approval process4. **Week 4**: Implement DevSecOps workshop on supply chain security ## Follow-Up Actions- [ ] Update build dependency pinning policy (DUE: 2026-03-25)- [ ] Implement SBOM change alerting (DUE: 2026-03-29)- [ ] Conduct post-incident review with customers (DUE: 2026-04-05)- [ ] Update incident response playbook (DUE: 2026-04-10)7. Playbook Testing and Maintenance
7.1 Quarterly Incident Drill
Scenario-Based Drills (rotate quarterly):
Q1: Malware detected in production image Participants: Security, Engineering, Product, Legal. Duration: 2 hours. Objectives: Test communication flow, decision-making, customer notification process.
Q2: Compromised build system Participants: Infrastructure, Security, Engineering. Duration: 2 hours. Objectives: Test containment, evidence preservation, remediation speed.
Q3: Supply chain vendor compromise Participants: Security, Legal, Communications. Duration: 1.5 hours. Objectives: Test escalation, regulatory notification, public communication.
Q4: Dependency vulnerability discovered post-deployment Participants: All teams. Duration: 2 hours. Objectives: Test vulnerability assessment, impact analysis, patch deployment.
Debrief: What went well. What was slow/unclear. Update playbook and timelines. Train new team members.
7.2 Playbook Updates
Review Frequency: Annually (or after any real incident)
Update Triggers: New supply chain attack type discovered (industry-wide). Tool/platform changes (Kubernetes version, registry software). Regulatory requirement change. Lessons from incident drill.
8. Legal and Regulatory Considerations
8.1 Notification Requirements
Regulation | Timeline | Notification To |
|---|---|---|
HIPAA | 60 calendar days | HHS, affected individuals, media (if >500) |
GDPR | Without undue delay (typically <30 days) | Data Protection Authority, individuals |
CCPA | Within 30 days | Individuals, CA Attorney General |
State Laws | Varies (30-45 days typical) | State AG, individuals |
SEC | Material breaches: 4 business days | SEC, public filing, investors |
Decision: Does this incident require notification?
Did the incident result in unauthorized access to[ePHI (HIPAA), PII (GDPR/CCPA), Payment Card (PCI)]? YES → Notify regulatory authoritiesNO → Document decision and file for audit8.2 Legal Hold
Evidence Preservation: All evidence related to incident must be preserved. Evidence accessible for potential lawsuit or regulatory investigation. Do NOT delete or modify evidence after incident. Legal department approval required for evidence destruction (after retention period).
9. Contact Information
Role | Name | Title | Phone | |
|---|---|---|---|---|
Incident Commander | [Name] | VP Security | [phone] | [email] |
CISO | [Name] | CISO | [phone] | [email] |
Chief Legal Officer | [Name] | CLO | [phone] | [email] |
Communications Lead | [Name] | VP Comms | [phone] | [email] |
Customer Support Lead | [Name] | Dir. Support | [phone] | [email] |
Document Control: Maintained by Chief Information Security Officer. Last reviewed: 2026-03-22. Next review: 2027-03-22.