Guide · Cyber insurance questionnaires
A cyber-insurance application or renewal questionnaire arrives, and most of it is written for a company with laptops, an IT department, and endpoint software. You run a WordPress or WooCommerce business on a server. The questions still apply — they just land on different things: the hosting panel rather than a domain controller, plugin updates rather than a patch management suite, a database and an uploads directory rather than file shares. This guide maps the questions that actually matter for a web business onto controls you can verify and evidence, and is explicit about which ones are not yours to answer.
Published Last reviewed
Why it matters
Insurer questionnaires are answered under a duty of accuracy. That makes an optimistic answer a category of risk all its own: misrepresented controls are a well-established reason for a carrier to dispute or decline a claim, which means the answer fails at precisely the moment the cover was supposed to work. A gap you disclosed is priced. A gap you asserted away is an argument you have later, under the worst possible conditions.
The practical consequence is counter-intuitive. A questionnaire with several honest “no, but here is the plan and the date” answers is a stronger position than one with uniform yeses that nobody could evidence. Underwriters see incomplete controls constantly and price them. What they cannot price is an answer that turns out to be wrong.
The second consequence is about method: almost nothing on the form should be answered from memory. “We have backups” and “a restore has been performed and it worked” are different statements, and only one of them is a control. The questionnaire is asking about the second and most businesses answer with the first.
The mapping
Generic guidance on these forms is written for corporate IT and will tell you to deploy endpoint detection on every workstation. Here is what the same questions are actually asking when the asset is a website and the server under it.
| The questionnaire asks | What that means for your site and server | Evidence that answers it |
|---|---|---|
| Is MFA enforced for administrative access? | Coverage on the hosting or control panel, the domain registrar, the WordPress administrator accounts, and the email account those recover to. Checked per account, not assumed from a policy. | An account-by-account list showing MFA state, including the accounts that do not have it. |
| Are systems patched and supported? | WordPress core, plugins, and themes — including anything abandoned or removed from the directory — plus the PHP version's support status and the operating system's. | A component inventory with versions, update cadence, and support-window notes. |
| Is access restricted and controlled? | Named accounts rather than a shared login, least privilege on WordPress roles, how SSH and SFTP are exposed and authenticated, and how contractor access is granted and removed. | An account inventory with privilege levels, plus the access-removal record for people who have left. |
| Are backups maintained and tested? | Where backups live relative to the server, whether an attacker with site access could reach or delete them, whether the database and the uploads directory are both covered, and whether a restore has ever actually been run. | Backup configuration, retention, separation from the host — and the result of a restoration test with its date. |
| Is activity logged and retained? | Authentication events, administrative changes in WordPress, and web-server access logs: what is captured, where it lives, how long it survives, and whether someone with site access could erase it. | A log source inventory with retention periods and who can modify them. |
| Is endpoint protection deployed? | Usually written for workstations. For a web business the meaningful reading is server-side malware detection and file-integrity monitoring, plus whatever runs on the machines that hold administrative credentials. | What is installed, what it covers, and — importantly — who reads its alerts. |
| Is there an incident response plan? | Who is called, who can suspend the site or take it offline, who talks to customers, where backups and credentials are held, and how the hosting provider is engaged out of hours. | A written plan naming people and contact routes, not a document describing a process in the abstract. |
| Is cardholder or personal data handled? | Whether payments are redirected to a gateway or captured on your own pages, what customer data the database holds, and how long it is kept. On WooCommerce this determines which PCI obligations attach to you. | A data inventory and the checkout integration method, stated precisely. |
The usual gaps
In practice a handful of items account for most of the “we do not actually know” answers on these forms. None of them is unusual and all of them are fixable — but they take time, which is the argument for starting before the renewal date.
Backups run nightly and report success, and nobody has ever restored one. Backup success and restoration readiness are separate questions, and only a performed restore answers the second. This is the single most common gap.
A backup on the same server, or in a location the site's own credentials can reach, does not survive the scenario the insurance covers. Ransomware and destructive attackers look for backups first.
The hosting panel, the registrar, and the recovery email are the accounts that can undo everything else. MFA on WordPress administrators alone leaves the doors either side of it open.
A scanner is installed and its output goes to a mailbox nobody opens, or to a former employee. The control exists and does not function, which is harder to answer honestly than having no control at all.
Developers, agencies, and freelancers accumulate administrator accounts, SFTP logins, and SSH keys. An access list nobody has reviewed in two years is a question you cannot currently answer.
Default retention on shared hosting is frequently days. If an intrusion is discovered a month later, the evidence an insurer or a forensic investigator would want has already rotated away.
Ownership
Several questions concern controls your hosting provider owns: physical security, hypervisor and network isolation, parts of the perimeter, and on managed platforms some of the patching. Answering those on the provider's behalf is a bad idea in both directions — you are asserting something you cannot verify, and you are obscuring a genuine dependency.
The better approach is to mark them explicitly as provider-dependent, reference the provider's published assurances or certifications where they exist, and ask the provider directly where they do not. That gives the insurer an honest boundary instead of an answer nobody could stand behind, and it gives you a clear list of what is actually within your reach to improve.
The distinction is sharper than it looks on managed WordPress hosting, where the platform may own updates, backups, and server hardening while you still own the accounts, the plugins, and the data. Read each question against your actual plan rather than against the general idea of “hosting”.
Getting ready
The work is mostly inventory and verification rather than engineering, and it is much cheaper done deliberately in advance than assembled in the week the form is due.
Ask your broker for the questionnaire early, or reuse last year's. The questions vary enough between carriers that preparing against a generic checklist leaves gaps in the specific one you have to sign.
Every account that can change the site or the server: WordPress administrators, hosting panel, registrar, SFTP and SSH, database users, deployment tooling, and the email accounts they recover to. Most questionnaire items are answerable once this list exists.
Restore to a staging environment, record how long it took, and note what was missing. This converts the most commonly overstated answer on the form into one you can evidence — and it frequently discovers that the uploads directory or the database was not covered.
A setting that appears enabled and a control that demonstrably holds are different claims. Where a question matters, confirm the behaviour: that MFA is actually required, that the backup actually restores, that the log actually retains.
Each gap gets an owner and a date. That list is both your remediation plan and, where a control is still missing at signing, the honest exception you disclose alongside the answer.
If a control was fixed in order to answer yes, verify it again after the change. The answer should reference a verified end state, not an intention, and the date of that verification is worth recording.
The inventory, the restore test result, and the remediation record are worth as much after a claim as before one — and they should not live solely on the system the claim would be about.
Beyond insurance
Insurer questionnaires are the most common trigger for this work but rarely the only one. Enterprise clients send vendor security assessments, payment providers ask about data handling after an incident, and larger customers increasingly ask agencies to evidence controls on the sites they manage. The questions overlap heavily, and the evidence assembled for one answers most of another.
That is the practical argument for treating this as a standing inventory rather than an annual scramble: the account list, the component inventory, the restore test, and the log retention record are the same artifacts every time, and they are only expensive the first time.
Common questions
No. A planned control is not an implemented one, and the gap between them is exactly what a carrier examines after a claim. Answer accurately and disclose the plan and its date alongside — that is a normal and well-understood position to be in, and it is priced rather than disputed.
Describe what you actually have and where the assets are. For a web business the meaningful equivalents are server-side malware detection and file-integrity monitoring, plus protection on whatever machines hold administrative credentials. Ask the broker how the carrier reads the term rather than guessing at it — this is one of the most commonly misanswered items on these forms.
It is enough for the parts they actually own, which is usually less than the phrase suggests. Managed hosting may cover server patching, platform backups, and network controls while you still own accounts, plugins, WordPress-level access, and the data. Get the split in writing and answer each question against the correct owner.
Usually not for an application or renewal. Most questionnaire items are about controls existing and being verifiable, which an audit answers. A penetration test answers a different question — whether controls hold against an attacker — and is more often requested by enterprise clients or after an incident than by a carrier at renewal.
Generally no, and concealing it is considerably worse. What tends to matter is what changed afterwards: what was found, what was remediated, and whether it was verified. An incident with a documented response and retest is a much better story than an incident that was quietly cleaned up.
The inventory and verification work is typically days rather than weeks. What extends it is remediation — a gap like untested restores or missing MFA coverage takes as long as the fix takes, and that is the argument for starting well before the renewal date rather than in the week the form is due.