Walk into most security operations centers and you will find a dashboard full of numbers: alerts closed, mean time to detect, mean time to respond, false-positive rate. Ask the SOC manager what the team is trying to become over the next two quarters, and the answer is often less crisp. That gap is the difference between a KPI and an OKR — and confusing the two is one of the quietest ways a SOC stalls. A SOC manager who wants to genuinely raise the quality of the service, not just keep the lights on, has to understand both instruments and know when to reach for each.
Two instruments, two jobs
A Key Performance Indicator (KPI) is a quantitative measure of performance against a specific goal. It tells you how a process that already exists is behaving right now. In the words often used to summarize the distinction, KPIs are measures of health. Your MTTD, your MTTR, your false-positive rate, your analyst utilization — these are vital signs. They describe the current state of the running machine.
Objectives and Key Results (OKRs) are a goal-setting framework, not a single metric. As John Doerr — who brought OKRs to Google in the late 1990s — frames it, the objective is the what and the key results are the how. The objective is an ambitious, qualitative statement of where you want to go; each objective carries three to five quantitative key results that prove you are getting there, typically scored on a 0-to-1 scale. Where KPIs measure health, OKRs are measures for change. They describe the machine you are trying to build, not the one you already run.
This is why the two are not competitors. The team at What Matters, John Doerr’s OKR organization, calls OKRs “KPIs with soul”: the objective supplies the direction and ambition that a bare metric lacks, and because KPIs are already measurable, a good KPI often makes an excellent key result. Treating them as either/or throws away the value of both.
What this looks like in a SOC
Consider a SOC drowning in noise. The relevant KPIs are easy to name and already on the dashboard: false-positive rate sitting at, say, 70%; MTTD measured in hours; a backlog of un-triaged alerts. As steady-state health indicators these are useful — they tell you something hurts — but on their own they do not mobilize anyone. A KPI with no target and no owner is just a thermometer.
Now frame the same situation as an OKR for the quarter:
- Objective: Make alert triage trustworthy enough that analysts spend their time on real threats.
- Key Result 1: Reduce false-positive rate from 70% to 40%.
- Key Result 2: Cut median MTTD for high-severity detections from 4 hours to 45 minutes.
- Key Result 3: Automate enrichment on the top 10 alert types so every case arrives pre-contextualized.
Notice what happened. The objective gives the work a reason that a human cares about. The key results are mostly existing KPIs, now bound to a target and a deadline — which is exactly how a KPI becomes a key result. And the team has a way to score itself at quarter’s end rather than staring at a number that drifts without meaning.
Use KPIs to run the SOC; use OKRs to change it
The practical rule for a manager is this: KPIs govern the standing service, OKRs govern the improvements. You will always watch MTTD, MTTR, coverage, and false-positive rate because they are the operational vital signs of a live service — they never “complete.” OKRs, by contrast, are deliberately temporary and ambitious. You set them when you are launching something new or trying to move a capability to a level it has not reached: standing up threat hunting, rolling out SOAR automation, expanding detection coverage to a newly onboarded cloud estate. When the objective is achieved or the quarter ends, that OKR retires and the gains it produced fold back into the KPIs you monitor forever.
A complementary way to see it: KPIs are baseline measurements of programs you already have, so they are perfect for telling whether an existing process is healthy. OKRs are built to be aspirational — they encourage reaching for stretch goals where falling short is acceptable and even informative. That ambition is a feature, not a bug; a key result you always hit was probably set too low.
Common mistakes SOC managers make
Dressing up KPIs as OKRs. “Keep MTTR under two hours” is not an objective — it is a steady-state KPI target with no ambition and no end state. If a goal describes maintaining the current service rather than changing it, manage it as a KPI.
Writing task lists instead of key results. “Deploy three new SOAR playbooks” is an activity, not an outcome. The key result should measure the impact — for example, the percentage of alerts auto-triaged or the reduction in analyst touch-time — not the act of building the playbook. Tasks belong in the initiatives that support a key result, not in the key result itself.
Vanity metrics. “Number of alerts processed” rewards volume, not security. A SOC that closes more alerts because it generates more noise is not improving. Tie every KPI and key result to an outcome that actually reduces risk: time to detect, time to contain, coverage of the techniques that matter to your threat model.
Setting OKRs and never scoring them. The discipline of OKRs comes from the regular review — checking whether key results are moving in the right direction and scoring them honestly at the end of the cycle. Without the review cadence, OKRs decay into a forgotten slide.
Tying it to SOC maturity
The reason this matters for service quality is that a SOC improves in deliberate steps, not by accident. Maturity models such as the SOC-CMM exist precisely to assess where a SOC stands across people, process, technology, and services, and to build improvement plans from the gaps they expose. That assessment is a natural OKR engine: the maturity gap defines the objective, the model’s measurable dimensions become key results, and the everyday KPIs confirm the gains stuck once the quarter closed. KPIs tell you whether today’s service is healthy; OKRs, anchored to a maturity assessment, tell you whether the service is getting better on purpose.
The bottom line
A SOC manager who only watches KPIs will keep a steady service but rarely transform it — the dashboard is green and the SOC stays exactly as good as it was last year. A manager who only chases OKRs may push ambitious change while losing sight of whether the day-to-day service is healthy. The mature move is to run both: KPIs as the continuous vital signs of the live operation, OKRs as the quarterly engine of deliberate improvement, with your strongest KPIs graduating into key results whenever you decide it is time to move a number, not just watch it.