A clean incident history is one of the first metrics cyber insurers reach for when assessing an organization's security posture. Fewer incidents, the logic goes, signal lower risk. But that logic has a gap, and a quiet record may show only what an organization detected and chose to disclose. It says nothing about what reached its systems without being caught.
Ashu Savani, co-founder of TryHackMe, a browser-based cybersecurity training platform, argues that a clean incident record is a poor proxy for cyber readiness. Here, he outlines what risk managers, insurers, and security teams should be examining instead.
The Payment Card Industry Data Security Standard (PCI DSS), created by major card networks to set baseline security requirements, establishes a principle worth borrowing. A low finding count on a security assessment is rarely proof of genuine security. More often, it means the assessment was too narrow to catch what was there.
Savani applies that logic to incident history as an underwriting signal.
"A clean record can mean real resilience, but it can just as easily mean an organization scoped its testing narrowly enough that nothing surfaced, quietly downgraded the severity of what it did find, or simply didn't report what happened," he said.
Savani points to detection as the structural gap that compounds the problem. An organization's incident count, he argues, is bounded only by what its monitoring catches. A breach that goes undetected cannot be disclosed. An insurer then reads a clean record with no way of knowing whether security held or monitoring failed entirely.
"You can't disclose an incident you never saw," Savani said.
That creates a structural problem in underwriting. A low incident count treated as a reliable low-risk signal rewards organizations that may have kept counts low for the wrong reasons. A clean record may say more about monitoring quality than about an organization's actual cyber readiness.
The threat Savani describes isn't a more skilled attacker. It's a less skilled one with better tools. Large language models (LLMs) have made deep platform expertise available on demand, at any point in an attack, on almost any enterprise system.
Savani's team encountered a case that illustrated this. An attack opened with the kind of sloppy moves associated with a low-skill operator. Without warning, the same attacker showed the fluency of a long-term platform insider and moved toward fraud execution.
"We debated whether this was an initial access broker handing off to a more advanced buyer," he said. "Forensics confirmed it was the same person the whole way through."
Savani argues that a general-purpose AI model will answer how Society for Worldwide Interbank Financial Telecommunication (SWIFT) messaging works or how a customer relationship management (CRM) system is built. Those are technical, publicly available questions rather than requests for hacking assistance, and the model has no reason to refuse them. The threat this creates for organizations is already drawing warnings from intelligence agencies across the US, UK, Australia, Canada, and New Zealand.
"An attacker no longer needs years on a given platform to operate on it effectively," he said. "They can become a passable expert on demand, mid-attack, on almost any enterprise system, however specialized."
Savani draws a distinction between how different threat actors use this capability. Reconnaissance-focused groups use AI to understand a target quietly before they move. Ransomware and e-crime groups skip the patience and use it to automate and scale.
"Organizations and employees hand over an enormous amount of useful information for free, on social media or on corporate pages, so attackers often aren't digging so much as stumbling into it," he said. "AI has removed the skill and effort ceiling that used to cap what one attacker could do."
The problem with most cyber risk assessments, Savani says, is that they measure presence rather than performance. "Start from the fact that insurance wants risk to sort into neat, countable boxes, and preparedness doesn't sort that way," he said.
The distinction he draws is between attestation and validation. "Attestation is an organization telling you it has six domain admins. Validation is showing how it got to six."
The same test applies across any control, Savani argues. Are the firewall rules checked or just written down, and are the detection rules tested or just documented in a questionnaire? The answer tells you whether a program is working or merely present.
Snapshot assessments make this worse, he says. A single measurement tells you what an organization has at one point in time. Two or more measurements over time show whether its programs in exposure management, incident response, and insider threat are actually improving.
"Think of it like the difference between browsing listing photos of a house and walking through it room by room," Savani said. "A better underwriting model has insurers doing the walkthrough directly.
In practice, he argues, that means insurers sitting in on tabletop exercises and checking whether a penetration test covers what it claims to cover. Taking a report at face value is the old model.
"There's a version of this that already exists elsewhere in insurance," Savani said. "Commercial insurers install sensors on a client's equipment and offer a lower premium in exchange for the data, or car insurers who lower your rate if you let them see how you actually drive. Cyber insurance could work the same way, incentivizing transparency and proactive capability validation."
Strong organizations with few live incidents face a paradox, Savani says. The better the controls, the less practice the team gets under pressure. That leaves less real-world evidence that the response actually holds up.
"Mature teams get around this by assuming breach," he said. "They run live exercises where certain controls are deliberately switched off, and the team has to respond from that point on as if it were real. It isn't the same as a genuine incident, but it's the closest thing available, and it's how strong programs build practice without waiting for an attacker to hand it to them.
"The organizations we worry about are the ones that skip this step, where confidence rests entirely on the controls holding, and gets tested for the first time on the day one of them doesn't," Savani added.
Genuine cyber readiness, Savani argues, is not a binary state but a scale. At one end sits a basic tabletop exercise. At the other is a full organization-wide simulation that tests technical response, business continuity, and disaster recovery, and whether the business can keep functioning while all of it is happening.
Organizations don't need to start at the top of that scale, according to Savani.
"The entry point is three things. Do responders actually have the skills the plan assumes they have? Do the plan's assumptions hold up once tested, rather than just read well on paper? Can the workflow survive contact with a real incident?"
That gap between what looks ready and what is ready is the only thing worth measuring, he adds.
"Training isn't the same as being ready," Savani said. "A control being deployed isn't the same as that control working. Readiness is whatever is left once you strip out the assumptions and actually test the plan under pressure."
