Nobody sabotages a SecOps agreement on purpose. It dies of well-meaning habits — small compromises, each defensible in the meeting where it was made, that together hollow the thing out. The list below collects eight of those habits in the wild. If you recognise your own team in three or more of them, the agreement probably exists on paper only; the good news is that every one of these is reversible, and most reversals cost nothing but an uncomfortable conversation. Read it as a field guide to the ways these arrangements die quietly — and, at the end, to the order in which to revive them.
The SecOps report thrown over the wall
The oldest failure in the book, and still the most common: a scanner finishes, a spreadsheet with thousands of rows lands in a shared channel, and the sender considers the job done. A report is not a delivery. Until each finding has a named receiving team and a date, the wall has simply moved from inside the security department to the edge of it, and the findings pile up on the landing side exactly as they did before.
“The SOC will catch it”
Detection is not hardening. When operations skips a baseline fix because the monitoring team has “eyes on it”, the estate quietly carries a preventable weakness and a 24-hour room inherits the consequence. The SOC exists to catch what slips through; it is not a warehouse for things that were never fixed. Agreements that survive write the division explicitly: the watchers watch, the builders build, and neither borrows the other’s excuse.
Security tools that skip the change board
Scanners run with root. Endpoint agents run as SYSTEM. Automation platforms hold tokens that can trigger actions across the estate. These are not ordinary tools; they are trust boundaries wearing software costumes, and the agreement should say so in those words. A sensible rule: treat each of them the way you treat domain admin access.
- Scanners see everything and touch a great deal — compromise one and the attacker inherits your map.
- Root and SYSTEM agents can alter the very machines meant to watch them.
- The person who can edit those routing rules controls which findings ever reach a human being — and could, in theory, make problems vanish without a trace.
Vendor content updates treated as routine patches
On 19 July 2024, a sensor content update from a security vendor went out and took down machines around the world. The window was brief — the bad deployment ran from 04:09 to 05:27 UTC and crashed machines on sensors from version 7.11 upward — but the lesson stuck: security’s own updates are changes, and changes need a customer-side rein. The formal recommendation that followed said exactly that, calling for customer control over the deployment of Rapid Response Content. Your change board exists to protect the business from everyone, including the people protecting the business.
Big-bang hardening without a pilot ring
The plan is finished, the date is set, and the whole estate flips at once. Sometimes it works. When it does not, every server fails in a different way at the same hour, and the agreement earns a reputation it never recovers from. A pilot ring — one office, one cluster, two lab machines, anything small — converts that risk into a rehearsal. The cooling-off period after the pilot is not lost time; it is the cheapest insurance the programme will ever buy.
One big SecOps percentage, faithfully wrong
A single estate-wide “92 percent remediated” is arithmetic wearing a suit. It averages the internet-facing servers that fixed everything with the datacentre corner that fixed nothing, and reports the result as one virtue. Cut the number by cell — how important the asset is, crossed with how urgent the finding was — and the same month usually shows one cell carrying the estate and another quietly failing. Publish the cells, not the average; leadership decisions live in the differences.
Exceptions that never expire
Every real estate needs waivers; legacy appliances exist. The failure is not granting one — it is granting one without an expiry, which converts an exception into invisible policy. A healthy register shows every deferral with an owner, a reason and a review date, and shows the count shrinking. If the exception list only ever grows, the baseline is not a baseline; it is a suggestion with a fan club.
Two asset lists in two drawers
Security keeps one inventory, operations keeps another, and each is confident about the other’s errors. Findings route to machines that exist on one list and not the other, coverage numbers disagree, and every meeting starts with reconciling instead of deciding. One shared asset register, jointly owned, is dull work up front and the foundation of everything else — routing, telemetry coverage, on-time metrics, all of it inherits the addresses.
The recovery order that works
Teams that find themselves in several of these patterns at once should resist fixing everything simultaneously. The sequence that consistently works:
- Merge the asset lists first — every later fix depends on the addresses being real.
- Convert the over-the-wall report into a register with owners, even a rough one.
- Put security’s own tools and content updates under the change board it enforces on others.
- Add expiry dates to every exception the register already holds.
- Only then publish per-cell metrics, once the underlying data can bear the weight.
For the neighbouring disciplines that share this ground, the pieces on automating incident detection and response and incident management through SRE practices cover what happens after something slips through, while this guide to eliminating alert fatigue keeps the watching side humane. And when a definition argument starts — it will — the Ops Atlas’s working SecOps contract settles it faster than any meeting can.