For the renewal file
Twelve controls, eleven you can prove yourself
A carrier checks twelve controls at renewal. For eleven of them the evidence is a file you or your IT provider can pull this week. For one of them the evidence is a signature, and it cannot be yours. In Coalition's 2025 claims data, 58 percent of incidents were email compromise or payment fraud, which is why two of the twelve rows below belong to finance rather than IT.
What a carrier means by evidence
An underwriter is not looking for a policy that says you will do something. They are looking for a record that you did it, with a date, generated by a system rather than typed by the person filling in the form. An export from your identity provider is evidence. A line in a security policy saying multi-factor authentication is required is not.
Where you cannot produce the artifact, write the gap down in plain words rather than rounding the answer up. The forms themselves explain why. Cowbell's application closes with Misrepresentation of any material fact in this Application may be grounds for the rescission of this Policy. and requires the declaration to be signed by the undersigned authorized officer of the organisation (Cowbell Cyber Risk Insurance Application, Prime 250). That is the sentence doing the work. An answer you cannot evidence is not a small administrative problem, it is a representation, and it is made by an officer of your company.
The register
Work down the evidence column and put the artifacts in one folder before the application arrives. Every item in that column is a file with a date on it. The "who produces it" column is who can generate the artifact, not who is accountable for the control.
| Control | What the application is asking | Evidence that satisfies it | Who produces it |
|---|---|---|---|
| 01 Multi-factor authentication | Whether it is enforced on email, on remote access and on every administrator account, and which factor you use. | A dated export from your identity provider showing enforcement by account group, with the exceptions listed rather than rounded away. | You or your IT provider |
| 02 Endpoint detection and response | Whether it runs on every endpoint and every server, and who is watching it outside business hours. | A console export giving coverage as a count of devices, not a percentage, plus the monitoring hours written into your provider contract. | You or your IT provider |
| 03 Backups you have restored from | Whether backups are isolated from production, and when you last restored from one. | The restore test record. Date, what was restored, how long it took, who ran it. | You or your IT provider |
| 04 Separated administrator accounts | Whether admin accounts are separate from daily-use accounts, and how many people hold them. | A privileged account list with an owner against each one and the date it was last reviewed. | You or your IT provider |
| 05 Patching and end-of-life systems | Your patching cadence, and whether anything the vendor no longer supports is still running. | The latest scan summary, plus a named owner and a date against every unsupported system still in use. | You or your IT provider |
| 06 Email authentication | Whether SPF, DKIM and DMARC are published and enforced on your sending domains. | Your DNS records and your DMARC policy value. An underwriter can check this one from outside without asking you, so answer it accurately. | You or your IT provider |
| 07 Awareness training and phishing tests | Whether staff are trained, how often, and your click rate on the last simulated phishing run. | A completion report broken down by department and the result of the last simulation, both dated. | You |
| 08 Remote access paths | How people reach internal systems from outside, and what authentication sits on each path. | A list of every remote path with its authentication beside it. Remote desktop exposed straight to the internet is the answer that ends applications. | You or your IT provider |
| 09 Payment and bank detail verification | Whether a payment instruction or a change of banking details is confirmed on a second channel before money moves, and above what amount. | The written payment authorization procedure, with the callback rule and the threshold in it, and something showing it is followed. | Finance |
| 10 Vendors and outsourced IT | Who else can reach your systems, and what your provider is contractually responsible for during an incident. | A provider list showing what each one can reach, and the incident clause out of the contract. | You and your IT provider |
| 11 A written incident response plan | Whether you have one, who is named in it, and when it was last updated. | The plan itself, dated, with named roles and contact details that do not depend on company email still working. | You |
| 12 A tested incident response plan | When you last tested it, what scenario you used, who took part, and what changed afterwards. | A dated report naming the scenario, the participants by role and the findings, signed by whoever ran the exercise. | An outside witness |
The question, as the applications put it
Row eleven and row twelve are two different questions, and the forms separate them on the page. Beazley's Canadian application asks whether you have an incident response plan addressing network incidents and data breaches, then gives two tick boxes: Have a plan and Tested in last year (Beazley Cyber Application, Canada). Two boxes, two different pieces of evidence, and only one of them is in your filing cabinet.
Cowbell folds both into one line. Its question asks Does the organization have an incident response plan, set off mid-sentence by tested and in-effect, and continuing setting forth specific action items and responsibilities for relevant parties in the event of a cyber incident or data breach matter? (Cowbell Cyber Risk Insurance Renewal Application, Prime 250). One tick, two claims.
Why the last row is different
Eleven of these are artifacts your systems already generate. You export them, date them, file them. The twelfth is not an artifact. It is an account of something that happened in a room.
You can write down the date, the scenario and the findings. What you cannot do is be the independent person who confirms any of it happened. That is not a comment on your integrity and it is not a rule anybody invented to sell services. It is the same reason a company does not audit its own accounts.
The Canadian baseline has the same gap, from the other side. The Canadian Centre for Cyber Security's baseline controls for organisations with fewer than 500 employees ask for a written incident response plan: Organizations should assume that cyber security incidents will occur and have a plan on how to respond and recover from them. (Canadian Centre for Cyber Security, Baseline Cyber Security Controls for Small and Medium Organizations V1.2). It does not ask you to test it. Your carrier does. Those are two different questions and only one of them needs somebody else in the room.
Two decisions, before the application arrives
Collect the eleven artifacts into one folder, dated, before the form lands
Every row from 01 to 11 is a file that already exists somewhere in your systems or your provider's. The work is asking for it, dating it and keeping it in one place. Where a row cannot be evidenced, the answer on the application is the gap in plain words, not a rounded-up yes. Delegate the collection. Do not delegate the signature.
Decide who witnesses row twelve, and book it inside the renewal runway
You can run the exercise yourself with our agenda, which is free, and you should. What a self-run exercise cannot produce is the signature. If your renewal is inside the next 90 days and row twelve is blank, it is the row to fix first, because it is the only one with a lead time.
What "tested" means to an underwriter
A date. A scenario. Who was in the room, by role. What they decided and how long each decision took. What was found. What changed afterwards. And a name at the bottom of the page belonging to somebody who does not work for you.
Nothing here is insurance advice and we do not place coverage. Your carrier's own application is the only authority on what it requires. "What the application is asking" describes the pattern across published underwriting question sets and broker guidance, not the wording of any one insurer's form, except where a form is quoted and cited above.