A cyber insurance application looks like a survey. It behaves like a representation.

That distinction is easy to miss when a client forwards you a forty-question renewal form three days before it is due and asks you to “fill in the technical parts.” You know the environment. You know the answers. You type yes where yes is true, send it back, and move on to the ticket queue.

The problem is that nobody verifies those answers at the moment they are given. They get verified after a loss, by a forensic investigator working for the carrier, reconstructing what the environment looked like on the day the policy was bound. And at that point, the gap between “we have MFA” and “here is the enforcement scope as of March 31, with the user population it covered” is the entire conversation.

The case worth keeping in front of you

In 2022, Travelers filed to rescind a cyber policy it had issued to International Control Services, an Illinois manufacturer. The sequence is the lesson.

ICS signed a multifactor authentication attestation on March 10. The application followed on March 31. The policy bound on April 4. On or about May 25, the company was hit with ransomware (complaint, C.D. Ill. 2:22-cv-02145).

The attestation ICS answered yes to said that multifactor authentication was required for all remote access to the network provided to employees, contractors and third-party service providers, and for all internal and remote administrative access to network backup environments. Travelers alleged that MFA protected the firewall and nothing else. The parties later agreed the policy be declared “null and void, from its inception,” with no coverage available to anyone under it, and the case was dismissed with prejudice.

Two caveats before anyone builds a sales deck on this. The matter resolved by agreement between the parties, not by a court finding that the insured committed fraud. And the allegations were exactly that — allegations. What survives as instruction is the process failure, not the verdict.

Here is the detail that should matter most to an MSP. Travelers’ own form stated that the attestation should be completed with the assistance of the people in charge of IT security. It was signed by the company’s chief executive. Somewhere between the person who knew what the environment actually did and the person whose signature carried the legal weight, nobody had written down who verifies a control claim before it is asserted.

That is not an insurance problem. That is the same shared responsibility gap that shows up in every audit finding, wearing a different hat.

What practitioners are seeing on renewals

Across MSP and broker commentary, the same observation keeps surfacing: renewal questionnaires that used to accept a checked box now ask for artifacts. Configuration screenshots, deployment reports from the RMM, restore test logs, coverage percentages (SeedPod Cyber, Cyber Advisors). One MSP guide describes the shift bluntly: the underwriter wants proof, not answers.

Treat that as what the practitioner community reports experiencing rather than as a documented industry-wide policy change, because carriers do not publish their underwriting standards. But you do not need the trend to be universal for the response to be correct. Whether or not your client’s carrier asks for the export this year, being able to produce it is the difference between an answer and a defensible answer.

What a standing evidence pack contains

The useful version of this is not a folder of screenshots. It is a set of artifacts where each one has three properties: a generation date, a named producer, and a scope statement. An MFA screenshot with no date and no indication of which user population it covers proves nothing twelve months later, which is precisely when it will be asked for.

Organize the pack by the claims the application makes.

Identity and MFA. The claim is usually some version of “MFA enforced on email, remote access, and administrative accounts.” The artifact is a conditional access or policy export showing enforcement plus a coverage report showing the population it applies to and any exclusions. The producer is the MSP. The scope statement names which accounts are out of scope and why.

Privileged access. The claim is that administrative rights are limited and reviewed. The artifact is the current privileged account inventory plus the date of the last review and who performed it.

Endpoint coverage. The claim is that EDR runs everywhere. The artifact is a deployment report with a denominator, because “deployed” and “deployed on 94 percent of managed assets” are different representations and only one of them survives a forensic review.

Patching. The claim is a defined cadence. The artifact is compliance reporting against that cadence, including the exceptions, not a policy document describing what the cadence is supposed to be.

Backup and recovery. The claim is usually the one that hurts most, because it typically includes a testing assertion. The artifact is the backup configuration plus dated restore test results. A backup job that completes is not a tested restore.

Email security, logging, awareness training, and vendor access. Same pattern. Configuration state, coverage denominator, date, owner.

Note what is not on this list: a binder. The point is not to produce a document. It is to be able to retrieve current, dated, scoped records for each claim on demand.

Who signs, and what they are signing

The MSP produces the evidence. The client makes the representation. Those are two different acts, and they should be visibly separated in your process.

Write the split down. The MSP supplies dated artifacts and a scope statement for each answer. The client’s signer reviews those artifacts before signing, rather than delegating the reading to the vendor who wrote them. And any question the MSP cannot evidence gets flagged to the client in writing, before submission, rather than quietly rounded up to yes.

That last one is the uncomfortable part of the job. There will be an answer the client wants to give that the environment does not support, and there will be pressure — sometimes stated, usually not — to be optimistic about scope. Document the decline. Send the email. A written record showing that you identified the gap, priced the remediation, and the client chose to proceed anyway is worth considerably more to your practice than the goodwill you buy by looking away.

This is also why a responsibility matrix on its own does not finish the job. PCI DSS makes the same point in its own domain: an attestation, a website declaration, a policy statement or a responsibility matrix is not a written acknowledgment of responsibility (PCI SSC). The matrix tells you who does what. The signature tells you who answers for it.

Make the QBR the refresh cycle

Evidence decays. Staff turn over, tenants get reconfigured, an exception gets granted in October for a project that ended in November and nobody closed it. An annual pre-renewal scramble reproduces the exact conditions that make attestations wrong, because it asks you to reconstruct twelve months of drift from memory under deadline.

Put the pack on the quarterly business review agenda instead. Walk the artifacts. Note what changed. Capture new exceptions and accepted risks with a date and a name attached. Leave the meeting with a refreshed set.

Do this four times and renewal stops being a project. It becomes retrieval. The client’s signer walks into the attestation having already seen the evidence three months ago, which is a materially different posture than reading a form for the first time on the day it is due.

There is a second benefit that is harder to quantify and easier to feel. The QBR conversation changes character when there are artifacts on the table. It stops being a status update and starts being a review of a program the client can see.

Why this is worth doing as a service

Evidence maintenance is recurring, defensible, and billable. It produces something the client can hold, which is rare in security work. And it is a service that gets harder to displace every quarter it runs, because the value compounds in the record rather than in the tooling.

But the argument that actually lands with a client is simpler than any of that. Insurance is the thing they bought so that a bad day would not become a closed business. Making sure it still works on the bad day is not a compliance chore. It is the point.

Blacksmith InfoSec keeps mapped controls, assigned ownership and dated evidence in one place, so an insurance questionnaire gets answered from records instead of from memory. Schedule a demo.

Frequently Asked Questions

Q: Can a cyber insurance claim be denied because of a wrong answer on the application?

A: Yes. Insurers can seek to void a policy when they allege the insured misrepresented its security controls during underwriting. In Travelers v. International Control Services, the insurer sought rescission over a multifactor authentication attestation, and the parties ultimately agreed the policy be declared null and void from its inception. The exposure is not limited to deliberate misstatement — an answer that was overstated in scope can produce the same argument.

Q: Who should sign a client’s cyber insurance attestation?

A: The client, after reviewing evidence supplied by whoever operates the controls. Attestation forms frequently instruct that they be completed with the assistance of the people responsible for IT security, but the signature and the legal consequence sit with the insured organization. The MSP’s role is to make the underlying facts verifiable, not to make the representation.

Q: What evidence do underwriters ask for on multifactor authentication?

A: Practitioner accounts consistently describe requests for configuration or policy exports showing enforcement, along with coverage reporting that identifies which accounts are in scope and which are excluded. Scope matters more than the yes. MFA on the firewall and MFA on backup administration are different claims.

Q: How often should an MSP refresh a client’s evidence pack?

A: Quarterly, aligned to the business review, is the practical cadence. It matches the rate at which environments actually drift and it means renewal becomes a retrieval exercise rather than a reconstruction.

Q: Is a responsibility matrix enough to satisfy an insurer or an auditor?

A: No. A matrix documents who performs which function, which is necessary but not sufficient. PCI DSS states directly that a responsibility matrix, an attestation or a policy statement does not constitute a written acknowledgment of responsibility. The matrix belongs alongside the agreement that assigns accountability, not in place of it.