Cyber underwriting platform: a six-week go-live from your guidelines

A cyber underwriting platform is the software in which a cyber submission is read, graded against the carrier's guide, conditioned and documented, so that the underwriter decides from one screen instead of five documents. Going live on one is less a software project than a rules project: the platform has to grade by your minimum-controls guide, stop at your score floor, refer by your authority rules and write subjectivities in your approved words. For Botminds' Cyber Underwriting Risk Assessment the plan takes six weeks: two to load and confirm the rules, two to prove them on closed submissions, one for governance, and one running in parallel on live business before the switch. The six weeks are a plan, not a measured result, and the inputs below decide whether it holds.

The guide is written for the head of cyber who will own the rules, the underwriting operations lead who will run the project, and the IT and model-risk colleagues who will approve it. The examples use a fictional sample carrier, Corvane Specialty, whose guide is at version 14.

What is a cyber underwriting platform, and what should it hold?

It holds four things a cyber desk otherwise keeps in documents and heads. The minimum-controls guide: which controls are eligibility, required or priced, by revenue band. The grade rules: what counts as partial EDR coverage, how old a scan may be, when leaked credentials matter. The authority rules: the score floor, the referral line, the limit an underwriter may bind. And the wording library: the approved subjectivities and conditions, each with a reference.

A platform that holds these as settings can apply them the same way to every submission and show which version applied. A platform that holds them as prompts or as a vendor's defaults cannot. The test is simple: change one threshold, and the platform should re-grade the open submissions under the new version and keep the old grades with the old version.

The minimum-controls guide, by revenue band, owned by the head of cyber

What do I need to set up cyber underwriting software? The inputs for week one

Six inputs, and most delays come from the last two. The current application and ransomware supplement forms, so the reader knows each question's number and scope. The minimum-controls guide in whatever form it exists today, even a memo. The subjectivity and condition wordings underwriters actually use, collected from recent quote letters if there is no library. The authority matrix and referral rules. The output format of your outside-in scan provider. And a set of closed submissions, with the documents as they arrived and the decisions as they were made.

The closed set is the one to start collecting first. Forty to sixty submissions from the last two quarters, mixing quoted, declined and referred files and several industries, give the back-test enough contradictions to be meaningful. Where a written guide does not exist, week one is also when the head of cyber writes the first version; the back-test in week three will show quickly where it is ambiguous.

Can cyber underwriting software use our own guidelines?

It should use nothing else. In week two the guide becomes settings: each control's treatment by revenue band, the grade rules, the score floor and the referral triggers. The sample carrier's settings show the shape: a ransomware supplement required above $25 million of revenue, a partial grade for EDR coverage under 98%, a rescan for any scan older than 30 days, a control score floor of 60, referral to the head of cyber for a score under 50, a limit over $5 million or any overridden contradiction, and default due dates of 30, 60 or 90 days for conditions after binding.

Every one of those numbers is a choice the carrier can defend, and none is a vendor's default. The head of cyber signs off the loaded settings at the end of week two, and from then on every change is a new version. That is also what makes the platform's grades usable later: a claim on a 2027 policy can be traced to the guide version that graded the submission in 2026.

Settings: what every cyber submission is read against, versioned

How do you validate underwriting software? Back-test on files you have already decided

Validate it on closed submissions, against your own underwriters' decisions, before it sees a live one. In week three the platform reads and grades the closed set with your grades held back. In week four the comparison is counted control by control: contradictions both found, contradictions only the platform found, and contradictions only your underwriters found. Each disagreement is read by a senior underwriter and sorted into one of three causes: the platform misread a document, the guide was ambiguous, or the original decision missed something.

The second and third causes are the useful surprises. An ambiguous guide (does "MFA on all remote access" include a vendor's remote support tool?) is fixed by a new version, not by tuning the software. A missed contradiction on a bound policy is a finding for the head of cyber, and sometimes a reason to look at that policy before renewal. Only the first cause is the platform's to fix, and the re-run at the end of week four shows whether it was.

Time how long the underwriters spend reviewing the platform's output on the same files. That number, not the vendor's target, is what goes in the business case set out in the guide to automating the cyber underwriting process.

Who is responsible for an AI underwriting tool? The insurer, in every regime that has said

The insurer is, and week five exists because of it. The UK Prudential Regulation Authority, in its supervisory statement on cyber underwriting risk, is blunt: "Regardless of any external input or advice obtained in relation to such risks, responsibility and accountability for this risk remains with the firm" (PRA SS4/17, 4.3). The European insurance supervisor makes the same point about models of every kind: insurance law already requires proportionate governance of any mathematical model an insurer uses, whether or not it counts as AI (EIOPA Opinion on AI governance and risk management, 2025; quoted in algorithmic underwriting insurance).

In New York, the Department of Financial Services' July 2024 circular on AI in underwriting and pricing leaves responsibility for vendor-built tools with the insurer and expects an inventory of the AI systems in use, with documentation of each; it is read in full in New York's Circular Letter 7 and the AI inventory. Many U.S. jurisdictions have also adopted the NAIC's model bulletin on insurers' use of AI, set out in the NAIC AI bulletin requirements.

What happens in the governance week of a cyber underwriting platform go-live

Week five turns the back-test into the documents a reviewer needs. The tool goes into the carrier's AI or model inventory with its purpose, owner and limits written down: it reads and grades, and it never quotes, binds, declines or contacts an insured. The back-test results go on file with the disagreements and how each was resolved. The loaded guide version and wording library are signed by the head of cyber. Model risk or internal audit writes up its review and the conditions on use, such as a quarterly sample of grades checked by a senior underwriter.

Two design choices make this week shorter than it sounds. Every grade cites both sides, so a reviewer can check any row without asking how the tool reached it. And every action is attributed: the drafted note lists which agent did what and which person decided, which is the evidence of human control a regulator's AI program expects.

The underwriting note: every statement cited, the referral check computed, a person signs

Week six: a parallel run, then the switch

The last week runs the platform on live submissions alongside the desk's normal process. Underwriters read the platform's scorecard and their own file side by side, decide as they always would, and note any disagreement. When a week passes without a disagreement the back-test did not predict, the desk switches: the scorecard becomes the starting point, and the underwriter's review of it becomes the process.

The plan slips in predictable places. Closed submissions that cannot be found with their original documents; a guide that exists only in a senior underwriter's head; a model-risk queue measured in months. None of them is a software problem, and all of them are cheaper to solve in week one than in week five.

Where Cyber Underwriting Risk Assessment fits as a cyber underwriting platform, and where it does not

It is the reading, grading and drafting layer of a cyber platform. It reads the five documents a mid-market cyber submission can carry, grades fifteen controls against your guide with both sides cited, drafts subjectivities from your library and drafts the note. It does not run the outside-in scan (it reads your provider's), rate the risk (your rating plan does), or issue the policy (your policy system does). The scan matcher's place in the chain is set out in the guide to cyber insurance security scan tools.

It is a fit where submissions arrive as documents, where the guide can be written down, and where the carrier wants every grade defensible to a referral reviewer, an auditor or a regulator. If your cyber book is mostly small accounts quoted from a short online form with no scan or supplement, the reading this solution automates barely exists, and a rules-based quote engine is the better buy. New York's framework for cyber insurers, which expects a data-driven assessment of each insured, is turned into checks in NYDFS cyber insurance requirements.

Questions people ask

How long does it take to implement underwriting software?

For a reading-and-grading layer like this one, Botminds plans six weeks. The schedule depends less on software than on having a written guide, a wording library and a set of closed submissions ready in week one.

What does NYDFS say about AI in underwriting?

Its July 2024 Circular Letter 7 leaves insurers responsible for AI tools built or run by vendors, expects an inventory and documentation of the systems in use, and asks for unfair-discrimination testing before a system goes into production and regularly afterwards. Its examples centre on consumers and protected classes, but the responsibility principle is general.

Do we need a data scientist to run a cyber underwriting platform?

Not for this kind of platform. The rules are underwriting rules, owned by the head of cyber, and changing them is a settings change with a version. Model risk reviews the tool once in week five and then samples its grades.

What if our minimum-controls guide is not written down?

Then week one includes writing version one, drawn from recent quote letters and the senior underwriters' practice. It is worth doing anyway: in New York, an insurer's practice on similar risks is admissible when the materiality of a misrepresentation is in question.

Can the platform run alongside our current underwriting system?

Yes. It reads the submission documents and returns a graded scorecard, drafted wording and a drafted note; the quote and the policy stay in the systems you already use, and the signed note can be filed with them.