Launching a cyber portfolio with thin data

The control cycle requires the problem to be specified, a solution developed, the outcome monitored, and the whole process set in its professional and business context. Here the problem is not simply ‘price a cyber product’; it is whether the insurer can enter a new line with an acceptable risk appetite, capital and reinsurance structure given very limited credible data. In development, I would define the target market, limits and exclusions, estimate frequency and severity from the 60 claims plus vendor and market data, add explicit loadings for parameter and model uncertainty, and test the plan against the assumed 55% loss ratio and 30% expense ratio. The average premium of £15,000 implies about 3,300 policies, so a small number of large claims could dominate the result. I would test the £50m premium plan against a 70–90% loss ratio and against a systemic cyber event.

The weakest part is the assumption that a vendor catastrophe model and 60 claims are sufficient for pricing and capital. The plan also assumes reinsurance protection that excludes systemic events, so the retained tail is not fully understood. I would not present the 15% ROE as a central expectation without a range and a clear statement of model risk.

The key risks are accumulation, systemic or cascading cyber events, silent cyber in property and liability policies, data quality, model risk, pricing inadequacy and reinsurance basis risk. The data are thin and probably biased: cyber endorsements on property policies will not represent standalone commercial cyber, and 60 claims are too few to estimate tail severity. I would reconcile the data, check definitions and claims coding, and use external market benchmarks only with adjustments for portfolio mix. I would commission independent validation of the vendor model, check its assumptions against the actual portfolio, and use it for relative accumulation and scenario analysis rather than as the sole pricing tool. For silent cyber, I would work with underwriters and claims to identify non-affirmative exposures, apply explicit affirmative or exclusion wordings, and quantify the possible accumulation across property and liability. I would set limits by sector and by single point of failure, and stress the portfolio for a cloud-provider outage or a widespread ransomware event. The reinsurance treaty should be tested for gaps, and capital should include a model-risk and systemic-risk loading.

I would recommend monthly monitoring of premium, policy count, average limit, broker concentration and claims, and quarterly monitoring of loss ratio, frequency, severity, rate adequacy and accumulation against risk appetite. The plan should compare actual experience with the pricing assumptions and with external cyber loss trends. I would set clear triggers in advance: for example, if the rolling loss ratio exceeds 70%, if a single event or sector accumulates above the board’s limit, if silent cyber claims emerge in non-cyber lines, or if reinsurance is not bound on the assumed terms. Triggers should prompt a review, not automatic exit.

If experience deteriorates, options include repricing, tightening wordings, reducing limits, increasing reinsurance, or exiting the segment. I would also require a post-launch review after 12 months, with an independent challenge of the model and the reserving basis. The board should approve the risk appetite and triggers before launch, and the monitoring should be reported to the risk committee so that commercial pressure does not override the agreed controls.