Incident response: Verification and response

Defines evidence-driven incident verification, severity, containment, communication, recovery, and post-incident learning with protected timelines and explicit decision ownership.

Package status: reference context ready for human review. The contract and test scenarios are complete, but no claim is made that an adopting implementation has passed them.

Decision

Use a single incident record and commander for coordination while work proceeds in parallel. Preserve original evidence, separate confirmed facts from hypotheses, choose reversible containment first, and define recovery through observable service and security criteria.

Scope

• Alert intake, verification, severity, roles, timeline, evidence, containment, eradication, recovery, communications, regulatory escalation, and review.
• Cybersecurity incidents affecting service, data, identity, or supply chain.
• Exercises and measurable readiness.

Outside this block

• A universal notification deadline or legal determination.
• Replacing specialized forensic, legal, safety, or law-enforcement expertise.

Contract

• The incident record has ID, commander, severity, declared time, affected scope, status, and next update time.
• Timeline entries distinguish observed fact, hypothesis, decision, and action with source and author.
• Evidence collection preserves original data, access controls, time source, digest where appropriate, and chain-of-custody needs.
• Containment decisions record expected benefit, blast radius, reversibility, owner, and validation signal.
• External and user communications state confirmed impact and actions without unsupported attribution.
• Recovery requires technical health, security control, data integrity, monitoring, and owner sign-off criteria.

Implementation guidance

• Pre-authorize emergency access, credential rotation, traffic isolation, and evidence storage paths.
• Maintain contact routes outside the potentially affected identity system.
• Create service-specific playbooks that reference this common lifecycle.
• Exercise detection-to-decision and recovery validation, not just meeting attendance.

Failure handling and safeguards

• If scope is uncertain, describe it as unknown and bound the investigation; do not report zero impact.
• If containment destroys evidence, document the tradeoff and preserve alternative sources first when feasible.
• If primary communications are compromised, switch to the tested out-of-band channel.

Verification and operations

• Measure time to acknowledge, verify, contain, recover, communicate, and close actions; evidence completeness; repeat cause; and exercise findings.
• Track corrective actions to owner and due date outside the ephemeral incident chat.
• Review access to incident records and retention after closure.

The executable-looking examples in this package are fixtures and acceptance contracts. Run python tools/validate.py from the collection root to check package structure and metadata; then implement and execute the scenarios in the target repository.

Adoption assumptions

• Names and numeric values in example.yaml are an adoption profile, not universal defaults.
• The adopting team must map actors, data classes, error vocabulary, and ownership to its system.

References

• nist-ir