Where cyber-insurance pricing breaks down
Cyber-insurance pricing often begins with a questionnaire. The applicant describes its security controls, and the insurer uses those responses, sometimes alongside broker information and an external scan, to assess risk and determine a premium.
The questions are familiar: Are critical systems patched promptly? Is multi-factor authentication enforced? Is sensitive data encrypted? Are backups protected and tested? Is there an incident-response plan?
These are important controls. But a questionnaire can only reflect what the organisation believes, understands or reports at a particular moment. It may not reveal whether a control is consistently applied across the environment, whether a public-facing system is exposed, or whether a recent change has introduced new risk.
That creates an information gap. If the information used to price a policy does not match the organisation’s real-world security posture, the difference may only become clear after an incident when both the insurer and the insured have the most to lose.
The answer is not to discard the questionnaire. It is to support it with relevant, observable technical evidence: a clearer view of the systems, exposures and controls that matter to cyber risk.
Why cyber losses can still be difficult to predict
Cyber insurance has matured quickly. As ransomware, business interruption, data breaches and supply-chain incidents have become more costly and more complex, insurers have strengthened underwriting requirements and organisations have invested more heavily in cyber resilience.
Even so, cyber risk is not static. An organisation’s exposure can change when a supplier is compromised, a cloud environment is misconfigured, a new system is connected, or an otherwise minor weakness combines with another to create a material vulnerability. These issues are not necessarily visible in a questionnaire or apparent from a point-in-time external scan.
For insurers, that can mean the information available at placement does not fully reflect the risk that emerges during the policy period. For insured organisations, it can mean their actual security maturity is not clearly recognised in the underwriting process—particularly where they have made meaningful investments in controls, monitoring and remediation.
A clearer view for both sides
Relevant technical evidence helps insurers assess cyber risk with greater confidence, while helping organisations demonstrate the security measures they have in place. It gives both parties a clearer basis for underwriting, pricing and productive conversations with brokers.
What “pricing on proof” means
Pricing on proof means assessing how a system behaves in practice—not relying only on what is stated in a form.
The definition
Consider a finance company that uses one third-party service to generate PDF documents. The document template is retrieved from a web address supplied by the customer. On its own, that may appear to be a reasonable feature.
The same company also uses another third-party service to process images. If an image address redirects to a different location, the service follows that redirect. Again, viewed separately, this may not appear high risk.
The risk appears when those components operate together. A customer could provide an address that causes the system to follow a request into internal services that should never be reachable from outside the organisation.
A standard scan may identify each component as low or medium risk in isolation, but it may not reveal how the components, permissions and network connections interact. A fuller technical assessment maps those relationships, identifies the potential attack path and shows where the exposure begins.
A questionnaire still has value: it records the organisation’s stated controls, policies and intentions. Technical evidence adds the missing view of what is operating in the real environment, so insurers and insured organisations can make decisions based on a more complete picture.
How separate components can create one material risk
A system can appear secure when its individual components are reviewed in isolation. A standard vulnerability scan may identify known issues in a library, application or cloud service, but it cannot always show how those elements behave when they are connected through the same workflow.
For example, a document-generation feature may retrieve a file from a web address supplied by a user. A separate image-processing component may follow redirects to retrieve linked content. Each function can appear reasonable on its own, but when both operate within the same request, an attacker may be able to influence the path the application follows and cause it to communicate with internal services that should not be accessible from outside the organisation.
This type of exposure may not appear on a public vulnerability list, and it may not be captured in an insurance questionnaire. It arises from the way components, permissions, inputs and network connections work together in a specific environment.
A broader technical assessment maps those relationships to identify realistic attack paths and the controls that can prevent them. For insured organisations, that means clearer priorities for remediation and stronger evidence before approaching a broker or insurer. For insurers, it provides a more complete basis for understanding the exposure they are being asked to assess.
Five things that matter to both insurers and insured organisations
Which vulnerabilities are genuinely reachable
A list of known vulnerabilities does not, on its own, show the level of risk. What matters to both the insurer and the insured organisation is whether an attacker can actually reach and exploit a weakness from outside the environment.
A technical assessment can distinguish between issues that require attention and exposures that present a realistic path to compromise. This helps organisations prioritise remediation before seeking cover, while giving insurers a more meaningful view of the risk they are being asked to insure.
What third-party code and dependencies are in use
Modern software depends on components, libraries and services developed by other organisations. These dependencies can introduce vulnerabilities, licensing obligations and supply-chain risk that neither the insurer nor the insured organisation may be able to see clearly from a questionnaire alone.
An up-to-date software inventory helps the organisation understand what it relies on and where action may be needed. It also gives insurers clearer evidence of how third-party risk is identified, managed and monitored.
How separate components can create one material risk
A system can appear secure when individual components are assessed in isolation. The more serious exposure may emerge only when two otherwise ordinary components, permissions or integrations interact in an unexpected way.
Understanding these relationships helps an insured organisation address weaknesses before they become incidents. For insurers, it provides a fuller picture of the real-world pathways that could lead to a claim.
Where operational disruption could occur
Cyber risk is not limited to unauthorised access or data loss. A failure in a critical system, integration or process can interrupt operations, delay customer service and create significant business-interruption costs.
Mapping how systems work together can identify single points of failure, fragile dependencies and recovery challenges. Organisations can use this insight to strengthen resilience; insurers can use it to better understand potential interruption exposure.
A clear record of risk and remediation
Both parties benefit from a clear, evidence-based record of the environment at the time it is assessed. It should show what was reviewed, the issues identified, the actions recommended and where remediation has been completed, the improvements made.
For an organisation, this provides a practical basis for discussing its security posture with brokers and insurers. For an insurer, it supports a more informed underwriting decision and creates a clearer record of the information considered when the policy was priced.
Talk to Codebridge about an evidence-based assessment of your software environment
Cyber risk cannot be reduced to a questionnaire, vulnerability list or point-in-time scan. Understanding how systems, code, dependencies and controls work together helps organisations address issues before seeking cover and helps insurers assess the risk.