METHODOLOGY
How the readiness check works
Our free scan checks publicly observable security controls against what cyber insurance carriers typically ask. Here's exactly what it does, what it doesn't, and how to interpret the results.
What We Scan
- SPF record presence and policy strength
- DKIM selector validation
- DMARC policy and reporting configuration
- MX record security
- TLS certificate validity and protocol versions
- Subdomain enumeration via public DNS
- Internet-facing service exposure
What We Do Not Scan
- Internal network controls (firewalls, segmentation)
- Endpoint protection deployment (EDR/AV)
- Backup configuration and testing
- Identity provider / MFA enrollment rates
- Physical security
- Employee training completion
These controls require direct evidence from your internal tools. See our evidence collection guides for step-by-step export instructions.
How Scoring Works
Each check maps to one or more carrier questionnaire topics. We flag findings as:
- Pass — Control verified and aligns with carrier expectations
- Warning — Control present but configuration may not meet strictest carrier requirements
- Fail — Control missing or misconfigured — likely underwriter blocker
- Not Applicable — Check does not apply to this domain configuration
Limitations
This is a passive external scan using only publicly available DNS, certificate, and service data. It does not prove the absence of a vulnerability, the completeness of a security program, or the accuracy of any application response. Results are informational and should be reviewed by a qualified professional before use in any insurance application.
Update Cadence
Scan logic is updated as carriers publish new application forms and as security standards evolve. The carrier mapping layer tracks form changes across Coalition, Travelers, Hartford, At-Bay, and Cowbell.
Is this a vulnerability scan?
No. BindLedger performs passive external observation only. We query publicly available DNS records, certificate data, and service banners. We do not probe systems, exploit vulnerabilities, or access internal infrastructure. If you need comprehensive vulnerability scanning, use dedicated tools like Qualys, Tenable, or Rapid7 that perform active testing and penetration analysis.
Think of this as an outside-in verification of your public-facing security posture. It complements but does not replace vulnerability assessments.
Can this prove MFA coverage?
Not directly. MFA enrollment and enforcement are entirely internal—we cannot observe them from outside your network. Our readiness check can verify that your email infrastructure supports secure authentication protocols, but that's not the same as proving that multi-factor authentication is actually deployed and enforced across your organization.
To prove MFA coverage for an insurance application, you need exports from your identity provider (Okta, Microsoft Entra ID, Duo, or similar). See our evidence collection guides for step-by-step instructions on exporting MFA enrollment data from Okta, Microsoft 365 Entra, and other platforms.
Why can't outside-in checks prove backup immutability?
Backups are entirely internal. No external scan can verify whether backups exist, are immutable, are tested, or meet retention requirements. Carriers expect platform-native evidence: reports from Veeam, Datto, Azure Backup, or your backup platform showing configuration, testing frequency, and retention policies.
Backup immutability specifically requires proof that backups cannot be modified or deleted—typically shown through your platform's configuration export or compliance report. See our evidence guides and Veeam backup documentation for how to export and present backup evidence to carriers.
Can I use these results alone for a carrier submission?
No. The readiness check covers a subset of controls that are externally observable. A complete cyber insurance submission typically requires evidence across 10–15 control categories: email security, MFA, endpoint protection, backup immutability, incident response, access controls, training completion, business continuity, asset inventory, and more.
Use the readiness check as a starting point to see what's externally visible. Then use our evidence collection guides to gather internal evidence, structure your submission with our evidence templates, and submit the complete packet through our evidence submission tool.
Frequently asked questions
How often is scan logic updated?
As carriers publish new application forms and questionnaires. BindLedger tracks form changes across Coalition, Travelers, Hartford, At-Bay, and Cowbell. Updates are released as carriers update their requirements. Follow carrier updates to stay informed about changes that might affect your renewal timeline.
Does this scan touch my infrastructure?
No. The scan is read-only and passive. We query publicly available DNS, certificate transparency logs, and service banners. We do not deploy agents, request credentials, or access internal systems. No data is collected from inside your network.
Why do some checks show "Not Applicable"?
The check may not apply to your domain configuration. For example, if your domain has no MX record, email security checks won't apply. If you use a CDN, we may see CDN headers instead of your origin server's headers. "Not Applicable" indicates that the check cannot be meaningfully evaluated given your domain's current setup.
Ready to see how it works?
Run the free readiness check on your domain, explore our evidence collection guides, or browse common underwriting questions.