A direction from a bench is never self-executing. The order gets published, the compliance date is recorded, and then some named official has to actually do the thing — which is precisely where most orders stall. Security programmes fail at the same juncture. Scanners emit verdicts by the thousand, consultants leave impressive decks behind, and the fix rate stays dismal because nobody was ever put on the hook for a dated commitment. The machinery that closes this gap has a name, SecOps, and the reading worth adopting treats it as a working contract between the security function and the operations teams who own the machines. This piece runs the diagnosis first, then the remedy, evidence attached throughout.

The Diagnosis: SecOps Breaks Where Findings Have No Owner

Ask a CISO how many vulnerabilities are open and you will get a number. Ask who is fixing row 2,941 of the spreadsheet and the room goes quiet. The classic failure mode is the report pushed over the wall: thousands of findings in a shared file, no names attached, no dates agreed, and a monthly complaint that operations ignores security. Nothing in that arrangement assigns responsibility, so nothing gets fixed. Even the term for the discipline that should fix it is unsettled. NIST’s glossary carries no entry for SecOps at all, and a BMC press release from January 2016 was already writing about a “SecOps gap” between the two camps. Usage since then has split three ways: collaboration between security and IT operations; the monitoring centre itself; and Google’s product name, adopted in April 2024. The Ops Atlas takes the first sense and defines it as a contract — hardening baselines, a single owned queue, governed exceptions and joint metrics.

Clause One: One Queue, Named Owners, Real Timeframes

Two parallel lists guarantee failure — one living in the scanner, one in the ticketing tool, both slowly rotting. The contract collapses them into a single register where every finding lands against a support group, not an org chart abstraction. Each owner group gets timeframes that someone has actually resourced: a database team of two cannot carry the same clock as a platform squad of twelve. The plumbing already exists. ServiceNow’s Vulnerability Response, in its Yokohama release, assigns findings automatically from the support group recorded on the configuration item in the CMDB. What is usually missing is the governance decision underneath: a finding that cannot be routed to a named owner is treated as a defect in the asset register, not as an excuse. A healthy register answers five questions for every entry.

• Which team holds the pen — one group, never a committee.
• Which deadline applies, and which policy set it.
• What evidence closes the item, agreed before work starts.
• Whether the item is an exception, and when that exception dies.
• Who reviews the queue weekly when an owner goes quiet.

Clause Two: SecOps Deadlines Proportionate to Exposure

Courts distinguish between matters that need hearing tomorrow and matters that can wait for the regular list. Regulators do the same. CISA’s Binding Operational Directive 26-04, issued in June 2026, gives United States civilian agencies three days for the worst combinations of known-exploited flaws and internet exposure, and 14 or 60 days for the rest. NIST describes emergency patching as running on “a highly accelerated schedule”. The proportionality matters more than the numbers, because a flat deadline teaches owners to ignore the queue. It also matters to measurement. A September scorecard that reads 82.5% on time overall is hiding the story: internet-facing and high-importance assets hit 95% while datacentre and high-importance assets sat at 75%, missing their windows because nobody had agreed a change slot with that owner group. NIST rejects a single estate-wide “% patched” figure as not actionable for exactly this reason — the cell is the unit of accountability in SecOps, not the average.

Clause Three: Exceptions Are Stays, Not Acquittals

An interim order buys time; it does not overturn the underlying ruling. Security exceptions work the same way. A system cannot be hardened before a revenue date, a legacy application cannot tolerate a setting, a vendor firmware lags — all legitimate, all temporary. The contract requires each exception to carry an owner, a justification and an expiry, with the register reviewed on a schedule. The health metric is blunt: of 35 exceptions on the books in the worked example, 6 had drifted past their review date, roughly 17%. That number, reported weekly, tells you whether the exception process is a controlled delay or a quiet amnesty. Exceptions without expiry are how breaches inherit old architecture.

Clause Four: The Evidence Duty Owed to Monitoring

The contract runs both ways. Operations owes the monitoring function a floor of telemetry duties, spelled out in CIS Control 8. Implementation Group 1 covers the logging process, audit log generation and storage in controls 8.1 through 8.3. Implementation Group 2 adds time synchronisation (8.4), centralised collection (8.9), retention of at least 90 days (8.10) and weekly log reviews (8.11). Beyond the controls sit two shared arrangements: a change calendar the monitoring desk can read, and containment authority agreed in advance so a 2 a.m. decision does not need a conference call. Without these duties, every detection promise is aspirational.

Reading the Contract Like a Compliance Document

Readers who follow the courts will recognise the shape of every clause. Enforcement only binds when authority is valid and communicated — as when the Supreme Court upheld the West Bengal Madrasah Service Commission Act and settled who held recruitment power. Deadlines bite only when notices actually issue, the way the Delhi High Court pulled up exporters over unpaid IGST rather than waiting for voluntary filings. And an order without follow-through is decoration, the lesson of the Madras High Court directing police to act on objectionable content about officials: issuance is the beginning of compliance work, never the end. Security governance lives on the same continuum, and the Ops Atlas entry on SecOps is the cleanest single statement of the contract version — what each side signs, what each side owes, and which numbers both parties read from the same page every week.

The diagnosis, in one line: findings fail for want of an owner and a date, not for want of another scanner. The remedy is contractual, auditable and unglamorous — one queue, proportionate clocks, expiring exceptions, evidence duties on both sides. Organisations that adopt it stop arguing about whose job security is and start arguing, productively, about whether this quarter’s numbers are good enough.