IT & Security OKRs · 10 min read
IT & Security OKRs That Track Risk, Not the Status Page
I've run security and IT-adjacent teams for about a decade, and I've watched too many of them sign off a quarter with a green dashboard and a breach waiting to happen. The status page is the comfortable number. The unpatched box in a back rack is the one that wakes you up. Here's how I write OKRs for these teams so the scary metric is the one we actually move. Every Key Result below has a baseline and a target, because anything else is a wish in a slide deck.
By Max Bondarenko · Last updated June 2026
Your status page is lying to you about how safe you are
The trap this team falls into is worshipping uptime. Three nines on the dashboard, a wall of green, and everyone feels covered. Meanwhile there are forty critical vulnerabilities sitting open past their patch window and a third of the company logs in with a password and nothing else. Uptime is a vanity metric here. It's real, it matters to the business, but it's also the easiest number to keep green while the actual risk surface quietly rots underneath it.
So the rule I hold these OKRs to is simple. The Objective describes a safer, more reliable state of the world. The Key Results are the scary numbers going down: open critical vulns, time-to-fix, the percentage of accounts with no second factor. If a KR can't be tied to reduced risk or restored service, I'd kill it in the planning meeting. 'We deployed the new SIEM' is a task, not a result. Tell me what got less dangerous and by how much.
Security posture / risk
This is the heart of it. The unpatched, unfixed, exploitable stuff. If you only run one of these OKRs, run this one.
Shrink the window where a known weakness can be exploited against us.
KR1Cut critical vulnerabilities open past 30 days from 40 to 5
KR2Drop mean time to remediate a confirmed critical from 8 hours to under 2 hours
KR3Raise patch compliance across managed endpoints from 78% to 97%
The cardinal sin here is counting how many vulns you found instead of how many you closed and how fast. Scanners will always find more; that's their job. The number that matters is the aging backlog of criticals, because that's the door an attacker walks through. I anchor everything to time-open, not volume detected.
Service / uptime
Uptime still belongs in your OKRs. I just won't let it be the headline that hides everything else. And I refuse the pure availability percentage on its own, because nudging 99.9% to 99.95% is mostly noise. Recovery speed is the honest measure.
Make our core services boringly dependable and fast to recover when they break.
KR1Reduce mean time to restore a P1 incident from 47 minutes to 18 minutes
KR2Cut repeat incidents from the same root cause from 9 per quarter to 2 per quarter
KR3Bring change-related outages down from 6 per quarter to 1 per quarter
What teams get wrong is chasing a higher availability number instead of a faster recovery number. Things break. The grown-up question is how fast you're back and whether the same thing breaks twice. Repeat incidents from one root cause are the real tell that you patched a symptom and walked away.
Identity & access
This is where the cheap, high-leverage wins live. Most breaches I've seen up close came in through a credential, not a zero-day. Identity hygiene is unglamorous and it's the best return on the board.
Make a stolen password worthless on its own.
KR1Push MFA coverage on all human accounts from 70% to 100%
KR2Cut standing admin accounts from 34 to 12
KR3Reduce orphaned accounts of departed staff from 21 to 0, deactivated within 48 hours of exit
100% MFA is one of the rare KRs where I'll accept a hard ceiling as the target, because 95% means the gap is exactly where someone will aim. The orphaned-account number is the one people forget and it's brutal in an audit. A leaver who still has live access three weeks later is a finding waiting to happen.
Compliance
Compliance OKRs go sideways the instant the goal becomes 'pass the audit'. Passing is the byproduct. The real objective is that the controls are genuinely working when nobody's watching, not staged for the auditor's week.
Be continuously audit-ready instead of cramming before every assessment.
KR1Lower phishing simulation failure rate from 12% to 3%
KR2Raise controls passing continuous automated evidence checks from 61% to 90%
KR3Cut overdue access reviews from 28 to 0 at quarter end
The phishing number is the one I trust most because you can't fake it; it's real people clicking real bait. Watch the trap of teaching to the test, though. If the same five scenarios run every month, the rate drops and means nothing. Rotate the lures or you're measuring familiarity, not resilience.
The logic: why these work
Every KR above passes a three-part test. There's a baseline (where we are today, measured, not guessed), a target (where we're going), and an outcome behind it (less risk or faster recovery, never an activity). '40 to 5 open criticals' tells you the start line, the finish line, and why anyone should care. 'Improve our security posture' tells you nothing and lets everyone declare victory in December. If you can't state the baseline number out loud in the planning room, you don't have a Key Result yet. You have an intention.
On ambition: I calibrate these so landing around 70% is a good quarter. If you're hitting 100% on everything, your targets were sandbagged and you're not learning where the real friction is. Here's my scar. One quarter I let a team set seven security objectives at once because everything felt urgent after a near-miss. Vulns, identity, logging, training, vendor reviews, the lot. We landed about 40% on average across all seven and finished worse than if we'd picked two and actually moved them. The open-criticals backlog barely budged, from 40 down to 33, because attention was sprayed across too many fronts. Now I cap it at two or three objectives per quarter for this team and the numbers move like they're supposed to.
The weekly check-in for IT & Security
This team's check-in is different from a sales standup. You're not just reporting progress; you're triaging risk in real time. Fifteen minutes, numbers up first, and the oldest open critical gets named out loud every single week until it's gone.
Five questions I ask every week
- 01What's the single oldest open critical vulnerability right now, and what's blocking the fix?
- 02Did our MTTR on this week's incidents beat the target, and if not, where did the time go?
- 03Which accounts still don't have MFA, and why are they exceptions?
- 04Did any leaver keep access past 48 hours, and how did that slip?
- 05Which KR is drifting away from us, and is the target wrong or is the work stuck?
If a target turns out to be wrong, change it in week two, not week eleven. I'd rather reset '40 to 5' to '40 to 12' in February because we found a dependency we didn't see, than limp toward a fantasy number and call the whole quarter a failure. Revising a target early with a stated reason is honest. Discovering in the last week that it was never reachable is just bad planning wearing a brave face.
An IT & Security OKR template you can steal
Fill in your own baselines from your last scan and last quarter's incident log. The example numbers are there to show the shape, not to be copied. If you don't know your baseline yet, your first job this quarter is measuring it, not setting the target.
| Objective | Shrink the window where a known weakness can hurt us |
|---|---|
| KR1 | Cut open critical vulns past 30 days from [40] to [5] |
| KR2 | Reduce mean time to remediate a critical from [8h] to [2h] |
| KR3 | Raise MFA coverage on human accounts from [70%] to [100%] |
| Cadence | 15-min weekly check-in, numbers first, oldest critical named aloud |
| Owner | Security lead (single accountable name, not 'the team') |
Drop in your own measured baselines before the quarter starts
Questions people actually ask
What's a good Key Result for a security team that isn't just 'pass the audit'?
Anchor it to a number that's true whether or not an auditor is watching. Phishing simulation failure rate dropping from 12% to 3%, or controls passing continuous automated evidence checks going from 61% to 90%. Passing the audit then becomes the byproduct of controls that actually work, instead of a one-week performance you cram for.
Should uptime be the main IT OKR?
No, and that's the mistake I see most. Uptime is the easiest number to keep green while real risk piles up underneath. Keep it, but make recovery speed the headline: mean time to restore a P1 from 47 minutes to 18 minutes, and repeat incidents from one root cause from 9 per quarter to 2. How fast you're back, and whether it breaks twice, tells you far more than another decimal of availability.
How many objectives should an IT and security team run per quarter?
Two, maybe three. I once let a team run seven at once after a scare and we landed about 40% across all of them, with the critical-vuln backlog barely moving from 40 to 33. Pick the scariest one or two risks and actually move the numbers. Spreading attention thin is how the open-criticals count stays stuck.
What baseline numbers should I use for IT and security OKRs?
Pull them from your own data, not a benchmark blog. Your last vulnerability scan gives you open criticals and patch compliance, your identity provider gives you MFA coverage and standing admin counts, and your last quarter's incident log gives you MTTR and repeat-incident counts. If you don't know a baseline yet, measuring it is your first KR for the quarter, not the improvement.
Run these without the spreadsheet
Okiar is free during beta. Voice check-ins, AI projections, team health — live in minutes.
Start free →OKR examples for other teams