Cyber insurance asks for missing controls: how to respond safely

TL;DR — Your insurer is usually asking for a small set of concrete security controls: multi-factor authentication (MFA), endpoint protection, backups, logging, patching, and privileged-access restrictions. The most common fix is to stop treating the questionnaire as legal wording and map each question to a real system check; if you truly do not have the control, do not answer "yes" — either implement it, document an equivalent control, or ask your broker/insurer for an exception in writing. Reading time: ~6 min

The scenario

It is Tuesday afternoon, your renewal form is due tomorrow, and the questionnaire suddenly asks whether you enforce MFA (multi-factor authentication), maintain offline or immutable backups (backups that cannot be altered), run endpoint detection and response (EDR, security software on laptops/servers), and restrict admin access with least privilege (only the access needed). You know your agency hosts the app, your staff use Google Workspace or Microsoft 365, and your client data lives in a cloud database — but you are not sure which boxes you can honestly tick. Your broker says, "Most customers have these," which is not helpful. You need a fast, defensible answer that will not create coverage problems later.

Symptoms

• The renewal form asks questions like:
  • "Do you enforce MFA for all remote access, email, VPN, and privileged accounts?"
  • "Are backups encrypted, offline, or immutable?"
  • "Do you deploy EDR on all endpoints?"
  • "Do you restrict local administrator rights?"
  • "Do you patch critical vulnerabilities within 14 days?"
• You cannot point to a setting, policy, or report that proves the control exists.
• Different people in your team give different answers: "I think Google prompts count as MFA" / "We back up the database, but I do not know if it is immutable."
• The insurer or broker asks for evidence such as screenshots, policy documents, or exportable reports.
• You discover gaps such as:
  • Some staff can still log in to email without MFA.
  • Production backups exist, but can be deleted by the same admin account that manages production.
  • Laptops are managed inconsistently, or not at all.
  • Shared admin accounts exist for hosting, DNS, or the cloud provider.

Likely causes

Step-by-step diagnosis

1. Identify the exact control being asked.

   • Action: Copy the insurer question into your working notes and underline the nouns: "MFA", "all users", "privileged accounts", "immutable backups", "EDR", "within 14 days".
   • This is your problem if: the question contains a scope you have not checked, such as "all users" or "all privileged accounts".
   • Jump to: the matching fix section below.

2. Check identity and email first, because MFA is the most common blocker.

   • Action: In your identity provider dashboard, open the security page.
     • Google Workspace example: Admin console → Security → Authentication → 2-Step Verification.
     • Microsoft example: Entra admin center → Protection/Security → MFA or Conditional Access.
   • This is your problem if: MFA is optional, excluded for some users, or not separately enforced for admin roles.
   • Jump to: ### MFA is enabled for some users but not enforced for all users/admins.

3. Check who has admin access.

   • Action: In each core system dashboard — email/identity, cloud provider, DNS provider, password manager — open Users/Roles or IAM (identity and access management).
   • This is your problem if: you see shared logins like "admin@company", more admins than expected, or staff using the same account for daily work and admin tasks.
   • Jump to: ### Privileged access is too broad.

4. Check backup properties, not just whether backups exist.

   • Action: In your hosting/cloud/backup dashboard, open the production backup policy and look for retention lock, immutable/object lock, or a separate backup account.
   • This is your problem if: backups can be deleted by the same production admins, or there is no immutable/locked retention setting.
   • Jump to: ### Backups exist, but they are not offline/immutable.

5. Check endpoint coverage.

   • Action: In your device management or security console, open Devices and export the list. Compare it with payroll/HR or your laptop inventory.
   • This is your problem if: active staff devices are missing, unmanaged, or have no security agent installed.
   • Jump to: ### Endpoint protection/EDR is missing or incomplete.

6. Check whether patching is provable.

   • Action: In your device/server management dashboard, open update compliance and try to export a report for the last 30 days.
   • CLI fallback for Linux servers:

apt list --upgradable 2>/dev/null | sed -n '1,20p'

• This is your problem if: you cannot show compliance by deadline, or critical updates have been pending longer than your insurer allows.
• Jump to: ### Patch management exists informally, but there is no evidence.

1. If you think you have an equivalent control, test whether it is documentable.
   • Action: For one questionnaire item, collect one screenshot/report and one sentence of explanation.
   • This is your problem if: the explanation starts with "We usually..." instead of "Here is the setting/report/policy".
   • Jump to: ### The insurer's wording does not match your setup, but you have an equivalent control.

[Questionnaire] ---- 1. identify control ----> [Checklist]
                                         |
                                         v
                                [Identity/MFA check]
                                         |
                                         v
[Admin roles check] ---- 4. backup check ----> [Backup policy]
                                         |
                                         v
                              [Devices/patch evidence]
                                         |
                                         v
                              [Answer yes/no/exception]

Fixes

MFA is enabled for some users but not enforced for all users/admins

• In your identity provider dashboard, turn MFA from optional to enforced.
  • Google Workspace: Admin console → Security → Authentication → 2-Step Verification → Allow users to turn on 2SV = On, then Enforcement = On for the required organizational units.
  • Microsoft: Entra admin center → Protection/Security → Conditional Access → create a policy requiring MFA for all users; create a separate stricter policy for admin roles.
• Remove exclusions unless they are documented break-glass accounts (emergency admin accounts kept offline and tightly controlled).
• For admin roles, require phishing-resistant methods where available, such as security keys.
• Verify it worked: sign in as a normal user and as an admin; both should be prompted for MFA.

Backups exist, but they are not offline/immutable or are controlled by the same admin account

⚠️ Changing backup retention or object lock can increase storage costs and, in some systems, cannot be undone until the retention period expires.

• In your backup or cloud storage dashboard, enable immutable retention/object lock on the backup destination if your provider supports it.
• Put backups in a separate account/project/tenant from production if possible, with separate admin credentials.
• If your current provider cannot do immutability, document the gap and answer the insurer honestly while planning a change.
• Example S3-compatible CLI fallback for object lock on a new bucket:

aws s3api create-bucket --bucket company-prod-backups --object-lock-enabled-for-bucket
aws s3api put-object-lock-configuration --bucket company-prod-backups --object-lock-configuration '{"ObjectLockEnabled":"Enabled","Rule":{"DefaultRetention":{"Mode":"COMPLIANCE","Days":30}}}'

• Verify it worked: the bucket or backup policy shows object lock/immutable retention enabled, and a test backup cannot be deleted before expiry.

Endpoint protection/EDR is missing or only installed on some laptops/servers

• In your device management or security console, enroll all company-managed laptops and any servers in scope for the questionnaire.
• If you do not have a device manager yet, start with your existing platform's built-in management first (for example, the one tied to your email/identity platform) and deploy the security agent to all active devices.
• Export the device list and chase missing devices by owner.
• Verify it worked: enrolled device count matches your active device inventory, and each device shows the security agent as healthy.

Privileged access is too broad: shared admin accounts, too many admins, no separate admin accounts

• Remove shared admin logins. Give each person a named account.
• Create separate admin accounts for staff who need admin rights; do not use day-to-day email accounts for admin tasks.
• Reduce global/super admin roles to the smallest practical set.
• In each provider dashboard, review roles:

# CLI example for AWS: list IAM users and attached admin policies
aws iam list-users
aws iam list-attached-user-policies --user-name USERNAME

• Verify it worked: you can list every admin by name, there are no shared credentials, and admin accounts are separate from normal accounts.

Patch management exists informally, but there is no evidence or deadline-based process

• Turn your update process into a reportable one using your device/server management dashboard.
• Set a written internal target that matches the insurer's wording, such as "critical patches within 14 days".
• For Linux servers, schedule unattended security updates if appropriate:

sudo apt-get update
sudo apt-get install -y unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

• Keep one monthly export or screenshot showing compliance status.
• Verify it worked: you can produce a dated report showing patch status and exceptions.

The insurer's wording does not match your setup, but you have an equivalent control

• Do not guess. Write a short exception/equivalency note and send it to your broker or insurer before submission.
• Template you can paste into email:

Question: "Do you enforce MFA for all privileged accounts?"
Answer: We enforce MFA for all workforce identities through our identity provider, including all administrator roles. Evidence attached: screenshot of MFA enforcement policy and admin role policy. If you require a vendor-specific control name, please confirm this equivalent control is acceptable.

• If they reject the equivalency, answer "no" and attach your remediation plan with target date.
• Verify it worked: you receive written confirmation from the broker/insurer, or you submit a truthful "no" with supporting notes.

Prevention

• Keep a one-page control register for renewals. Use a simple table with columns: Control, System, Owner, Evidence, Review date.

[
  {"control":"MFA for all users","system":"Google Workspace","owner":"IT admin","evidence":"2SV enforcement screenshot","review_date":"2026-11-01"},
  {"control":"Immutable backups","system":"Cloud backup bucket","owner":"Ops","evidence":"Object lock policy export","review_date":"2026-11-01"}
]

• Add a quarterly admin-access review. Export admin roles from identity, cloud, DNS, and password manager; remove any unnecessary admins the same day.
• Add a monthly evidence folder for compliance. Save one screenshot or export each month for MFA enforcement, backup policy, device coverage, and patch compliance.
• Put security checks into onboarding/offboarding: no new starter is complete until their device is enrolled and MFA is enforced; no leaver is complete until accounts are disabled and admin roles removed.
• Add a renewal pre-check 60 days before insurance renewal. Use this checklist: MFA enforced, admin roles reviewed, backup immutability checked, device coverage exported, patch report exported.
• If your agency manages systems for clients, separate "what we operate" from "what the client owns" in writing so the questionnaire is answered against the correct scope.

This article was written by an AI system and published pending human review. Verify anything you intend to act on.