Flight training teaches diagnosis before repair: the engine runs rough, so you work the sequence — fuel, air, spark — instead of replacing parts at random. Security operations deserves the same respect, and the rough-running symptom appears everywhere in the same form: a scanner report nobody acts on. This post diagnoses that symptom properly, then applies the fix the industry has converged on, which The Ops Atlas calls SecOps — a working contract joining the security side with the operations side, rather than the monitoring room or the Google product that answers to the same word, built on hardened baselines, one queue for remediation that somebody owns, deadlines, exceptions that expire, and numbers both sides share.
The SecOps symptom: reports that land and stay
Watch for these in any organisation that feels busy but never safer.
- A scan exports to a spreadsheet, circulates by email, and receives no owner against any row.
- Everyone assumes another team is acting — the Atlas names this anti-pattern “reports over the wall”, and pairs it with the related myth that the monitoring centre will somehow fix findings itself.
- Deadlines exist only as wishes, because the people expected to meet them were never asked what they could staff.
- Exceptions to hardening settings are granted in corridors and never revisited; the Atlas’s worked month found 6 of 35 sitting past their review date.
- Leadership reads one blended number and feels reassured.
Three quick checks before the deep diagnosis
Like any checklist run before the panels come off, three questions sort most cases in ten minutes. Who answered when the last report’s rows were called for owners? Which exceptions were granted this quarter without a review date attached? And when the last hardening change shipped, did it go to a pilot group or to the whole estate at once? A “nobody”, a “several”, and an “all at once” confirm the pattern this article treats; the deeper numbers below then tell you how far the corrosion reaches.
The underlying fault, named
None of these is a tooling failure. Each is a missing contract clause: no named owner, no resourced timeframe, no expiry, no joint reading of results. The evidence for that claim is the Atlas’s worked September example, which deserves quoting in full because every number is diagnostic. The topline said 82.5 percent of fixes landed on time — respectable, until the cells separated: 95 percent for internet-facing, high-importance assets, against 75 percent in the datacentre tier, whose real problem was a change window nobody had ever agreed. Meanwhile 18 of 600 findings belonged to nobody (3 percent of the estate, responsible to no reader), exceptions past review ran at 17 percent, telemetry reached 1,540 assets out of 1,600 — and the sixty absentees turned out to be an acquired company nobody had ever scanned, and 3 of 120 security changes caused disruption — every one of them traced to a lone estate-wide baseline that shipped with no pilot ring ahead of it. Every fault above is organisational. That is the diagnosis.
The repair: writing the SecOps contract
The fix follows the same order as any good troubleshooting flow — cheapest checks first, structural repairs once confirmed.
- Name an owner per finding. Automate where possible: one ITSM example from the Atlas hands each finding to whichever support group sits in the asset’s CMDB entry, making inventory quality the true routing engine.
- Set deadlines with the teams who must meet them. A date without resourcing is a fiction; the contract matches timeframes to each group’s actual capacity.
- Expire the exceptions. Every corridor promise becomes a dated entry with a review — and the weekly count of ownerless findings keeps new ones honest.
- Give security work real slots. Change windows, plus a disruption counter so the trade-off stays visible; the counter-metric exists precisely to catch the un-piloted estate-wide push before it repeats.
- Report by cell, never by topline. Asset importance against urgency, with median and p90 fix speeds, is what NIST considers actionable; the blended percentage is not.
None of the five steps needs new headcount, which is the part sceptics underrate. The work moves because it is written down and watched, not because more people are pushed at it — the same reason a careful student with a checklist outperforms a hurried one with extra hours. Instrument the repair, though: a weekly glance at the ownerless count, the exception diary, and the routing success rate tells you whether the contract is being honoured or merely framed.
SecOps after the fix: what good looks like
Recovery is measurable and fast. Unowned findings trend toward zero within weeks of routing automation. The datacentre cell gets its change window and its 75 climbs. Telemetry coverage rises as the acquired estate gets scanned. Maturity, in the Atlas’s ladder terms, moves from ad hoc to defined once ninety percent of findings route themselves, and to managed after a scorecard survives three months. The habit underneath all of it is one student pilots already own: see the whole pattern before touching the controls, then act in a fixed sequence. The same discipline shows up in ground-side planning, whether the topic is reducing flight training expenses step by step, understanding how flying hours shape the cost, or planning ahead with a scholarship guide for training students — name the problem, sequence the repairs, measure the result.
One caution belongs in the log: do not let the emergency lane swallow the routine one. NIST’s phrase for urgent patching, “a highly accelerated schedule”, covers the rare true emergency; contracts that route every finding down that lane end up with no schedule at all. The source behind the diagnosis, the worked numbers, and the contract model is the Ops Atlas’s SecOps page. Run the checklist against your own queue this week; the spreadsheet that nobody owns will tell you how far the repair has to reach.
