SECURITY STANDARD · INCIDENT RESPONSE
Contain verified risk without losing the evidence needed to explain it.
The response lifecycle assigns authority, severity, evidence, containment, recovery validation, communication, and corrective actions.
1. Activation and roles
A security incident is activated when available evidence indicates unauthorized access, material control failure, credential compromise, destructive action, or a credible vulnerability with active exposure. The incident commander owns severity and decisions; an evidence lead preserves records; technical owners contain and recover; a communications owner maintains approved updates.
2. Severity model
| Level | Example condition | Coordination objective |
|---|---|---|
| SEV-1 | Confirmed broad unauthorized control or destructive impact | Immediate command, containment, and executive notice |
| SEV-2 | Confirmed scoped compromise or high-risk control failure | Immediate owner assignment and frequent updates |
| SEV-3 | Contained exposure with limited impact | Business-day coordination and tracked remediation |
| SEV-4 | Unconfirmed signal or hardening observation | Standard triage and evidence collection |
3. Evidence collection
Record UTC times, request IDs, actor and role, session references by digest where available, resource IDs, action and outcome, relevant configuration revision, deployment version, and the source of each observation. Preserve original records; analyze copies. Do not place live cookies, passwords, factors, private keys, or full secret values in the incident timeline.
Normal deletion is paused only for records within the defined incident scope. The hold has an owner, reason, start time, review date, and release decision.
4. Containment and eradication
- Revoke affected sessions or access while preserving the minimum required evidence.
- Block the vulnerable route, transition, or integration when the impact is verified.
- Identify whether the root condition is credential, authorization, input, dependency, deployment, or operating-process failure.
- Remove the root condition through a reviewed change.
- Rotate secrets only when exposure is credible; record scope and completion without copying the new value.
5. Recovery validation
Recovery confirms origin health, API readiness, expected authentication, role denial, one authorized control path, audit emission, service bindings, and the absence of the initiating failure. When gateway infrastructure shares the host, validate that gateway processes, tunnel interfaces, public ports, and firewall policy remain unchanged.
6. Communication and retrospective
Public updates are based on confirmed service impact or required user action. Internal investigation detail remains restricted while disclosure could expand risk. The retrospective documents impact, timeline, contributing conditions, successful and failed controls, recovery evidence, corrective owners, due dates, and the decision to revise a runbook or control.