Incident response plan drafted

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.

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: 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