Ask five people to define SecOps and you will get five answers, two of them about software products. The version worth your calendar hour is this SecOps contract overview from the Ops Atlas: an arrangement where the security side sets hardening baselines and the operations side lives in them, with a single remediation register, exceptions that carry expiry dates, and numbers both teams read together. The monthly meeting is where that arrangement either breathes or quietly dies, so chairing it well matters more than any tool you can demo. Here is the six-step agenda we have settled on — friendly, half an hour, no laptops required beyond one shared screen.
Step one: set the table before the slides open
Invite the people who fix things, not just the people who count them. A review without the operations folk becomes a lecture, and lectures do not fix servers. Put the person who actually applies the settings in the room, even if they only speak twice. Open with a ten-second reminder of the deal: findings get owners, owners get dates, exceptions get reviewed, and the numbers belong to both sides. If someone new attends, this is the whole induction. The chair’s only job in step one is making sure nobody reach for blame before the data appears.
Step two: read the unowned count out loud first
Before any percentages, ask the uncomfortable question: how many open findings currently have nobody’s name on them? Say the number aloud every single month. One real September register held six hundred findings, of which eighteen floated ownerless — three percent. Small, but only because someone counted; most organisations cannot produce the denominator. Unowned findings are not a workload problem, they are an assignment problem, and they rot faster than anything else on the list. The chair should also ask how the eighteen became unowned in the first place: a departing engineer, a queue that silently reassigned nothing, an asset list nobody updated. If the number moved up, the fix is routing, not scolding.
Step three: walk the SecOps grid, one cell at a time
This is the heart of the meeting. On-time remediation gets reported per cell — asset importance crossed with urgency — never as one estate-wide percentage. NIST considers the blended number not actionable, and the September scorecard shows why: the overall figure read a healthy 82.5% (198 of 240 on time), yet internet-facing high-urgency work hit 95% while the datacentre’s high-urgency cell managed only 75%. The gap had a boring explanation — nobody had given the datacentre a change window — and a one-line fix. A blended number would have filed the story under “fine” and moved on. While walking the grid, note the median and p90 remediation times; medians reveal the typical case, and p90 exposes the tail everyone else hides.
Step four: open the exception shelf
Exceptions are pauses, not pardons. Count how many have drifted past their review date and treat that figure as a direct measure of governance health. In the same September register, six of thirty-five exceptions had slipped — about seventeen percent — which is precisely the range where shelves start collapsing. Every expired exception gets one of two endings this month: renewed with a fresh date and a named owner, or closed. An exception renewed three times without re-examination is not an exception any more; it is a hole with paperwork.
Step five: check the seams — telemetry coverage
The watchers upstairs can only guard what reports in. Ask for the coverage number: how many of your machines are actually sending logs? September’s count ran 1,540 against 1,600 — 96.25% — and the sixty missing all belonged to a newly acquired subsidiary nobody had scanned. That single sentence told the room more than any dashboard: an entire estate, invisible to the monitoring side. Coverage gaps get an owner and a date like everything else, or the number becomes wallpaper.
Step six: close with the side-effects ledger and two actions
Security work should not break things, and when it does, the meeting must see it. Track a disruption counter: how many operational incidents did security changes cause this month? September logged three out of 120 changes — 2.5% — and all three traced back to a single estate-wide setting rolled out without any pilot group. That is not a security failure; it is a process failure wearing a security badge. Close the meeting by assigning exactly two actions with names and dates. Two. A chair who leaves with fifteen actions leaves with none. Every action should carry three parts:
- the specific change to make — never “improve monitoring”;
- the one person accountable, by name;
- the date it will be checked, which is next month’s meeting.
Anything that cannot fit that shape is a discussion topic, not an action, and belongs in a working session instead.
Why this SecOps agenda survives contact with real months
Notice what never appears in the six steps: a victory lap about tickets closed. Rewarding closed-ticket counts incentivises closing the easy tickets, not shrinking risk. The agenda works because each number has a human sentence attached — who owns it, what broke, what changes by next month. Teams wanting the broader operating picture can start with a step-by-step DevOps career guide to understand how these roles fit together, or study how observability-first teams operate through this simple guide to drones and their services — same pattern, smaller stakes: coverage, control, and honest reporting. And when the meeting threatens to sprawl, borrow the planner’s trick from our piece on choosing the right event to attend: decide in advance what success looks like, and cut anything that does not serve it. Your first review will be clumsy. Your sixth will run itself.
