Maya runs dispatch for a flight school on one side of the field; Dev holds the ops desk for a charter operator on the other. Between shifts, over coffee that airport diners should be famous for, they compared screens, and the comparison turned into the clearest explanation of SecOps either had produced. Both screens claimed to describe security work. Maya’s showed one number — a percentage of things patched, updated nightly. Dev’s showed a small grid. What follows is their side-by-side, and why the grid belongs to the working contract the Ops Atlas calls SecOps: hardening baselines, one remediation queue where owners and dates attach to every finding, exceptions that expire, and metrics both security and operations read together — a definition set apart from both the monitoring centre and the Google product with a similar name.
The SecOps number on Maya’s screen
The big percentage is seductive. It moves, it fits on a slide, and board members nod at it. Its troubles start with arithmetic: a figure blended across the whole estate averages away the very differences that matter. NIST’s own position is that the estate-wide “percentage patched” is not actionable — it cannot tell anyone what to do next. Maya’s screen also rewarded the wrong behaviour quietly: her helpdesk had discovered that closing tickets lifted the number, so tickets closed first and verified later, if ever. The Atlas’s guidance is blunt on this point: closed-ticket counts must never become the reward, because volume is the simplest security number to farm. And when an auditor asked Maya’s team which findings had owners, the honest answer, eighteen unowned rows in six hundred, had never appeared anywhere on the screen at all.
The SecOps grid on Dev’s screen
Dev’s dashboard was smaller and louder at the same time. Each row was a cell — asset importance crossed with urgency — and each cell reported an on-time percentage, with the median and p90 speed of fixes alongside. One cell glowed: internet-facing systems at high importance, the charter booking path, running at 95 percent on-time. Another sat dull: a datacentre tier stuck at 75, and the grid’s annotation said why in one line — no change window ever agreed with that tier’s owners, so fixes waited for permission that never came. That is the property the grid has and the percentage lacks: it converts a vague worry into a specific conversation with a named person, and the conversation happens while the finding is still cheap. Dev’s screen also carried three counters Maya’s had no place for: findings without owners that week, exceptions past their review date, and disruption caused by security changes themselves — the honest ledger, since the Atlas’s worked month shows all disruption from security work can trace to a single estate-wide change that skipped any pilot ring.
The grid earned its keep within the fortnight. The datacentre tier’s owners, shown the 75 with the annotation beside it, agreed a change window in one meeting that had failed to happen across two years of general requests; the dull cell turned amber the next month with no other intervention. Dev did not hire anyone, buy anything, or reorganise anything to get that result — the grid simply made an existing failure visible to the people who could fix it, which is most of what good measurement ever does.
The comparison, row by row
- What it measures — a blended average versus on-time delivery inside cells of importance and urgency.
- What it hides — the single number conceals both a shining cell and a starving one; the grid publishes both.
- What it rewards — ticket-closing volume versus meeting dates the affected owners agreed to.
- What it triggers — relief versus a scheduled conversation with the tier that needs a change window.
- What it costs — nothing to build either, which is the quiet scandal of the comparison.
Why the grid ships with a contract
A dashboard does not create obligations; the contract does. Dev’s grid works because a signed agreement backs it: baselines borrowed from published benchmarks rather than improvised, exceptions that expire on review, security changes confined to agreed windows, and telemetry duties — logs, synchronised clocks, central collection, ninety-day retention, the CIS Control 8 IG2 set — treated as deliverables rather than favours. The order matters, and both colleagues learned it the roundabout way: measurement installed before ownership exists merely documents the argument, and a scorecard nobody has signed is a screenshot of disagreement. Maya is drafting the same one-page agreement now, and her first act was deleting the big number from the board pack. Her second was merging the two queues her helpdesk and the contractor had been keeping separately, which cut the visible finding count by a third and gave every remaining row a name. Both changes cost an afternoon. Both colleagues noted the career angle afterwards: the person who can explain why a blended percentage misleads is becoming more employable than the one who can recite it, a shift with real consequences for anyone weighing a return on pilot training investment, comparing a pilot salary against training cost, or planning career growth after training — ops desks increasingly hire for exactly this literacy.
The full reference behind both screens — definitions, the worked month, and the metrics that replace vanity percentages — sits on the Atlas’s page devoted to SecOps. Maya’s advice to anyone still staring at a single number: keep it if it comforts you, but build the grid before your next auditor asks a question it cannot answer. And if the choice feels like extra work, remember Dev’s fortnight: one meeting, one annotation, one amber cell — the grid did not add labour so much as aim the labour that was already being spent.
