In this section
Containment Decisions: The Limits of Triage Containment
Containment is not resolution
You can now make the containment decision well, and the temptation that follows is to treat containment as the end of the incident. It is not. Triage containment stops the compounding harm, the live exfiltration, the active spread, the replaying session, and stopping that is genuinely valuable, it is the bleeding halted. But the incident is not over because the bleeding stopped, and an analyst who confuses containment with resolution declares victory while the attacker's entry path remains open, the root cause unexamined, and the environment unrecovered. The honest boundary of this module is that containment buys time and stops harm; it does not resolve the incident.
This is the same shape of boundary the network, correlation, and severity modules each closed on: the instrument does one thing well and is not the whole job. Triage containment's one thing is stopping the compounding harm fast, under the clock, with the right action aimed at the right capability. What it explicitly does not do is eradicate the attacker's presence, fix the weakness that let them in, or recover the affected systems to a trusted state, and those are not optional extras, they are the rest of the incident, owned by the full incident response that triage hands off to. Knowing where triage containment ends is part of doing it well, because the analyst who knows the boundary contains hard and hands off cleanly, while the one who does not contains and then believes the job is done.
What containment does not do
Three things sit outside triage containment, and naming them is how you avoid mistaking the part for the whole. Eradication is the first: containment severs the attacker's current access, but it does not guarantee the attacker is gone, because they may hold persistence you have not found, a second backdoor, a dormant grant, a foothold on a system outside your scope. Containment stopped the access you saw; eradication is the deliberate hunt for the access you did not, and it is a different, longer activity than the fast triage action.
Root cause is the second: containment stops the harm, but it does not explain how the attacker got in, and until the entry path is understood and closed, the same compromise can recur. The phished credential, the misconfigured grant, the unpatched edge device, that initial access is untouched by revoking a session, and finding and fixing it is the investigation's job, not triage's. Recovery is the third: containment may leave systems isolated, accounts reset, services disrupted, and returning the environment to a trusted, operational state, rebuilding, restoring, re-enabling, validating, is its own phase. These three, eradication, root cause, recovery, are the incident after triage, and triage containment is the fast first move that makes them possible by stopping the harm while they are done, not a substitute for them.
The distinction is not academic, because each of the three can fail independently of a clean containment. You can revoke every session and remove every grant you found, a textbook containment, and still have an attacker in the environment through a second persistence mechanism your triage never surfaced, so eradication failed even though containment succeeded. You can stop the harm perfectly and never learn that the entry was a phished credential on an account that still has the same exposure, so root cause is open and the next compromise is already possible. And you can sever every target and leave a dozen systems isolated and accounts reset, operationally broken until someone does the recovery work. A clean containment tells you the harm stopped; it tells you nothing about whether these three are done, which is exactly why they must be tracked separately rather than assumed to follow from the containment.
Containment is the front of the incident; three phases follow, and each can fail independently of a clean containment.
Containment halts the bleeding; eradication, root cause, and recovery are the incident that follows.
The handoff is part of the job
Because containment is not resolution, the triage analyst's job ends in a handoff, not a closure, and doing the handoff well is the last part of containing well. When you have stopped the compounding harm, what you pass to the full incident response is not "contained, done" but a precise statement of what you stopped, what you did to stop it, and what remains open: the harm halted, the actions taken, the targets severed, and the explicit unknowns, the persistence not yet ruled out, the root cause not yet found, the recovery not yet begun. That handoff is what lets eradication, root cause, and recovery start from where triage left off rather than from scratch, and it is the difference between containment that buys the response time and containment that creates a false sense of completion.
The failure this guards against is the quiet one: the analyst contains the harm, the dashboards go green, the alert closes, and because the bleeding stopped it feels finished, so the handoff is thin or absent and the open items, the unhunted persistence, the unfixed entry path, fall through the gap. Weeks later the same attacker returns through the access nobody eradicated or the entry path nobody closed, and the incident that was contained was never resolved. The handoff prevents that by making the boundary explicit: triage stopped the harm and here is exactly what is still open. Containing well includes saying clearly what containing did not do, so the work it did not cover is owned by someone rather than assumed complete.
A good handoff has a recognisable shape, and it is worth stating because the thin handoff is so easy to default to under the relief of a stopped attack. It names the harm that was halted and the evidence that it stopped, so the next responder knows what was achieved rather than taking it on faith. It lists the actions taken and the targets severed, so eradication and recovery know exactly what state the environment is in. And it states the open items explicitly, the persistence not yet ruled out, the root cause not yet found, the recovery not yet begun, as owned work rather than implied next steps. The difference between that and "contained, closed" is the difference between a baton passed and a baton dropped, and under the clock the dropped baton is the easy default, which is why naming the shape matters.
The same stopped harm becomes a resolved incident or a recurring one, depending on the handoff.
Holding the backdoor at the boundary
The hybrid backdoor, contained, shows the boundary cleanly. Triage containment stopped the harm: the session revoked, the malicious grant removed, the compromised credential reset, the host isolated, the attacker's live access severed. That is real and valuable, the bleeding is halted. But it is not resolution, and the honest handoff names what remains. Eradication: is this the only persistence, or did the attacker plant a second grant or foothold while they held organisation-wide access, which a deliberate hunt must rule out. Root cause: how was the sync account compromised in the first place, the phish, the exposed credential, the misconfiguration, because until that is found and closed the same access can be re-established. Recovery: the isolated host, the reset account, the removed grant all need validating and returning to trusted operation.
None of those is triage's to complete, and all of them are triage's to flag. The contained backdoor handed to the full response with "harm stopped, these actions taken, these three things open" is containment done well; the same backdoor marked "contained, closed" because the live access stopped is the failure the boundary warns against, because it treats the halted bleeding as a healed wound. The module taught you to contain well, and containing well ends here, at the honest statement of what containment achieved and what it left for the response that follows. Stopping the compounding harm fast, with the right action, aimed correctly, ordered well, at the narrowest cost, is the whole of triage containment, and it is genuinely valuable precisely because it is the fast first move that makes the rest of the incident survivable, not because it is the end of it.
Your turn
You contain an incident cleanly: the live harm is stopped, every target you found is severed, and the dashboards are green within the hour. A colleague says "great, that's closed then." Why is that wrong, and what do you actually say in the handoff?
Reveal
It is wrong because containment is not resolution: you stopped the compounding harm, which is real and valuable, but stopping the bleeding is not the same as healing the wound, and three things remain open that triage containment does not address. The colleague is making the exact error the sub names, treating the halted harm as a finished incident because the dashboards went green, when what actually happened is that the fast first move succeeded and the rest of the incident has not been done. So you do not accept "closed." What you say in the handoff is a precise statement of what you stopped, what you did, and what remains open, in three parts. First, what containment achieved: the live harm is stopped, here are the targets severed and the actions taken, the session revoked, the grant removed, the credential reset, the host isolated. Second, the explicit unknowns, which are the parts triage containment does not cover. Eradication: you severed the access you found, but you have not ruled out persistence you did not, a second grant or foothold the attacker may have planted, so the hunt for remaining persistence is open. Root cause: you stopped the access, but you do not yet know how the attacker got in, the phish or misconfiguration or exposed credential that was the initial access, and until that is found and closed the same compromise can recur. Recovery: the isolated host, the reset account, the disrupted services need validating and returning to trusted operation. Third, the boundary stated plainly: triage stopped the harm, and these three items, eradication, root cause, recovery, are open and owned by the full incident response, not done. That handoff is what lets the response start from where you left off rather than from scratch, and it is what prevents the quiet failure where the open items fall through the gap and the same attacker returns weeks later through the access nobody eradicated or the entry path nobody closed. The reason "closed" is dangerous is precisely that it feels true, the harm stopped, the alerts cleared, so without a deliberate handoff naming the open work, the incident that was contained is assumed resolved and never is. The lesson is the sub's core: triage containment stops the compounding harm and nothing more, eradication and root cause and recovery are the incident that follows, and containing well ends in an honest handoff that says clearly what containment did not do, so that work is owned rather than assumed complete.
Where this leads: that is the full containment decision and its honest boundary. The module summary draws the arc together, from the grade that arrived from severity to the contained incident handed to the response, names the single idea that runs through it, and bridges to triage in the age of AI and automation, where the speed pressure this module worked under intensifies.