Here is a scene that plays out in a thousand offices every Tuesday. The weekly scan finishes, the export lands in someone’s inbox as a cheerful spreadsheet, and then… nothing. Not because anyone is lazy, but because the spreadsheet is addressed to everybody, which means it is addressed to nobody. Three weeks later the same rows reappear in a fresh export, slightly staler, nobody the wiser. If that loop feels familiar, the problem is not your scanner — scanners are cheap and loud. The problem is routing, and fixing it is the first real job of SecOps, the working agreement between security and the people who run the systems. Let us diagnose why findings pile up, and what actually gets them moving.
Symptoms of a SecOps routing problem
Pile-ups have a tell-tale pattern. Any one of these three signs means findings are being broadcast rather than delivered.
- Nobody recognises the address. Ask five people who fixes a finding on the payment server and you will get five shrugs and a guess. If ownership has to be worked out per finding, per week, it never gets worked out at all.
- Fixes bounce between teams. The security desk raises it with the app team, the app team says the fleet belongs to platform, platform points back at security. Each bounce costs days, and bounces are invisible in a spreadsheet.
- The same rows return every scan. A finding that survives four consecutive scans unowned is not a finding any more; it is furniture. Nothing in the process is embarrassed by it, so nothing changes.
The industry has an old name for the root cause: “reports over the wall” — thousands of spreadsheet rows thrown at a broad audience, with no addressee, no clock and no consequence. The wall is comfortable for both sides, which is what makes it so durable.
The SecOps cure: deliver, do not broadcast
The fix sounds almost too dull to say out loud: every finding needs a destination before it needs a deadline. The SecOps contract described in the Ops Atlas puts it at the centre of the agreement — one shared register, each finding assigned to an owning group, each group carrying timeframes it has actually resourced. Dull is the point. A queue where every row has an addressee behaves like mail; a queue without addressees behaves like a lost-property office.
Delivery means the ticket arrives in the queue of the group that can log into the machine, not in a channel where someone kindly forwards it. It also means the timeframe belongs to the group, set with their capacity in view, so the deadline is a commitment rather than a wish. When those two things hold, the weekly argument “whose is this?” simply stops happening — and that argument is where most of the delay was hiding all along.
Why auto-routing decides maturity level one
Manual delivery does not scale past a few dozen findings a week, so the mature versions of this discipline automate the addressing step. On the common maturity ladder, level zero is the ad-hoc spreadsheet; level one — defined — expects roughly ninety percent of findings to route to their owner automatically. The machinery for that already exists in most estates:
- A configuration management database that records which system belongs to which service, and which service to which team.
- A support-group field on each record, kept as current as the rest of the asset data.
- A vulnerability-management tool that reads that mapping and opens each finding with the right group.
ServiceNow shipped exactly this capability in the Yokohama release of its Vulnerability Response product: each finding is assigned automatically by reading which support group is listed against the affected system’s CMDB record. Note what that implies — the hard part is not the security tooling, it is asset data quality. An estate whose records are stale will auto-route confidently to the wrong desks, which is arguably worse than not routing at all, because the misdelivery comes with a timestamp that says it was handled.
Count the unowned, weekly, out loud
Once routing exists, the number to watch is small and blunt: how many findings in the register have no owner this week? That single figure exposes every gap in the address book, and unlike total open findings — which grows for reasons nobody controls — it is directly fixable. A sensible rule keeps it visible in the same review that tracks on-time completion, because the two numbers cheat off each other: a team can look punctual while a quiet tenth of the register drifts with nobody attached. Reward closing tickets and people will close tickets; reward shrinking the unowned count and the address book gets honest.
It also gives the routing setup a maintenance signal. Asset databases decay quietly — teams rename, services move, acquisitions arrive with their own inventories. A weekly unowned figure that ticks upward is usually the first symptom, appearing long before anyone notices that a whole cluster changed hands.
Where to start this week
The first thirty days of the standard adoption plan aim at exactly this: a signed agreement on the model, owner fields populated in the asset database, and one register as the single destination for everything. No new scanners, no platform migration — just addresses, entered and checked. Teams that begin there usually find the pile-up was never a motivation problem. It was a postal problem, and the post office had been left unstaffed. Sort the addressing, and most of the queue starts moving on its own momentum; the deeper work of baselines and exception governance then has somewhere to land.
If the wider subject appeals, the digital growth planning blueprint and this guide to integrating web, cloud and AI systems put the practice in business context, and this DevOps career guide shows how operations skills stack for newcomers. Diagnose the routing first, though. Everything else in the agreement depends on findings actually reaching a desk that can act.
