Cyber insurance readiness: a checklist for public agencies

Reference article · 9 min read

Use this checklist in the weeks before a cyber insurance application or renewal is due, not the week it is submitted. Give one person the packet and work backward from the broker's deadline. Underwriters ask narrow questions about specific controls, and an authorized officer signs the form attesting that the answers are accurate. Answer only what you can support, because an inaccurate answer can become a problem if a claim is later investigated.

Aim for two results. The first is an application where every yes is backed by something you could hand to a third party: a screenshot, a tool report, an adopted policy, or a dated test record. The second is a short written list of gaps you could not close, each with an owner and a target date, given to the broker before submission.

Application scope and evidence

• You can name every entity and operation the policy needs to cover. Write down the departments, joint powers authorities, component units, and contracted operations that would look to this policy after an incident, and have risk management confirm the list. If no, ask the broker in writing how affiliated entities, contractors, and shared systems are treated, and get the answer before the form is signed.
• Every figure on the form traces to a named source. Budget and revenue come from finance, employee and contractor counts from human resources, and counts of records containing personal information from the records custodian or system owners. If no, request the number from its owner instead of estimating, and where only a range is available, say so on the form.
• Prior incidents and claims are listed from records rather than memory. Pull the period the form asks about from the ticketing system, incident reports, and the risk management claim file. If no, ask counsel and finance what has already been reported before you answer, because prior notice and prior claim questions are easy to get wrong.
• This year's answers reconcile with last year's. Put the two filings side by side and note what changed, when, and why. If no, reconcile them before submitting and be ready to explain any answer that moved from yes to no.
• Evidence sits in one dated folder. Each yes has a file in it, named for the question it supports. If no, create the folder now and file evidence as you answer, so next year's renewal starts from it.

Identity and access controls

• Multifactor authentication is enforced on every remote path into the network. List the paths, including virtual private networks, remote desktop gateways, virtual desktop services, and vendor or maintenance access, then confirm enforcement in each system's configuration rather than in policy text. If no, enable it on the paths you control, put the rest on the remediation list with dates, and ask the broker how the remaining paths affect the quote.
• Multifactor authentication is enabled for email, and you can list every exception. Check sign-in or conditional access reporting for accounts excluded, including executives, shared mailboxes, and service accounts. If no, answer with the coverage you can prove and a completion date rather than a yes.
• Privileged accounts require a second factor. Cover domain and cloud tenant administration, the backup console, network devices, hypervisors, and administrator accounts in core business systems, and verify by reviewing configuration or attempting a sign-in. If no, start with the backup console and domain administration, because those are what an attacker needs to make an incident unrecoverable.
• Access ends on the departure date. Take a sample of recent separations and compare the account disable time against the effective date in the personnel record. If no, fix the handoff so disablement is triggered by the human resources action, and add a recurring review of accounts with no recent sign-in.
• No remote desktop service answers from the public internet. Confirm with an external scan or a review of firewall rules, not with an internal assumption. If no, close the exposure or move it behind a gateway that requires multifactor authentication before you submit, because the form asks about this by name.

Endpoint, email, and network defenses

• You have a current endpoint coverage report. The report compares the device inventory against the security tool's device list and names what is missing and why, such as servers, operational technology, or legacy machines. If no, export both lists and compare them, then answer with the coverage you can prove.
• Someone is responsible for alerts outside business hours, by name or by contract. Verify with an on-call roster or with the provider contract that states covered hours and response times. If no, answer no and get a price for monitoring, rather than describing an unwatched console as monitoring.
• The patching cadence is written down and recent cycles met it. The written cadence should cover routine updates and a faster path for critical vulnerabilities, and patch reporting should show compliance over the last several cycles. If no, write down the cadence you actually meet and report that, then set a target for improving it.
• Unsupported systems are inventoried with mitigations. Each entry names the system, why it is still running, its compensating controls such as network segmentation or restricted access, and the status of its replacement. If no, build the list before answering, because applications ask about end-of-life systems specifically.
• Email defenses are configured and can be demonstrated. Check filtering, sender authentication records in DNS such as SPF, DKIM, and DMARC, an external sender banner, and blocking of risky attachment types. If no, publishing sender authentication records and turning on the external banner are usually the fastest items to complete before submission.

Backups and recovery

• At least one backup copy cannot be deleted or encrypted by someone holding administrative credentials. Verify by checking whether an administrator can shorten retention or delete the copy, whether it is offline, immutable, or held by a provider under a retention lock. If no, treat this as a priority alongside multifactor authentication, because it decides whether an incident is a recovery or a negotiation.
• The backup platform uses credentials separate from the production directory. Confirm the backup console does not authenticate against the same directory with the same administrator accounts. If no, separate the accounts and restrict console access to a small named group with multifactor authentication.
• A restore test has been performed and written up, with a date. The record should name what was restored, how long it took, and what went wrong. If no, schedule a test of a full system rather than a single file, and until it happens, answer with the date and scope of what was actually tested.
• Recovery targets are agreed with departments in writing. A document should list systems in priority order with a target restore time and the amount of data loss each department can tolerate, minuted or signed. If no, meet department heads before answering, because targets set by IT alone will not hold during an incident.
• Cloud and vendor-hosted data is covered by a backup you control. For email, files, and hosted applications, identify who holds the backup, how long it is kept, and how a restore is requested, keeping in mind that a vendor's retention setting is not a backup. If no, read the contract and service description, then either add third-party backup or record the accepted risk in writing.

Response, people, and third parties

• A written response plan names roles and current contacts. It should include after-hours numbers for leadership, counsel, the insurer or broker, and key IT vendors, and those numbers should have been dialed in the last exercise or contact test. If no, write a short plan that is accurate instead of keeping a long plan that is out of date.
• The plan tells staff to notify the insurer or broker before engaging outside help. Policies commonly require prompt notice and the use of vendors from an approved panel, and costs incurred without approval may not be reimbursed. If no, put the notice step and hotline number at the top of the plan and brief whoever takes the after-hours call.
• A tabletop exercise has been run and documented, with a date. The summary should list the scenario, the participants, the decisions that proved difficult, and the changes made afterward. If no, schedule one and include the ransom payment question and who holds authority to decide it.
• Notification obligations are identified before an incident. The plan should name who decides on notification and list the categories of rules that could apply, such as state breach notification law, sector rules covering criminal justice, health, or student data, contract and grant conditions, and any reporting requirements that apply to your type of entity. If no, ask counsel for a one-page summary of current obligations and attach it to the plan, and review it periodically because these requirements change.
• Security awareness training with simulated phishing is running and tracked. Completion reporting should break out groups, including elected officials, finance, human resources, and anyone with access to payment systems. If no, start with staff who can move money or change vendor records, then extend to everyone.
• Payment and payroll changes are verified out of band. The written procedure should require a call back to a number already on file, not one supplied in the request, before vendor banking or employee direct deposit details are changed, and finance should be able to describe how the last change was verified. If no, write the procedure with finance and include a second approver, since applications commonly ask about this and funds transfer coverage often carries its own sublimit.

What to do with the results

Sort the answers into three groups. Answers backed by evidence go on the form as they stand. Items you can close before submission, such as a second factor on one remaining system, get an owner and a date this week. Gaps that need budget or time go into a written remediation plan you give the broker before submission, because a disclosed gap with an owner and a date is a different conversation from one an underwriter finds.

Keep the completed checklist and the evidence folder with the submitted application. When the policy binds, read the claim conditions, including the notice timeline, the approved vendor panel, the retention, any waiting period before business interruption coverage starts, and any sublimits for ransomware, funds transfer fraud, and social engineering. Write those terms into the response plan so a decision made at night matches what the policy requires.

Frequently asked questions