What is wrong with the way prices are set today
Almost every cyber policy written today is priced from a form the customer fills in about themselves. Sometimes there is an outside scan and a note from the broker as well. The customer ticks the boxes: yes updates are installed quickly, yes two-step login is in place, yes data is scrambled, yes a plan is written for when something goes wrong. The insurer puts them in a price band, adjusts for their industry, their size and their country, and out comes a premium.
This works fine when the form matches reality. When it does not, the insurer finds out only after something has gone wrong and the claim is already on the desk. There is no warning in between.
It gets worse. Customers now know which answers make the price go down. Brokers help them word the answers carefully without actually lying. So the form reveals less every year, and it is still the main thing prices are set on.
Why the losses keep coming as a surprise
Cyber cover has been through a rough ride. In the early 2010s, few people bought it and few people claimed, so it looked easy. In the late 2010s, criminals turned ransomware into an industry and the claims poured in. In the early 2020s, prices shot up to catch up. Prices have settled since then, but not to a level anyone is comfortable with.
Here is the reason the losses keep surprising insurers. The events that cause the big claims are exactly the ones nobody could see when the price was set. A supplier gets attacked. Two harmless-looking pieces of code turn out to be dangerous together. A cloud setting is left open by mistake. The customer did not know. The scanner did not find it. The form did not ask.
The trap
The claims that hurt insurers are, by definition, the ones nobody priced for. Adding another question to the form only protects against last year’s problem. Looking at the actual software is how insurers break out of that loop.
What “pricing on proof” means
It means one simple thing, and the test for whether a firm really does it is straightforward.
The definition
A finance company uses one third-party component to generate PDF documents. The document design is retrieved from a web address supplied by the customer. On its own, that function may appear reasonable.
The company also uses another third-party component to process images. If an image address redirects elsewhere, the component follows that redirect. On its own, that may also appear reasonable.
The risk emerges when both components operate within the same request. A customer may be able to provide an address that the system follows, causing the server to reach internal services that should not be accessible from outside the organisation.
Each component may receive only a medium or low-risk rating in a standard scan. The serious issue appears only when the components, permissions, and network connections are assessed together. Mapping the complete system reveals the attack path and identifies the precise point where it begins.
This does not replace the form. The form still shows what the company intends to do and what rules it has written down. The measurement shows what is actually there. Price on both, and the nasty surprises get much rarer.
Five things insurers need and do not get today
Which holes an attacker can actually reach
Most security reports list every known hole in the customer’s software. Almost none identify which of those holes an attacker can reach from the internet. That is the part that matters. A hole nobody can get to is not going to cost the insurer money. Most scanners cannot tell the difference.
An up-to-date list of borrowed code
Every software company builds on code written by other people. That list is the supplier risk register. Almost no company keeps it current, and almost no insurer asks for it. Attacks that come in through a supplier now cause some of the biggest claims in the market. This is a serious gap.
Problems caused by two parts working together
In CodeBridge’s work for insurers, this is the single biggest source of serious findings. Two pieces of code, each safe on its own, become dangerous when they meet. Section 5 explains it with an example.
How the system falls over
Cyber claims are not only about break-ins. A big share of the money goes on business interruption: the customer’s system stops working and they lose trading days. That usually comes down to how the software was built. Code that retries forever when something fails. Jobs with no time limit. Slow steps sitting right in the middle of the critical path. This can be priced, but only if someone looks.
A paper trail that survives the claim
When a big claim lands and the reinsurer has to pay, they will ask how the risk was priced. So might the regulator. A clear record of what was checked protects the insurer, and it protects the reinsurer too. Pricing from a form alone leaves almost nothing to show.
Two safe parts, one dangerous result
Some of the worst problems come from two pieces of code that are both fine on their own. Put them together in the same place and they open a door. No public warning list mentions them, because they are unique to that company. No scanner sees them, because scanners look at one file at a time. And a person will not see them either, unless someone has mapped how the whole system connects.
The definition
A finance company wanted $50 million of cyber cover. Their software used one piece of borrowed code to make PDF documents. It fetched the document design from a web address the customer typed in. On its own, fine. It used a second piece of borrowed code to handle images. If a web address pointed somewhere else, it followed it. On its own, fine.
In one part of the system, both ran on the same request. That meant a customer could type in a web address, get it followed, and reach the company’s own internal systems from the inside.
The company’s own scanner had rated both files “medium risk” or lower. No public warning list had this combination on it. CodeBridge found it, the customer fixed it, and the policy was written at 15 percent above the price the form alone would have produced. Twelve months on, no claim.
This is the difference between a defensible price and a guess. If the firm doing the risk checks cannot explain how it finds this kind of problem, it is handing over scanner output and calling it a full review.