Security metrics: the 10 measures a B2B tech firm should report to its board, customers and investors

A regulated customer's due diligence asks how quickly you fix critical vulnerabilities and how many admin accounts use multi-factor authentication. The board wants a quarterly security update, and an investor has asked whether security is a deal risk. You have a dozen tool dashboards and no agreed set of security metrics.

This list is for CTOs, heads of security and founders at UK B2B technology firms selling into financial services, insurance or the public sector. It sets out 10 security metrics, the system each comes from, who asks about it and what to do when it moves.

How we chose them. Every measure here passes four tests. It measures an outcome, the exposure you carry, rather than activity. A named audience asks about it: the board, a customer's due diligence team or an investor. It comes from a system, not a hand-kept spreadsheet. And it has a target, so a miss triggers an action.

A number nobody owns is decoration.

What are security metrics?

Security metrics are measures of how well your security controls reduce exposure, such as patch age, MFA coverage, backup recoverability and the time taken to detect and contain incidents. A B2B supplier needs about ten, each with an owner, a data source, a target and a trend, chosen because a board, customer or investor will ask about it.

NIST SP 800-55 Volume 1 (December 2024) defines metrics as measures and assessment results designed to track progress, support decisions and improve performance against a set target. It sorts measures into four types: implementation, effectiveness, efficiency and impact. Most of this list measures effectiveness and efficiency: whether controls work, and how fast.

A metric is any measure you track. A key performance indicator (KPI) is a metric with a target. A key risk indicator (KRI) warns that a risk is nearing the edge of your appetite, and setting those thresholds is a separate job. Compliance programme measures belong to GRC metrics.

Which security metrics should a B2B tech firm report?

The 10 security metrics below cover patching, identity, recovery, detection and people. Together they answer the three questions your audiences ask: is exposure going down, could you recover, and would an incident become a deal risk? Each row names the system the figure comes from and whether it can be collected automatically.

What does each security metric show, and what do you do about it?

Each measure below follows the same shape: what it is and where the number comes from, when it matters and to whom, and what to do about it, including the target and the direction the trend should move. Start with the core five named in the next section.

1. Critical and high vulnerability age against SLA

What it is. The number of open critical and high vulnerabilities, and how long each has been open against the fix time your policy sets. The scanner supplies the dates.

When it matters. When a customer asks how fast you patch. The NCSC's question set for boards names the time taken to patch and mitigate high-risk vulnerabilities as a KPI boards should see, with an agreed target range.

What to do about it. Set the fix time in your vulnerability management process and report the count past it. Aim for none overdue, with the trend falling. For internet-facing systems, the Cyber Essentials 14-day rule for critical and high-risk updates is a defensible ceiling.

2. Patch coverage on internet-facing assets

What it is. The share of internet-facing systems running supported software with all security updates applied. Joining the asset inventory to scanner results makes unlisted systems show as gaps.

When it matters. Attackers and questionnaires both reach these systems first. Cyber Essentials requires in-scope software to be licensed, supported and removed once support ends.

What to do about it. Aim for every internet-facing system to be listed and patched on time. Report the trend, and name each exception with an owner and a fix date.

3. MFA coverage, including admin accounts

What it is. The share of accounts that must use multi-factor authentication, reported separately for all users, admin accounts and internet-facing accounts. Your identity provider holds the figure.

When it matters. Customers and investors ask about MFA by name. Cyber Essentials requires MFA for every sign-in to cloud services, and tells you to use it on admin accounts and accounts reachable from the internet.

What to do about it. Aim for full coverage of admin accounts and cloud services, with no standing exceptions. Treat any admin account without MFA as a finding, whatever the overall share says.

4. Privileged account count and review

What it is. The number of accounts with admin or elevated rights across your identity provider, cloud platforms and production systems, with the date each was last reviewed. Your identity provider and cloud settings hold the list.

When it matters. Every audience wants to know who can change production or reach customer data. Cyber Essentials expects separate admin accounts, with rights removed once they are no longer needed.

What to do about it. We recommend a quarterly review. Report the count, the share reviewed on time and the rights removed. A count that only ever rises means rights are granted and never taken back.

5. Leaver access removed within SLA

What it is. The share of leavers whose access to every system was removed within the time your access policy sets, measured from the HR leaving date to the last account disabled.

When it matters. Regulated customers ask how you remove access, because their supplier controls depend on it. Cyber Essentials requires accounts to be removed or disabled when no longer needed, such as when someone leaves.

What to do about it. Aim for every leaver to be removed on time, and we recommend the same working day for privileged access. Report misses by system. Repeated misses on one system usually point to a manual step worth automating.

6. Backup success with tested restores

What it is. Two figures: the share of scheduled backups that completed, and the share of restore tests that met the recovery time agreed with the business. Backup tooling and restore records supply them.

When it matters. Boards, customers and investors all ask the same thing: could you recover the service? Successful backup jobs prove only that data was copied. A backup you have never restored is a hope, not a control.

What to do about it. We recommend restore-testing each critical system at least quarterly against its recovery time. Report restore results beside job success, and treat a failed restore as an incident. See our ISO 27001 backup guide.

7. Mean time to detect and to contain

What it is. The average time from an incident starting to its detection, and from detection to containment or resolution. The figures come from ticket timestamps and security monitoring alerts.

When it matters. Boards and investors read these times as a guide to how much harm an incident could do before it is stopped. The NCSC's board question set suggests metrics such as mean time to detect and recover from an incident, aligned to key business functions.

What to do about it. Record the same timestamps on every security ticket; without them the average is invented. Report the median beside the mean, because one long incident can drag the mean alone.

8. Security incidents by severity

What it is. The count of confirmed security incidents in each period, split by the severity levels in your incident response plan. Ticketing is the source.

When it matters. Boards and investors want to know whether real events are rising or falling. Customers ask in service reviews whether any touched their service.

What to do about it. Report by severity, with near-misses counted apart. A falling count is good news only if detection stayed steady.

An incident count of zero is a question, not a result.

9. Phishing report rate versus click rate

What it is. Across simulations and real campaigns, the share of recipients who reported a suspicious email set against the share who clicked. Your report button and simulation records supply both.

When it matters. The Cyber Governance Code of Practice asks boards to gain assurance, using suitable metrics, that awareness training works. The NCSC adds that you should count who reported an email, not only who clicked.

What to do about it. Report both, with the report rate rising and staying above the click rate. Keep board figures at team level. Naming individuals who clicked teaches people to stay quiet next time.

10. Open penetration test findings by severity and age

What it is. The open findings from your latest penetration test, by severity and days open. Load them into ticketing when the report arrives, so they age like any other fix.

When it matters. A customer's due diligence asks for your latest test and what is still open, and investors ask the same in a funding round.

What to do about it. Apply your scanner fix deadlines. Aim for no critical or high findings overdue by the next test, and have the tester confirm each fix.

How should you use this list of security metrics?

Start with five measures, set a target for each and report the trend rather than a snapshot. Give the board one page in risk language. Use the same figures in customer service reviews and investor updates, so every audience sees one set of numbers and they never disagree.

1. Start with five. Measures 1, 3, 5, 6 and 7. Add the rest once those run automatically.
2. Set a target and an action. Write down each target, its owner and what happens on a miss.
3. Report the trend. NIST SP 800-55 Volume 2 notes that tracking the same measures quarter to quarter tells you more than any single reading.
4. One page for the board, in risk language. "Two internet-facing systems sat past the patch deadline for three weeks" means more than raw scanner output.
5. Reuse the figures. Customers see the measures for their service, never raw vulnerability lists; investors see the trend.

What do UK boards expect from security metrics?

The UK Cyber Governance Code of Practice asks boards to require formal cyber reporting at least quarterly, with suitable metrics and agreed tolerances for each. The government and the NCSC published it in April 2025. The NCSC's board toolkit then asks whether effective security metrics are shared with the board.

The Code is written for boards of medium and large organisations and ties metrics to the cyber strategy and risk appetite. The NCSC Cyber Security Toolkit for Boards adds questions, such as whether new security controls trace to the risks they mitigate.

How do security metrics evidence ISO 27001 clause 9.1 and SOC 2 CC4.1?

The same measures double as audit evidence. ISO 27001 clause 9.1 asks you to decide what to monitor and measure, how, when, and who collects and evaluates the results. SOC 2 criterion CC4.1 asks for ongoing or separate evaluations showing controls are present and functioning. A dated, owned metric with a recorded review answers both.

Each measure also evidences an Annex A control: A.8.8 for measures 1, 2 and 10, A.8.5 for MFA, A.8.2 for privileged accounts, A.5.18 for leavers, A.8.13 for restores, A.8.16 for detection times, A.5.26 for incidents and A.6.3 for phishing reporting. Under the SOC 2 Trust Services Criteria, all ten feed your CC4 monitoring evidence.

Collect a figure once, from the system, and it serves the board pack, the customer review and the auditor's sample.

What are the common mistakes with security metrics?

The common mistakes with security metrics are counting activity instead of exposure, tracking too many measures, publishing dashboards nobody owns and setting targets with no action on a miss. Each produces numbers that look busy but cannot show whether exposure is falling.

• Activity counts. Blocked attacks and filtered emails rise and fall with the threat, whatever you do.
• Too many measures. Thirty metrics on a board slide means none get discussed. Keep the board set to ten or fewer.
• Dashboards nobody owns. A tool dashboard with no named owner drifts until nobody trusts it.
• Targets with no action. If a miss changes nothing, the target is a wish. Agree the response in advance.

Frequently asked questions