Cyber Insurance Readiness Checklist

Cyber insurers have moved beyond self-reported questionnaires. Most now run automated external scans against applicants and policyholders, evaluating the same publicly observable security signals that CyberShield assesses. This checklist maps insurer requirements to CyberShield findings, giving you a clear remediation path before your next application or renewal.

How Insurers Assess Your External Security

Underwriters evaluate your external security posture using automated scanning tools that check your domains, certificates, DNS records, open ports, and web server configurations. The process is entirely non-intrusive -- insurers scan only publicly accessible information, the same way an attacker would perform initial reconnaissance.

The shift from questionnaires to automated scanning happened because self-reported data proved unreliable. Organizations frequently overstated their security maturity on applications, leading to unexpected losses for insurers. Automated scanning provides objective, verifiable data that correlates with actual breach likelihood.

What this means for you: your external security posture directly influences your premium, coverage terms, deductible amounts, and whether you receive coverage at all. For a deeper look at how security ratings affect your premiums, including which findings carry the most weight, improving your posture before the insurer evaluates it is the single most effective way to reduce your cyber insurance costs.

TLS/SSL Requirements

TLS configuration carries the highest weight in most insurer evaluations because certificate and encryption issues are immediately visible and directly correlate with data protection capability.

Valid certificates on all services:

• All TLS certificates must be current (not expired or expiring within 30 days)
• Certificate Subject Alternative Names (SANs) must match the serving domains
• Complete certificate chains (server cert + all intermediates) must be served

Protocol version enforcement:

• TLS 1.2 must be the minimum supported version
• TLS 1.0 and 1.1 must be disabled
• TLS 1.3 support is recommended but not yet universally required

To disable deprecated protocols in Nginx:

ssl_protocols TLSv1.2 TLSv1.3;

In Apache:

SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1

Strong cipher suites:

• Forward secrecy (ECDHE or DHE key exchange) must be preferred
• Authenticated encryption (AES-GCM, ChaCha20-Poly1305) should be prioritized
• Weak ciphers (RC4, DES, 3DES, export-grade) must be removed

ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305';
ssl_prefer_server_ciphers on;

HSTS (HTTP Strict Transport Security):

• Must be enabled with a minimum max-age of 15768000 (6 months)
• includeSubDomains is recommended
• Preload list submission provides the strongest protection

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

CyberShield findings to check: TLS module findings cover all of the above. Fix any critical or high findings in the TLS category before your insurer scans. For a detailed explanation of how TLS findings affect your overall score, see understanding your security score.

Email Authentication Requirements

Email authentication is the second highest-priority area for insurers because business email compromise (BEC) and phishing are among the most frequent and costly claim categories.

SPF (Sender Policy Framework):

• Must be published as a DNS TXT record
• Must include all authorized sending services
• Must end with -all (hard fail), not ~all (soft fail) or +all
• Must not exceed 10 DNS lookups

example.com.  IN  TXT  "v=spf1 include:_spf.google.com include:sendgrid.net -all"

DKIM (DomainKeys Identified Mail):

• Must be enabled on all outbound email services
• Public keys must be published in DNS for each selector
• Signatures should use RSA-2048 or Ed25519

selector1._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgk..."

DMARC:

• Must be published with policy at enforcement level
• p=quarantine is the minimum acceptable level for most insurers
• p=reject provides the strongest protection and best premium impact
• Reporting (rua) should be configured to monitor authentication results

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@example.com"

MTA-STS (Mail Transfer Agent Strict Transport Security):

• Recommended to prevent SMTP downgrade attacks
• Requires an HTTPS-hosted policy file and a DNS TXT record

_mta-sts.example.com.  IN  TXT  "v=STSv1; id=20260310"

CyberShield findings to check: Email module findings cover SPF validity, DKIM presence, DMARC policy strength, MTA-STS, and TLS-RPT. A DMARC policy of p=none will be flagged -- move to enforcement before your insurer reviews.

Network Exposure Requirements

Open ports represent direct attack surface that insurers weigh heavily, particularly ports associated with common ransomware entry vectors.

Critical ports that must not be externally accessible:

Port	Service	Risk
3389	RDP (Remote Desktop)	Primary ransomware entry vector
445	SMB (Server Message Block)	Lateral movement, WannaCry-type attacks
23	Telnet	Unencrypted remote access
1433	MSSQL	Database compromise
3306	MySQL	Database compromise
5432	PostgreSQL	Database compromise
27017	MongoDB	Database compromise
6379	Redis	Cache/data store compromise
11211	Memcached	DDoS amplification, data leakage

Required mitigations:

• Close all unnecessary ports at the firewall level
• If remote access is required, use VPN or zero-trust network access instead of direct exposure
• Database services must never be directly internet-accessible
• Management interfaces (SSH, admin panels) should be restricted to known IP ranges or VPN

Recommended services to evaluate:

• Web servers (80, 443) -- expected and acceptable
• Mail servers (25, 465, 587, 993, 995) -- expected if you run your own mail
• DNS (53) -- expected if you run authoritative DNS
• Everything else -- question whether it needs to be internet-facing

CyberShield findings to check: Ports module findings identify all open ports and flag unnecessary or dangerous services. Critical findings for exposed RDP or database ports require immediate remediation.

HTTP Security Headers Requirements

Security headers indicate defense-in-depth implementation. While individual missing headers rarely trigger coverage declination, the cumulative absence of security headers signals low security maturity.

Required headers:

Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=()
Strict-Transport-Security: max-age=31536000; includeSubDomains

In Nginx, add these as response headers:

add_header Content-Security-Policy "default-src 'self'; script-src 'self';" always;
add_header X-Frame-Options "DENY" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;

Headers to remove (information disclosure):

• Server version banners (e.g., Server: Apache/2.4.52)
• X-Powered-By (e.g., X-Powered-By: PHP/8.1.2)
• Any custom headers that reveal internal technology stack

server_tokens off;
proxy_hide_header X-Powered-By;

CyberShield findings to check: HTTP module findings cover all security headers. Address high-severity findings (missing CSP, no HSTS) before medium-severity ones (missing Referrer-Policy, Permissions-Policy).

DNS Security Requirements

DNS infrastructure security is increasingly evaluated by insurers as DNS hijacking and domain takeover attacks become more common.

DNSSEC:

• Recommended for all domains
• Protects against DNS spoofing and cache poisoning
• Requires coordination with your domain registrar and DNS host

CAA records:

• Restrict which certificate authorities can issue certificates for your domain
• Prevents unauthorized certificate issuance

example.com.  IN  CAA  0 issue "letsencrypt.org"
example.com.  IN  CAA  0 issuewild "letsencrypt.org"
example.com.  IN  CAA  0 iodef "mailto:security@example.com"

No dangling CNAME records:

• CNAME records pointing to decommissioned services create subdomain takeover risk
• Regularly audit CNAME records and remove any pointing to unclaimed endpoints

Proper NS configuration:

• Multiple nameservers for redundancy
• Nameservers on different networks/providers for resilience

CyberShield findings to check: DNS module findings cover DNSSEC, CAA, NS configuration, and zone transfer protection.

Domain and WHOIS Hygiene

Domain registration health is a lower-weight but still evaluated factor.

Registration expiration:

• Domain must not be expiring within 90 days
• Auto-renewal should be enabled
• Multi-year registration demonstrates permanence

Registration lock:

• Domain transfer lock should be enabled to prevent unauthorized transfers
• Registrar-level security (2FA on registrar account) should be in place

Privacy protection:

• WHOIS privacy is generally acceptable to insurers
• Consistent registrar information across all organizational domains

CyberShield findings to check: WHOIS module findings cover registration expiration, registrar health, and domain age.

Preparing Your Evidence Package

When applying for or renewing cyber insurance, compile the following evidence:

Scan reports:

• Recent CyberShield comprehensive scan PDF (within 30 days of application)
• Score summary showing overall posture grade
• Module-by-module breakdown

Compliance mapping:

• CyberShield compliance report mapping findings to relevant frameworks (PCI-DSS, SOC 2, ISO 27001)
• This demonstrates security program alignment, which insurers value

Remediation history:

• Scan comparison showing improvement over time
• Documentation of remediation actions taken for previous findings
• Timeline of security posture progression

Monitoring evidence:

• Active scan schedule demonstrating continuous monitoring
• Alert configuration showing proactive issue detection

Remediation Priority Matrix

Focus remediation effort where it has the most impact on both your security and your insurance evaluation.

Priority	Finding Type	Insurance Impact	Fix Timeline
P0	Exposed RDP/VNC/database ports	Coverage declination	Immediate
P0	Expired TLS certificates	Coverage restriction	Immediate
P0	No email authentication	Significant premium increase	Within 1 week
P1	DMARC at p=none	Premium increase	Within 2 weeks
P1	TLS 1.0/1.1 enabled	Premium increase	Within 2 weeks
P1	Weak cipher suites	Premium increase	Within 2 weeks
P2	Missing HSTS	Moderate premium impact	Within 4 weeks
P2	Missing CSP header	Moderate premium impact	Within 4 weeks
P2	SPF soft fail (~all)	Moderate premium impact	Within 4 weeks
P3	No DNSSEC	Minor premium impact	Within 8 weeks
P3	No CAA records	Minor premium impact	Within 8 weeks
P3	Missing secondary headers	Noted but low impact	Within 8 weeks
P3	WHOIS approaching expiry	Noted but low impact	Within 8 weeks

Work through this matrix from P0 to P3. Each fix should be verified with a CyberShield quick scan of the relevant module to confirm the finding is resolved before your insurer runs their evaluation.