When is it safe to say the incident is over?

An incident is over when four things are true, not when the systems are back. You know how the attacker got in and that route is closed. You've found and removed every way they set up to get back in: accounts, tokens, scheduled tasks, implants, rogue app consents, and changed configurations. You've rebuilt or verified every system they touched rather than trusting a scan. And you've run with elevated monitoring on the specific indicators from this incident for long enough, usually weeks, that you'd have seen a return. Declare it over before that and you're not ending the incident, you're pausing it.

"Systems are back" is recovery, not closure

The pressure to declare victory is enormous. The business wants its systems, the board wants a line under it, and the response team is exhausted. NIST's recovery guidance separates restoring operations from the work that has to happen around it: understanding root cause, validating that restored systems are actually clean, and confirming the problem can't simply recur (Bartock et al., 2016). Restoring a server from a backup taken after the attacker was already inside brings the attacker back with it. That happens more often than anyone admits.

The current NIST incident response profile treats eradication and recovery as linked but distinct, with lessons-learned and improvement as part of the cycle rather than an optional afterthought (Nelson et al., 2025). The practical consequence is that "over" is a conclusion you reach with evidence, not a date you pick.

The four tests

1. Root cause is known and closed. Not "probably phishing." The specific credential, vulnerability, exposed service, or vendor connection, and proof that it's fixed. If you can't name the entry point, you can't say it's shut, and the attacker who used it once will use it again.

2. Persistence is gone. Attackers plan for being discovered. Look for new accounts, especially service accounts and accounts with innocuous names; new MFA registrations and app consents; scheduled tasks and services; modified startup items; new or changed firewall and remote-access rules; SSH keys and API tokens; and changes to identity-provider configuration, including federation trust. Each of these survives a password reset. Several survive a rebuild if the configuration is restored from a tainted source.

3. Affected systems are rebuilt or independently verified. The clean answer is a rebuild from known-good media and configuration. Where that's impossible, the system should be verified by someone who didn't restore it, using a method that would actually find what the attacker left. A clean antivirus result is not that method.

4. Monitoring has run long enough. Take the indicators from this incident, the source addresses, the tooling, the accounts, the techniques, and watch for them specifically. Attackers often wait out the response and come back when attention moves on. How long is long enough depends on the attacker and the environment; for a serious intrusion I'd want weeks, not days, and I'd want the decision to stand down made by the incident lead, not by whoever is paying the retainer.

The question that gets skipped: is the data gone?

If data was taken, the incident isn't over for the people whose data it was, and the organisation's obligations continue after the technical closure. That includes notification duties, which run on their own clocks (I've set them out in Who do we have to notify), and in extortion cases the possibility that the data surfaces months later. Closure of the technical incident should be recorded separately from closure of the legal and commercial one.

What to write down before you close it

A timeline from first access to last known activity. The entry route and the fix. The list of persistence mechanisms found and removed. The list of systems rebuilt or verified, and by whom. The monitoring plan and its end date. The decisions taken, who took them, and when. And a short, honest account of what would have stopped this earlier. That document is the single most valuable thing an incident produces, and most organisations never write it.

What I'd do next

If you've had an incident in the last year, ask whether anyone can show you the four tests above with evidence. If they can't, it may not be over. If you want an independent read on a closed incident, or help building the closure criteria into your plan before the next one, request a briefing. More on this cluster is in Incident response.