Meeting Cyber Insurance Technical Requirements: A Control Implementation Guide

Problem

Cyber insurance has transformed from a financial instrument into a technical audit process. Before 2020, most cyber insurance policies were relatively easy to obtain: answer a short questionnaire about whether you had antivirus and firewalls, pay a premium, and receive coverage. The wave of ransomware attacks on underinsured organisations changed this fundamentally.

Insurers now require detailed technical evidence of specific security controls before issuing or renewing policies. Applications are 20–40 pages of technical questions. Underwriters request screenshots, configuration exports, and policy documents. Some insurers deploy automated scanners against your internet-facing infrastructure before quoting. Premiums for organisations that cannot demonstrate the required controls have increased 200–400% since 2020, and coverage terms have narrowed significantly.

The controls that virtually all major insurers now require:

Multi-factor authentication on all privileged access. This is no longer “do you have MFA” — it is “do you have MFA on all accounts with privileged or administrative access, with no exceptions?” Insurers specifically ask about break-glass accounts, service accounts, remote access, and cloud management consoles. A single admin account without MFA can void coverage for ransomware.

Endpoint Detection and Response (EDR) on all managed endpoints. Basic antivirus is no longer sufficient. Insurers require EDR — specifically, solutions that provide behavioural detection, telemetry, and automated response capabilities. Coverage of all managed endpoints is required, not just a majority. Unmanaged endpoints in a BYOD environment need to be addressed via NAC or policy.

Immutable, tested backups with offline or air-gapped copies. Ransomware that can also encrypt backups is the reason for this requirement. Insurers ask whether backups are: (a) stored separately from production, (b) cannot be modified or deleted from the production environment, and © tested via restoration at least quarterly. Many organisations have backup infrastructure but fail on the “tested” and “isolated” requirements.

Documented and tested incident response plan. The plan must be documented, reviewed within the last 12 months, and tested via a tabletop exercise. “We know what we’d do” is not acceptable — insurers want dated test records.

Vulnerability management with defined patch SLAs. Critical vulnerabilities must be patched within defined timeframes. Insurers ask for evidence of a vulnerability scanning programme and the SLA for critical patches (typically ≤30 days, with ≤7 days now requested by some underwriters for internet-facing systems).

Email security controls. Anti-phishing controls (DMARC with p=reject, anti-spoofing, attachment sandboxing) and anti-spam filtering are required. Email remains the primary ransomware delivery vector.

Network segmentation. Flat networks that allow lateral movement from any endpoint to any server receive higher premiums or coverage exclusions. Basic segmentation of production from corporate environments is typically required.

Failing to implement these controls doesn’t just mean a higher premium — it means coverage exclusions. A ransomware claim where the attacker entered via a privileged account without MFA will be denied if the policy requires MFA on all privileged accounts.

Target systems: any organisation purchasing or renewing cyber insurance; security teams responsible for demonstrating control implementation to underwriters; CISOs managing the insurance questionnaire process.

Threat Model

The “threat” in this context is financial exposure — the risk of a denied claim due to control gaps identified post-incident:

Risk 1 — MFA gap discovered post-breach. A ransomware attacker compromised an admin account that lacked MFA. The insurer’s forensic team discovers this. The claim is denied under the “failure to maintain required controls” exclusion.

Risk 2 — Backup compromise undermines recovery. Ransomware encrypted production systems and the backup server. The backup was on the same network segment, reachable from production. The insurer argues that adequate backup controls were not in place and reduces the claim payout.

Risk 3 — Unmanaged endpoint is the entry point. A contractor’s personal laptop (unmanaged) was used to access a corporate VPN. The laptop had malware. The insurer denies the claim because the endpoint was not covered by the required EDR deployment.

Risk 4 — Undocumented IR plan during a claim. The incident response was improvised. No documented plan existed. The insurer argues the organisation did not have “the capability to respond to an incident” as required by the policy and reduces the settlement.

Configuration / Implementation

Step 1 — MFA coverage audit and remediation

The most common coverage gap. Map every privileged access path:

#!/bin/bash
# mfa-coverage-audit.sh — identify accounts without MFA

echo "=== AWS Root Account MFA ==="
aws iam get-account-summary \
  --query 'SummaryMap.AccountMFAEnabled' --output text
# Expected: 1 (enabled)

echo ""
echo "=== AWS IAM Users without MFA ==="
aws iam generate-credential-report 2>/dev/null && sleep 5
aws iam get-credential-report --output text --query 'Content' | \
  base64 -d | \
  awk -F',' 'NR>1 && $8=="false" && $1!="root" {print "NO MFA: "$1}'

echo ""
echo "=== Okta Users without MFA Enrolled ==="
# Requires Okta admin token
curl -s -H "Authorization: SSWS $OKTA_API_TOKEN" \
  "https://YOUR_ORG.okta.com/api/v1/users?limit=200" | \
  jq -r '.[] | select(.status == "ACTIVE") | .profile.login' | while read -r user; do
  factors=$(curl -s -H "Authorization: SSWS $OKTA_API_TOKEN" \
    "https://YOUR_ORG.okta.com/api/v1/users/${user}/factors" | jq length)
  [[ "$factors" == "0" ]] && echo "NO MFA: $user"
done

# Azure AD — users without MFA registration
az ad user list --query '[].{upn:userPrincipalName}' -o tsv | while read -r upn; do
  mfa=$(az ad user authentication-methods list --user-id "$upn" \
    --query '[?methodType != null] | length(@)' 2>/dev/null || echo 0)
  [[ "$mfa" == "0" ]] && echo "NO MFA: $upn"
done 2>/dev/null

For the insurance questionnaire, document:

• Total privileged accounts: N
• Accounts with MFA: N (100%)
• MFA type: FIDO2 hardware keys for tier-1 admins; TOTP for tier-2
• Exceptions process: documented with approval and compensating controls

Step 2 — EDR deployment coverage

#!/bin/bash
# edr-coverage-check.sh — verify EDR is deployed on all managed endpoints

# For CrowdStrike Falcon via API:
TOKEN=$(curl -s -X POST "https://api.crowdstrike.com/oauth2/token" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "client_id=${CS_CLIENT_ID}&client_secret=${CS_CLIENT_SECRET}" | \
  jq -r '.access_token')

ONLINE_COUNT=$(curl -s -H "Authorization: Bearer $TOKEN" \
  "https://api.crowdstrike.com/devices/queries/devices/v1?filter=status:'Online'" | \
  jq '.meta.pagination.total')

# Compare against your asset inventory
MANAGED_ENDPOINTS=$(cmdb-query "SELECT COUNT(*) FROM endpoints WHERE managed=true")

echo "EDR online sensors: $ONLINE_COUNT"
echo "Managed endpoints: $MANAGED_ENDPOINTS"
if [[ "$ONLINE_COUNT" -lt "$MANAGED_ENDPOINTS" ]]; then
  UNPROTECTED=$((MANAGED_ENDPOINTS - ONLINE_COUNT))
  echo "WARNING: $UNPROTECTED managed endpoints without active EDR"
fi

Document coverage for insurance:

• EDR product: CrowdStrike Falcon / SentinelOne / Microsoft Defender for Endpoint
• Coverage: 100% of managed Windows/macOS/Linux endpoints
• Exclusions: IoT devices, network infrastructure (covered by NDR)
• Last coverage audit: (date)

Step 3 — Backup isolation and testing

# Verify backup isolation from production
# Test: can production systems modify or delete backups?

# AWS S3 — check Object Lock on backup bucket
aws s3api get-object-lock-configuration \
  --bucket your-backup-bucket \
  --query 'ObjectLockConfiguration.ObjectLockEnabled' --output text
# Expected: Enabled

# Verify backup account is separate from production account
aws sts get-caller-identity --query 'Account' --output text
# Should show the BACKUP account ID, not production

# Test backup restoration — document results
cat > /tmp/backup-test-$(date +%Y%m%d).md << 'EOF'
# Backup Restoration Test

Date: $(date)
Tester: [Name]
System: [Production DB / File server / etc.]

## Test Performed
Restored [specific dataset] from backup dated [date] to test environment [name].

## Result
- Restoration time: [X minutes]
- Data integrity check: [PASS/FAIL]
- RTO achieved: [Yes/No - target was X hours]
- RPO achieved: [Yes/No - backup was X hours old]

## Verification
[Screenshot or log excerpt showing successful restoration]

## Signoff
Tested by: [Name] [Signature/initials]
EOF

Schedule quarterly backup restoration tests and retain records with dates.

Step 4 — Document and test the incident response plan

# Incident Response Plan — Template for Insurance Compliance

## Version: 2026.1
## Last Reviewed: 2026-05-14
## Next Review: 2026-11-14
## Last Tested: 2026-04-10 (Tabletop Exercise — Ransomware Scenario)

## 1. Purpose and Scope
This plan governs the organisation's response to cybersecurity incidents affecting 
systems classified as [production/customer data/financial].

## 2. Incident Classification
| Severity | Definition | Response Time |
|----------|-----------|---------------|
| P1 — Critical | Data breach, ransomware, service unavailable | 15 minutes to engage |
| P2 — High | Suspected compromise, significant vulnerability | 1 hour |
| P3 — Medium | Policy violation, minor incident | 4 hours |

## 3. Response Team
| Role | Primary | Backup | Contact |
|------|---------|--------|---------|
| Incident Commander | [Name] | [Name] | +1-xxx-xxx |
| Security Lead | [Name] | [Name] | +1-xxx-xxx |
| Legal/Compliance | [Name] | [Name] | +1-xxx-xxx |
| Executive Sponsor | [Name] | [Name] | +1-xxx-xxx |

## 4. Response Phases
### Phase 1: Detection and Initial Response (0–1 hour)
- Identify and classify the incident
- Activate incident response team
- Begin initial containment

### Phase 2: Containment (1–4 hours)
- Isolate affected systems
- Preserve evidence
- Notify stakeholders per notification matrix

### Phase 3: Eradication and Recovery
- Remove threat actor access
- Apply patches/fixes
- Restore from clean backups

### Phase 4: Post-Incident
- Root cause analysis
- Lessons learned
- Update this plan

## 5. External Contacts
- Cyber Insurance: [Insurer Name] Hotline: [Number] Policy: [Number]
- Incident Response Retainer: [Firm Name] [Contact]
- Legal Counsel: [Firm Name] [Contact]
- Breach Notification Attorney: [Name] [Contact]

## 6. Test Record
| Date | Type | Scenario | Participants | Findings |
|------|------|---------|-------------|---------|
| 2026-04-10 | Tabletop | Ransomware | IR team + Legal + Exec | [ref doc] |
| 2025-10-15 | Tabletop | Data breach | IR team + Privacy | [ref doc] |

Step 5 — Generate evidence documentation for insurers

Create a control evidence registry that makes questionnaire responses efficient:

#!/bin/bash
# generate-insurance-evidence.sh
# Generates dated evidence exports for common insurance requirements

EVIDENCE_DIR="/var/evidence/cyber-insurance-$(date +%Y%m%d)"
mkdir -p "$EVIDENCE_DIR"

# MFA coverage
{
  echo "MFA Coverage Report — Generated: $(date)"
  echo "Privileged accounts with MFA: $(query_your_idp_for_mfa_count)"
  echo "Total privileged accounts: $(query_your_idp_for_total)"
} > "$EVIDENCE_DIR/mfa-coverage.txt"

# EDR deployment
{
  echo "EDR Deployment Report — Generated: $(date)"
  # CrowdStrike Falcon example
  echo "Sensors online: $(get_cs_sensor_count)"
  echo "Managed endpoints: $(get_cmdb_count)"
} > "$EVIDENCE_DIR/edr-coverage.txt"

# Patch SLA compliance
{
  echo "Vulnerability Management Report — Generated: $(date)"
  echo "Critical CVEs patched within 7 days (last 90 days): X%"
  echo "High CVEs patched within 30 days (last 90 days): X%"
} > "$EVIDENCE_DIR/patch-compliance.txt"

# Backup testing
cp /var/backup-tests/latest-test-record.md "$EVIDENCE_DIR/backup-test-record.md"

# IR plan (last reviewed date extracted from the plan)
cp /security/incident-response-plan.md "$EVIDENCE_DIR/ir-plan.md"
grep "Last Reviewed\|Last Tested" /security/incident-response-plan.md

echo "Evidence package generated: $EVIDENCE_DIR"
ls -la "$EVIDENCE_DIR"

Expected Behaviour

Trade-offs

Failure Modes

Related Articles

• Passkey Enterprise Rollout Security — implementing FIDO2/passkey MFA to satisfy the privileged access MFA requirement
• Backup Recovery Security — the backup architecture that satisfies the immutable, tested backup requirement
• Incident Response Hardening Playbook — building the IR plan that insurance requires to be documented and tested
• Vulnerability Management Program — the formal vulnerability management process with SLAs that underwriters audit
• NIS2 Directive Technical Compliance — significant overlap between NIS2 requirements and cyber insurance requirements; dual compliance