How do you know your business and operations well enough to trust the technology to take the action necessary to prevent harm? That question sits underneath Monday's sort, and most programs never reach it, because they are still busy pricing the action as the harm.
Start after the files are gone, because the weeks that follow are where this gets decided. A review convenes. Somebody builds the timeline, and the timeline is clean.
Detection caught the callout on the first beacon. Triage came in under SLA, and the analyst who worked it reached the correct conclusion in a few minutes of genuinely skilled work that nobody in the review will think to praise, because correct work delivered too late reads on a timeline exactly the same as no work at all. Escalation followed the documented path to the named authority. The approver responded promptly on receipt and approved it, because it was obviously the right call.
So the review produces no finding. There is no failed control to write a remediation item against, no missed alert, and nothing to tune. Somebody suggests tightening the SLA, which was already met, and the room agrees to look at it.
Fifty-two minutes. That's the gap between the escalation going out and the approval coming back, in the case I know.
Nobody dropped it, and that is the part that should bother you. The approver got the escalation and responded to it, and responding took longer than the attack took, which is the whole problem stated in one line with nobody in it to blame. Average breakout time is 29 minutes, and in the intrusion CrowdStrike documented the data started moving at four. By the time that approval landed, the window had been closed for forty-eight minutes, and every one of those minutes belonged to a process somebody wrote down deliberately and nobody has reread since.
A postmortem with no findings produces no change. The chain gets left exactly as it was, fully armed, ready to run again next quarter and produce the identical outcome, and every person in that room did their job correctly on the way to that result.
The one component nobody examined is the gate, and the reason is structural rather than careless. Reviews look for controls that failed. The gate did not fail. It performed exactly as designed, which is to say it stopped the machine and waited for a person, and that is precisely what it was built to do. Nobody reviews a control for succeeding.
Ask why it's there and you get a story that is usually true. Somebody isolated a domain controller during business hours and took out a chunk of the company before lunch. The gate went in as the fix, in a room where people were upset, and for that specific problem it was the right fix.
Then it stopped being scoped to that problem, and this is the part worth naming.
Call it worst-case pricing. A set of actions with wildly different costs gets governed at the cost of its most expensive member, because that member is the one everybody remembers.
The mechanism deserves precision, because it is not laziness. After the domain controller went down, somebody had to produce a control that would prevent a repeat, quickly, in front of people who wanted an answer that afternoon. Writing "isolation of tier-0 infrastructure requires approval from the infrastructure owner" takes a working knowledge of your own asset tiers, a defensible definition of tier-0, and a conversation with the people who own them. Writing "containment actions require approval" takes eleven seconds and covers the incident completely. The broad version always wins under pressure, and it never gets narrowed afterward, because narrowing it means volunteering to be the person who removed a safeguard.
A library of actions gets priced at the cost of its worst member. The quarantine on a marketing intern's mailbox waits behind the same signature as severing a payment path, and the wait runs longest for exactly the actions that could never have hurt anybody.
Once the label is in your head you will find it everywhere, and the version that should bother you most is the change advisory board. A database migration went badly in 2019, so a CSS change on a marketing page and a schema change on the transaction ledger both wait for the same Thursday meeting. The teams shipping the CSS change learned to batch their work into fewer and larger releases to reduce how often they have to sit in that room, which makes each release riskier, which justifies the board. The control manufactures its own evidence.
Vendor security review runs the same shape. A four-hundred-dollar-a-month scheduling tool gets the identical two-hundred-question assessment as the platform holding customer financial records, because one procurement failure years ago produced a policy that drew no distinction. Everybody involved knows it's absurd, and the absurdity is not the interesting part. Nobody proposes the tiering, because the person who proposes it owns the boundary they drew on the day something eventually goes wrong on the light side of it, which is a bet nobody takes for a scheduling tool.
Worth an aside here, because it comes up every time somebody tries this sort and it derails the first meeting. You will be told to start from the CMDB. Don't. The CMDB records what got provisioned and who owned it at provisioning time, and the useful question is which machines matter on a Tuesday afternoon, which is a different question with a different answer that nobody has ever written down. More on where to get it further down, and it is not a system.
The conventional answer to all of this is a maturity roadmap. Crawl, walk, run. Pilot one low-risk playbook, gather evidence over a quarter, present results to a governance forum, expand scope in the next phase. Nearly every automation adoption framework published in the last two years recommends approximately this, and the ones that skip it are selling you a platform that promises to collapse the middle two steps on your behalf.
Sit with why it's appealing, because the appeal explains its survival. It's defensible in front of any audience. It produces a schedule with named phases, and a schedule reads as control to people who have never had to run one. Nobody has to make a decision that could turn out wrong, because the decision gets deferred into a process, and processes don't get fired. Best of all it looks like motion while requiring nothing to change this quarter.
Crawl, walk, run is a project management artifact wearing a security costume. A program on that plan reaches partial automation of endpoint containment in three years, and breakout time got 65 percent faster during one year of that. You are pacing adoption to your organization's comfort while the other side paces theirs to the compute they can rent, and those two clocks are not going to converge in your favor.
Now the flip, and this is the part worth an argument. Trust was never the measurable variable. You cannot measure whether you trust a SOAR platform, and whatever answer you give is a mood with a budget attached. What you can measure is what one specific action costs when it fires on the wrong host, this week, by asking people who already know. Stop trying to trust the machine and price the action instead.
Pricing it is less analytical than it sounds, which is where that CMDB aside earns its keep. Ask the service desk. The people answering the phones can tell you from memory which machines generate a screaming call inside four minutes of going offline and which generate a ticket that sits until Tuesday, and they have been maintaining that distinction informally for years because their afternoons depend on it. That list is your sort, already done, in somebody else's head.
Two places it gets hard, and both live in the tail of the word endpoint. The executive laptop is the obvious one, where a false positive costs you politically rather than operationally. Automate it anyway and tell the executive in advance what will happen and why, because that conversation costs a fraction of the one you have afterward. The harder case is the workstation quietly running a scheduled job somebody set up in 2021 and never documented, which is a production dependency wearing a user endpoint's clothes. You find those by isolating things. That is an uncomfortable sentence and also an accurate one, and the audit catches it in week one.
The audit is the second half of the question, and it wants to stay small enough that it actually happens. Read every automated action from the past week. Mark each one right or wrong, and where it was wrong, write what it cost in the unit that matters, which is almost always minutes of somebody's day. Ten actions takes about twenty minutes. Put it somewhere a person other than you can read it.
The payoff shows up around week eight and it arrives sideways. You now hold a written record of automated containment with a real error rate and a real cost per error, which means the next argument about expanding scope stops being two people trading instincts and becomes a document somebody reads. That argument finishes in one meeting instead of one quarter.
The quieter effect lands on your analysts. Someone who spends a shift routing approvals for decisions they already made is doing clerical work with a security title, and they know it, and it is a genuinely miserable way to spend a career. Take the routing away and those hours go back into the work only a person can do, which starts after containment and asks how the thing got through the door in the first place.
Audit and act where it matters.