Chief Information Security Officer
Defend the number, not just report it
"Are we more or less exposed than last quarter, and how do I know?"
The board question is rarely "how many vulnerabilities". It is whether the programme is working, and whether the answer survives a follow-up. A number that cannot be decomposed into the findings behind it gets asked once and never trusted again.
Judge it by: whether you can answer a board follow-up question live, in the room, without saying you will come back to them.
Read: The Enterprise Security Visibility Crisis →Today
- Board pack assembled by hand from six exports, two weeks before the meeting
- The number cannot be drilled into, so it is presented once and quietly retired
- No comparable measurement from last quarter, so "improving" is an assertion
- Spend is defended by activity — findings closed — rather than by risk reduced
With correlated data
- One score, decomposable to the findings and services that produced it
- Direction of travel over quarters, computed the same way each time
- Exposure expressed by business service, in language the board already uses
- The same model produces the engineer queue, so the story is consistent downward
Security Manager · Vulnerability Management
A queue the team believes
"What do my people work on this week, and can I defend that order?"
You are rationing a fixed amount of engineering attention. The ranking is the product. An engineer who disagrees with it will work from their own list, and at that point the programme exists on paper only.
Judge it by: the ranking challenge rate — how often an engineer disputes a rank, and how often they turn out to be right.
Read: Why Vulnerability Prioritisation is Broken →Today
- Sort by CVSS, work downwards, escalate whatever someone shouts about
- A third of the queue is "critical", so the label carries no information
- The same weakness arrives as four tickets from four tools
- MTTR looks good because easy low-risk items close fastest
With correlated data
- Ranked by reachability, exploitation activity, criticality and verified controls
- Every rank shows its factors, so it can be challenged specifically
- Duplicates collapse to one finding with one owner
- Time-to-remediate measured on the top decile, where it means something
Product Security · AppSec
Stop arguing about whether it is real
"Is this finding reachable, and does the threat model already cover it?"
Most of the friction between AppSec and engineering is not about whether a flaw exists. It is about whether it matters here — a question the scanner that raised it cannot answer, so it gets settled by whoever argues best.
Judge it by: how many findings are closed as "won't fix, not reachable" after an engineer has already spent time on them.
See how a finding is traced end to end →Today
- Threat models live in documents nobody opens after the design review
- Reachability is decided in triage from memory and opinion
- A library CVE is raised against every service that imports it, called or not
- Compensating controls are asserted verbally and never verified
With correlated data
- Findings joined to the threat model that already predicted that attack path
- Exposure and authentication state attached before triage begins
- Ownership resolved to the team that can actually change the code
- Control state carried as data, with the date it was last verified
Compliance · GRC · Internal Audit
Evidence that is derived, not assembled
"Can I show this control is working without a two-week fire drill?"
Evidence collection is expensive, so it happens annually. Because it happens annually, controls drift unobserved for eleven months, and the audit measures a state that was manufactured for the audit.
Judge it by: elapsed days from an auditor's request to defensible evidence — and whether the answer would have been the same last month.
More on measurement and evidence →Today
- The same underlying facts extracted four times for four frameworks
- Evidence is entered by hand, so it describes intention rather than state
- Control coverage is known once a year, on the day it is asked for
- Exceptions accumulate, expire silently and are never revisited
With correlated data
- One control mapped to every framework that references it
- Evidence derived from live findings, not typed into a register
- Coverage as a continuous number, so drift is visible in week two not month eleven
- Every acceptance carries an owner, an expiry and a review that happens
Security Operations
Context at the moment of triage
"Is this alert against something already known to be vulnerable and exposed?"
A SIEM correlates events in time. It rarely knows the standing posture of the asset those events landed on — so the analyst enriches by hand, in the middle of an incident, from systems they do not own.
Judge it by: minutes spent per escalation establishing what the affected asset is and who owns it.
Why SIEM correlation is not this →Today
- Alert arrives with a hostname and no business meaning
- Analyst pivots through three consoles to learn what the asset supports
- No visibility of whether that asset had an open critical finding last week
- Ownership found by asking in a channel and waiting
With correlated data
- Asset resolves immediately to a service, a business unit and an owner
- Standing posture visible: open findings, exposure, control state
- An alert on a KEV-listed, internet-facing asset is prioritised as such
- Post-incident, the finding that was exploited is already in the record
DevSecOps · Platform Engineering
Work arrives where the work happens
"Can my teams fix this without leaving the tracker they already use?"
Every security tool that asks engineers to log into it loses. The measure of a security programme's usability is whether a developer ever has to see it.
Judge it by: how many engineers hold a login to a security console — ideally very few, because the work reaches them elsewhere.
How the pipeline writes back →Today
- Findings exported to a spreadsheet and pasted into tickets by hand
- Tickets arrive without context, so the first action is asking why
- Fixed issues stay open in the scanner until someone reconciles
- Build-blocking rules based on severity stop releases for unreachable flaws
With correlated data
- Prioritised items routed into Jira or ServiceNow with the reasoning attached
- Ownership already resolved, so nothing waits in a triage queue
- Closure flows back, so the two systems agree without reconciliation
- Gates keyed to real exposure, so builds stop for things that matter
In one table
The same model, six questions
| Role | The question | What the model supplies | Measured by |
|---|---|---|---|
| CISO | Are we more or less exposed than last quarter? | A decomposable score with direction of travel | Surviving a board follow-up live |
| Security Manager | What do we work on this week? | A ranking that shows its factors | Ranking challenge rate |
| Product Security | Is it reachable, and did we model it? | Exposure plus the threat model join | "Not reachable" closures after effort spent |
| Compliance | Can I evidence this control today? | Evidence derived from live findings | Days from request to defensible answer |
| SOC | Is this asset already known-vulnerable? | Standing posture at triage time | Minutes per escalation on enrichment |
| DevSecOps | Can we fix it in our own tracker? | Routed work with context and writeback | Engineers needing a security login |
Note what is not claimed here: none of these roles gets a new scanner, and none is asked to change the tool they work in. The change is that the data those tools already produce arrives joined to the business that owns it.
Bring the question your role actually asks.
We will answer it with your data.
Forty-five minutes. Ideally the question your current tooling answers badly.