Security reporting for leadership tends toward two failure modes: the wall of technical dashboards nobody outside IT can read, and the reassuring green checkmark that means nothing at all. (“Blocked 14,000 threats this month” — mostly spam filters doing their routine job — is the security equivalent of bragging that your door was locked 14,000 times.) What a leader actually needs is a handful of numbers that answer one question: are we more or less exposed than last quarter? Here are seven that do, and what to ask when they move.

The seven numbers

1. MFA coverage — with the exception list, by name. Not “MFA: enabled ✓” but how many accounts lack it, and which ones. The exceptions are the finding: it’s routinely a shared mailbox, a service account, or an executive who pushed back — and attackers find the exceptions too. Target: exceptions rare, documented, and shrinking. Ask: why does each name on this list exist?

2. Days since a successful restore test. Not backup job status — jobs “succeed” while restores fail. The date somebody last actually recovered data, and whether the recovery met your time and data-loss targets. If this number exceeds a quarter, your ransomware resilience is a hypothesis.

3. Patch latency on critical fixes. When a serious vulnerability gets a fix, how many days until it’s deployed across your environment? Attackers weaponize known flaws in days; a disciplined process keeps this under a couple of weeks for critical items — and the systems excluded from patching (there are always some) should appear on the report by name, with a reason.

4. Phishing simulation: report rate, not just click rate. Click rate gets the attention, but the number that predicts real-incident outcomes is how many people reported the phish, and how fast — because in a real attack, one early report lets IT purge the message from every inbox. A falling click rate with a rising report rate is a training program actually working. Ask: is reporting getting faster?

5. Offboarding lag. Average time between an employee’s departure and their access being fully revoked — every account, remote access included. This should be measured in hours. If nobody can produce this number, the honest value is “unknown,” which is a worse answer than any number would be. (The checklist that makes it hours.)

6. Admin account count. How many accounts hold administrative rights, trending over time. The right number is small and shrinking; a growing one means privileges are accumulating the way they do when nobody’s counting. Twice a year, ask for the list with reasons.

7. Incidents and near-misses — narrated. Not a count; a paragraph each, in plain English: what happened, how it was caught, what changed as a result. Zero reported incidents quarter after quarter usually measures detection, not safety. A good near-miss report is the cheapest security education a leadership team can get.

How to read them together

Individually these are gauges; together they answer the leader’s real questions. Exposure: numbers 1, 3, 5, 6 measure how many doors stand open. Resilience: number 2 measures whether a bad day is recoverable. People: number 4 measures your largest attack surface’s readiness. Reality check: number 7 tells you whether the other six are describing the world or a spreadsheet. They’re also, not coincidentally, the numbers your cyber insurer is pricing — a leadership team fluent in these seven fills out the renewal application from memory.

Two rules keep the exercise honest. Trend beats snapshot — the question is always “versus last quarter,” which is why these belong as a standing page in your quarterly business review, same format every time. And reward honest numbers: the first accurate offboarding-lag figure may be embarrassing, and if leadership shoots the messenger, every future report will be green and useless. The provider or IT lead who brings you an ugly true number is the one you want.

The bottom line

You don’t need to understand the technology to govern the risk — you need seven numbers, quarterly, trending, with the exceptions named. Any competent IT team or provider can produce them without heroics. If yours can’t, that’s the first finding; if yours won’t, that’s the second.