Security Metrics Have Always Been Broken. AI Made It Impossible to Hide

Why are security metrics broken? Because security's scope covers every system that touches company data, boards now ask "how safe are we?" continuously instead of quarterly, and answers get reported in tool language — CVSS scores, product names — instead of business risk. AI didn't create these gaps. It removed the time that used to hide them.

Every board meeting eventually arrives at the same four words for security: "How safe are we?"

Every CISO who hasn't automated the answer is buying time — not because they aren't diligent, but because the real answer lives across thirty siloed systems, ten spreadsheets, and tribal knowledge from two engineers who happen to be out this week.

That pause is the most expensive four seconds in your quarter. The board doesn't hear "let me be thorough." They hear "we're not sure." And where decisions get made fast, an unsure security program loses three things: funding, remediation support, and the benefit of the doubt when something breaks.

Here's what makes it worse: the metrics were already broken before AI. The quarterly review cycle just gave you time to work around it. Then AI compressed the timeline — threat actors pushing exploitation harder, the board consuming AI faster — and the question moved to weekly, then daily. The cover disappeared.

AI didn't break the metrics. It made the break impossible to hide.

Why are security metrics so hard to get right?

Security metrics break for three structural reasons: an impossibly broad measurement scope, a reporting cadence that collapsed from quarterly to continuous, and a translation layer that reports tools instead of risk. Each one is covered below.

Why is security's measurement scope bigger than any other department's?

Security is one of the only functions whose data lives in every system, not one or two. Ask the CRO how sales is doing: Salesforce. Marketing has HubSpot and Google Analytics. Engineering has GitHub and Jira. Finance has NetSuite.

Security has... all of them.

Everything that touches company data is in scope for security: workstations, servers, SaaS apps, APIs, code repos, IoT and OT devices, machine identities, guest users, even personal devices. The business adopts new technology; security inherits the risk. Answering "how safe are our devices?" means stitching asset state, threat context, applied controls, and entitlements across multiple systems — and that's just one question.

Risk is also multi-dimensional. A vulnerability only becomes urgent when you layer in context: Is this asset publicly exposed? Does it hold crown-jewel data? Is endpoint protection missing or outdated? Does the user have admin access to critical systems? That answer only emerges from cross-system context — and most teams are still assembling it by hand.

How often does the board now ask "how safe are we?"

The cadence has collapsed from quarterly to continuous. What used to be a once-a-quarter review is now a question that can land any day of the week.

The threat timeline is compressing. Events like [Mythos — confirm exact name + date] shortened the window between discovery and exploitation. The board is consuming AI faster and reading threat headlines sooner than you can answer them with metrics — and that gap becomes distrust. The quarterly cadence was never great. Now it's a liability.

Why doesn't the board understand the security metrics they're given?

Only 64% of CISOs say their board sees eye-to-eye with them on cybersecurity. A 20% decline since 2024. (Proofpoint, Voice of the CISO, 2025). That gap lives almost entirely in the translation layer.

When the CFO reports up, they don't walk the board through balance-sheet mechanics or tax strategy. They talk cash in the bank, whether we're making more or less, and where to cut. That's the strategic signal leadership needs; the fine detail stays insulated. Security's goals reduce just as cleanly — mitigate risk, stay compliant, limit financial impact — but siloed tooling leaves you reporting CVSS scores and tool names instead, adding cognitive load the board never signed up for.

Metrics land through the ears of the listener. Fail here and you create bias that damages security culture and erodes the trust you need to get anything done.

How do you fix security metrics reporting?

There are three moves — adopt business-language metrics, make risk transfer explicit, and build continuous feedback loops. But first, accept two things about the environment:

• Security teams grow linearly. Security work grows exponentially. The assets to protect keep multiplying across cloud, SaaS, legacy systems, shadow IT, and now AI. Vulnerabilities, patching backlog, and incidents grow with them while SLAs compress. Your team, budget, and technical capacity don't scale at the same rate, so the gap widens every year. Automation — and making security a team sport — aren't optional. They're the only way the math works.

• Security is a zero-sum game for budget. Every dollar you ask for competes directly against sales, marketing, R&D, headcount, M&A — and now tokens, because the company has to pay for inference too. Each of those areas has a compelling story. Security's story has to be clearer, faster, and better grounded in business language than it used to be.

How do you report security in business language the board understands?

Report security in the language of the listener's goals — mitigate risk, stay compliant, limit financial impact — never in the language of your tools. The goal is to reduce cognitive load for the person receiving the message. Two frameworks help:

Henrik Parkkinen's KPI/KRI/KCI model organizes cybermetrics into three altitudes:

• KPIs (Key Performance Indicators): above the fold for the board — governance, incidents, awareness, SLAs — are we safe, yes or no?

• KRIs (Key Risk Indicators): the why beneath — which risks are driving that performance, and at what levels

• KCIs (Key Control Indicators): practitioner-level — MFA coverage, endpoint completeness, the controls being run to address risk

Parkkinen's other rule: use fewer metrics. Keep only a few per level. Less cognitive load means better decisions — individuals see their contribution, leaders see risk, the board sees performance.

Gartner's Outcome-Driven Metrics (ODMs) link operational security metrics to the business outcomes they support. Gartner provides a coverage checklist of ~16 security functions to track — a useful sanity check on what to measure.

More sophisticated models exist. Factor Analysis of Information Risk (FAIR) provides quantitative cost modeling for risk decisions, introducing Loss Event Frequency (the % chance of an incident per year) and Loss Magnitude (in dollars). It can be complex to deploy — nail the fundamentals first, before moving to sophisticated metrics.

How do you transfer security risk back to the business?

Make the risk you aren't funded to fix explicit — otherwise you become the silver bullet, and everything that breaks is security's fault whether or not security was ever funded to prevent it. There will always be more risk than you can fix. Nobody will hand you a metric that holds them accountable; you have to build it. Two mechanisms do this.

Gamification. Show every team's open security findings, with owners, in a simple, comparable package. Departments are competitive — when they can see their risk posture relative to peers, they self-correct. Orphaned findings surface on their own, and SLA violations become a team conversation. You don't have to trigger any of it; the visibility does the work.

The metrics that make this real: mean time to ownership and ownership rate. They tell you whether the system is working without chasing anyone down. This also shifts how security is perceived — from the department that says no, to the one that asks how do we do this responsibly?

What is a Protection Level Agreement (PLA), and how is it different from an SLA?

A Protection Level Agreement (PLA) is a commitment to leadership: for this level of funding, I deliver this level of protection. Unlike an SLA — which measures your team against an internal target — a PLA puts the funding-versus-protection trade-off in the business's hands.

Take patching critical assets as a hypothetical. The floor: 14 days, $100/year, P4 tickets and optimism — too risky given how fast exploitation timelines move. The ceiling: $1M, all P1, all hands — which the business can't fund. So you meet in the middle: $100K, P2 tickets, a 7-day PLA.

Now the line is clear. An incident before day 7 is residual risk of a business decision — the company chose $100K over $1M. An incident after day 7 is a failure in execution.

Benchmark that PLA against similar companies and the investment becomes defensible. You're not dodging accountability — you're giving your board and investors the instruments to stand behind the decision.

How do you answer "how safe are we?" continuously instead of quarterly?

If the question is asked continuously, the answer has to be ready continuously — which means compiling the metrics that matter every day, not scrambling every quarter. Treat it as an engineering discipline: think PDCA (Plan, Do, Check, Act). Compile daily, see what's deviating, and correct before you're asked.

Every manual hand-off, every silo, every place a human has to stop and interpret raw data is latency you can no longer afford. And answering fast doesn't just satisfy the asker — it turns them into an agent of security, because the very next thing they say after a clear answer is "how can I help?" That shift from interrogation to collaboration is what a well-built feedback loop produces.

How do you measure AI risk across your environment?

AI risk enters from two directions at once, so your metrics have to capture both. To answer "how safe are we?" today, you need to instrument the AI dimension directly — the tools you're actively adopting and the AI features appearing inside software you already own.

Horizontally: your company is actively adopting new AI vendors and tools — cloud tools, agentic platforms, AI-native SaaS. Agentic execution running without a human in the loop can hallucinate and can route sensitive data to unintended destinations. Every new adoption expands the surface.

Vertically: the assets you already own are expanding into AI. Software you already approved and SaaS you already deployed are adding AI functions you didn't select — and those functions may run automatically.

The questions to instrument:

Which SaaS applications in my environment have AI functions?

Start with an inventory of which approved and deployed applications now include AI capabilities — this is the base layer everything else builds on.

Which of those are assistive, human-in-the-loop, or fully autonomous?

Classify each AI function by autonomy: assistive (humans in full control), agentic with a human in the loop, or agentic autonomous (executed without approval or oversight). The autonomous category is where the risk concentrates.

Which AI providers are my applications using?

Map which third-party model providers your applications route to. If you don't want context bleeding to certain providers, confirm you're actually enforcing that — not just assuming it.

Where is shadow AI adoption happening?

Look for tools expensed but not in your SSO, or installed on managed devices without an enterprise license. This is more findable than it looks: cross-reference what's installed on devices against what's licensed and approved, and shadow AI surfaces by elimination. The asset CrowdStrike doesn't report but three other systems see daily — that's the signal.

What's the first step to better security metrics? Crawl, walk, run

The first step is always the same: eliminate silos. Every downstream improvement depends on having assets, risks, and AI usage visible in one place first.

1. Crawl — eliminate silos (assets, risks, and AI). Kill the visibility gaps that block a fast feedback loop, and establish ownership rules so other teams carry their share. This removes the single biggest time-sink. Do it first; everything downstream depends on it.

2. Walk — deliver the language of risk. Build dashboards in the language of dollars, KCIs, KRIs, PLAs, and ODMs — then test them on the actual consumer. The bar isn't a polished slide; it's moving your listener from "tell me more…" to "how can I help?" Include AI exposure: here's how the company is adopting AI, here's what's running without humans in the loop, here's the risk we're carrying.

3. Run — programmatic risk reduction. Turn hand-offs into rules. Make dashboards live and daily with deltas. Invest in proactive security that catches vulnerabilities before they surface. The goal: zero mean time to ownership, zero mean time to risk transfer, hardening as the default.

Where does an asset intelligence platform fit — and where doesn't it?

These principles work on any stack, because they're fundamental problems of security, not product problems. What a platform changes is the crawl phase: eliminating silos is dramatically easier when your data already lives in one place.

An asset intelligence solution like Axonius gives you a single view of 40+ asset types through 1,400+ integrations and 150+ exposure sources across your infrastructure — AI usage included. That single view is what lets you automate the cyber metrics that matter, all from the same place. (platform tour)

Frequently asked questions

What are security (cyber) metrics? Security metrics are the measurements a security team uses to show how well it's managing risk — from board-level indicators like incidents and SLA performance down to control-level measures like MFA coverage and endpoint completeness. Good metrics translate technical activity into business risk.

What's the difference between KPIs, KRIs, and KCIs? KPIs (Key Performance Indicators) show board-level performance — are we safe, yes or no? KRIs (Key Risk Indicators) show the risks driving that performance. KCIs (Key Control Indicators) show practitioner-level control health, like MFA coverage. Together they let each audience see the altitude that's relevant to them.

What is a Protection Level Agreement (PLA)? A PLA is a commitment that says, for a given level of funding, security delivers a defined level of protection — for example, patching critical assets within 7 days for $100K/year. It makes the funding-versus-protection trade-off an explicit business decision.

How is a PLA different from an SLA? An SLA measures your team against an internal delivery target. A PLA frames protection as a function of funding and puts the trade-off in leadership's hands, so residual risk is owned as a business decision rather than a security failure.

How do you measure shadow AI? Cross-reference what's installed on managed devices against what's licensed and approved. Tools that are expensed but missing from SSO, or running on devices without an enterprise license, surface by elimination.

How often should you report security metrics to the board? The practical cadence has shifted from quarterly to continuous. Compile the metrics that matter daily so you can answer "how safe are we?" whenever it's asked, rather than only at scheduled reviews.

What's the first step to better security metrics? Eliminate silos across assets, risks, and AI usage. A fast, trustworthy feedback loop is impossible while the answer is scattered across dozens of systems, so consolidating visibility comes first.

What does answering confidently actually look like?

The board can see the gaps now. That's the forcing function.

The next time someone asks how safe you are, you choose which version of yourself answers: the one who pauses, buying time for a system that was never quite working — or the one who turns the screen around, shows the number, points to the PLA the business signed off on, and says:

"Here's our surface, here are the risks we're carrying including AI, here are the risk owners, and here's how you can help."

You don't have to fix everything at once. Pick one move and ship it. Start with the crawl: kill one silo. That's the whole thing beginning to work.

To see what Axonius does in real life, get a demo.