What cyber-insurance carriers ask MSPs to prove at renewal

The asks, verbatim

An MSP describing what comes up in client audits lists three specific, recurring requests: "proof of tested backups", "proof of when we last did user/security audits", "proof of MFA" (r/sysadmin). Notice the shape of each one: not "do you have backups," but "prove the backup was tested"; not "do you use MFA," but "prove it was verified across every user." A carrier reading a renewal questionnaire is asking the same way.

Configured is not the same as verified

A thread on cyber-insurance claims being denied at an alarming rate makes the distinction explicit: "MFA was enabled, but was it verified across every user? Backups were configured, but was the restore tested on schedule?" (r/msp). This is the gap that gets claims denied after an incident: the control existed on paper, but nobody can show it was actually checked on the schedule the policy assumed. "Backup policy: exists, configured, retained 30 days" satisfies a checkbox; it does not answer "when did you last run a restore drill?" — and that second question is the one a claims adjuster actually asks.

A 12-month evidence calendar

The fix is not more tooling — it is a schedule that turns each recurring control into a dated record instead of a one-time setup:

• Monthly: MFA coverage report exported from the identity provider, timestamped and hashed.
• Quarterly: user access review, with reviewer, decision and revocation date per entitlement.
• Quarterly: backup restore test, with what was restored, from which restore point, the result, and a timestamped screenshot.
• Semi-annually: break-glass account test — sign in, confirm alerting fired, rotate the credential, record the result.
• Annually: full review of the control set itself against the current renewal questionnaire.

What a generated pack looks like

At renewal, the useful artifact is not a narrative describing your security posture — it is a dated log per control, one row per time it ran, each row with its own evidence attached: the restore test's screenshot and outcome, the MFA report's export date, the access review's sign-off. A carrier or their auditor can scan that log and see the cadence directly, instead of taking your word for it.

Running this across many clients without it becoming spreadsheets and Slack

A single client's evidence calendar is manageable by hand. The same calendar across twenty or fifty clients is where it usually collapses back into ad hoc tracking, described plainly in one MSP thread: "this tends to live in spreadsheets and Slack until you outgrow it" (r/msp). The fix is not a bigger spreadsheet — it is treating each client's calendar as its own record, with its own dated log per control, rather than one shared tracker where a missed row for one client is easy to lose among the rest.

Who signs the record

An MSP running these controls for a client is usually the one gathering the evidence, but should not be the one attesting that the client's own environment is secure. The safer split is: the MSP provides the evidence — the restore test result, the MFA export, the access review log — and someone at the client signs off on the control itself. That keeps the MSP in the role of evidence provider rather than the party vouching for its own work, which matters if a claim is ever questioned later.

Starting the calendar before the next renewal, not during it

The evidence a carrier wants at renewal is evidence of a cadence, which by definition cannot be produced in the week before the questionnaire is due. If renewal is close and the calendar does not exist yet, the honest answer is to start it now, log what you can verify going forward, and be straightforward with the carrier about what predates the calendar. A short, real history beats a long one that was reconstructed from memory after the fact. The same applies each renewal cycle after this one: extend the same calendar rather than starting a fresh one, so the history a carrier can see keeps getting longer instead of resetting every year.

Questions

Does this replace our GRC platform?

Not necessarily. A GRC platform is often the right tool once you are running many overlapping frameworks for many clients; a controls ledger fits underneath it, or in place of it, for the specific recurring evidence a renewal actually asks for. See our guide on choosing between a spreadsheet, a GRC platform and a controls ledger.

Who at the MSP should own the evidence calendar?

Whoever runs the audits today. The calendar does not add new work; it schedules and records work that is usually already happening, just not on a fixed cadence with proof attached.

Is this legal, insurance or audit advice?

No. This describes what carriers and auditors have said they ask for; the record you keep is not a substitute for reading your own policy's actual requirements.

Next step

ControlLedger schedules each control on the calendar above per client, logs the result with its evidence attached, and hands you a dated Evidence Pack at renewal time instead of a week of reconstruction.