Already scanned? Compare your renewal next.

Use Renewal Delta to see whether readiness improvements showed up in the renewal declarations page.

What the readiness check scans

The BindLedger readiness check performs four core security assessments visible from the outside of your network. Email security verifies your SPF, DKIM, and DMARC authentication records and validates MX record configuration to detect spoofing risks. Web security inspects your TLS certificate validity, cipher strength, and installed security headers like HSTS, X-Frame-Options, and Content-Security-Policy that signal layered web application hardening. Subdomain discovery identifies all publicly registered subdomains via DNS enumeration to flag forgotten infrastructure. Internet-facing service exposure scans for open ports and service banners that reveal what your organization exposes to the public internet—login portals, management interfaces, or legacy services you may have forgotten about. Together, these checks map to carrier expectations for baseline outside-in security posture.

What the readiness check does not scan

The readiness check cannot observe internal controls that require direct system access or administrative exports. MFA enrollment rates, endpoint detection and response (EDR) deployment coverage, backup configuration and testing, security awareness training completion rates, and incident response plan existence all require tenant-level evidence from your platforms—Okta for identity posture, CrowdStrike for endpoint coverage, Veeam for backup proof, or direct attestation for training and IR plans. The readiness check does not probe or exploit systems. For proof of these internal controls, visit our evidence collection guides to learn how to gather the specific exports and documents carriers expect.

How to interpret pass, warning, and fail results

A Pass result means the control is present and verified to align with carrier expectations—your SPF record is valid, your TLS certificate is current and uses strong ciphers, or your critical security headers are in place. A Warning result indicates the control is present but may not meet strictest carrier requirements—your DMARC record exists but is set to p=none instead of p=reject enforcement, or your TLS uses acceptable but not state-of-the-art cipher suites. A Fail result means the control is missing or misconfigured and likely represents an underwriter blocker—DMARC is absent entirely, your certificate is expired, or an admin panel is exposed on a discovered subdomain. Review the specific guidance provided with each result and prioritize Fail and Warning items before submission. For a detailed explanation of how scoring works, see our full scoring methodology.

Common blockers found in readiness checks

Across thousands of readiness checks, five patterns repeatedly surface as underwriter concerns:

DMARC not at enforcement (p=none vs p=reject). Carriers increasingly require enforcement-level DMARC as a baseline email security control. Many organizations deploy p=none to monitor spoofing attempts before enforcement, but underwriters view unenforced DMARC as insufficient. Enforcement blocks spoofed emails at the receiver, dramatically reducing business email compromise risk.
Expired or weak TLS certificates. Expired certificates signal poor certificate lifecycle management. Weak cipher suites (DES, RC4) or older protocol versions (TLS 1.0) suggest incomplete web hardening and expose encrypted traffic to known vulnerabilities. Certificate rotation and cipher strength are table-stakes for underwriters.
SPF records exceeding 10 DNS lookups. SPF validation requires DNS lookups to resolve the authentication chain. More than 10 lookups causes SPF validation to fail (the SPF specification hard limit). This often happens when multiple third-party email providers (marketing platforms, SaaS vendors, carriers) are included and not consolidated. Failed SPF validation means spoofed emails slip through.
Exposed admin panels on subdomains. Subdomain enumeration frequently uncovers forgotten infrastructure: old staging environments, legacy portals, or developer tools left on public subdomains. If a login portal is exposed without MFA, it becomes an obvious entry point for attackers and a red flag for underwriters.
Missing HTTP security headers (HSTS, X-Frame-Options, CSP). Security headers provide browser-level protections against common attacks: clickjacking, MIME-type confusion, and injection. Their absence signals incomplete web hardening. Carriers expect modern web applications to implement at least HSTS and X-Frame-Options.

Who should run this check

Three audiences benefit from the readiness check. Brokers preparing renewal submissions should run it as an early baseline to understand their client's public-facing security posture before formal submission—finding and addressing blockers early avoids delays during underwriting. Managed service providers (MSPs) documenting client security posture use the check to demonstrate outside-in controls are in place per client, adding external validation to their security assessments. IT teams self-assessing before the application season run the check to identify and fix issues in their own infrastructure before carriers see them, turning readiness gaps into proactive remediation.

Frequently asked questions

Is this a vulnerability scan?

No. The readiness check performs passive observation of public DNS records, TLS certificates, and service banners. It does not probe systems, attempt exploitation, or request system access. All data comes from publicly available sources. For technical details on what gets queried, see the methodology.

Do I need to install anything?

No. The readiness check requires no agents, credentials, or network access to your systems. It uses only publicly available data and runs entirely in your browser. Enter a domain and get results immediately.

Can I use this as proof for my carrier?

Readiness check results are informational and show your publicly observable security posture, but they are not formal evidence carriers will accept. Carriers expect direct exports from your platforms (identity, endpoint, backup systems) or attestations from your team. For guidance on collecting formal proof, see our evidence collection guides.

Which carriers does this map to?

The readiness check aligns findings to Coalition, Travelers, Hartford, At-Bay, and Cowbell underwriting frameworks. These carriers are among the most common in the mid-market and small business cyber insurance space. The scoring and recommendations are updated as carrier forms and expectations evolve—see carrier updates for the latest changes.

How often should I run this check?

Run the readiness check before every renewal submission to confirm your security posture is fresh. Also run it after major infrastructure changes: domain migrations, TLS certificate rotations, email platform switches, or significant network architecture changes. Most organizations run quarterly checks to stay ahead of drifts.

What if I get a failing result?

Prioritize Fail results first—these are likely underwriter blockers. Start with DMARC enforcement and TLS issues, as these are the fastest wins and highest impact. The readiness check provides specific remediation guidance for each result. For internal controls you can't prove externally (MFA enrollment, EDR coverage, training completion), consult our evidence guides for step-by-step proof collection.