Files
policies/Security/incident_response_guidance.md

2.1 KiB

Incident Response Guidance

Document owner: [Owner/Role]
Approved by: [Steering Committee / CISO]
Effective date: [YYYY-MM-DD]
Review cadence: [Annually]


1. Purpose & Scope

Implementation guidance for the Incident Response Policy. Applies to the IR team and all staff as first reporters.


2. Severity Triage — Quick Reference

Question If Yes
Kill-chain system involved (IdP, PKI, backup, break-glass)? SEV1
TLP:AMBER+STRICT/RED data confirmed exposed? SEV1/SEV2
Contained to one endpoint, no lateral movement seen? SEV3
Just an anomaly, nothing confirmed yet? SEV4, investigate before downgrading further

3. Post-Mortem Template (Blameless)

  1. Timeline — what happened, when, who/what detected it.
  2. Root cause — technical, not "human error" as a final answer; ask what let the human error matter.
  3. What worked — don't only harvest failures.
  4. Structural change — the mandatory output per policy §3.5. Must be a policy, architecture, or control change, not just "we'll be more careful."
  5. Owner and due date for the structural change.

4. Tabletop Exercise — Calibrated Dose Checklist

Scope defined and bounded before starting (which systems, which team).
Abort condition agreed in advance ("if X happens, we stop and debrief").
Non-production/simulated scenario before ever touching production for the first run of a new scenario type.
Findings captured and fed into the post-mortem template above, even for a successful exercise.

5. Notification Timeline Cheat Sheet

  • T+1h: internal report and triage.
  • T+72h: GDPR breach notification assessment complete (notify if required).
  • Ongoing: customer/partner notification per contract, coordinated through Legal — don't let engineering notify unilaterally.

6. References