How to Pass a Carrier's Vendor Security Review as an Insurtech CTO

To pass an insurance carrier's vendor security review, answer the questions the carrier's own regulator makes it ask: how you control access, how you encrypt, how fast you will tell them about an incident, and how you know what is inside the software you sell them. Build one evidence pack that answers those with documents and records rather than adjectives, state your gaps with dates attached, and keep the pack in one place so next year's review is a refresh instead of a rebuild.

This post is for the CTO of a 30 to 200 person insurtech who is also the entire security and compliance function, holding a renewal with a vendor review stapled to it.

Key takeaways

• Carriers do not invent their vendor reviews. New York's 23 NYCRR 500.11 requires covered entities to have written third-party service provider policies covering risk assessment, minimum practices, due diligence and periodic reassessment. States that adopted the NAIC Insurance Data Security Model Law impose a similar due diligence duty on licensees.
• The questions cluster into a predictable set: access control and multi-factor authentication, encryption, incident notice, secure development, open source and vulnerability handling, subcontractors, and evidence of testing.
• Your answer pack needs five parts: policies, an inventory of what you ship (an SBOM), a vulnerability handling record, access and encryption evidence, and an incident notice commitment you can actually keep.
• Gaps are normal at your size. A gap stated plainly with an owner and a date usually passes; a vague yes that a carrier later finds false does not.
• Incident notice is a contract term, not a slogan. Carriers have their own regulatory clocks (72 hours to the New York superintendent under 500.17), so they will ask you for a shorter one. Commit only to what your on-call reality supports.
• Reuse comes from keeping answers mapped to controls and evidence, not from copying last year's spreadsheet.
• Safeguard covers the evidence side of this job. SBOM generation and analysis is GA. Vulnerability management with EPSS and CISA KEV context is GA. The Compliance and GRC suite, including its Questionnaires tab, is GA. Trust Center is GA. Portal, meaning the SBOM publish and share product, is GA.
• None of that negotiates your contract, signs your attestation or replaces your judgment. Draft questionnaire answers still need a human to read and own them.

The situation

The renewal email came from the carrier's procurement or vendor management team, not from the business owner who championed your product. Attached is a questionnaire. It might be a few dozen questions, it might be several hundred across tabs, and it might arrive inside a vendor portal you have never logged into. There is usually a due date, often a few weeks out, and a soft threat behind it: renewal cannot be finalized until third-party risk signs off.

The questionnaire asks whether you maintain a software bill of materials, how you track vulnerabilities in open source components, whether you perform static analysis, how you manage privileged access, whether you have had a cybersecurity event in the last twelve months, and how quickly you will notify the carrier if one happens. It asks for a SOC 2 report, or if you do not have one, a list of compensating evidence.

A bad week looks like this. You answer from memory. You say yes to "do you maintain an SBOM for all production software" because you once ran a tool that produced one. The carrier's analyst asks for the SBOM. You generate a fresh one, and it contains three critical vulnerabilities you did not know about. Now the analyst wants a remediation plan, the business owner wants to know why renewal is stuck, and your engineers are pulled off the roadmap to patch under pressure. Next year you start from scratch again.

A good week looks different. You open a folder, or a tool, that already holds this year's policies, last month's SBOM, the vulnerability record with dates, the access review, the incident response plan and last year's answers mapped to controls. You update what changed, write two honest gap statements with dates, and send it back early. The analyst has fewer follow-up questions because the evidence is attached.

The difference between the two weeks is not budget. It is whether the evidence exists before the questionnaire does.

Why carriers ask what they ask

It helps to read the questionnaire as the carrier's compliance record, not as an attack on your product. (For the carrier's side of the same process, see third-party risk assessment for insurtech SaaS platforms.) The analyst is filling in their own file, and the shape of that file is set by regulation. This section summarises the rules in plain terms. It is not legal advice; your counsel and the carrier's counsel own the interpretation for any specific contract.

What third-party duties do carriers carry under NYDFS 500.11 and the NAIC model law?

New York. Part 500 of Title 23 of the New York Codes, Rules and Regulations is the Department of Financial Services cybersecurity regulation. It applies to covered entities licensed under New York's banking, insurance and financial services laws, which includes insurers writing business in the state. Section 500.11 was adopted in 2017 and amended effective 1 November 2023, according to the Cornell Legal Information Institute's annotated text.

Section 500.11(a) requires each covered entity to implement written policies and procedures designed to secure information systems and nonpublic information that are accessible to, or held by, third-party service providers. Those policies must address, where applicable:

1. identification and risk assessment of third-party service providers, 500.11(a)(1);
2. minimum cybersecurity practices a provider must meet to do business with the covered entity, 500.11(a)(2);
3. due diligence processes to evaluate the adequacy of a provider's practices, 500.11(a)(3);
4. periodic assessment of providers based on the risk they present, 500.11(a)(4).

Section 500.11(b) then lists what the due diligence or contract terms should cover, again where applicable:

1. the provider's access control policies, including multi-factor authentication as required by section 500.12, 500.11(b)(1);
2. the provider's encryption policies for nonpublic information in transit and at rest, per section 500.15, 500.11(b)(2);
3. notice to the covered entity of a cybersecurity event directly affecting its systems or its nonpublic information held by the provider, 500.11(b)(3);
4. representations and warranties about the provider's cybersecurity policies and procedures, 500.11(b)(4).

Read that list next to your questionnaire and the questionnaire suddenly makes sense. The multi-factor question is 500.11(b)(1). The encryption question is (b)(2). The incident notice clause in the renewal paper is (b)(3). The "please confirm the following statements are true" section is (b)(4). And the fact that this happens every year, rather than once at onboarding, is (a)(4). Our post on what engineering checks before a vendor gets data under NYDFS 500.11 walks the same section from the carrier's engineering side.

Two other sections explain the pressure behind the timeline. Section 500.17(a)(1) requires a covered entity to notify the superintendent as promptly as possible and no later than 72 hours after determining that a cybersecurity incident has occurred at the covered entity, its affiliates, or a third-party service provider. That last phrase is why the carrier cares how fast you will tell them. Section 500.17(b) requires an annual submission to the superintendent by 15 April: a written certification of material compliance for the prior calendar year, based on data and documentation sufficient to demonstrate it, including where necessary documentation of outside vendors. Your answer pack ends up as part of that documentation.

The NAIC model law and the states that adopted it. The National Association of Insurance Commissioners published the Insurance Data Security Model Law, Model #668, as a template for state legislatures. States that adopt it write it into their own insurance codes, sometimes with changes. Virginia's Insurance Data Security Act is a convenient public example. Virginia Code § 38.2-623(E) says that beginning 1 July 2022, a licensee that uses a third-party service provider shall exercise due diligence in selecting it and shall require it to implement appropriate administrative, technical and physical measures to protect the information systems and nonpublic information it can access or holds. Section 38.2-623(D) requires a report to the board, at least annually, that covers third-party service provider arrangements among other matters.

The notice clock in an adopting state may differ from New York's. Virginia's § 38.2-625(A) sets notice to the Commissioner as promptly as possible and no later than three business days from the determination that a cybersecurity event has occurred, when the stated conditions apply. Other adopting states use their own wording; our guide to the NAIC model law for software vendors covers the model in more depth. If you sell to carriers domiciled in several states, expect their incident notice asks to reflect the strictest clock they carry, and expect them to want you inside it.

What the frameworks add. Many carriers map their vendor program to the NIST Cybersecurity Framework 2.0. Its Govern function has a Cybersecurity Supply Chain Risk Management category, GV.SC, with ten outcomes. Several read like a description of your renewal week: GV.SC-05 says supply chain requirements are integrated into contracts; GV.SC-06 says due diligence is performed before entering supplier relationships; GV.SC-07 says supplier risks are understood, recorded, assessed and monitored over the course of the relationship; GV.SC-08 says relevant suppliers are included in incident planning, response and recovery. NIST SP 800-161 Rev. 1 is the longer federal guidance on cybersecurity supply chain risk management practices, and carriers with mature programs borrow from it.

On SBOMs specifically, CISA published the 2026 Minimum Elements for a Software Bill of Materials on 29 July 2026, jointly with the NSA, the FBI and international partners. It updates and replaces the minimum elements the NTIA published in 2021. When a carrier asks whether your SBOM "meets minimum elements", this is the current reference. CISA's page also notes that some software types, including software as a service in cloud environments, may need additional elements, which is relevant if what you sell the carrier is a hosted platform rather than a library they install.

The short version for your team

Step by step: build the answer pack

This section works with whatever tools you already have: a shared drive, a ticket system, a spreadsheet and a few command line tools. Do it once properly and every later review becomes maintenance.

1. Read the questionnaire for scope before you answer anything

Before you write a single answer, confirm three things with the carrier's analyst or your business contact.

• Which product or service is in scope. If you sell a policy administration add-on and a claims analytics service, the carrier may only need one assessed.
• What carrier data you touch. Nonpublic information, as Part 500 and the model law define it, covers more than you might expect. Write down whether you hold policyholder personal data, claims data, health information or only aggregated data. This decides your risk tier in their program.
• The format and deadline. Their portal, their spreadsheet, or your own standard pack with their questions mapped to it. Ask whether they accept a completed standard questionnaire in place of theirs. Many will at least take it as an attachment that answers most rows. The SaaS startup security questionnaire playbook has more on working through long questionnaires quickly.

2. Assemble the policy set

Carriers want to see written policies, dated and approved by someone with authority. For a company your size, the core set is usually:

• information security policy (the umbrella);
• access control policy, including MFA and privileged access;
• secure development policy, including code review, dependency management and vulnerability handling;
• incident response plan, including a customer notification step;
• vendor management policy, covering your own subprocessors;
• data retention and disposal;
• business continuity and backup;
• acceptable use.

Short is fine. A two page secure development policy that matches what your engineers actually do survives follow-up questions; a forty page template describing a team you do not have does not.

3. Produce an inventory of what you ship

This is the part most small vendors skip and most carrier questionnaires now ask about. Generate an SBOM for each production service in a standard format (SPDX or CycloneDX). Check it against CISA's 2026 minimum elements. Keep the generated file with the date, the commit or release it describes, and the tool that produced it.

Two practical notes. First, generate from what you build and deploy, including container images, not only from the source repository, because base image packages count. Second, keep every SBOM you hand to a carrier. If an analyst asks next year what you told them, you want the exact file, not a regenerated one.

4. Write down how you handle vulnerabilities

The carrier does not expect zero vulnerabilities. It expects a process. Your vulnerability handling record should show:

• where vulnerability data comes from (for example NVD, GitHub Security Advisories, OSV, CISA's Known Exploited Vulnerabilities catalog);
• how often you check (on each build, daily, weekly);
• how you prioritise (severity, exploit likelihood such as EPSS, presence on KEV, whether the vulnerable code is reachable, whether the service handles carrier data);
• your target remediation times by priority;
• how exceptions are approved, by whom, and when they expire;
• a dated log of the last quarter's critical and high findings and what happened to each.

The last item is the evidence; the rest is policy.

5. Collect access and encryption evidence

For access: an export or screenshot of MFA enforcement in your identity provider, the last quarterly access review with who signed it, and the list of people with production access. For encryption: a short architecture note stating what is encrypted in transit and at rest, with which mechanisms, and how keys are managed. If you rely on a cloud provider's managed encryption, say so and reference their documentation.

6. Prepare the incident notice commitment

Pull your incident response plan and check that it has a customer notification step with a named owner, a clock that starts at a defined moment, a channel (email to a named security contact at the carrier, not a generic inbox), and the content of the first notice. Section 5 below covers what you can commit to.

7. Map answers to evidence and store them together

Make a single table where every question you answer points to the policy section and the evidence file that supports it. This is the asset you will reuse. Here is a template you can copy into a spreadsheet today.

The values in the table are illustrative. Use your own timelines and only commit to the ones you meet.

8. Review, sign and send

Read every answer as if the carrier's counsel will quote it back after an incident; under 500.11(b)(4) that is what representations are for. Remove anything you cannot evidence. Send the pack with a short cover note listing what is attached and naming a security contact.

What carrier questionnaires usually ask about software development and open source

The software supply chain tab is where most small insurtechs lose time, because the questions assume a process the company has but has never written down. Expect versions of these:

• Do you have a secure software development lifecycle? They want the policy and one piece of evidence that it runs: required code review on the main branch, a CI configuration that runs tests and scanners, or a release checklist.
• Do you perform static application security testing? Dynamic testing? Penetration testing? Answer each separately and say how often. If your penetration test is annual, say annual and give the date of the last one.
• Do you maintain an inventory of open source and third-party components? This is the SBOM question. Some questionnaires ask for the file; most ask whether you can provide it on request. Say yes only if you can produce one within a day.
• How do you identify and remediate vulnerabilities in third-party components? Point to your vulnerability handling record from step 4.
• What are your remediation timelines by severity? Give numbers you meet. If you have exceptions, say how they are approved.
• Do you review open source licenses? Carriers' legal teams care about copyleft obligations in software they deploy. A license policy and a license report from your SBOM answers it.
• How do you protect the build and release pipeline? Branch protection, who can deploy, how secrets are stored, whether builds are reproducible or signed. Answer what is true.
• Do you use AI tools in development or in the product? Newer questionnaires ask this. Say which tools, whether carrier data is sent to any model, and how outputs are reviewed.
• Who are your subprocessors? List hosting, logging, support tooling and any service that touches carrier data.

A one line "yes" invites a follow-up request; a one line "yes, see SBOM-claims-api-2026-10-20.json and vulnerability log Q3" usually closes the row.

What evidence a small insurtech should keep ready

Keep the following in one place, dated, and refreshed on a schedule you can actually sustain. Quarterly is realistic for most of it.

If you are early and have no third-party audit report, do not pretend otherwise. Provide the readiness assessment, the planned audit window and the controls already in place.

How to answer gaps honestly with a plan

Every vendor at your stage has gaps. The question is whether the carrier finds them in your answer or in an incident.

Use a consistent gap statement with four parts:

1. What is true today. "We generate SBOMs for our two API services. Our batch processing service is not yet covered."
2. The risk it leaves. "Components in the batch service are tracked through dependency manifests but not exported in a standard SBOM format."
3. The compensating control. "Dependency updates for that service go through the same code review and CI checks as the API services."
4. The plan with an owner and date. "Coverage extends to the batch service by 31 January 2027, owned by the engineering lead."

What not to do:

• Do not answer "partial" without saying which part.
• Do not commit to a date that depends on a hire you have not made.
• Do not promise a certification by a date the auditor has not agreed to.

A carrier's vendor management team usually records your gap as an open item with a follow-up date. If you meet the date, you have built trust. If you miss it, tell them before they ask.

How incident notice terms work, and what you can commit to

The incident notice clause is where the regulatory chain becomes a contract clause. The carrier must notify its regulator within its own clock, 72 hours from determination in New York under 500.17(a)(1), or as the adopting state's law sets it. The carrier cannot meet that clock if its vendor takes a week to call. So the renewal paper will ask you to notify within a shorter period, and it will define what counts as an event.

Read four things in the clause.

1. The trigger. Is it a "cybersecurity event" (an attempt, successful or not) or a "cybersecurity incident" (one that actually affects systems or data)? Part 500 uses both terms differently. A clause that triggers on any attempted access would have you notifying every blocked login. Ask for the trigger to align with events that directly affect the carrier's systems or nonpublic information, which mirrors the language of 500.11(b)(3).
2. When the clock starts. "Upon discovery", "upon determination", "upon confirmation" and "upon becoming aware" are different moments. Determination after triage is the most workable.
3. The window. Ask yourself honestly how fast your team can confirm and draft a notice at 3 a.m. on a holiday weekend. Commit to that, not to the shortest number on offer.
4. What the first notice must contain. A first notice is usually a short statement of what is known. Ask that the clause allow updates, which matches the continuing obligation the carrier has to its regulator under 500.17(a)(2).

What you can commit to depends on what you can operate. A two person on-call rotation can usually support a notice within a day or two of determination. Committing to a few hours from "awareness" without that on-call coverage is a promise your counsel will regret. If the carrier's paper asks for more than you can do, propose what you can do and explain how, with your incident plan attached. Your counsel handles that negotiation with you; go in knowing your real number.

Also prepare the mechanics before you need them: a named security contact at each carrier, a notice template, and a list of which carriers' data sits in which service, so you can tell quickly which carriers an event touches.

How to reuse the pack across carriers

The second carrier review should take a fraction of the first. That only happens if the pack is organised around controls and evidence rather than around one carrier's question numbers.

1. Keep a master answer set. One answer per control area, in your words, with policy and evidence references.
2. Map each carrier's questionnaire to the master set. Keep the mapping, so next year you only map new or reworded questions.
3. Answer once in a standard format. Completing one widely used standard questionnaire and offering it up front cuts the custom questions some carriers send.
4. Publish what you can. A public security page with your policies summary, framework status and a request path for restricted documents answers the first round of questions before they are asked.
5. Version everything. Every pack you send gets a date and a copy kept, so you can show what a given carrier was told and when.
6. Track carrier-specific terms separately. Notice windows, audit rights and right-to-assess clauses differ by contract. Keep a short table per carrier so your incident plan can find the strictest clock quickly.

How Safeguard does this

Everything above works with a drive and a spreadsheet. What Safeguard changes is where the evidence comes from and where it lives: SBOMs and vulnerability records generated from your actual repositories and images, answers kept beside the evidence that supports them, and a page you control for sharing it. Here is the flow, built from Safeguard's documentation.

1. Connect your code and images to generate SBOMs. In the Enterprise Software Supply Chain Manager, the Integrations page connects repositories from GitHub, GitLab, Bitbucket or any Git URL, container registries, and manifest uploads, according to Safeguard's SBOM generation docs. SBOM generation and analysis (GA) produces SPDX and CycloneDX output, with an optional Deep Analysis setting. If you prefer to start from a terminal, the docs show the CLI (GA):

# Install the CLI
curl -fsSL https://cli.safeguard.sh/install | bash
# Open the terminal, then type /login and /scan .
safeguard
# Or scan from the command line, writing results under ./output
safeguard scan --dir .

The docs say a scan from the interactive terminal while signed in uploads the SBOM and findings to the platform, and your source never leaves the machine.

2. Turn on continuous scanning. The docs describe daily continuous scanning of all projects, with optional triggers on push, on a schedule, or on release. This is what keeps the vulnerability record current between reviews, instead of rebuilt the week a questionnaire arrives.

3. Work the vulnerability record. Vulnerability management (GA) shows findings by Critical, High, Medium, Low and Exploitable, drawing on NVD, GitHub Security Advisories, OSV, CISA KEV and vendor bulletins. Each finding carries CVSS, EPSS, exploit status, the affected component and version, the fixed version and reachability. Reachability analysis (GA) helps you put the code paths your service actually calls first. When something does not apply, the docs show Mark False Positive with a justification, and Accept Risk with an expiration date and a business justification, both submitted for approval. Those records are the exceptions register a carrier asks about.

4. Map controls and keep evidence in the Compliance suite. The Compliance and GRC suite (GA) has tabs for Frameworks, Controls, Evidence, Monitoring, Tests, Policies, Questionnaires, Risks and Vendors, according to Safeguard's offering reference. Map your controls to the frameworks your carriers reference, such as NIST CSF 2.0, and attach the evidence once. The suite's framework library covers hundreds of frameworks grouped by region.

5. Draft questionnaire answers from your evidence. The Questionnaires tab is where carrier questionnaires are worked. Safeguard's offering reference describes questionnaire auto-answer from standard formats such as SIG and CAIQ as part of Trust Center. Treat every drafted answer as a first draft: read it, check it against the evidence, and edit it into your own words before it goes to a carrier. You remain the person warranting it.

6. Publish a Trust Center. Trust Center (GA) is set up on Compliance › Trust Center, per the Trust Center docs. You choose a public slug under trust.safeguard.sh, set the organisation name, description and security contact, and turn on Publish Trust Center in Advanced settings. Nothing goes live on its own. You pick which frameworks to show, each with a status of Compliant, In progress, Not assessed or Signed, and which control areas to show, read live from continuous monitoring. The docs are explicit that a framework needing an independent auditor cannot be declared compliant on a self-assessment, which keeps you honest by default.

7. Share restricted documents through access requests. In the Trust Center Documents section you add files with a category, including Questionnaire, Penetration test and Compliance report, and set each to Public or Restricted. Restricted documents, such as a penetration test summary, are released only through access requests: per the access request docs, the visitor accepts your NDA and confirms their email, your team approves or denies, and the approved viewer downloads only what they were given. Each file shows its size and SHA-256. If an auditor records an issued opinion in the audit workspace, the docs say you can publish the audit outcome, with the signed report available on request through the same approval path.

8. Share SBOMs through Portal. Portal (GA), the SBOM publish and share product, gives you three methods according to the sharing docs: direct sharing to named email addresses with a permission level (View, Download or Full), shareable links with expiration date, download limit, password protection and format restrictions, and a branded customer portal. You can require NDA acceptance per SBOM, restrict sharing to approved domains, see who accessed which SBOM and when, and revoke access immediately. Publishing to Portal creates an immutable copy, per Safeguard's offering reference, which answers the "what exactly did you send us" question next year.

9. Keep carriers informed between reviews. The Trust Center docs describe updates that can be an announcement, an incident or a security advisory, subscribers who receive email when you publish a change, and security contacts your customers name to receive notifications. Notify about an update sends a published update to every security contact by email. That is a delivery channel for the notice you committed to in the contract; the decision to send, and what it says, stay with you.

10. Refresh, do not rebuild. At renewal, the SBOMs, vulnerability log, exceptions and evidence are already current. Your work is to review changed answers, update gap statements, and send.

Requirement, what Safeguard does, what you still own

Where Safeguard itself stands

If a carrier asks about Safeguard as one of your subprocessors, use the wording from Safeguard's compliance docs: the platform is designed for FedRAMP High, it does not hold a FedRAMP authorization, and its SOC 2 Type II audit is in progress. Do not describe it any other way in a questionnaire answer.

What Safeguard does not do

• It does not negotiate with carriers. Notice windows, audit rights, indemnities and right-to-assess clauses are contract terms between you and the carrier, with counsel on both sides.
• It does not sign or warrant your answers. Questionnaire drafts are drafts. Under 500.11(b)(4) the carrier treats your answers as representations, and a person at your company owns them.
• Trust Center shows only what you publish. It does not make a framework compliant, and the docs prevent declaring an auditor-backed framework compliant on self-assessment. If you have not done the work, the page will show that.
• It does not write your policies or run your controls. It can hold policies, map controls and collect evidence. Your access reviews, tabletop exercises and incident decisions still happen in your company.
• It does not decide when an incident is notifiable. The determination that starts a regulatory or contractual clock is a judgment your incident lead and counsel make.
• It does not fix vulnerabilities by itself unless you choose that. Autonomous remediation ships switched off, with every category set to Manual. Engineers still review and merge.
• It is not legal advice. Neither is this post. How 500.11 or a state's model law applies to a specific contract is a question for counsel.

What stays yours: contract terms, policies and the carrier relationship

Some of this job is not about evidence at all.

• Contract terms. You decide which notice window you can meet, which audit rights you accept, and how you respond when a carrier's paper asks for more than your size supports.
• Policies. They must describe what your company actually does. A tool can store and map them; only you can make them true.
• The relationship. The analyst at the carrier is a person with a backlog. Answering early, attaching evidence, and telling them about a slipped gap date before they find it does more for renewal than any single control.
• Your own vendors. Your hosting provider, logging service and support tools are your third-party service providers. Carriers increasingly ask how you assess them, because GV.SC applies to you too.

Common mistakes

• Answering "yes" to the SBOM question without a current file. Generate it first, read it, then answer.
• Using a generic policy template that describes a company you are not. It fails on the first follow-up question.
• Committing to an incident notice window your on-call cannot meet. The clause outlives the renewal call.
• Treating the questionnaire as a sales document. Representations are for the carrier's file and, after an incident, for its counsel.
• Leaving container images out of the inventory. Base image packages are part of what you ship.
• Rebuilding the pack every year. Keep the master answer set, the mapping and the evidence together, and refresh it.
• Hiding gaps. Stated gaps with dates pass reviews. Discovered gaps cost trust.
• Forgetting your own subprocessors. The carrier's fourth parties are your third parties.

FAQ

How does an insurtech pass an insurance carrier's vendor security review?

Answer the questions the carrier's regulation forces it to ask, with evidence rather than assertions. Provide policies, a current SBOM, a vulnerability handling record, access and encryption evidence, and an incident notice commitment you can keep. State gaps plainly with owners and dates.

Why do insurance carriers send vendor security questionnaires every year?

In New York, 23 NYCRR 500.11(a)(4) requires periodic assessment of third-party service providers based on their risk. States that adopted the NAIC model law require due diligence on providers and annual reporting to the board that covers those arrangements. The annual review is how carriers meet those duties.

Do insurtech startups need SOC 2 to sell to carriers?

Not always as a legal matter, but many carriers ask for an independent report. If you do not have one, provide your readiness assessment, the planned audit window and your control evidence. Many carriers have a path for vendors without a report, often with more questions.

What does NYDFS 500.11 require from vendors?

It places duties on the covered entity, not directly on the vendor. The carrier must assess you, set minimum practices, run due diligence and reassess periodically, and its contract terms should address your access controls, encryption, incident notice and representations. Those duties reach you through the contract and the questionnaire.

How fast do I have to notify a carrier of a cybersecurity incident?

Whatever your contract says. The carrier's own regulator may expect notice within 72 hours of its determination in New York, or within the adopting state's clock, so carriers ask vendors for less. Commit to what your team can actually do, and negotiate the trigger and start of the clock.

Should I share my SBOM with a carrier?

If the carrier asks and the SBOM describes software they use, sharing it under appropriate terms is reasonable. Share through a channel that records who received which version, set an expiry, and keep the exact file you sent.

What SBOM format do carriers want?

Most accept SPDX or CycloneDX. Check that the SBOM meets CISA's 2026 Minimum Elements, which replaced the NTIA 2021 minimum elements, and ask the carrier if they have a format preference.

Can I reuse one questionnaire answer set for every carrier?

Yes, if you organise answers by control and evidence rather than by one carrier's question numbers. Keep a master set, map each carrier's questionnaire to it, and track carrier-specific contract terms separately.

What if I cannot meet one of the carrier's minimum requirements?

Say so, explain the compensating control, and give a plan with an owner and date. Many carriers record an open item with a follow-up date rather than blocking renewal outright. If they do block, you know what to fix first.

Before the renewal goes out

The vulnerability handling record is the part of the pack that changes most between reviews, and carriers increasingly ask what you do when a fix is not yet available. The section below describes how Safeguard closes that gap for the open source in your product, which is the same record you will show the carrier at the next renewal.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo shows Claude connected to the Safeguard MCP server with OAuth, where you choose which tools Claude can use. For a CTO answering a questionnaire late at night, the same connection lets you ask Claude about your own projects and vulnerabilities in plain language while you draft, with the tool access you approved.

Click through it at your own pace, or open it full screen.

The second demo is a real session in the Safeguard desktop app. The CLI session appears in the conversation list, you ask for work on your computer, pick the folder, then Approve or Deny each command and file edit, and it ends with a dependency upgrade done and tests passing. That approved, tested change is exactly the kind of dated entry the vulnerability log in your carrier pack needs.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• 23 NYCRR 500.11, Third Party Service Provider Security Policy (Cornell LII)
• 23 NYCRR 500.17, Notices to Superintendent (Cornell LII)
• Code of Virginia § 38.2-623, Information security program
• Code of Virginia § 38.2-625, Notice to Commissioner
• NIST Cybersecurity Framework 2.0 (NIST CSWP 29)
• NIST SP 800-161 Rev. 1, Cybersecurity Supply Chain Risk Management Practices
• CISA, 2026 Minimum Elements for a Software Bill of Materials
• Safeguard docs: Compliance
• Safeguard docs: Trust Center setup
• Safeguard docs: Trust Center access requests
• Safeguard docs: Portal sharing
• Safeguard docs: Generate SBOM
• Safeguard docs: Vulnerabilities

Download Safeguard at safeguard.sh/download and read the documentation at docs.safeguard.sh/docs.

Last reviewed: 25 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.