Write security OKRs as one objective per quarter with two or three key results that count finished, checkable outcomes: coverage reached, actions closed, exercises run. Avoid counting alerts, tools bought or training hours. If you cannot yet measure a result, make "establish the baseline" the key result.
The common mistake
Many first year security OKRs reward activity. "Deploy a scanner" is a task. "Run 12 trainings" is effort. Neither tells leadership whether risk moved. They also invite gaming: once a number is a target, people optimize the number.
A better key result describes a state of the world that you can check.
A pattern that works
Each quarter, write the objective as a plain sentence about the company, then back it with key results.
| Quarter | Objective (example) | Key result patterns |
|---|---|---|
| 1 | We know what we run and who owns it | Share of repositories with a named owner; inventory reviewed on schedule |
| 2 | Code changes pass a consistent check | Share of production repositories with scanning and review rules; gate running in report mode |
| 3 | We can respond and prove it | Incident exercise held; share of exercise actions closed; vendor notice clause in new contracts |
| 4 | The year's controls keep running | Continuous checks on the top controls; year two plan agreed |
The numbers inside those key results come from your own inventory. If you do not have a base yet, say so, and set the first key result to produce one. Do not borrow a target from another company or from a vendor survey.
Rules for key results
- Count outcomes, not effort. Coverage and closure beat activity.
- Make them checkable. Someone else could verify it from a list or a report.
- Keep to two or three. More than that dilutes attention.
- Own each one. A key result without a name goes nowhere.
- Allow a baseline result. Early in the year, "measure X for the first time" is honest and useful.
Avoid goal distortion
Goodhart's law, often stated as "when a measure becomes a target it ceases to be a good measure", applies to security counts. A team told to reduce open findings can close them as won't fix. Pair each count with a quality check: for example, review a sample of closed items for correctness, and track how many reopen.
Keep OKRs separate from the control list
OKRs describe what you are trying to change this quarter. Ongoing controls such as weekly reviews or access checks are the baseline operation and should not eat OKR slots. Otherwise, by quarter three the OKRs list nothing but maintenance.
Presenting to leadership
Show last quarter's results, what you learned, and the next objective on one slide or page. Where a result missed, say why. Leaders tend to trust a program more when misses are explained plainly.
Safeguard's asset discovery and compliance and evidence automation can supply the coverage numbers that feed these key results. Try the free scan to see a first coverage view.
Quick check
Should security OKRs include a target for number of vulnerabilities?
Be careful. Raw counts shift with scanner changes and invite gaming. Prefer coverage, ownership and closure of actions, and pair them with a quality sample.
What if we have no baseline data in quarter one?
Make the baseline the key result: for example, produce the first inventory and the first coverage figure.
Last reviewed: 19 October 2026.
