# Incident response plan drafted

- **Pattern:** `ab-001585` (`gov-fisma-fedramp.documentation-readiness.incident-response-plan`)
- **Severity:** low
- **Lifecycle:** active
- **Last modified:** 2026-04-18
- **Canonical URL:** https://auditbuffet.com/patterns/ab-001585
- **License:** CC-BY-4.0 — attribute to AuditBuffet Pattern Catalog (https://auditbuffet.com/patterns/ab-001585)

## Why it matters

Without a written incident response plan, a security breach becomes an improvised crisis: response teams disagree on escalation paths, evidence is destroyed before it is preserved, and affected users receive notifications too late to take protective action. NIST 800-53 rev5 IR-8 (Incident Response Plan) requires a documented, tested response plan; IR-4 (Incident Handling) requires detection, analysis, containment, and recovery procedures. CMMC 2.0 IR.L2-3.6.1 and FedRAMP rev5 IR-8 both make this a mandatory control. Most state breach notification laws impose 72-hour or shorter notification windows — a team with no rehearsed plan routinely misses them.

## Severity rationale

Low as a code-level control because the absence of documentation does not cause a breach, but it guarantees that response to any breach will be slower and more damaging than it needs to be.

## Remediation

Create `docs/incident-response-plan.md` covering all six phases. Assign named roles — not just job titles — so every person knows their specific responsibilities during an incident.

```markdown
# Incident Response Plan

## Reporting
- Internal: security@yourcompany.com (monitored 24/7)
- External: `/.well-known/security.txt` with Contact + Policy

## Detection
- Automated: error-rate spike alerts, failed-login threshold (>10/min), CloudWatch alarms
- Manual: user report → #security Slack channel → on-call engineer

## Investigation
1. Assign incident commander (on-call lead)
2. Preserve logs — take snapshots before any remediation
3. Determine scope: what data, which users, what timeframe

## Containment
1. Revoke compromised credentials via admin panel
2. Block attacker IP at WAF / hosting firewall
3. Roll back or disable affected feature flag

## Recovery
1. Restore from last clean backup
2. Verify integrity with checksum comparison
3. Re-enable service and monitor for 24h

## Communication
- Notify affected users within 72 hours (GDPR / CCPA requirement)
- Post status page update within 1 hour of confirmed incident
```

## Detection

- **ID:** `incident-response-plan`
- **Severity:** `low`
- **What to look for:** Look for incident response documentation, security runbooks, or incident.txt files. Count the number of required sections present: detection, reporting/escalation, investigation, containment, recovery, and communication. Check for procedures describing how security incidents are detected, reported, investigated, and resolved.
- **Pass criteria:** An incident response plan is documented with at least 5 sections: detection mechanisms, escalation procedures, investigation steps, containment measures, recovery procedures, and communication plan. Contact information for security reporting is clear.
- **Fail criteria:** No incident response plan found, or plan covers fewer than 5 of the required sections.
- **Skip (N/A) when:** Never — incident response is critical for government systems.
- **Detail on fail:** `"No incident response plan found. No security.txt or incident reporting procedures documented."`
- **Remediation:** Create an incident response plan:

  ```markdown
  # Incident Response Plan

  ## Reporting
  - Security issues: security@company.com or use security.txt
  - Bugs: GitHub Issues (for public issues only)
  - Do not post security issues publicly

  ## Detection
  - Automated: intrusion detection, log anomalies, security scanning
  - Manual: user reports, audit log review

  ## Investigation
  1. Isolate affected systems
  2. Preserve evidence (logs, snapshots)
  3. Determine scope and impact
  4. Document timeline

  ## Containment
  1. Block attacker access
  2. Revoke compromised credentials
  3. Patch vulnerabilities
  4. Apply mitigations

  ## Recovery
  1. Restore from clean backups
  2. Verify system integrity
  3. Monitor for recurrence
  4. Rebuild if necessary

  ## Communication
  - Notify affected users within 72 hours
  - Provide details: what happened, what data was affected, what they should do
  - Regular status updates
  ```

## External references

- nist IR-8
- nist IR-4
- fedramp IR-8
- cmmc IR.L2-3.6.1

Taxons: operational-readiness, regulatory-conformance

HTML version: https://auditbuffet.com/patterns/ab-001585