Insurance & Claims
Cyber Insurance Risk API
Cyber underwriting still runs largely on a questionnaire the insured filled in themselves. Much of what it asks about is observable from outside.
- Cyber insurers
- MGAs
- Reinsurance brokers
- Commercial underwriters
- Risk engineering teams
What your customers would see
example interfaceMockupIllustrative mockup of the interface we would build. Figures shown are examples, not results from a live deployment.
The problem this solves
Cyber proposal forms ask whether multi-factor authentication is enforced, whether backups are tested, whether end-of-life systems remain in production. The answers are self-reported by someone who may not know, may be guessing across a group of subsidiaries, or may be answering about the policy rather than the practice. Underwriters know this, which is why the questions keep multiplying without the information improving much.
A meaningful subset of security posture is visible externally without touching anything. Which services are exposed to the internet and on which ports. Whether TLS configuration is current. Whether email authentication is published and enforced. Whether subdomains have been left pointing at decommissioned infrastructure. Whether the organisation’s domains appear in credential dumps. None of this requires access, consent beyond the insured’s, or anything that resembles an intrusion.
The limits deserve stating plainly, because this is where cyber scoring vendors overreach. External observation sees the perimeter, and most serious incidents involve something inside it — a phishing email, a compromised credential, an unpatched internal system, a supplier. Attack surface measurement correlates with incident likelihood; it does not determine it. A score presented as a probability of loss is claiming far more than the evidence supports.
Who buys this
Cyber insurers, MGAs, Reinsurance brokers, Commercial underwriters, Risk engineering teams
What the API returns
What comes back
- External attack surface inventory: domains, hosts, exposed services and ports
- Security posture findings by category with severity and remediation guidance
- TLS, DNS and email authentication configuration assessment
- Exposed administrative interfaces, databases and remote access services
- End-of-life and unpatched software identified from service banners and published advisories
- Credential exposure in known public breach corpora, at domain level
- Posture score with factor breakdown, and an explicit statement of what it does not measure
- Portfolio monitoring with change detection and new-exposure alerts
Endpoints
| Method | Path | Returns |
|---|---|---|
| POST | /v1/assessments | Assess one organisation from its domains, with authorisation recorded |
| GET | /v1/assessments/{id} | Findings, posture score and attack surface inventory |
| GET | /v1/organisations/{id}/surface | Current external attack surface inventory |
| POST | /v1/portfolio/monitor | Register an in-force book for ongoing monitoring |
| GET | /v1/portfolio/changes | New exposures and posture changes across the monitored book |
| GET | /v1/findings/{id}/remediation | Remediation detail for one finding, for risk engineering use |
Request and response
illustrativeRequest
{
"organisation": {
"name": "Marchwood Components Ltd",
"primary_domain": "marchwood-components.example",
"known_domains": ["marchwood.example", "mwc-portal.example"],
"asn_hints": []
},
"authorisation": {
"basis": "insured_consent",
"reference": "proposal_2026_88412",
"recorded_at": "2026-10-20T09:00:00Z"
},
"scope": ["attack_surface", "tls", "email_auth", "credential_exposure"],
"intrusive_testing": false
}Response
{
"assessment_id": "asm_9920114",
"posture_score": 48,
"band": "weak",
"score_basis": "external_observation_only",
"surface": {
"domains_discovered": 14,
"hosts_resolved": 61,
"exposed_services": 23,
"unexpected_subdomains": 3
},
"findings": [
{ "id": "f_1", "category": "remote_access_exposed", "severity": "critical",
"detail": "RDP reachable on a host in the corporate range",
"evidence": "tcp/3389 open, service banner consistent with Windows RDP",
"remediation": "Restrict to VPN or a brokered access gateway" },
{ "id": "f_2", "category": "end_of_life_software", "severity": "high",
"detail": "Web server banner indicates a release past vendor end of support" },
{ "id": "f_3", "category": "email_authentication", "severity": "medium",
"detail": "DMARC published at p=none; no enforcement" },
{ "id": "f_4", "category": "dangling_dns", "severity": "medium",
"detail": "Subdomain resolves to a deprovisioned cloud resource" }
],
"credential_exposure": {
"domain_accounts_in_public_corpora": 412,
"most_recent_corpus_date": "2026-06",
"note": "Domain-level counts only; no credentials retrieved or stored"
},
"not_measured": [
"internal network segmentation", "backup testing and recoverability",
"MFA enforcement on internal systems", "endpoint protection coverage",
"supplier and third-party risk", "security awareness and phishing resilience"
],
"assessed_at": "2026-10-21T14:12:00Z"
}Where the data comes from
| Public DNS and certificate transparency data | Domain and subdomain discovery from public records, which is how an attack surface is enumerated without touching the target |
| Internet-wide scan datasets | Licensed or self-collected service and banner data on publicly routable addresses, within the terms the dataset permits |
| Published vulnerability advisories | Vendor advisories and public vulnerability databases, used to interpret observed software versions |
| Email authentication records | SPF, DKIM and DMARC records published in public DNS — open, instantly checkable and frequently misconfigured |
| Breach corpora | Public credential dump datasets, used only for domain-level exposure counts; we would not retrieve or store credentials |
| Your own claims and incident history | Realised cyber losses against prior assessments, which is the only way to know whether any of this predicts your claims |
The intelligence layer
The difference between a demo and a service is mostly in this section. These are the parts that keep the answer trustworthy once real traffic is hitting it.
- Non-intrusive observation only: passive data sources and standard connection checks, with no exploitation, credential testing or anything that could affect the target’s availability
- Authorisation recorded per assessment before any active check, with scope bounded to assets attributable to the insured
- Asset attribution treated as a first-class problem, since scoring an organisation for infrastructure it does not control is the most common error in this category
- Findings graded by exploitability and exposure rather than by raw vulnerability severity, because an advisory’s severity rating is not the same as risk in this configuration
- Posture scoring with an explicit, published statement of what is outside its measurement, returned in every response rather than buried in documentation
- Validation against your own claims experience where you can share it — without that, a posture score is an engineering measurement with no demonstrated relationship to loss
- Change detection across the monitored book, since new exposure appearing mid-term is more actionable than a score at inception
- False positive handling with an insured-facing dispute path, because an incorrect finding on a proposal has commercial consequences for them
What it changes for the business
Evidence against self-report
Observable findings give an underwriter something to test the proposal form against rather than accepting it at face value.
Mid-term visibility
Monitoring catches exposure appearing after inception, which is when much of the real deterioration happens.
Risk engineering conversations
Specific, evidenced findings with remediation detail turn a declinature into an improvement condition.
Portfolio accumulation
Shared platform and provider exposure across the book becomes visible before a common-cause event makes it obvious.
How it fits into your product
How it embeds
- Called at proposal with the insured’s authorisation recorded, returning findings alongside the posture score
- Portfolio monitoring across the in-force book, with change alerts routed to underwriting and risk engineering
- Findings exportable as an insured-facing report, which is usually how remediation conditions get agreed
- Dispute endpoint so an insured can challenge asset attribution or a finding, with the challenge recorded
- Underwriting workbench components, or raw JSON into your existing rating and referral flow
- Deployment inside your infrastructure where assessment data and insured identities must not leave
Included in every build
- Authentication, scoped API keys and per-customer rate limiting
- Input validation with predictable, documented error responses
- Versioned endpoints so your integration never breaks without notice
- Request and response logging for audit and dispute resolution
- Latency, error-rate and usage monitoring with alerting
- OpenAPI specification, sandbox environment and client examples
- Backups, failover design and a documented recovery procedure
- An agreed support arrangement once the service is live
How we would build it
about 20 weeksDiscovery and feasibility
Weeks 1–3
This one depends heavily on data access, so we start by proving the sources exist, can be licensed for your use, and actually carry the signal the model needs. If they do not, you find out here.
Architecture and baseline model
Weeks 4–6
A written architecture and a baseline model measured against a holdout period, so you know what accuracy you are buying before the full build starts.
Production build
Weeks 7–16
Data pipelines, model training and serving, historical archive, validation harness, API, security, monitoring and documentation.
Validation and integration
Weeks 17–20
Backtesting against held-out history, accuracy reporting your team can audit, integration support and an agreed retraining cadence.
Commercial models
There is no fixed price list, because the cost is driven by data complexity, integration count, model requirements, request volume and the support level you need. Scope is agreed in writing before development starts.
Fixed-scope prototype
A defined slice of the service, built and priced as one piece of work. The usual first step when the business case needs proving internally.
Fixed-price build
An agreed scope against a written architecture, delivered for an agreed price. Best when the requirements are already clear.
Build then retainer
We build the service, then operate and improve it under a monthly agreement covering monitoring, updates and model maintenance.
White-label product
The service runs under your brand, your domain and your pricing, with MLPivot invisible to your customers.
Questions buyers ask
Is this a penetration test?
No, and it is important that it is not. Everything here is passive observation or standard, non-intrusive connection checks — the equivalent of looking at a building from the street. There is no exploitation, no credential testing, nothing that could affect availability. If you want actual penetration testing, that requires a scoped engagement with explicit written authorisation from the asset owner and specialist testers, and it is not what this builds.
Does a good score mean the insured will not have a claim?
No, and we would resist any presentation that implies it. External posture measures the perimeter. Most significant cyber incidents involve something the perimeter cannot show — a phishing email, a reused credential, an unpatched internal server, a compromised supplier. Attack surface findings correlate with incident likelihood in published research; they do not determine it. Every response lists what the score does not measure, deliberately.
Do you need the insured’s permission?
For active checks, yes, and the assessment records the authorisation basis before running them. Purely passive data — public DNS, certificate transparency, published email authentication records — involves no contact with the insured’s infrastructure at all. We draw that line explicitly because ‘it is all public’ is a weaker position than it sounds once you are connecting to someone’s hosts.
How do you know which assets belong to the insured?
Imperfectly, which is the honest answer and the reason attribution gets its own engineering effort. Domains are reliable; IP ranges in shared hosting are not, and group structures with subsidiaries and acquisitions are genuinely hard. Confidence is reported per asset, low-confidence assets are excluded from scoring rather than included quietly, and the dispute path exists because we will sometimes get it wrong.
Can you validate that the score predicts losses?
Only with your claims data, and we would want to do that before the score influences pricing. Without it, a posture score is a well-defined engineering measurement with no demonstrated relationship to your loss experience. With a few years of claims matched against assessments, we can test which findings actually separate loss from no-loss in your book — and it is worth knowing in advance that some commonly-sold indicators may not survive that test.
Related blueprints
Property Risk Scoring API
Flood, wildfire, storm and subsidence exposure scored at individual address level, for property underwriting and portfolio management.
Insurance Fraud Detection API
Claim scoring, duplicate evidence detection and network analysis, so organised claim fraud is visible before payment rather than after.
Vehicle Damage Estimation API
Damage detection, parts identification and a repair cost range from claim photographs, for motor insurers and claims administrators.
Want this built for your platform?
Tell us what your product does today and what you want another system to be able to ask it. We will come back with an approach, a scope and a price.