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.
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.
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.
# 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
ID: gov-fisma-fedramp.documentation-readiness.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:
# 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