Runbooks

Incident Communication Runbooks

Step-by-step procedures for detecting, containing, and recovering from the most common security incidents — with clear communication timelines and stakeholder notification requirements.

1 Data Breach Response

Severity: Critical — P1 Target Response: < 1 hour

Step 1 Detection

  • Monitor for unauthorized data access alerts
  • Identify anomalous data exports or bulk downloads
  • Investigate customer reports of suspicious activity

Step 2 Containment

  • Isolate affected systems from the network
  • Revoke compromised credentials immediately
  • Enable enhanced logging on all affected endpoints

Step 3 Assessment

  • Determine scope of data exposed or exfiltrated
  • Identify affected data types (PII, financial, health)
  • Assess regulatory notification requirements (GDPR, CCPA, HIPAA)

Step 4 Notification

  • Notify affected individuals within 72 hours (GDPR requirement)
  • Report to regulators — CNIL, ICO, state Attorneys General as applicable
  • Notify internal stakeholders: CISO, legal counsel, executive team

Step 5 Eradication

  • Patch the exploited vulnerability
  • Rotate all credentials system-wide
  • Implement compensating controls to prevent recurrence

Step 6 Recovery

  • Restore from verified clean backups
  • Conduct enhanced monitoring for 30 days post-recovery

Step 7 Post-Incident

  • Complete root cause analysis within 5 business days
  • Publish incident report to affected parties
  • Update security policies and procedures
Related: Incident Response Plan · Data Processing Agreement · Privacy Policy

2 Unauthorized Access / Account Compromise

Severity: High — P1 Target Response: < 1 hour (admin), < 4 hours (standard)

Step 1 Detection

  • Failed login spike detected by SIEM
  • Impossible travel alerts (logins from geographically distant locations)
  • MFA bypass attempts or unusual MFA enrollment
  • Privilege escalation or unauthorized role changes

Step 2 Containment

  • Force logout all active sessions for compromised accounts
  • Disable compromised accounts immediately
  • Block source IPs at firewall / WAF level

Step 3 Assessment

  • Review audit logs for lateral movement indicators
  • Check for data exfiltration via API, export, or download logs
  • Identify the attack vector (phishing, credential stuffing, brute force)

Step 4 Notification

  • Notify affected users with password-reset instructions
  • Alert security team and incident commander
  • Notify management within 4 hours for admin account compromises

Step 5 Eradication

  • Reset all credentials for affected accounts
  • Review and revoke OAuth tokens and API keys
  • Patch the exploited vulnerability or misconfiguration

Step 6 Recovery

  • Re-enable accounts with forced password reset
  • Require MFA enrollment before account reactivation

Step 7 Post-Incident

  • Update access controls and authentication policies
  • Improve detection rules based on attack patterns
  • Conduct security awareness training for affected teams
Related: Incident Response Plan · Information Security Policy

3 DDoS / Availability Incident

Severity: High — P1 Target Response: < 15 minutes

Step 1 Detection

  • Traffic spike alerts from monitoring / CDN dashboards
  • Service degradation or increased error rates
  • CDN / WAF automated notifications

Step 2 Containment

  • Enable rate limiting on all public endpoints
  • Activate DDoS mitigation service (Cloudflare / AWS Shield)
  • Auto-scale infrastructure to absorb excess traffic

Step 3 Assessment

  • Identify attack vector: volumetric, protocol, or application layer
  • Estimate customer impact and affected services

Step 4 Notification

  • Update public status page with incident details
  • Notify affected customers via email / in-app banner
  • Engage ISP and CDN provider for upstream filtering

Step 5 Mitigation

  • Implement traffic filtering rules targeting attack signatures
  • Apply geographic blocking if attack originates from specific regions

Step 6 Recovery

  • Gradually restore normal operations and remove emergency rules
  • Monitor closely for renewed attack waves

Step 7 Post-Incident

  • Update DDoS playbook with lessons learned
  • Review infrastructure resilience and capacity planning
  • Add new monitoring signatures from attack patterns
Related: Incident Response Plan · Service Level Agreement

4 Credential Compromise / Secrets Exposure

Severity: Critical — P1 Target Response: < 30 minutes

Step 1 Detection

  • Secret scanning alerts (GitHub, GitGuardian, TruffleHog)
  • Credential leak monitoring services flag exposure
  • Abnormal API key usage patterns

Step 2 Containment

  • Immediately rotate all exposed credentials
  • Revoke compromised API keys and tokens
  • Disable affected integrations and service accounts

Step 3 Assessment

  • Determine exposure scope: public repo, logs, error messages, third-party
  • Check for unauthorized use of exposed credentials

Step 4 Notification

  • Notify affected service owners immediately
  • Rotate all related secrets within 1 hour of detection

Step 5 Eradication

  • Remove secrets from source code history and logs
  • Implement secret scanning in CI/CD pipelines

Step 6 Recovery

  • Issue new credentials and update all dependent services
  • Verify all integrations restored and functional
  • Audit access logs for the exposure window

Step 7 Post-Incident

  • Improve secret management practices (vault, environment variables)
  • Add pre-commit hooks to prevent future secret commits
Related: Incident Response Plan · Information Security Policy

5 Third-Party Vendor Security Incident

Severity: High — P2 Target Response: < 4 hours

Step 1 Detection

  • Vendor security advisory or public disclosure
  • Supply chain monitoring alert (dependency, SaaS provider)
  • Abnormal vendor system behavior or unexpected API responses

Step 2 Containment

  • Disable vendor integrations and webhook connections
  • Block vendor IP ranges at network perimeter
  • Isolate systems dependent on compromised vendor

Step 3 Assessment

  • Determine if vendor breach impacts our data or systems
  • Review all data shared with or accessible by vendor

Step 4 Notification

  • Notify internal stakeholders and legal team
  • Notify affected customers if their data was exposed through vendor

Step 5 Mitigation

  • Implement alternative workflows for affected vendor services
  • Apply vendor-provided patches or mitigations when available

Step 6 Recovery

  • Re-enable vendor access with enhanced monitoring in place
  • Update vendor risk assessment score and classification

Step 7 Post-Incident

  • Review vendor security requirements and SLAs
  • Update subprocessor agreements and data processing addenda
Related: Incident Response Plan · Data Processing Agreement · Terms of Service

Related Policies

Incident Response Plan Data Processing Agreement Service Level Agreement Terms of Service Information Security Policy Privacy Policy