Incident response runbook documented with severity levels, communication plan, on-call rotation

When production goes down at 2am, the difference between a 15-minute resolution and a 3-hour outage is whether your team has a documented incident runbook. NIST IR-8 requires incident response plans; SOC 2 CC9.1 requires risk mitigation procedures; NIST CSF RS.RP-1 requires response plan execution. Without defined severity levels, teams cannot triage — every problem looks like a P1. Without escalation contacts and communication channels, the on-call engineer is making high-stakes decisions alone with no authority to act.

Create INCIDENT_RESPONSE.md at the repo root. At minimum it must define severity levels, escalation contacts, and the communication plan.

# Incident Response Runbook

## Severity Levels
| Level | Response SLA | Example |
|-------|--------------|---------|
| P1 — Critical | 15 min | Production down, data loss |
| P2 — High | 1 hour | Core feature unavailable |
| P3 — Medium | 4 hours | Minor feature broken, workaround exists |

## Escalation
- On-call rotation: [link to PagerDuty/schedule]
- Slack: #incidents
- P1 only: page on-call + notify engineering lead

## Communication
1. Declare incident in #incidents: "P2 incident — login flow returning 500"
2. Update status page at status.your-app.com within 10 minutes
3. Post resolution summary within 30 minutes of recovery

Link the runbook from your DEPLOYMENT.md and README so on-call engineers can find it under pressure.