An application is more than paperwork. It turns your technical and organizational security into statements about data, backups, email, access, response, and recovery. This guide explains the common requirements and helps you find open items before submitting a questionnaire.
Cyber insurers look beyond industry, revenue, and policy limit. They want to understand how likely an incident is, how far it could spread, and whether the business can keep operating. The questionnaire translates those risks into specific yes/no or maturity questions.
Answers can affect premium, retention, sublimits, and exclusions. Missing baseline controls may trigger follow-up questions, conditions, or a refusal to quote. A control should therefore be implemented across the relevant scope and supported by evidence, not merely selected in a form.
The declaration matters because application answers may form part of the contractual basis. Describe the current state, not the target state. The legal effect of an incomplete or inaccurate answer depends on the application, policy, and applicable law; consult the insurer, broker, or legal adviser when material wording is unclear.
Mature controls can support a clearer risk assessment. This check does not calculate a premium or promise a discount.
An insurer may attach conditions or restrict specific risks. The application, quotation, and policy remain decisive.
Unclear answers and missing evidence often create follow-up work. Critical gaps can make underwriting harder.
Wording differs between applications, but the core themes are stable. These controls are deliberately generic and name no insurer. For every answer, ask whether it covers all relevant systems, works in daily operations, and can be supported by configuration, logs, policy, or test results.
Insurers first need to understand which assets and dependencies require protection.
Know which business-critical data you process, where it resides, and which systems support revenue, operations, and customers. Include cloud services, IT providers, system owners, and a practical data classification. A maintained inventory gives context for protection scope, recovery order, and possible loss.
Possible evidence: asset register, data classification, system owners, and supplier inventory.
Backups count only when they are separated, protected, and recoverable.
Back up critical data at least weekly and more often where the rate of change requires it. Cover databases, SaaS data, files, configurations, and identity services. Define acceptable data loss and make sure the schedule meets that recovery point.
Possible evidence: backup plan, job logs, retention settings, and recovery targets.
Protect backup data in transit and at rest, and document who controls the decryption keys. Include exported SaaS data and portable media. Test that authorized people can recover data during an incident without making access unnecessarily broad.
Possible evidence: encryption settings, key management, access roles, and a recovery test.
Maintain a current copy that ransomware cannot alter or delete through the production environment. Separate administrative access and test a real restore. An isolated copy is weak if the same compromised account can erase both production and backup data.
Possible evidence: offline or immutable configuration, separate admin roles, and restore logs.
Answer 13 concise questions and receive an assessment of each control as met, partial, or open. The check needs no account, submits no insurance application, and makes no statement about premium, coverage, or acceptance.
Free Insurance Check (13 questions, no account)Many losses begin with a message, a known vulnerability, or an unmanaged device.
Use controls for malicious links and attachments, sender authenticity, suspicious forwarding rules, and rapid reporting. Give extra attention to executives, finance, and IT because payment fraud and account takeover are especially damaging in those roles.
Possible evidence: mail security settings, domain protection, reporting process, and incident metrics.
Inventory systems, assess vulnerabilities, and set risk-based patch deadlines. Internet-facing services and widely exploited software need an emergency path. Track failed deployments and time-limited exceptions rather than assuming automatic updates reached every device.
Possible evidence: patch policy, coverage report, exceptions, and critical update tickets.
Centrally managed endpoint protection should cover laptops, desktops, and relevant servers. Current detection, tamper protection, and a process for responding to alerts matter as much as installation. Identify unmanaged and long-offline devices.
Possible evidence: EDR or antivirus console, coverage, policy, alert history, and response process.
Identities provide direct access to email, cloud platforms, administration, and finance.
Use long, unique passwords with a password manager, avoid shared accounts, and separate normal from privileged administration. Control joiners, movers, leavers, dormant users, external access, and service accounts.
Possible evidence: password policy, manager rollout, user review, and joiner-mover-leaver process.
Cover email, remote access, cloud administration, privileged accounts, and critical business applications. Measure actual coverage, control exceptions, and remove legacy sign-in paths that bypass MFA. Stronger factors are preferable for high-risk roles.
Possible evidence: identity-provider export, MFA coverage, access rules, and exception register.
Provide short, recurring guidance on phishing, payment approval, password managers, data handling, remote work, and rapid reporting. Train new starters early and tailor exercises for exposed teams. Measure participation and improvement without creating a blame culture.
Possible evidence: training plan, attendance, materials, phishing exercises, and improvements.
Readiness also depends on how quickly you contain an incident and restart operations.
Define roles, decision paths, contacts, and first actions for ransomware, data loss, account takeover, and supplier failure. Clarify who can isolate systems, preserve evidence, notify external parties, and coordinate advisers. Test the plan in a tabletop exercise.
Possible evidence: approved response plan, contact list, exercise record, and improvement actions.
Prioritize critical services, acceptable downtime, manual workarounds, and the recovery order for IT. Include cloud outages, communications, key people, and suppliers. Test the most important scenarios against business recovery objectives.
Possible evidence: impact analysis, continuity plan, recovery order, exercises, and supplier contacts.
Track unsupported systems with an owner, risk, replacement date, and compensating controls. Where replacement cannot happen immediately, reduce exposure through segmentation, restricted access, monitoring, and removal of direct internet access.
Possible evidence: lifecycle register, support status, replacement plan, segmentation, and approved exception.
The 13-question check is intentionally narrow. It highlights where a deeper review may be useful, but it cannot fully assess technical scope, operating effectiveness, or evidence. Saying yes to MFA does not show which accounts are covered or whether bypasses remain.
The full 106-question assessment examines the same themes in greater depth against NIST CSF 2.0. Its insurance lens overlays the 13 common control areas onto your answers, showing which application statements are well prepared, where evidence is missing, and which improvements should come first.
Readiness does not mean answering yes to everything. It means knowing the current state, naming gaps honestly, assigning owners, and demonstrating improvement. That creates a stronger basis for discussion but guarantees neither a policy nor particular terms.
Thirteen questions identify the most visible strengths and open items.
The full NIST CSF assessment examines scope, maturity, and dependencies.
The insurance lens connects answers to controls and prioritizes preparation.
CyberGapAudit helps structure preparation and surface gaps. It does not independently verify implementation, certify controls, or provide insurance or legal advice. It does not replace an application or an individual review by an insurer, broker, security professional, or legal adviser.
Common topics include data and systems, backups, email security, patching, endpoint protection, passwords, MFA, training, incident response, business continuity, and end-of-life technology. Applications also ask about the business, previous losses, requested cover, and industry-specific risks.
No. It is an initial baseline across 13 common controls. It does not create or submit an application, verify evidence, or reflect individual policy terms. Use it to find early gaps and answer the actual questionnaire from the evidenced current state.
The consequences depend on the application, policy, and applicable law. Describe the current state and label planned measures as planned. Clarify material or ambiguous wording with the insurer, broker, or legal adviser before submission.
Review it before application and renewal, and after material changes such as a cloud migration, acquisition, critical supplier change, or incident. A quarterly short review is also useful because users, systems, exceptions, and evidence change.
It depends on the risk profile, dependencies, financial resilience, contracts, and existing cover. A policy can transfer some residual risk and provide crisis services, but it does not replace baseline security. Individual risk and insurance advice can support the decision.
No. Good readiness may reduce follow-up work, but underwriting remains the insurer's decision. Industry, revenue, loss history, exposed systems, requested limit, and other factors also matter. CyberGapAudit provides no acceptance or coverage promise.
Thirteen questions, about five minutes, no account. Get an honest view of common controls and see where a deeper assessment may help.