Your Security Awareness Metrics Are Lying to Your Board

Here is a conversation that happens in boardrooms all over the world every year, sometimes every quarter.

The GRC team or CISO presents the security awareness numbers. Training completion is at 94%. The simulated phishing click rate dropped from 6.1% to 4.8%. The board nods. A slide goes into the audit pack. The control is marked as effective.

And then, a few months later, the organization gets breached. Through a phone call. Through a text message. Through a weeks-long relationship a contractor built with an employee before asking for anything at all.

The metrics looked fine. The breach happened anyway. And the board, reasonably, wants to know how.

The 2026 Verizon Data Breach Investigations Report (DBIR) has an answer, and it is one that GRC leaders need to sit with. In 2025, the year covered by the 2026 report, the human element was present in 62% of all data breaches. That number was 60% the year before. It keeps climbing, quietly and steadily, while training budgets grow and completion rates hit record highs.

Something is broken. But it is probably not the training.

The Control You Are Measuring Is Not the Risk You Think You Are Managing

Training completion rates and phishing click rates are easy to measure. They produce clean numbers. They go neatly into a dashboard. Auditors like them because they are documented evidence that a control exists and is being operated.

But they are measuring the wrong thing.

What those metrics actually tell you is that employees sat through a module and that some percentage of them did not click on a fake email. What the metrics do not tell you is whether your organization is actually less exposed to human-driven attacks than it was last year. Those are different questions, and GRC programs that conflate them are giving boards a false picture of where the risk actually sits.

The DBIR makes this uncomfortably concrete. Phishing, the attack vector that most awareness training is designed to address, remained flat at 16% of all breaches in 2025. No improvement, despite years of training investment.

Yet pretexting, which involves an attacker building a relationship over time rather than sending a suspicious link, grew as an initial access vector and was specifically called out as a driver of high-profile ransomware cases this year.

Pretexting does not show up in your click rate metrics. It cannot be simulated with a phishing tool. And the countermeasure for it has almost nothing to do with training.

It has to do with process.

What Pretexting Actually Reveals About Your Control Framework

Here is why pretexting is important for GRC specifically, beyond the security team.

A pretexting attack succeeds when business processes are ambiguous or unenforced. The attacker, posing as an IT contractor, or a vendor, or a new colleague, and after a period of building a relationship with the target employee, asks that employee to do something. Reset a password. Approve a transfer. Grant temporary access to a system. The employee complies not because they were fooled by a phishing email, but because they had no clear process telling them how that request should actually work.

Who is authorized to request a credential reset, through which channel, and with what verification step? Who can approve an emergency wire transfer, and what does the approval chain look like? What happens when a vendor asks for elevated access to fix an issue remotely?

These are not security awareness questions. They are process and policy questions. They live in the control framework. And they fall squarely within GRC's domain.

A control framework that documents these processes, tests whether employees actually follow them, and monitors exceptions in something close to real time, is directly addressing the pretexting risk. No training module required. What is required is process clarity, control enforcement, and the visibility to know when something falls outside the expected pattern.

Most GRC programs have the documentation. The continuous monitoring piece is where the gap tends to be.

The Mobile Problem Your Dashboard Is Not Capturing

There is another finding in the 2026 DBIR that deserves attention from anyone responsible for reporting human risk to a board.

In phishing simulations, the successful click rate for mobile-centric attack vectors, meaning voice calls and text messages rather than emails, is 40% higher than for email.

Forty percent.

Your phishing simulation platform is almost certainly measuring email click rates. That is the metric in the dashboard. That is the number that goes to the audit committee. But the attack surface that is actually generating higher success rates for attackers is not email. It is the phone in your employee's pocket.

This is a control coverage gap that very few GRC programs have documented, let alone addressed. The risk register probably has an entry for phishing. It most likely does not have a separate entry for voice-based social engineering with its own control set, its own testing methodology, and its own measurement approach.

That gap between where the risk actually lives, and what the control framework covers, is exactly the kind of thing GRC is supposed to find and close. But you cannot find it if you are only looking at email click rates.

What Boards Are Actually Asking For

Step back for a moment from the mechanics of phishing and pretexting. Think about what a board is actually trying to understand when it asks about human risk.

They want to know whether the organization has meaningful controls over the actions that humans can take, that would expose the business to harm. They want to know whether those controls are working. And they want confidence that if something goes wrong, the control framework will catch it or at least limit the damage.

A 4.8% email phishing click rate does not answer any of those questions. It is a proxy metric for a narrow slice of one attack vector, and it tells the board almost nothing about the actual state of human risk across the organization.

What would actually answer the board's question is something more like: here are the high-risk human actions in our environment, meaning wire transfers, credential changes, privileged access grants, and similar. Here are the process controls we have built around each of them. Here is how often those controls were tested, and how often exceptions occurred. Here is how quickly exceptions were detected and resolved.

That is a risk and control story. It is also a monitoring story. And it is the kind of board reporting that GRC programs should build toward, because it is the kind of reporting that actually reflects how breaches happen.

The Measurement Problem is a GRC Problem

The DBIR team emphasizes in the Introduction something that is easy to gloss over. "The fundamentals still matter most." Clear visibility into assets and third parties. Disciplined patch management. Well-practiced response plans.

They are right. But the data in the same report makes a point the authors leave unstated. Fundamentals only protect you if they are enforced continuously. Not reviewed annually. Not assessed quarterly. Continuously.

The 2026 DBIR documented over 22,000 security incidents in its dataset. In case after case, the controls existed. The guidance had been published. The patches were available. What was missing was the operational discipline to verify, at any given moment, that those controls were actually in place, actually working, and actually covering the right scope.

That is the same problem hiding inside the 62% human element figure. The awareness training existed. The phishing simulations ran. The click rates looked acceptable. But pretexting was growing, mobile-based attacks were outperforming email by 40%, and the control framework had not kept up with where the risk actually moved.

Closing that gap is not a security team responsibility. It is a GRC responsibility. And it does not get closed by better training scores or more thorough annual assessments. It gets closed by treating human risk the same way modern GRC should treat every risk. As a live, continuous question, not a periodic one.

Breaches do not wait for your next review cycle. Your controls should not either.

--------------------

Data in this post is drawn from the 2026 Verizon Data Breach Investigations Report. The human element figure and mobile-centric phishing statistics are from page 12. Pretexting as an initial access vector is discussed on pages 12 and 16. The number of security incidents and what Verizon says about fundamentals is in the Introduction, page 5, and in a few additional places throughout the report.