Monday's move put a price on one line and asked the business to pick its number. Writing that line turned out to be the easy part, and I learned it in front of my own team.
The timing worked in my favor. Budget planning was coming, and I had a QBR on the calendar with the team, so I put the ODM framework up, gave them the definitions, and asked them to review the ideas and the measures against the work they already run. Planning was about to ask every one of us to justify a number. This was a way to justify it in terms the business could actually buy.
I walked it the way Paul Proctor lays it out. An outcome-driven metric is the measurement instrument, and it answers what we are measuring. The protection level objective is the threshold, where we draw the line. The protection level agreement is the contract that carries the funding, the governance, and the trade-off, and it answers the one question the C-suite actually asks. What protection level are we buying and accepting?
Each layer has its own audience. Operations and engineering own the ODM. Service owners and risk teams own the PLO. The PLA belongs to the C-suite, the board, and the heads of the lines of business, which means it belongs to people who were not in that room.
It wasn't pushback. Nobody argued the model was wrong or that we didn't need it, and if they had, I'd have known what to do with that.
What showed up was an intellectual challenge, and it is a harder one to work through. Every person in that room, me included, spent years thinking in SLAs and SLOs. That structure is how IT learned to measure itself, and security learned to report right alongside it, using the same shapes and the same language and very often the same dashboards.
An SLA asks whether we kept the promise. The ticket closed inside the window, the patch cycle hit its date, the alert got triaged before the clock ran out. An SLO sets the target underneath the promise. Both are useful, and both measure what is actually context, not value. They describe the conditions the work happened under, and they say nothing about what the business got for paying for the work.
The measures that came back were the usual ones, the catalog every security team carries. Time to acknowledge and time to contain, tiered by severity. Patch windows keyed to CVSS score, with a tighter clock for anything internet-facing. A deprovisioning timer for terminations, an uptime figure for the identity provider, a coverage percentage for the EDR fleet. Every one of them is a good SLA, and I'd keep most of them. Not one of them tells the business what it gets if it spends more, or what it gives up if it spends less.
The team is making progress, myself included. I'd rather state plainly where we are and skip the polish. We cannot yet connect the work to the value and the value to the strategy, and this is new for me.
Call it the context trap. A metric falls into it when it measures the conditions around the work in place of the outcome the business paid to get. SLAs live there by design, because they were built to manage a service relationship between IT and its internal customer, and in that relationship the promise really is the product.
Security inherited the shape without inheriting the relationship. Nobody buys a four hour ticket close from security. The business buys a protection level whether anyone says so or not, and most of the time nobody says so.
A metric becomes value at the moment somebody outside security pays for the line and signs for the gap. Until then it is context, however good the trend looks.
Your vendor contracts are the clearest place to watch this happen, and almost nobody reads them that way. Pull your MDR agreement. It is full of SLAs, response inside so many minutes and escalation inside so many more, and after reading it you will know exactly what the vendor promised. You will not know what the business bought.
Run it through the framework with illustrative numbers. The organization commits $600k a year to an around the clock MDR provider with automated isolation playbooks, and the PLO says infected hosts get isolated and lateral movement contained within 60 minutes of detection. Then leadership decides not to fund overnight coverage. The PLO moves to eight hours, next business day, and the business formally accepts the risk of lateral traversal overnight.
The vendor SLA never changes in that scenario. Every response time in the contract still gets met. The protection level the business holds just dropped by seven hours, and the only document anywhere that records the drop is the PLA.
That is the gap between the work and the value, sitting in a contract most of us signed and filed. The work is the playbook. The value is the 60 minutes. The strategy is whatever the business decided it could live with overnight, and if nobody wrote that decision down, the strategy is an accident.
Most teams who hear about outcome-driven metrics treat it as a reporting project. They pick better KPIs and rebuild the dashboard. The dashboard gets nicer and the budget conversation stays exactly where it was, because the numbers still belong to security and the business still has nothing to sign.
The wrong version is appealing for a reason that has nothing to do with laziness. SLAs are safe for us. We set the target, we control most of the inputs, and when we hit it we look good in the QBR. A PLA hands the threshold to somebody else. The business decides whether recovery takes 24 hours or four, and security has to live inside whatever number it picks, which is a real loss of control that teams feel long before they can name it.
Recovery shows the difference better than anything else, again with illustrative numbers. The board and CFO approve $450k for immutable cloud storage tiers and quarterly isolated restoration dry runs, with full recovery of the critical ERP and database clusters inside 24 hours and an RPO of four. The business confirms that a 24 hour halt in revenue processing is acceptable during a catastrophic incident. Ask for a four hour recovery window instead and the infrastructure budget has to scale to warm site replication.
The teams who get this wrong promise four hours and fund 24. The few who get it right put both numbers on one page, with both prices, and make the business pick.
Promising four hours on a 24 hour budget is the most common quiet lie in this industry, and most of the people telling it believe it.
Start with the one you wrote Monday. Take it to the service owner before any executive sees it, because the PLO belongs to them, and a threshold the service owner never agreed to falls apart the first time the CFO asks who picked it.
The second order effect lands in budget planning, and it lands fast. Line items stop reading as tools and headcount and start reading as protection levels with prices next to them. A cut stops being a security problem to absorb quietly and becomes a business decision to record. The postmortem changes too. When an incident lands inside a window the business accepted, the conversation turns to whether that decision still holds, and nobody spends the first hour hunting for whoever missed an SLA.
It gets hard when the price is friction instead of dollars. Privileged access is the cleanest example. The PLO says every domain and cloud administrator account uses hardware-backed MFA with a four hour session cap, and the PLA says the business units fund the administrative overhead and accept the friction during emergency changes, in exchange for taking credential theft off the table. Everybody agrees in the meeting. The real test comes with the first emergency change that runs into that four hour cap and somebody asks for an exception. Count the exceptions and bring the count back as a renegotiation of the PLA, because an exception granted quietly is a protection level changed without a signature.
The other hard part is the one my team and I are still in, which is connecting the value to the strategy.
The ask I've put to my team is simple to say and hard to answer. Show your value in business terms. If we get more money, is it better, and how much better, in terms the business understands? Then answer the same question for less money.