Cyber insurers stopped taking security questionnaires at face value around 2022, and by 2026 most carriers writing tech E&O and cyber policies above $5M in coverage require documented evidence of an application security program before binding or renewing a policy. That evidence bar keeps rising: insurers now ask for SBOM coverage, vulnerability remediation SLAs, and proof that critical CVEs in production code are actually being fixed — not just logged in a spreadsheet. Coalition, Beazley, and Chubb have all published underwriting guidance in the last two years that explicitly references software composition analysis and patch cadence as rating factors. For engineering and security leaders, this turns cyber insurance from a finance line item into an AppSec program requirement with real deadlines: renewal applications, retroactive audits, and claims investigations all now probe whether you can show, with artifacts, that your SDLC actually reduces exploitable risk. This post breaks down what underwriters ask for, why, and how to build the evidence trail without slowing down engineering.
What do cyber insurers actually require for AppSec programs?
Cyber insurers require four documented controls: a current software bill of materials (SBOM) for production applications, a defined vulnerability remediation SLA (typically 15 days for critical, 30 for high), evidence of code and dependency scanning integrated into the SDLC, and a named individual or team accountable for the AppSec program. Coalition's 2025 underwriting checklist, for example, asks applicants to attach either an SBOM export or a screenshot of a software composition analysis (SCA) tool dashboard showing open critical/high findings and their age. Beazley's renewal questionnaire (revised Q3 2024) added a specific question: "Can you produce evidence that a critical vulnerability identified in the last 12 months was remediated within your stated SLA?" That's not a policy statement anymore — it's a request for an audit trail: ticket creation date, fix commit, deploy date. Carriers that can't get a straight answer either decline coverage, apply a coinsurance penalty, or exclude ransomware/breach coverage tied to unpatched known vulnerabilities, which is now a standard exclusion clause in Marsh McLennan-brokered policies.
Why did insurers start requiring SBOMs and scan evidence?
Insurers started requiring this because claims data showed a direct correlation between unpatched, known-exploited vulnerabilities and breach payouts. NetDiligence's 2024 Cyber Claims Study, drawing on over 3,500 claims, found that incidents traced to a known CVE with an available patch accounted for a disproportionate share of claims over $1M, and the average claim severity for "unpatched vulnerability" root causes was materially higher than claims from phishing or credential theft. CISA's KEV (Known Exploited Vulnerabilities) catalog crossed 1,300 entries by early 2025, and insurers began cross-referencing applicant disclosures against it during underwriting. Log4Shell (CVE-2021-44228) is the underwriting industry's reference case: multiple insureds that suffered Log4Shell-related breaches in 2022 couldn't demonstrate they knew Log4j was in their dependency tree at all, because they had no SBOM. That single gap — not knowing what software you run — is now treated by underwriters as a rating-worthy risk signal on its own, independent of whether a breach occurred.
What SBOM format and depth do carriers actually accept?
Carriers accept CycloneDX or SPDX in machine-readable form (JSON or XML), and they increasingly require component-level data, not just a top-level package list. A flat list of direct dependencies doesn't satisfy the requirement, because most exploited vulnerabilities in 2023-2025 incident data (per Sonatype's State of the Software Supply Chain report) sit in transitive dependencies two or more levels deep — the XZ Utils backdoor (CVE-2024-3094) is the canonical example, since xz was a transitive dependency of OpenSSH via liblzma on many systems, invisible to anyone only tracking direct imports. Underwriters reviewing renewal applications in 2025 began asking specifically whether the SBOM includes transitive dependencies and whether it's regenerated on every release or only annually. A static SBOM generated once a year is now flagged during audits as insufficient, since it can't reflect what's actually running in production at the time of a claim.
How does remediation SLA evidence affect premiums and claims?
Remediation SLA evidence directly affects both premium tier and claims outcomes, because carriers use it to price the likelihood of a breach originating from a known, disclosed vulnerability. Applicants who can show a 15-day mean-time-to-remediate (MTTR) for critical findings, backed by ticketing timestamps and deploy logs, typically qualify for the lower end of a carrier's rate band; Coalition's public underwriting notes describe MTTR as one of the top-three factors in their technology risk score alongside MFA coverage and endpoint detection. On the claims side, several 2023-2024 disputed claims (reported in industry publications like Advisen and Insurance Journal, without insurer names disclosed) turned on whether the insured's stated remediation SLA in the application matched their actual patch history — a mismatch discovered during forensics gave carriers grounds to invoke misrepresentation clauses and reduce or deny payout. This makes the SLA claim on your insurance application a legal representation, not a marketing line, and it needs to be backed by the same evidence an auditor would ask for.
What happens if an AppSec program fails a renewal audit?
If an AppSec program fails a renewal audit, the immediate outcomes are a coverage lapse, a premium increase, or a narrowed policy with breach-related exclusions carved out for unpatched vulnerabilities — not automatic non-renewal, but a materially worse position. A common mid-market pattern in 2024-2025 renewals: the carrier's underwriting team requests a follow-up call after the questionnaire flags "unable to confirm SBOM currency," and the applicant is given a 30-60 day remediation window to produce updated scan evidence before the renewal is finalized at a higher rate. Some brokers report carriers now attaching a "known vulnerability exclusion" endorsement specifically for CVEs that were disclosed more than 90 days before a breach and remained unpatched — meaning even a bound policy may not pay out if the breach traces to a stale CVE your SBOM should have caught. That endorsement language is the strongest signal yet that insurance and AppSec tooling now function as the same control, not adjacent line items.
How Safeguard Helps
Safeguard turns insurance-audit evidence gathering from a quarterly fire drill into a continuous, exportable record. Our platform generates CycloneDX/SPDX SBOMs automatically on every build and can ingest existing SBOMs from other tools for a unified inventory, so you always have a current, transitive-dependency-aware artifact ready for an underwriter request. Reachability analysis cuts the noise underwriters actually care about by identifying which flagged CVEs are in code paths your application actually executes, so your remediation SLA applies to real risk instead of every CVSS-critical entry in a manifest. Griffin AI, Safeguard's AI triage engine, prioritizes findings and drafts the remediation context your security team needs to document MTTR evidence, while auto-fix PRs close the loop by opening the dependency-bump pull request directly — turning a documented SLA commitment into a defensible, timestamped record from detection to deployed fix.