Top 10 Incident Response Mistakes

Most incidents that turn into disasters do so because of avoidable mistakes made during the response, not because the original intrusion was unstoppable. This list covers the ten response errors that recur in public post-incident reports: leaving machine credentials live, scoping too narrowly, destroying evidence, missing legal deadlines and more. Each entry explains why it matters, points to a real incident on the NHI Mgmt Group breach database where one fits, and gives a concrete fix. It is written for incident responders, SOC leads and security managers who own an incident response plan. For building the capability from scratch, see the Incident Response Guide; this page focuses on what goes wrong.

The Top 10 at a glance

The list is ordered roughly by how often each mistake turns a contained incident into a second one. The mapping column uses NIST CSF 2.0 subcategories, which NIST SP 800-61 Rev. 3 (April 2025) now uses as its incident response model in place of the older four-phase lifecycle.

1. Not rotating non-human credentials after a breach

The mistake: responders reset human passwords and revoke sessions but leave service accounts, API keys, OAuth tokens and CI/CD secrets in place, often because nobody knows which ones were exposed or the owners say they are unused.

Evidence: after the Okta support system breach, Cloudflare rotated thousands of credentials but, by its own account, failed to rotate one service token and three service accounts it believed were unused. An attacker used them weeks later to reach Jira, Confluence and Bitbucket, viewing 120 code repositories. See the Cloudflare Thanksgiving breach. The Internet Archive breach and the Trivy supply chain attack repeat the pattern: unrotated or incompletely rotated secrets led to a second compromise.

The fix: treat every credential the attacker could have read as compromised, including "unused" ones (disable those rather than trust the label). Keep an inventory that maps each system to the machine identities it holds so the rotation list exists before the incident. Rotate, then verify the old value fails. See the Secrets Rotation Runbook Template and the Identity Incident Response Playbook.

2. Scoping too narrowly and too early

The mistake: the team declares the blast radius on day two ("only the CRM was affected") and stops looking.

Evidence: in the Salesloft Drift breach, Google Threat Intelligence first described theft through the Salesforce integration, then updated its advisory on 28 August 2025 to confirm that Drift Email OAuth tokens for Google Workspace had also been compromised, and advised treating every token connected to the platform as compromised.

The fix: scope by identity, not by system. List every credential and token the compromised identity or platform could use, follow each to its downstream systems, and communicate scope as a working hypothesis with a confidence level until analysis (RS.AN-03) supports a firmer statement.

3. Losing or overwriting logs and evidence

The mistake: reimaging hosts first, letting SaaS audit logs age out of a short default retention window, or running ad hoc commands without recording them.

Why it matters: SP 800-61 Rev. 3 notes that collected incident data is still evidence even where formal chain of custody is not used, and asks for the integrity and provenance of investigation records to be preserved (RS.AN-06, RS.AN-07). Without logs you cannot prove what data left, which drives notification decisions.

The fix: centralise logs outside the systems being investigated with retention set before an incident (AU-9, AU-11); export SaaS and cloud audit logs on day one; capture volatile data before reimaging; keep a timestamped action log. The NCSC recommends recording decisions, actions and which data was captured or missing. See the Digital Forensics (DFIR) Guide and the Cloud Logging and Audit Trail Guide.

4. Missing regulatory reporting deadlines

The mistake: legal and compliance hear about the incident days in, or nobody knows which clock applies.

Why it matters: several clocks start at awareness or determination, not at the end of the investigation:

The fix: put a regulatory triage step in the first hours of the plan, with named legal contacts and pre-drafted notices, and record when awareness occurred. Contractual notification duties to customers sit alongside these. See the Breach Notification Laws by Country Guide and the SEC Cybersecurity Disclosure Rules Guide.

5. Containing before understanding

The mistake: blocking one IP address or disabling one account the moment it is spotted, while the attacker holds other access.

Why it matters: the NCSC advises containing only once you are confident it is safe, and notes that in targeted attacks it may be better to monitor and analyse first because the attacker may react. Piecemeal containment tells the adversary to use their backup persistence.

The fix: decide early between immediate containment (destructive malware, active exfiltration) and coordinated containment (stealthy, persistent actor). Pre-authorise the actions the technical team can take without waiting for approval, as the NCSC suggests, and execute coordinated containment in one window covering accounts, tokens and hosts.

6. A plan nobody has exercised

The mistake: a plan exists as a document, but contact lists are stale, decision rights are unclear and nobody has rehearsed a ransomware or SaaS compromise.

The fix: run tabletop exercises at least annually with executives, legal and key suppliers, and feed findings back into the plan (ID.IM-02, ID.IM-04, IR-3). Test the hard calls: paying a ransom, shutting down production, notifying a regulator on partial facts. See the Tabletop Exercise Guide and the Incident Response Plan Template.

7. Coordinating over compromised channels

The mistake: running the response in the corporate email, chat and ticketing systems the attacker may already control, or that are down.

The fix: provision an out-of-band channel in advance, tied to identities outside the compromised directory. The NCSC recommends planning secure or alternative channels and documenting at least two contact methods and two or more people for each contact. See the Incident Communication Plan Template.

8. Leaving suppliers out of the response

The mistake: discovering mid-incident that the MSP, SaaS provider or forensic retainer has no agreed role, no log access and no notification duty.

Why it matters: SP 800-61 Rev. 3 notes that providers may hold privileged access and that contracts should define responsibilities, information flows and authority to act. In the Okta support system breach, 134 customers depended on their provider's investigation and notification before they could scope their own exposure.

The fix: include critical suppliers in planning and exercises (GV.SC-08), agree log access and notification times in contracts (SR-8), and keep provider security contacts in the plan. See the Third-Party Risk Management Guide.

9. Recovering before eradication is verified

The mistake: restoring from backups or bringing systems back under business pressure while persistence (new accounts, scheduled tasks, OAuth grants, web shells) remains.

The fix: define exit criteria for eradication: persistence hunted, all exposed credentials rotated, backups scanned before restore. The NCSC advises confirming remediation has worked, which may need a period of monitoring, before moving to recovery. See the Ransomware Response and Recovery Guide.

10. No lessons learned, or lessons never actioned

The mistake: the review is skipped, blames individuals or produces actions with no owner.

The fix: hold a blameless review covering both the incident and the response, as the NCSC recommends, asking what data was missing and who lacked authority to act. SP 800-61 Rev. 3 notes that lessons should often be shared as soon as they are identified rather than after recovery. Track actions to closure like any other risk (ID.IM-03).

Mapping to NIST CSF 2.0 and SP 800-53

Where to start

If you can fix only three things this quarter, build the machine identity inventory that makes complete rotation possible (mistake 1), set log retention and off-system storage before you need it (mistake 3), and add a regulatory triage step with named owners to the first hours of the plan (mistake 4). Then rehearse a SaaS token compromise in a tabletop. Measure progress with time to rotate all exposed credentials, the share of critical systems with logs retained for at least the period your investigations need, and the number of exercise actions closed. Assess where you stand with the Incident Response Maturity Model.

Related NHI Mgmt Group resources: Incident Response Guide · Identity Incident Response Playbook · Cloud Incident Response Guide · Top 10 Secrets Management Mistakes