The 80-Page Cyber Insurance Answer Kit
Sign Your Cyber Insurance Application Without Guessing
Turn the 80-page form into sourced answers, open gaps, and a record the signer can defend.
Unlock the full document
This document is free. Leave a work email so we can send corrections and updated versions, and the full sheet unlocks below.
Before you sign the application
The cyber insurance application or renewal questionnaire is on your desk. It may run 80 pages, use unfamiliar control language, and ask for a yes or no where your evidence says partial or unknown.
This kit is for the signer: a managing partner, practice administrator, CFO, controller, firm administrator, or the Solo IT Director handed the PDF. CPA firms can also use it to collect the records behind questions that touch their written security plan requirement.
Work through the form before the signature date. You will finish with sourced answers, the exact rows still open, and a short gap list tied to owners and dates. Hire nobody to start.
Your signed answers can become part of the policy record
Your application is not a survey. In most cyber policies the application is attached to or incorporated into the policy itself, which means the answers become representations you have made to the carrier.
That has a practical consequence. An answer that is more optimistic than reality can give the carrier grounds to reduce, deny, or rescind coverage later, particularly if the claim traces back to the exact control you overstated. The specific effect depends on your policy wording, your state, and the facts. Ask your broker and your counsel to show you the language in your own policy that governs this.
So the rule for the whole kit is short.
A truthful “no” is safer than an unverified “yes.”
A “no” costs you money. A wrong “yes” can cost you the claim. Carriers price risk they can see. They do not price risk they were told did not exist.
Use three sessions before the signature date
Plan on three sessions rather than one long one.
Session one, about 45 minutes. Read the carrier’s form end to end without answering anything. Mark each question with one of six states, defined below. Do not research yet. You are only sorting.
Session two, variable. Work the unknown and partial rows. This is where the real work lives. Most firms find that ten to twenty questions carry all the difficulty and the rest are clerical.
Session three, about an hour. Fill the evidence index. Write the explanatory notes. Have the person who will sign read it cold and challenge anything they cannot defend in a phone call with an adjuster.
Mark every carrier question with one of six states
| State | Use it when |
|---|---|
yes | The control exists, covers everything the question describes, and you can produce evidence today |
no | The control does not exist, or does not cover what the question describes |
partial | It exists for some users, systems, or offices, and not others |
unknown | Nobody in the room can say for certain, and no evidence has been checked |
not applicable | Your organization does not have the thing the question asks about |
carrier clarification required | The question is genuinely ambiguous and the answer changes depending on the reading |
partial and unknown are legitimate answers. Most applications have a comments field, and a precise partial with a scope note reads better to an underwriter than a bare yes that falls apart under a claim. If the form gives you only a yes or no checkbox and the truth is partial, that is exactly when you use the comments field or a cover letter, and you tell your broker you have done so.
Part 1: Put every application question in one of ten evidence domains
Carrier forms differ. The wording differs, the order differs, and the level of detail differs a great deal between a small-firm short form and a mid-market full application. What does not differ much is the underlying set of things underwriters want to know.
Below are ten domains. For each one: the plain question behind the wording, what evidence actually satisfies it, the honest answer when the answer is no, and the specific way firms get this wrong.
Answer the form in front of you. Use these as translation, never as a substitute for the carrier’s own words.
Domain 1: Record your revenue, employee count, and sensitive-data count
Typical questions. Annual revenue. Employee count. Industry classification. Number of records containing personal information, health information, payment card data, or Social Security numbers. Locations. Whether you operate outside the United States.
What is really being tested. Your exposure size. Every other answer in the application gets weighted against these numbers. This domain sets your limit adequacy and a large part of your premium.
What satisfies it. Actual counts, not impressions. Pull the record count from the system of record rather than estimating from memory. For a CPA firm that is your practice management or tax software client count. For a medical practice it is your patient roster in the practice management system. For a law firm it is your matter and client database.
When the honest answer is “I do not know.” Say the number is an estimate and say how you produced it. “Approximately 4,200 individual client records, derived from active client count in [system] as of [date]” is a real answer. A round number with no derivation is a guess that the carrier will treat as fact.
How firms get this wrong. They count current clients and forget archived data. Old client files, terminated employee records, and backup archives contain personal information too. If you are holding seven years of tax returns because you are required to, those records count. Undercounting here is the most common source of a limit that turns out to be too small.
Domain 2: Show where MFA is enforced and every exclusion
Typical questions. Is MFA required for remote network access? For email? For administrative or privileged accounts? For remote access to backups? For all users or some users?
What is really being tested. Whether an attacker who steals one password gets in. This is the single highest-weighted domain on most current applications, and it is the domain where a wrong answer is most likely to be discovered after a claim, because the forensic report will say plainly whether MFA was in place on the account that was compromised.
What satisfies it. A configuration export or screenshot from your identity provider showing the enforcement policy, the scope it applies to, and the count of users in and out of scope. A screenshot of one user’s enrollment page proves nothing about the other ninety-nine.
Note that these are usually three separate questions with three separate answers:
| Scope | Common reality |
|---|---|
| Email, all users | Often yes |
| Remote access, all users | Often yes |
| Administrative and service accounts | Often no, or unmonitored |
| Backup system console | Frequently overlooked entirely |
| Legacy applications, VPN-only systems, on-premise line-of-business software | Frequently exempted and forgotten |
When the honest answer is no. Answer partial and specify the exception in writing. “MFA enforced for all users on email and remote access. Two service accounts on the [system] server are excluded, documented, and scheduled for remediation by [date].” That is an underwritable answer. An underwriter can price a named exception with a date. They cannot price a surprise.
How firms get this wrong. Somebody says “yes, we have MFA” because they personally have MFA. Nobody checks whether the enforcement policy has exemptions. Exemptions accumulate quietly: the partner who travels, the shared reception account, the scanner, the accounting package that does not support it. Check the policy, not the perception.
Domain 3: Name every human and vendor with administrative access
Typical questions. How many users have administrative privileges? Are administrative accounts separate from daily-use accounts? Do you use a privileged access management tool? How are administrator credentials stored? Do former employees retain access?
What is really being tested. Blast radius. If one account gets taken, how much of the organization goes with it.
What satisfies it. A current list of accounts holding administrative rights, exported from the directory, with a named human next to each one. Service accounts need an owner too, and they usually do not have one.
When the honest answer is no. Say how many admin accounts exist and that they are not separated from daily use. Then fix it, because this one is genuinely cheap to fix and it moves your risk more than most purchases will.
How firms get this wrong. The outsourced IT provider’s accounts are not counted. Your MSP almost certainly holds domain administrator credentials. Those are privileged accounts in your environment and they belong on the list. If the application asks how many people can administer your systems and you answer “two” while your provider has six technicians with access, the answer is wrong.
Domain 4: Produce the last restore-test date and result
Typical questions. Do you back up critical data? How often? Are backups stored offline, off-site, or in immutable storage? Are backups segmented from the production network? When did you last test a restore? How long would a full restore take?
What is really being tested. Whether ransomware ends with a payment or with a restore. This domain is why carriers care about backups more than they care about most security products.
What satisfies it. A restore test record with a date, what was restored, how long it took, and who verified it. Not a backup job success log. A backup that has never been restored is a hypothesis.
When the honest answer is no. “Backups run nightly to [destination]. Last verified full restore test: none on record. Restore test scheduled for [date].” Then actually do it. A restore test costs you an afternoon.
How firms get this wrong. Three ways, in order of frequency. First, they answer yes to “offline or immutable” when the backup target is a network share that the same compromised credentials can reach, which is not offline in any sense that matters. Second, they report the backup vendor’s marketing description of immutability without checking the retention setting actually applied to their tenant. Third, they have never tested a restore and they answer yes anyway because the backup dashboard is green.
Domain 5: Reconcile protected devices with the full asset count
Typical questions. Do you deploy endpoint detection and response across all endpoints and servers? What percentage of devices are covered? Do you have 24/7 monitoring? Is there a managed detection service? Who responds to alerts, and how quickly?
What is really being tested. Detection time. Whether an intrusion gets noticed in hours or in months.
What satisfies it. A coverage report from the console showing enrolled devices against total known devices, with the gap explained. The number that matters is the gap.
When the honest answer is no. State the coverage percentage honestly and name what is uncovered. Servers, personal devices used for work, and the two machines in the back office nobody manages are the usual answer.
How firms get this wrong. They answer “24/7 monitoring: yes” because the tool runs continuously. Continuous scanning is not continuous monitoring. The question is whether a human being looks at an alert at 2 a.m. on a Saturday. If the answer is that alerts go to an email inbox that gets read on Monday, that is the truthful answer, and it is a common one. Say so.
You do not necessarily need to buy a managed detection service to get through the application. You need to answer the question correctly and understand what the answer implies about your detection time.
Domain 6: List patch evidence and every unsupported system
Typical questions. How quickly are critical patches applied? Do you run vulnerability scans? Do you operate any unsupported or end-of-life operating systems or applications? Are internet-facing systems patched on a defined schedule?
What is really being tested. Whether known, published, already-fixed vulnerabilities are still open in your environment. Underwriters increasingly scan your public-facing footprint themselves before they quote, so this is one domain where they may already know the answer.
What satisfies it. Your patch policy, the actual compliance report showing patch level across the fleet, and an inventory of anything running past its support date.
A specific and current item. Standard support for Windows 10 ended on October 14, 2025. Microsoft ended technical assistance, software updates, and security fixes on that date. Commercial Extended Security Updates start at US$61 per device for the first year and double in each consecutive year. If you have Windows 10 devices, they belong on this answer with a count, whether they are on ESU, and a replacement date.
When the honest answer is no. Name the unsupported systems, the count, why they are still running, what compensating controls sit around them, and the retirement date. An underwriter can work with three isolated machines running a legacy application behind a segmented network with a retirement date. They cannot work with a blank.
How firms get this wrong. They think of workstations and servers and forget firewalls, switches, printers, VoIP systems, and the building access controller. Those have firmware and it is usually years old.
Domain 7: Show email controls and training completion with a denominator
Typical questions. Do you use email filtering? Do you tag external email? Do you have DMARC, SPF, or DKIM configured? Do you conduct phishing simulations? Do you deliver security awareness training, and how often? What percentage of staff complete it?
What is really being tested. Your exposure to the two attack paths that produce the most claims: credential phishing and business email compromise.
What satisfies it. Training completion records with dates and a denominator. “Annual training, 47 of 52 staff completed as of [date]” is evidence. “We do training” is not.
When the honest answer is no. Say it. Awareness training is one of the cheapest items on this entire form, and a “no” here is one you can convert to a “yes” before your next renewal without a large purchase.
How firms get this wrong. They count the training they bought rather than the training people completed. Buy-rate and completion-rate are different numbers and the carrier is asking about the second one.
Domain 8: Record transfer limits, callbacks, and named approvers
Typical questions. Do you initiate wire transfers or ACH payments? What is your typical and maximum transfer amount? Do you verify payment instruction changes by callback to a previously known telephone number? Is there dual authorization above a threshold? Have you experienced a fraudulent transfer attempt?
What is really being tested. Social engineering fraud exposure, which is often covered under a separate sublimit with its own conditions.
What satisfies it. A written payment verification procedure, the threshold, and the named approvers. Whether staff actually follow it under time pressure is the real question, and you should know the answer before the carrier asks.
When the honest answer is no. Write the procedure. It is one page. Callback verification to a number from your own records, never a number in the request, stops most of this category. This is the highest return-per-dollar control on the whole application and it costs nothing.
How firms get this wrong. Law firms and accounting firms handling client funds, escrow, or trust accounts often answer this domain thinking only about their own payroll. If you move client money, that is in scope, and the sublimit for social engineering fraud may be far below your policy limit. Ask your broker what your social engineering sublimit is. Many buyers do not know it until they need it.
Domain 9: List vendor access, data, contracts, and review dates
Typical questions. Do you outsource IT? To whom? Do vendors have remote access to your network? Do you assess vendor security? Do you hold contracts with security requirements? Do you rely on any single provider for critical operations?
What is really being tested. Access you do not directly control. In Verizon’s 2025 dataset, covering 22,052 incidents and 12,195 confirmed breaches, third-party involvement appeared in 30% of breaches. That is a contributed-case dataset rather than a population sample, so treat it as directional. The direction is clear enough.
What satisfies it. A vendor list with the access each one holds, the data each one touches, and the contract terms. Include your identity provider, your backup provider, your practice management or case management SaaS, your outsourced IT firm, and anyone who has a remote access tool installed on your machines.
When the honest answer is no. Most small and midsize organizations have no formal vendor assessment process. Say that, list the vendors, and note which contracts you have reviewed. The list itself is worth more to you than the answer is to the carrier.
How firms get this wrong. They answer only about software vendors. Your outsourced IT provider is usually your single largest third-party risk, because they hold administrative access to everything. Include them.
Domain 10: Attach current plans, tests, incidents, and applicable obligations
Typical questions. Do you have a written information security policy? A written incident response plan? When was it last tested or updated? Do you have a designated security officer? Have you experienced a security incident, claim, or regulatory inquiry in the past three to five years? Are you subject to HIPAA, GLBA, state privacy laws, or industry regulation?
What is really being tested. Whether anyone owns this, and whether you have a loss history.
What satisfies it. The documents themselves, with version dates. A policy written in 2018 and never reviewed answers the question truthfully as “yes” and answers the underwriter’s real question as “no.”
Regulatory obligations you may need to name. Get this section right, because a misstatement here can affect both coverage and your regulatory position.
| If you are | Obligation to identify | Source |
|---|---|---|
| A tax or accounting practice | Treated as a financial institution under GLBA. A written data security plan is required. The legal duty comes from GLBA and FTC rules. IRS Publication 4557 supplies guidance, revised May 2024 | SBK’s lead magnet source register, line 76; SBK’s CPA partner persona file, lines 259-260 |
| A covered financial institution under the FTC Safeguards Rule | Maintain a written information security program. Certain notification events involving at least 500 consumers must reach the FTC as soon as possible and no later than 30 days after discovery. Rule requirements effective June 9, 2023; notification requirement effective May 2024 | SBK’s lead magnet source register, line 75 |
| A HIPAA covered entity or business associate | Breach notification obligations under 45 CFR 164.404 and 164.408. Individual notice without unreasonable delay and no later than 60 calendar days after discovery. Notification timing to HHS differs by breach size | SBK’s lead magnet source register, line 74 |
| A NYDFS-covered financial services company | Notify the Superintendent as promptly as possible and no later than 72 hours after determining a defined cybersecurity incident occurred, including incidents at an affiliate or third-party service provider | SBK’s lead magnet source register, line 72 |
| A public company | Generally file within four business days after determining an incident is material, with the materiality decision made without unreasonable delay | SBK’s lead magnet source register, line 73 |
Whether any of these apply to your organization is a legal determination. Do not answer a regulatory applicability question on an insurance form without your counsel confirming it.
How firms get this wrong. The prior-incident question. Firms answer “no” while thinking of large breaches, and forget the wire fraud attempt in 2023, the ransomware that was contained, or the laptop that went missing. Read the question’s exact wording, including its lookback period and its definition of incident, and answer that. Non-disclosure of a prior incident is one of the cleanest grounds a carrier has to contest a claim.
Part 2: Answers that can affect your premium or claim
These are the specific patterns that create trouble. Each one is fixable before you sign.
1. “Yes” to MFA when it is partial. Covered above and worth repeating because it is the most consequential single answer on the form. If the compromised account turns out to be one of the exceptions, the forensic report will say so.
2. “Yes” to offline or immutable backups when the backup target is reachable with production credentials. Check the actual retention lock setting. Ask your provider to show you, in the console, the setting that prevents deletion, and who can change it.
3. “Yes” to a tested incident response plan when the test was a document review. A plan that has been read is not a plan that has been tested. If nobody has walked through a scenario with the decision-makers in the room, the honest answer is that the plan exists and has not been exercised.
4. Underreporting record counts. This does not usually raise premium. It creates a limit that is too small, which you discover during a claim. Notification costs scale directly with record count.
5. Omitting a prior incident. See above.
6. Signing without the technical answers being verified by whoever can verify them. The signature is often an executive’s, and the technical answers usually come from IT or an outsourced provider. If your provider filled in the technical section, ask them for the evidence behind each yes. They are answering questions about their own performance, which is worth remembering.
7. Leaving “we plan to” in an answer with no date. Underwriters read an undated plan as a no. A dated plan is a real answer and sometimes earns a conditional term.
8. Answering a question you do not understand rather than asking. carrier clarification required exists for a reason. Brokers are paid to get you that clarification. Use them.
9. Copying last year’s application forward. Your environment changed. The form changed too. Carriers have added questions steadily, and last year’s answers can become this year’s misstatements.
10. Letting the answer describe a product rather than a control. “We have [product name]” does not answer “is MFA enforced for all remote access.” A product that is licensed but not deployed, or deployed but not enforced, is not a control. The question asks about the control.
Part 3: Link each answer to the dated evidence
Build this once. It is reusable, and it is what makes next year’s renewal a two-hour job instead of a three-week one.
| # | Question or domain | Answer state | Control owner | System | Proof file | Proof date | Test result | Exception owner | Notes |
|---|---|---|---|---|---|---|---|---|---|
Column definitions:
- Control owner. A named person, not a department. If nobody’s name fits, that is your finding.
- System. Where the control actually lives, in the specific product or platform.
- Proof file. The exact artifact: an export, a configuration screenshot, a policy PDF, a training completion report, a restore test log. Store these together with the filename recorded here.
- Proof date. When the artifact was produced. Evidence ages. Most of it is stale after a year.
- Test result. Did somebody independently verify it works, and when. This is the column most firms leave empty, and it is the one that separates a real control from a claimed one.
- Exception owner. For every
partial, who owns closing the gap and by when.
Part 4: Give the signer one answer-status sheet
Track completion so you know when you are done.
| Domain | Total questions | yes | no | partial | unknown | n/a | clarification | Evidence attached | Owner | Due |
|---|---|---|---|---|---|---|---|---|---|---|
| 1. Organization and data | ||||||||||
| 2. Multi-factor authentication | ||||||||||
| 3. Privileged access | ||||||||||
| 4. Backup and recovery | ||||||||||
| 5. Endpoint and monitoring | ||||||||||
| 6. Patching and end-of-life | ||||||||||
| 7. Email and social engineering | ||||||||||
| 8. Funds transfer controls | ||||||||||
| 9. Third parties and vendors | ||||||||||
| 10. Governance and history |
You are finished when unknown is zero. Every unknown you leave in the form is a decision you handed to someone else.
Part 5: Assign every gap an owner and date
After you finish, you will have a list of no and partial rows. Sort them into three groups before anyone recommends a purchase.
Group A: costs nothing but attention. Writing the payment callback procedure. Removing stale administrator accounts. Turning on MFA where the license you already pay for supports it. Running a restore test. Setting the enforcement policy that already exists in your identity platform. Most firms find that a third to half of their gaps land here.
Group B: costs configuration or time. Segmenting backups. Separating administrator accounts from daily accounts. Setting up DMARC. Documenting the vendor list. Retiring or isolating end-of-life systems.
Group C: costs money. Endpoint detection where none exists. Managed detection and response. Replacing hardware that cannot be secured.
Do A and B before anyone quotes you C. Underwriters do not weight your controls by what you spent on them. If a vendor’s first response to your questionnaire gaps is a proposal, ask which of your gaps are in Group A, and why those were not the recommendation.
Part 6: Questions to send your broker before you sign
Four questions worth asking before you bind.
- What is my social engineering fraud sublimit, and what conditions apply to it? This is frequently much lower than the policy limit and frequently has a callback verification requirement attached.
- Which of my answers most affected the quote? A broker who can tell you is worth keeping. This also tells you where remediation would pay.
- Is the application incorporated into the policy, and what is the wording on misrepresentation and rescission? Ask to see the clause.
- What is the waiting period before business interruption coverage starts, and how is the loss measured? Firms are often surprised here after an incident.
Your broker is paid by the carrier, generally through commission. That is not a reason to distrust them. It is a reason to know it, and to ask questions that a commissioned party might not volunteer.
Keep the signed form, evidence index, and open-gap record together
This kit is general guidance about how cyber insurance applications are structured and how to answer them accurately. It is not legal advice, it is not insurance advice, and it does not interpret your policy. Coverage terms, regulatory applicability, and the effect of any given answer depend on your specific policy, your jurisdiction, and your facts. Have your counsel and your broker review your completed application before you sign it.
Every regulatory item in this document is sourced to a named authority through SBK’s source register. Where a requirement varies by entity type, state, or data type, this document says so rather than giving you one number.
SBK Consulting is a vendor-neutral IT advisory firm in the New York, Connecticut, and New Jersey metro area. Family-run since 2010. Zero vendor partnerships, zero reselling, zero referral fees or commissions. We do questionnaire evidence reviews if you want a second set of eyes on the unknown and partial rows you end up with. If you never call us and this document gets your application answered correctly, it did its job.
(718) 407-4169