Your Cyber Insurance Renewal Is Going to Ask for Proof. Do You Have It?

I spent a good part of this weekend reading through what the carriers are putting out about cyber insurance renewals this year, partly because a couple of people had asked me about it and partly because I fell down a rabbit hole once I started. The short version is that the application is not the two page questionnaire it was a few years ago. The ones I looked at are running eight to twelve pages, and a good third of the questions are no longer asking whether you have a control in place, they are asking you to attach evidence that you do. Screenshots, dates, logs, a copy of the written policy.

I think most business owners are going to find this out with a renewal sitting in the inbox and a deadline on it, so I wanted to get ahead of that.

What changed

For years the application worked on the honor system. You checked a box that said you had multi-factor authentication, you checked a box that said you had backups, and the carrier took your word for it. That is over. The carriers have paid out enough ransomware claims that they have gone back and looked at what those companies actually had in place on the day they got hit, and the answer was often not what was on the form.

So now the form is different in two ways. First, the questions are more specific. It is no longer "do you have MFA," it is "is MFA enforced on email, remote access, admin accounts, cloud storage, and your backup console," and each of those is its own line. Second, they want to see it. The carriers I have read guidance from this year are asking for what amounts to a proof packet, meaning screenshots of MFA enforcement, a report showing endpoint protection on every device, backup logs with the date of your last restore test, training completion records, a dated incident response plan, and documentation of how you handle patching.

The line on the form that catches people

Every one of these applications has an attestation on it. You are signing a statement that says the controls you described are real and in place. That matters, because if you file a claim and the carrier's investigation finds that something you attested to was not actually there on the day of the incident, the claim can be denied. That has happened, it is happening more, and it is the part of this I really want business owners to hear. The risk is not that you fail the application. The risk is that you pass it, pay the premium for a year, get hit, and then find out the policy does not pay because of a box that got checked a little optimistically.

The five things they are going to ask about

Every carrier's list is a little different, however they all come back to the same handful of controls, and the ask on each one is the same, do you have it, and can you show me.

• Multi-factor authentication — enforced, not just available, on email, VPN or remote access, admin accounts, your accounting system, and anything holding backups. Proof is a screenshot of the enforcement policy, not a screenshot of your own login prompt.

• Endpoint protection on every device — basic antivirus does not meet the bar anymore, they want detection and response, and one unmanaged laptop can sink the whole application. Proof is a deployment report from the console.

• Backups you have actually tested — a copy that is offsite or immutable, and a restore test with a date on it, usually quarterly. Proof is the log. A backup you have never restored from is a hope, not a backup.

• Patching with a deadline — this is the one that is changing fastest. Carriers are now asking how quickly critical vulnerabilities get fixed, and the windows I am seeing are 14 to 30 days, with regular scans and a record of what was found and what was done about it. Proof is a scan report and a remediation log with dates.

• A written incident response plan and staff training — a dated document with names in it, and training records with completion dates. Proof is the document and the records.

Notice that the proof on every one of those is a piece of paper or a screenshot with a date on it. That is the whole game. Doing the work is half of it, and writing down that you did it is the other half, and the second half is the one that gets skipped.

Why the patching line is the one I would start on

Of the five, patching is the hardest to fake and the hardest to backfill. You can turn on MFA the week before the renewal and screenshot it. You cannot produce six months of dated remediation history the week before the renewal. Either you have been keeping the record or you have not.

If you read my post last week on the CISA KEV list, this is where it connects. The carrier is going to ask how you prioritize what to patch, and "we patch anything on the government's known-exploited list inside the federal deadline, and everything critical inside 30 days, and here is the log" is an answer an underwriter understands. It is specific, it has a date on it, and it ties to a public standard they can look up. That is a better answer than most companies ten times your size can give.

What I would do this week

• Pull last year's application — read every box you checked and ask yourself honestly whether you could attach proof for it today. Circle the ones you cannot.

• Build the proof packet now, not at renewal — one folder, one file per control, dated. MFA policy screenshot, endpoint report, last restore test, IR plan, training records, and your patch log. It takes an afternoon the first time and ten minutes a month after that.

• Start the patch log today — even if it is a spreadsheet. Date found, severity, on KEV or not, due date, date fixed, who fixed it. Six months from now that spreadsheet is the difference between a renewal and a rejection.

• Ask your broker what the carrier wants to see — before the renewal lands. They know, and they would rather tell you in September than argue with an underwriter in December.

Where I can help

This is the exact problem RemedyOps was built for. It takes the output from whatever scanner you or your MSP already run, Defender, Tenable, Qualys, Rapid7, OpenVAS, it does not matter, and turns it into a tracked remediation workflow inside GitHub, where every finding gets a severity, a due date based on your SLA, an owner, and a dated close. When the renewal asks for your patch management documentation, you export the log. That is the proof packet line item, done, and it is the one you cannot build the week before.

If you want the plain English version to hand to a broker or an owner, ClarityOps takes the raw scanner file and produces a branded report with the risk scores and the priorities spelled out so a non-technical reader can follow it. And the Remediation SLA Calculator is free on the site if you just want to know what date a finding needs to be fixed by.

All of it is at opstacks.net.

The first time you pull this packet together it is going to take a weekend. After that it is an hour, because you are keeping the record as you go instead of reconstructing it. That is really all this is. Let me know if you have questions.

Curtis

opstacks@outlook.com · opstacks.net

Sources: Beancount, "Cyber Insurance for Small Businesses in 2026: MFA Requirements, Ransomware Coverage, and Premium Benchmarks" (May 2026); AlphaCIS, "2026 Cyber Insurance Requirements for Small Business Owners"; Total Business Systems, "Cyber Insurance in 2026: What It Actually Covers, What It Does Not, and What You Have to Prove First"; CISA Known Exploited Vulnerabilities Catalog.