Incident response
Response quality is decided before the incident: log coverage, access to tooling, clear authority, and playbooks written for the platform you actually run.
Updated
1Prepare
- Playbooks
- Access
- Authority
- Exercises
2Detect and analyse
- Alerting
- Triage
- Scope determination
3Contain and eradicate
- Token revocation
- Isolation
- Credential reset
- Persistence removal
4Recover and learn
- Service restoration
- Regulatory reporting
- Control change
What readiness looks like
- Every high-priority scenario has a playbook naming the exact queries, consoles and containment actions.
- Containment authority is pre-delegated — the responder can disable an account without waking an executive.
- Log retention exceeds your realistic detection lag, not your budget preference.
- Reporting clocks are embedded in the escalation path: DORA's 4-hour initial notification and NIS2's 24-hour early warning both run from the moment an incident is classified, with a 72-hour follow-up and a one-month final report under either regime.
- Post-incident reviews close with a control change, not a lessons-learned slide — the continuous-improvement emphasis NIST SP 800-61r3 now makes explicit.
Frequently asked questions
Cloud IR differences?
Evidence is API-derived and ephemeral, identity is the primary pivot, and containment often means revoking tokens rather than pulling cables.
Has the NIST guidance changed?
NIST retired the 2012 lifecycle model in SP 800-61 Revision 3 (April 2025) and now organises incident response around the six CSF 2.0 functions — Govern, Identify, Protect, Detect, Respond, Recover — splitting preparation and lessons-learned from the live response activities. Playbooks written against the old four-phase model still work operationally but are worth re-mapping.
Related
Incident readiness
Incident response plan review, cloud and identity playbooks, tabletop exercises and detection coverage assessment.
Incident response checklist
Printable IR readiness checklist aligned to NIST SP 800-61r3: authority, playbooks, evidence access, communications and regulatory clocks.
Microsoft Sentinel
Using Microsoft Sentinel for detection engineering: data source selection, analytics rules, ATT&CK coverage, the data lake tier and automation.
Penetration Testing
Adversarial testing of approved applications, APIs and exposed services, with evidence, risk context and a remediation retest.
IR playbooks that work
A playbook structure built for 03:00 use: decision points, containment options with trade-offs, evidence steps and the exact notification clocks under DORA, NIS2 and GDPR.
Tabletop exercises
How to design and facilitate a security tabletop that surfaces decision gaps instead of confirming that everyone has read the policy, and how it fits DORA/NIS2 testing obligations.