Testing and defence led by a published security researcher with five CVEs, including a CVSS 9.1 Mirai botnet kill-switch.
All security →SOC 2, ISO, and the Canadian privacy stack, run end to end with an independent auditor.
All frameworks →Original research, free tools, and plain-language guides on security and compliance, from a published security researcher.
Read the blog →An operating guide to the cyber application, the control questions behind the premium, the evidence to hold for each answer, and what happens at claim time when the answer was optimistic.
A cyber insurance application is a set of control assertions you are warranting to be true, not a marketing form. The questions that move the premium and the quote are narrow and repeatable: multi-factor authentication on email, remote access and privileged accounts; backups that are offline or immutable and have been restore-tested; endpoint detection deployed to a stated percentage of endpoints; a patch cadence for critical vulnerabilities; email filtering; no end-of-life software in scope; an incident response plan that has been exercised; and payment verification controls. For each one, hold a dated artefact that shows coverage across the population rather than a screenshot of one console. A SOC 2 or ISO 27001 position rarely buys a headline discount by itself, but it shortens underwriting, supports higher limits and better sublimits, and gives you the file you need if a claim is ever contested.
Cyber underwriting is not a security assessment. Nobody is testing your controls, reading your architecture, or forming an opinion on your engineering culture. An underwriter is pricing a small number of loss scenarios, and almost all of the money in the market flows into three of them: ransomware and the business interruption that follows it, business email compromise leading to fraudulent funds transfer, and a privacy breach that triggers notification, credit monitoring and regulatory response costs.
Every question on the application maps to one of those. Multi-factor authentication and email filtering are asked because they are the two controls with the clearest observed effect on business email compromise. Backups, immutability and restore testing are asked because they decide whether a ransomware event is a bad week or an existential one. Endpoint detection and patch cadence are asked because they change dwell time. Record counts and data types are asked because notification cost scales with the number of individuals, not the number of servers.
That framing is useful, because it tells you where to spend attention. An underwriter will not reward a well-written policy set. They will reward a specific, verifiable answer to a specific question, and they will punish vagueness by pricing for the worst reading of it. The practical goal is not to have a good security program in the abstract. It is to be able to answer each of eight to twelve questions with an unambiguous yes, and to have a dated artefact behind each yes.
The single most important thing to understand about the cyber application is that it is not a sales document. It is signed by an officer of the company, it is incorporated into the policy by reference in most wordings, and the insurer is entitled to rely on it. In Canadian insurance law the general principle is that a material misrepresentation or non-disclosure at placement can allow the insurer to void the contract, and the precise effect depends on the wording and the province. You should read the specific policy rather than a general description of the law, and you should not sign an application you have not personally verified.
This changes who fills the form in. The form usually arrives with the finance lead or the founder, because it arrives with the broker and it has premium on it. The control questions cannot be answered by that person from memory. They have to be answered by whoever operates the control, and the answer has to be checked against the system, not against the policy that says what the system should do.
The pattern to adopt is simple and it takes about three hours. Circulate the control questions to the named owners. Require each owner to attach the artefact that supports the answer. Where the artefact does not support an unqualified yes, answer with the qualification rather than the yes, and put the qualification in writing on the form or in the covering note. A qualified answer costs premium. An unqualified answer that turns out to be false costs the claim.
This is also why the application and the audit evidence register are the same exercise done twice. A team that has already been through a readiness engagement is answering the underwriter from a register that has owners, dates and artefacts on it. A team that has not is answering from memory, which is where misstatements come from.
Application wordings differ by insurer, and the ransomware supplement differs more than the base form. The substance, though, is stable. If you can answer the following without hedging, and evidence each one, you are quotable by most of the market at reasonable terms. If you cannot, expect either a loaded premium, a coinsurance provision on ransomware, a reduced sublimit for the class of loss you are weak on, or no quote at all.
MFA is the question most often answered wrongly in good faith. The form asks whether multi-factor authentication is enforced. The honest answer for a large number of small companies is that MFA is available, strongly encouraged, enabled for most people, and not actually enforced by policy in the identity provider. That is a no.
A truthful yes needs three things. It needs the enforcement to be a configuration rather than a norm, meaning a conditional access rule or equivalent that fails closed. It needs the exception list to be empty or explicitly listed, and service accounts and break-glass accounts are the usual residents of that list. And it needs to cover the paths that bypass the front door: legacy authentication protocols on the mail platform, application passwords, and any single sign-on bypass that a vendor left enabled during onboarding.
The evidence an underwriter will accept, and more importantly the evidence that protects you at claim time, is a system-generated export rather than a screenshot of a settings page. The strongest artefact is a report from the identity provider listing every active user with their MFA registration and enforcement state, exported with a visible date and a visible total count. That artefact answers three questions at once: the control exists, it covers the full population, and the population is the one you claimed.
Where you genuinely have exceptions, name them. A form that says MFA is enforced for all interactive users with four named service accounts excluded, each of which uses a rotated key and cannot log in interactively, is a better underwriting position than a bare yes, because it reads as a company that knows its own environment.
Backup questions look like four separate questions and are really one: if an attacker gains administrative control of your production environment, what survives, and how long does it take to bring it back. Most answers fail on the first half. Snapshots in the same cloud account, under the same credentials, with the same permissions that the attacker now holds, are not a recovery position. They are a copy of the thing being encrypted.
The properties an underwriter is looking for are separation and immutability. Separation means a different account, subscription or tenancy, with a different credential path, so that compromise of production does not imply compromise of the backup. Immutability means object lock, or a retention policy the production identity cannot shorten, so that a copy inside the retention window cannot be deleted even with valid credentials. If you have one of the two, say which one. If you have neither, fix it before you submit, because this is one of the few control gaps that can be closed in a fortnight.
The second half is the restore test, and it is the half almost nobody has. The question is not whether backups run. It is whether a restore has been performed and timed. The record has to name the date, the person, the system restored, the restore target, the elapsed time, and the outcome including anything that went wrong. A restore test that found a problem and recorded it is stronger evidence than one that reports a clean pass, because it reads as a real test.
The link to compliance work is direct. The same restore record satisfies the continuity and backup expectations in both major frameworks, where the practice is a documented restore test with elapsed time recorded against the recovery time objective. Running it quarterly gives you four records a year, which covers both an annual insurance renewal and an audit observation window without any additional work. Our guide to SOC 2 requirements covers where that evidence lands, and the disaster recovery plan walkthrough covers writing the plan the test exercises.
The endpoint questions are about coverage, and coverage is a fraction. The numerator is machines with the agent installed and reporting in the last seven days. The denominator is the asset inventory. Underwriters increasingly ask for the percentage rather than a yes, because the yes was found to mean anything from ninety-nine percent to the founder laptop.
This is the point where an asset inventory stops being a compliance chore and starts being commercially useful. If you cannot state the denominator, you cannot state coverage, and you are answering the highest-value question on the form with a guess. The inventory does not need to be sophisticated. It needs an owner per record, a type, an identifier, and a last-seen date, so that a stale record is visible as stale rather than counted as covered.
Patching questions ask for a window by severity, usually something like critical within a stated number of days and high within a longer window. Answer with the window you actually meet, not the window in your vulnerability management policy. The two are often different, and the gap between them is a finding waiting to happen in both an audit and a claim investigation. If the policy says fourteen days and the data says thirty, either fix the practice or amend the policy, but do not warrant the policy.
End-of-life software gets its own treatment because it is frequently handled by exclusion rather than by pricing. An unsupported operating system, database engine or hypervisor in the insured environment can result in an endorsement removing cover for any loss arising from it. If you have one, the useful move is to scope it out of the environment or to disclose it with the compensating controls, not to hope the question is read loosely.
Social engineering and funds transfer fraud cover is usually sublimited, and the sublimit is usually conditioned on a specific process control. The questions ask whether changes to vendor banking details are verified out of band using contact details held on file rather than details supplied in the request, and whether payments above a threshold require a second authoriser.
These are finance controls, and they are frequently answered by the security lead who does not operate them. Get the answer from whoever runs accounts payable, and get it in the form of the actual procedure. The evidence is the written procedure plus a sample of executed verifications: the callback log, the second approval in the payment system, the ticket where a change of details was refused because the number did not match the one on file.
The failure mode here is a policy that describes verification and a finance function that does it inconsistently under time pressure. That is exactly the pattern that produces a denied claim, because the insurer will ask for the verification record for the specific fraudulent payment, and the answer will be that the process is normally followed.
This is worth attention out of proportion to its premium, because it is the one class of loss where a small company with otherwise average controls can suffer a six-figure event in a single afternoon, and where the sublimit is often the difference between a covered loss and an uncovered one.
The application asks for assertions. It does not usually ask for evidence at submission. That is why the evidence discipline gets skipped, and it is why teams get caught. The insurer does not need the evidence to bind the policy. They need it at claim time, and by then the artefact either exists with a date inside the policy period or it does not exist at all.
The distinction that matters is between a record you can produce today and a record that only exists if it was made at the time. Configuration exports, policy documents and inventories can be produced at any point, because they describe a present state. A restore test, a tabletop record, a phishing simulation result and a training completion report describe an event, and an event record created afterwards is not a record of the event. If you did not run a restore test during the policy period, you cannot produce one for that period later, and no amount of remediation afterwards changes that.
The practical structure is an insurance evidence folder that mirrors the application, one item per answered question, refreshed on the same cadence as the renewal. Each item wants the same four properties: a visible date, a visible scope or population, an identifiable system as the source, and a named person who produced it. That is the same standard an auditor applies, which is the point. Build it once and it serves the renewal, the audit and any customer security review.
The sequence after a significant incident is predictable. You notify under the policy, usually within a short notice window and usually to a specified address rather than to your broker alone. The insurer appoints or approves counsel and a forensic firm. Forensics produces a report that establishes the initial access vector, the dwell time and the scope of data affected. That report is written for the insurer, and it will state plainly whether the account used to gain access had multi-factor authentication, whether the exploited software was supported, and whether the encrypted data had a recoverable copy.
That is the moment the application is re-read. If the form said MFA was enforced on remote access and the forensic report says the initial access was a remote desktop session with a password alone, the conversation shifts from indemnity to coverage. Depending on the wording, the insurer may reserve rights, deny the specific loss under a control condition, or seek to void the policy entirely for misrepresentation. The version of that outcome nobody expects is that the policy is voided, which removes cover for the whole period, not just the loss in question.
There is a second and subtler failure. Some policies carry conditions requiring you to maintain the stated controls throughout the period, not merely to have them at inception. A company that enforced MFA at placement, then created an exception for a contractor in month seven and never removed it, has a maintenance problem rather than a placement problem. This is the same failure as control drift in an audit program, and it has the same cause: nobody owns the ongoing check. Our note on control drift between audits covers the mechanics.
The defensive posture is unglamorous. Keep the signed application. Keep the evidence that supported each answer, dated within the period. Re-run the same checks at renewal and keep those too. If a control changes materially mid-term, tell the broker in writing at the time rather than discovering the significance of it during a claim.
The honest answer is that a report or certificate is not a discount coupon, and any broker who promises a fixed percentage is describing their relationship with one underwriter rather than the market. Underwriters price the controls, not the attestation. A company with a clean SOC 2 report and no immutable backup copy is still a poor ransomware risk, and will be priced as one.
What the attestation does is change the quality and speed of the conversation. Three effects are consistent enough to plan around. Underwriting friction drops, because the control questions are answerable immediately and consistently, and supplementary questions get answered in days rather than weeks. Access to capacity improves, particularly at higher limits and with insurers who will not write a first-time risk with self-attested controls. And the evidentiary position at claim time is materially better, because a Type II report describes controls that operated across a period and is produced by an independent firm, which is a different class of proof from your own assertion.
There is also a real indirect effect on price, which is that the work required to pass an audit closes exactly the gaps that load a cyber premium. MFA enforcement, offline backups, restore testing, an exercised incident response plan, access reviews and vendor management are audit requirements and underwriting questions at the same time. Teams routinely see their renewal improve after a readiness program, and attribute it to the certificate when it was caused by the remediation.
If you are choosing between frameworks with insurance partly in mind, the choice barely matters, and the buyer-driven reasons in our SOC 2 versus ISO 27001 comparison should decide it. What matters more is timing: getting the control remediation done before the renewal date rather than after it.
Most buyers compare limit and premium and stop. The terms that determine whether a policy pays are further in, and four of them are worth reading properly every year.
Sublimits carve the headline limit into much smaller amounts for specific losses. Social engineering, funds transfer, ransom payment, business interruption from a dependent system, and regulatory fines are the ones commonly sublimited. A five million dollar policy with a two hundred and fifty thousand dollar social engineering sublimit is a two hundred and fifty thousand dollar policy for the loss most likely to happen to a company your size.
The waiting period on business interruption is a time deductible, not a dollar one. If it is twelve hours and your outage lasted ten, the business interruption cover pays nothing regardless of the loss. Retentions apply per claim. Ransomware coinsurance, where you retain a percentage of the loss, appears when the underwriter is uncomfortable with the backup answers, and it is a signal worth reading rather than accepting quietly.
Panel provisions decide who responds. Most policies require you to use approved counsel and approved forensic providers, or to obtain consent before incurring costs. Costs incurred before notification are frequently not covered. This has an operational consequence: the incident response plan needs the insurer notification step and the panel contact in it, at the top, because the natural instinct at hour one is to call your own people and worry about the policy later. That instinct costs money.
Finally, check the definition of the insured entity and the covered systems. Subsidiaries, newly acquired companies and systems operated by a managed provider are all places where the scope of the policy and the scope of your actual environment quietly diverge.
Open the renewal file ninety days before the expiry date. That is not conservatism, it is arithmetic. The broker wants submission material roughly forty-five to sixty days out to market the risk properly. Anything you need to fix in order to answer a question truthfully needs to be fixed before that, and control changes that require a coverage or configuration rollout take weeks. Ninety days gives you one fix cycle. Thirty days gives you none, and you renew on last year is answers.
The file itself is short. Last year is signed application, so you can see what you warranted. The current control evidence, one artefact per question, dated within the last quarter. A note of every material change in the environment since the last renewal: new systems, new data types, new jurisdictions, new subprocessors, headcount, revenue. A record count and data classification summary, because notification exposure drives pricing. Any incidents, including ones that did not become claims, since insurers ask and non-disclosure of a known circumstance is its own coverage problem.
Two weeks before submission, run the control checks again rather than reusing the artefacts from the file. The purpose is to catch drift, and drift is common: an MFA exception granted for a contractor, an endpoint agent that stopped reporting on a subset of machines after a fleet change, a backup job that has been failing silently since a credential rotation. Finding these before you sign is the entire point of the exercise. Our cyber insurance readiness tool walks the same question set, and the note on what to do when an insurer asks about controls covers the shorter version of this conversation.
The application is completed by someone who does not operate the controls. This is the root cause of most of the others. The person with the form has the deadline, and answering yes moves the form along.
A control is described from the policy rather than the system. The policy says quarterly access reviews and the last one was fourteen months ago. The policy says fourteen-day patching and the data says thirty. The form warrants the policy, and the policy is aspirational.
MFA is answered yes on the basis of the main login path, with legacy protocols, application passwords or a single sign-on bypass still open. This is the specific gap most often found by forensics after a business email compromise.
Backups are asserted without an immutable or separated copy, because snapshots feel like backups. The distinction only becomes visible when someone holds your production credentials.
The restore test, tabletop and phishing simulation were never run during the period, and cannot be created afterwards. This is the one category of gap that cannot be remediated retroactively at all.
Coverage percentages are asserted without a denominator, because there is no asset inventory. The number is a guess presented as a measurement.
A control lapses mid-term and nobody notices, so the position at claim time differs from the position at placement.
The incident response plan does not contain the insurer notification step or the panel contacts, so the first forty-eight hours generate costs that are outside the policy.
Nobody kept the signed application or the supporting evidence, so at claim time the company cannot reconstruct what it said or prove what was true.
Take the control question list and assign each question a named owner who operates that control. Give them two weeks to return an answer and an artefact. Collect the artefacts in one place with the date visible in the filename.
Sort the answers into three groups: true and evidenced, true but not evidenced, and not true. The middle group is a documentation problem and is usually a day of work. The last group is a remediation decision, and the question for each item is whether it can be closed before submission or has to be disclosed.
Fix what is cheap and high-value first, in this order: MFA enforcement gaps, an immutable or separated backup copy, endpoint agent coverage, payment verification procedure. Those four move more premium and more coverage than anything else available to a small company, and none of them requires a budget cycle.
Schedule the recurring records so that the next period is evidenced whether or not anyone is thinking about insurance: a quarterly restore test, an annual tabletop, quarterly access reviews, and training with a completion report. Put them on the same calendar as the audit obligations, because they are the same obligations. Our compliance calendar sets out what genuinely repeats.
Then submit, keep the file, and re-run the checks two weeks before the next renewal. The whole cycle is a few days of work a year once the recurring records are running, and it is the difference between a policy that pays and a policy that is litigated.
| Application question | What a yes actually requires | Evidence to hold |
|---|---|---|
| MFA on email | Enforced by configuration for all users, with legacy authentication protocols disabled and no silent exceptions. | Identity provider export listing every active user with enforcement state, dated, with a total count visible. |
| MFA on remote access | Every VPN, remote desktop and jump host path. No direct internet exposure of remote desktop. | Access configuration export plus an external scan or firewall rule listing showing no exposed remote desktop. |
| MFA on privileged accounts | Cloud consoles, identity provider admins, production database access and source control owners, with the privileged population defined. | Privileged account list with enforcement state, reconciled to the access review for the same period. |
| Offline or immutable backups | A copy in a separate account or tenancy, or under object lock, that production credentials cannot delete inside the retention window. | Backup configuration showing retention and immutability settings, plus the account or tenancy separation. |
| Backups are tested | A restore was actually performed and timed against the recovery objective, not a job success report. | Dated restore test record naming the tester, the system restored, elapsed time and issues found. |
| Endpoint detection deployed | A stated coverage percentage against a defined endpoint population, with stale agents counted as gaps. | Agent coverage report reconciled to the asset inventory, both dated the same day. |
| Critical patches within a stated window | The window you actually meet, evidenced across a period, not the window written in the policy. | Vulnerability scan history or patch report showing time to remediate by severity across a quarter. |
| No end-of-life software in scope | No unsupported operating systems, databases or appliances in the insured environment, or the exceptions disclosed. | Inventory filtered by operating system and version, with support status stated per record. |
| Incident response plan, tested | A plan with named roles and an exercise actually run within the last twelve months. | Tabletop record with date, attendees, scenario, decisions taken and the resulting actions with owners. |
| Payment change verification | Out-of-band callback to a number held on file, plus dual authorisation above a threshold, operated consistently. | Written procedure plus a sample of executed verifications from the period. |
| Security awareness training | Completion across the whole staff population, including contractors and executives, with phishing simulation results. | Completion report by person, with the roster it was measured against and the non-completions named. |
| Access is reviewed periodically | Reviews with a recorded decision on every account and evidence that the revocations were actioned. | Review record with the population, the reviewer, the per-account decisions, and the confirmations of revocation. |
Sometimes, but not reliably, and not as a fixed discount. Underwriters price the specific controls rather than the attestation, so a report with weak backup answers behind it will not help much. What a report does consistently is speed up underwriting, improve access to capacity at higher limits, and give you independent third-party evidence that the controls operated across a period, which is valuable if a claim is ever contested. The larger real effect on price usually comes from the remediation work done to pass the audit, because it closes the same gaps that load the premium.
Tell your broker in writing as soon as you find out, before any incident. An error corrected proactively is normally an underwriting adjustment, which may mean a revised premium or an endorsement. The same error discovered by a forensic investigator after a loss is a coverage dispute, and depending on the wording and the materiality it can result in the specific loss being denied or the policy being voided for the whole period. The cost difference between the two paths is very large, and the only thing that separates them is who found it first.
At placement, most ask only for the answers, sometimes with a short supplementary form for ransomware. Evidence is requested at two points: occasionally during underwriting for a higher limit or after a poor answer, and routinely during a claim investigation. The mistake is to read the absence of an evidence request as evidence not mattering. The artefact has to exist with a date inside the policy period, and event records such as restore tests and tabletop exercises cannot be created after the fact.
Limits of one to five million dollars are common for seed and Series A companies, and the number is usually set by what customer contracts require rather than by a loss model. Read the contracts before setting the limit, because enterprise agreements frequently specify a minimum. Pay at least as much attention to the sublimits for social engineering, funds transfer and business interruption, and to the business interruption waiting period, since those determine what the policy pays for the losses most likely to occur at your size.
Usually not. The question behind the backup section is whether a copy survives an attacker who holds valid production credentials. Snapshots in the same account, under the same permissions, do not survive that, because the credentials that can create them can generally delete them. The fix is either a copy in a separate account or tenancy with a distinct credential path, or object lock and a retention policy the production identity cannot shorten. This is one of the few underwriting gaps that a small team can genuinely close in a couple of weeks.
Ninety days before expiry. The broker needs submission material around forty-five to sixty days out to market the risk, so anything that has to be fixed in order to answer truthfully has to be found before that. Ninety days leaves one cycle to close a control gap and produce the evidence. At thirty days there is no time to fix anything, so you either renew on last year answers that may no longer be true, or you disclose a gap you could have closed.
The officer signs it, but they should not answer it. Each control question should be answered by the person who operates that control and returned with the artefact that supports the answer. Notably, the payment verification questions belong to finance rather than to engineering, and they are frequently answered by the wrong person. Assemble the answers, check each one against the system rather than against the policy, then have the officer sign a form they have reason to believe is accurate.
Yes, in one specific way. Most policies require prompt notification to a stated address and require approved counsel and forensic providers, and costs incurred before notification are often not covered. So the insurer notification step and the panel contacts belong near the top of the plan, ahead of the technical response steps, along with the policy number and the notice deadline. Teams that leave this out call their own lawyer and their own forensics firm in hour one and create uncovered costs before anyone has read the policy.
traztech Workspace has every control of whichever frameworks apply to you, written in plain English, with somewhere to attach the proof. Free to use, with no card and no trial clock.
No credit card, no trial clock, no locked features. We make money when someone wants help closing the gaps, not from the Workspace.
| traztech Workspace | Other GRC platforms | |
|---|---|---|
| Licence cost | $0. Free forever, no card, no paid tier | $7,500 to $50,000 a year, on an annual contract |
| Control library, evidence register, policy templates, risk register, vendor questionnaires, readiness scoring | Included | Included |
| What it costs inside an engagement with us | $0. You need a workspace either way | Unchanged. The subscription sits on top of the fee |
| What it does to your audit quote | $11,000 off a five-figure quote on one engagement, for a documented readiness position | Nothing. The audit firm prices your readiness, not your tooling |
Pricing in the right column is what compliance automation platforms are publicly reported to charge; none of them publish a number, so treat it as a range rather than a quote. The $11,000 came off the audit firm's own number once the readiness position was documented (the engagement). Where a paid platform is the better buy, and the fuller comparison, is on the Workspace page.
We run the same control checks an underwriter is pricing, tell you which answers your evidence supports, and fix the ones it does not.
Book a strategy callWant the human version?
Jacob sends a few short, practical notes on getting security and compliance right without the months of pain. No fluff, unsubscribe in one click. Reply anytime; it reaches him directly.
From Jacob Masse, founder of traztech. No spam, unsubscribe in one click.
Track record
Five published CVEs. CVE-2024-45163 (CVSS 9.1) is a flaw in the Mirai botnet itself, which gave defenders a way to shut down attacker infrastructure. CVE-2026-42626 takes HP ENVY 5000 printers offline from any unauthenticated device on the same network.
At Humera, a venture-backed US security company, Jacob built the compliance programme in-house from nothing: no report, no policies, no documented controls. It ended in a Type II attestation across 76 controls with zero exceptions, on a team of 15.