Prepare for a State Insurance Exam IT Review as a CISO

To prepare for the IT review in a state insurance financial condition examination, start from the examiners' own playbook: the NAIC Financial Condition Examiners Handbook and its Exhibit C, which opens with an IT planning questionnaire and then tests IT general controls such as change management, vulnerability management and vendor oversight. Answer the questionnaire early and completely, stage evidence for each control the examiners are likely to sample, and write down known gaps with owners and dates before fieldwork starts. If your state has adopted the NAIC Insurance Data Security Model Law, or you hold a New York license, the same evidence also has to support your annual cybersecurity certification.

This guide is for the CISO of a US property and casualty or life insurer whose domiciliary state has just sent an examination notice with an IT review in scope. It draws on published NAIC, New York DFS and NIST texts. It is not legal or regulatory advice and does not describe what any particular examination letter says; your counsel and exam coordinator decide how you respond.

Key takeaways

• The IT review is part of the risk-focused financial condition examination. It is driven by Exhibit C of the NAIC Financial Condition Examiners Handbook: Part One is the Information Technology Planning Questionnaire (ITPQ) and Part Two is the IT work program of risks, controls and test procedures.
• The NAIC is revising it: an October 2026 exposure draft separates IT general controls (ITGC) reliability from a prospective cyber risk assessment and adds an Exhibit C Part Three aligned with NIST CSF 2.0. Ask which version applies to you.
• The NAIC Insurance Data Security Model Law (#668) puts risk assessment in Section 4(C), risk management (including secure development) in 4(D), third-party oversight in 4(F) and a February 15 certification in 4(I). Adoption varies by state.
• New York licensees add 23 NYCRR 500: vulnerability management (500.5), application security (500.8), third parties (500.11), asset inventory (500.13) and an April 15 certification (500.17(b)).
• Examiners sample: change tickets, emergency change reviews, vulnerability aging against SLAs and a risk-tiered vendor inventory. Stage those first.
• Fix what is cheap and visible before fieldwork; document the rest as known gaps with owners, dates and interim measures.
• Safeguard helps with the software and supplier part of the evidence: SBOM generation and analysis (GA), vulnerability management with EPSS and KEV enrichment (GA), reachability analysis and prioritization (GA), policies and gates with exceptions (GA), the compliance and GRC suite (GA), TPRM (GA), bulk data export (GA), the MCP server (GA) and the desktop app (GA). It does not prepare your examination response or speak to examiners.

The situation

The letter arrives from the domiciliary state's insurance department. It sets an as-of date, names an examiner-in-charge and, somewhere in the scope paragraph, says the examination will include a review of information technology. A request list usually follows, and the first item on it is often the IT planning questionnaire. The first meeting with the examination team may be a few weeks away. Fieldwork follows.

The CISO's problem is rarely missing controls. It is that the evidence lives in six systems owned by four teams, and the examiners will sample from a period that may run back years.

A bad week looks like this. The ITPQ goes back late and thin, so the IT examiner widens scope. The change population turns out to span two ticketing tools. A sampled claims system change has no test evidence. Critical vulnerabilities are older than your policy allows, with no exception records. A significant vendor's assurance report expired months ago. None of this is unusual, and all of it becomes a finding if you meet it first in front of the examiner.

The good news is that the NAIC exposed its revised IT work program for public comment in 2026, so you can read what examiners are told to request and test.

What the IT review is and which exhibit drives it

Domestic insurers are examined by their domiciliary state on a recurring cycle set by state law. Those financial condition examinations follow the NAIC Financial Condition Examiners Handbook, which guides how examinations are planned and performed. The handbook's general examination considerations include a section titled General Information Technology Review.

The handbook text exposed by the NAIC in October 2026 describes IT general controls (ITGCs) as policies and procedures that help computer systems operate properly, including network operations, software acquisition and maintenance, and access security. Effective ITGCs let financial examiners rely on your systems and reports. In other words, the IT review exists so the financial examiners can trust the numbers, which is why systems feeding financial reporting, policy administration, claims and investments get the most attention.

Exhibit C, part by part

Exhibit C, Evaluation of Controls in Information Technology, is the examiner's tool for the IT review.

• Part One, the ITPQ. The Information Technology Planning Questionnaire gives the department a high-level view of your IT environment. The handbook says it should be completed in advance of normal examination planning so the examiner can decide which sections of the work program to prepare. Its answers shape scope.
• Part Two, the IT work program. The Evaluation of Controls in IT Work Program lists general IT risks, example controls, the information examiners request and possible test procedures. In the exposed draft it is organized by COBIT 2019 domains: Align, Plan and Organize (APO); Build, Acquire and Implement (BAI); Deliver, Service and Support (DSS); and Monitor, Evaluate and Assess (MEA).
• Part Three, proposed. The October 2026 exposure adds a Prospective Cyber Risk Evaluation of Controls Work Program, with risk statements cross-referenced to NIST CSF 2.0 subcategories.

Six steps today, seven proposed

The handbook has long described a formal, stepwise general IT review that begins with gathering IT planning information, including the ITPQ, prior examination workpapers and the work of internal and external auditors. The exposed revision, put out for a 25-day comment period ending 2 November 2026, splits the work in two. Steps 1 to 3 assess ITGC reliability, based on COBIT 2019, and should be completed before the end of Phase 2 so the financial team gets a timely conclusion. Steps 4 to 6 are a prospective cybersecurity risk assessment, based on COBIT 2019 and NIST CSF 2.0, which may continue into later phases. Step 7 closes out by the end of Phase 5. The draft marks the change from six steps to seven.

The practical point: the IT examiner forms an early view of whether your ITGCs can be relied on, so planning is where you win or lose scope. Because the revision was still in comment at the time of writing, ask your examiner-in-charge which edition of the handbook and which version of Exhibit C apply.

What examiners say they will use

The handbook text lets the IT examiner use other people's work. It names prior examination workpapers, work by internal and external auditors or consultants, and reports from cyber self-assessment tools. Depending on their scope, date and whether an independent party validated them, those results may be used to populate Exhibit C or reduce the extent of testing. If your internal audit team tested change management last year, or an external firm assessed you against NIST CSF 2.0, put that work in front of the examiner early. It can shrink fieldwork.

The same section lists factors that shape IT scope, among them system complexity, recent changes, whether software was developed internally or externally, how much IT is outsourced and changes made to comply with state data security model laws. Answer each in the ITPQ before anyone asks.

What the NAIC Insurance Data Security Model Law requires

The NAIC adopted the Insurance Data Security Model Law (#668) in the fourth quarter of 2017. States that enact it, often with changes, impose an information security program duty on licensees, and Section 7 lets the commissioner examine a licensee for compliance with it. In an adopting state, the IT review and your data security program meet in the same room.

Section 4(C): risk assessment

Section 4(C) requires the licensee to name who is responsible for the program, identify reasonably foreseeable threats (including to information held by third-party service providers), assess their likelihood and damage, and assess the sufficiency of its safeguards. Among the areas it names are information systems, "including network and software design," and detecting, preventing and responding to attacks. It also requires the licensee to assess the effectiveness of key controls no less than annually.

Section 4(D): risk management

Section 4(D) turns the assessment into measures. Based on its risk assessment, the licensee designs the program to mitigate identified risks and determines which listed security measures are appropriate. Three of the listed measures map directly to software and supplier evidence:

• 4(D)(2)(b): identify and manage the data, personnel, devices, systems and facilities that enable the business, by their importance. That is an inventory duty.
• 4(D)(2)(e): adopt secure development practices for in-house applications, and procedures for evaluating, assessing or testing the security of externally developed applications the licensee uses.
• 4(D)(2)(h): regularly test and monitor systems and procedures to detect actual and attempted attacks.

Section 4(D)(4) adds a duty to stay informed about emerging threats and vulnerabilities. An advisory and known-exploited intake process is the obvious evidence.

Section 4(F): third-party service providers

Section 4(F) is short. The licensee must exercise due diligence in selecting a third-party service provider and must require the provider to implement appropriate administrative, technical and physical measures to protect the systems and nonpublic information it can access or holds. Examiners will look for both halves: evidence of diligence at selection, and contract terms or other requirements placed on the provider.

Section 4(I): annual certification and records

Section 4(I) requires each domestic insurer to submit a written statement by February 15 each year certifying compliance with Section 4, and to keep the records, schedules and data supporting the certificate for five years. Where the insurer has identified areas, systems or processes that need material improvement, updating or redesign, it must document them and the remedial efforts planned and underway, and make that documentation available for inspection. That sentence is the legal basis for the known-gaps register later in this guide.

Which states adopted it

The NAIC publishes an implementation map for Model #668. The version current at the time of writing shows status as of 1 April 2026, and the NAIC states that the map does not determine whether enacted legislation contains all elements of the model. Enacted versions differ in details such as notification deadlines. Treat the model as a reading guide only, and work from your own state's statute and any regulation or bulletin under it. If your company is licensed in several states, your domiciliary state's law governs the examination, but other states' versions may still apply to your operations.

For New York licensees: what 23 NYCRR 500 adds

If you are licensed by the New York Department of Financial Services, Part 500 applies alongside whatever your domiciliary state requires. The second amendment, effective 1 November 2023, sharpened several duties that overlap with the IT review.

Two consequences follow. The 500.17(b) certification must rest on documentation sufficient to demonstrate material compliance, so the state exam file and the April filing should share one evidence set. And because the acknowledgment route exists, a documented gap with a timeline is a recognized outcome, not a hidden failure. For a deeper look at 500.5, see NYDFS 500.5 vulnerability management in plain words.

Which software development, patching and vendor controls are usually tested

The exposed Exhibit C Part Two lists, for each risk, the control examiners expect, the information they will request and the test procedures they may use. The table below summarizes the rows most relevant to software and suppliers, in plain words, with the evidence that usually satisfies each. The control identifiers are from the October 2026 exposure draft and may change before adoption.

Two patterns stand out, beyond the vulnerability plan attributes covered in the FAQ.

Examiners sample from populations. For change management they ask for the list of completed changes in the period, then pick. If you cannot produce a complete population quickly, including periods covered by a retired tool, that is a finding before sampling starts.

Vendor evidence is a classification exercise. The draft asks whether the vendor list is comprehensive, whether it considers both risk and material adverse impact, and whether access rights and controls follow the classification. A list without tiers, or tiers without consequences, will draw comment. The software supply chain risk assessment guide for insurance carriers covers how to tier software suppliers in more depth.

Where open source fits

Neither the model law nor Part 500 says "open source," yet much of the code in policy administration, claims and customer portals comes from open source components your teams or vendors pulled in, and both 4(D)(2)(e) and 500.8 reach externally developed applications. NIST CSF 2.0 makes the link explicit in GV.SC-07, where supplier risks must be "understood, recorded, prioritized, assessed, responded to, and monitored," and in ID.AM-02, which calls for maintained inventories of software, services and systems. A software bill of materials (SBOM) for each significant application is the cleanest way to show component-level inventory and that vulnerability monitoring reaches it.

Step by step: weeks, not months

The plan assumes about six weeks before IT fieldwork and works with whatever tools you already have.

1. Day 1 to 3: set up the exam workstream. Name one exam coordinator (often from compliance or internal audit) and one IT evidence lead who reports to you. Agree with legal who approves each response, and open a request log on day one.
2. Day 1 to 5: read the request list against Exhibit C. Map every IT request to the work program area it serves. Ask the examiner-in-charge about any you cannot map.
3. Week 1: draft the ITPQ. Answer fully: systems, hosting model, outsourced functions and significant changes since the last exam. Flag controls internal audit or an external firm already tested.
4. Week 1 to 2: build the populations. Pull complete lists for the period: changes (normal and emergency), user access changes for significant systems, vulnerability findings opened and closed, patches deployed, vendors onboarded and reviewed. Reconcile each population against its source system, and record how you produced it.
5. Week 2: self-sample. Pick ten to fifteen items from each population yourself, the way an examiner would, and check each against your own policy. This is the single most useful week in the plan.
6. Week 2 to 3: classify every exception you find. Use the decision table in the next section to decide what to fix now and what to document.
7. Week 3: refresh the vulnerability and vendor evidence. Produce a current aging report against your SLAs, with exception records attached. Request any expired SOC reports from significant vendors and record the request.
8. Week 3 to 4: write management responses for known gaps. Each gets an owner, a date, interim measures and a link to the board or committee reporting where it was disclosed.
9. Week 4: stage the evidence room. Organize by work program area, index everything, and add a short cover note per folder saying what it shows, what was withheld and why.
10. Week 5: walk the board or committee through the posture. Model law Section 4(E) expects at least an annual written board report covering third-party arrangements and testing results. The board should not hear of gaps first from the examiners.
11. Week 5 to 6: rehearse. Each control owner practices explaining the control, the population, one sample and one exception, in plain language.
12. During fieldwork: one channel, one log. Every examiner request goes through the coordinator and into the log with a due date, an owner and what was provided.

Template: evidence request log

The rows above are illustrative.

Template: known-gap entry

Gap ID: G-07
Area: BAI 06 change management (emergency changes)
Condition: Post-implementation reviews missing for 3 of 20 emergency changes sampled internally
Root cause: Review step not enforced in the ticket workflow
Risk: Unreviewed emergency changes could introduce errors in a financial reporting system
Interim measure: Weekly manual review of all emergency changes by change manager, started [date]
Remediation: Workflow change making the review mandatory before closure
Owner: [name]   Target date: [date]
Disclosed to: [committee, date]
Status evidence: [file references]

The numbers in the gap entry are illustrative.

How to stage an evidence room without over-sharing

Examiners are entitled to what they ask for, and in the model law, Section 8 makes documents the commissioner obtains in an examination under the act confidential and privileged, while still usable in regulatory action. That still does not make it wise to hand over everything. Over-sharing widens scope, risks exposing policyholder data or credentials in screenshots, and buries the evidence that answers the question.

A few rules keep the room tight.

• Answer the request, then stop. Give what was asked for, for the period asked, for the systems in scope. If you think more context helps, say it in the cover note and offer it.
• Summaries first, raw data on request. For vulnerability evidence, a summary by system, severity and age answers most questions. Offer the raw export if the examiner wants to re-perform; this also keeps exploitable detail out of copies that travel.
• Redact what is not needed. Strip nonpublic personal information, internal IP addresses and credentials from screenshots and logs. Record what you redacted and why.
• One version, one index. Each file gets a request ID, a version and a date. When you replace a file, keep the old one in an archive folder, not in the room.
• Read-only access, logged. Whatever platform you use, give examiners read-only access and keep a log of who viewed what.
• Legal reviews anything that interprets. Facts and records go through the coordinator; anything that states a position (a management response, an explanation of a gap) gets legal review.

The general approach is set out in more detail in respond to an auditor evidence request without over-sharing.

What to fix before fieldwork and what to document as a known gap

Not every issue you find in self-sampling should be rushed. A hurried fix that breaks a production system, or a back-dated record, is far worse than an honest gap with a plan. Back-dating or fabricating evidence is never acceptable. Use the table to decide.

When a case is borderline, ask whether the fix can be finished and evidenced before fieldwork, and whether the fix itself adds change risk to a financial reporting system. If not, and yes, document it and tell the committee now.

Keep it current so the next exam is routine

Tag evidence with its Exhibit C area as it is produced, run the self-sample quarterly, and keep one known-gaps register that feeds the board report under model law Section 4(E), the February 15 certification under 4(I) and, for New York, the April 15 filing under 500.17(b). Refresh SBOMs on every release of significant applications, and map your controls to NIST CSF 2.0 once, since the proposed Part Three cross-references it.

How Safeguard does this

Safeguard's part is the software and supplier evidence: what is in the applications you build and buy, which known vulnerabilities affect them and for how long, whether policies were met or formally excepted, and how vendors are tiered and monitored. Everything below comes from Safeguard's offering documentation and docs.safeguard.sh. Commands were copied from the docs and were not run for this post.

1. Inventory every significant application with an SBOM. SBOM generation and analysis is GA, in SPDX and CycloneDX. In the web app, open Integrations from the sidebar and connect repositories or container images, or upload manifests and CSAF or VEX files; projects then appear under Projects with findings and vulnerability counts. The docs say Safeguard scans all projects daily for newly disclosed vulnerabilities, with optional triggers on push, on a schedule or on release. To scan locally, the docs show the CLI:

   # 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 note that a scan from the interactive terminal while signed in uploads the SBOM and findings to the platform, and the source stays on the machine.

2. Turn findings into an aging view the examiner recognizes. Vulnerability management is GA: detection draws on sources including NVD, GHSA, OSV and CISA KEV, with EPSS and KEV enrichment and severity categories. Reachability analysis and prioritization (GA) ranks the findings whose vulnerable code your application actually calls. That supports the scoring and aging attributes the draft work program asks for, at component level, for the applications you scan. Endpoint and network scanning stays with your existing tools.

3. Write your remediation SLA as a policy and gate it. Policies, gates and guardrails are GA. In Settings, Policies, select Create Policy, define conditions with the visual builder or YAML, set severity and an action, then save and enable. Conditions include severity, CVSS score, EPSS score, license and component age. Each policy's action decides what a failure does to the gate: Block fails the gate, Warn passes it with a warning naming the policy, and Notify passes it and sends a notification. Gates are evaluated by the platform on the scans it runs for connected repositories, and with policy outcomes on for your workspace the docs show a CI command that fails the job when a gate fails:

   safeguard ci scan --wait --fail-on-gate <gate>
   

   The gate result then becomes part of the change record for every change that goes through the pipeline.

4. Record every exception with a justification and an expiry. When a fix cannot ship in time, the docs describe Request Exception: select the policy and finding, give a business justification, set an expiration date and submit for approval. Approvers are notified, decide, and an audit trail is recorded. Reports cover status by policy, exception history and violation trends. That is the exception record examiners look for behind an aging report.

5. Switch on the frameworks you report against. The compliance and GRC suite is GA. Open Compliance, Manage, then the Frameworks tab, find a framework and switch it on. The docs list NY DFS 23 NYCRR 500, GLBA and NIST CSF 2.0 among the US frameworks. A scan checks each framework's requirements against what it found, including the SBOM; for 23 NYCRR 500 the docs map scan requirements to sections including 500.09, 500.11 and 500.13, plus catalog controls you evidence with tests, uploads, policies or attestations. Standard policy templates include Change Management, Vulnerability and Patch Management, and Third-Party or Vendor Risk Management. At the time of writing the NAIC model law does not appear as its own entry in the docs' framework list, so map its Section 4 clauses to the NIST CSF 2.0 or Part 500 controls yourself.

6. Read the readiness score for what it is. The docs define a framework's readiness score as the share of in-scope requirements that pass, either on a scan or on an attestation by a person that names its evidence. They state plainly that a readiness score is Safeguard's assessment of what it can see, not an audit opinion or a certification. Use it to find gaps before the examiner does, not as a statement of compliance.

7. Tier, request and monitor software vendors. TPRM is GA. The docs' getting started flow is: add vendors to your directory, categorize them by risk tier, request SBOMs from high-risk vendors, review and validate submissions, and enable continuous monitoring. The docs' default tiers ask critical vendors for quarterly SBOM updates and high-risk vendors for annual ones. The offering documentation adds request status tracking, automated follow-ups, a vendor risk score from 0 to 100 (higher is better) and alerts for new critical vulnerabilities, KEV additions and SBOM expiry. That supports the risk-classified inventory and periodic assessment parts of APO 10 and 500.11 for software suppliers. Contract terms and SOC report reviews remain your vendor management team's work.

8. Keep people in the approval seat. The docs' requests and approvals page lists the decisions that only count once a person makes them: a policy, evidence, an access review, a test exclusion, a risk acceptance, a crosswalk mapping. Safeguard's assistant and MCP clients can prepare work but never approve, accept or sign off. That is the separation an examiner expects between preparing evidence and attesting to it.

9. Export what the examiner asked for, no more. Bulk data export is GA, in formats including CSV, Excel, PDF and JSON, with filtering and column selection. The compliance docs describe custom reports (open Reports, select Create Report, choose the framework, set scope and date range, then generate and export) and audit support including read-only assessor access. Filter to in-scope systems and the exam period before exporting, and record the filter in your cover note.

10. Ask questions from Claude, if you use it. The Safeguard MCP server is GA, and Safeguard is listed in the Claude connector directory as a community connector. You choose which tools the assistant may use, and the approval rule in step 8 still applies.

Requirement, Safeguard's part and what you still own

What stays the insurer's job

• Examiner liaison. The coordinator, the CISO and counsel own the relationship and every conversation with the examination team.
• Management responses. Written and approved by management, with legal review. A tool supplies facts, not positions.
• Financial, actuarial and investment scope. Reserves, investments and reinsurance are outside anything a software security platform touches.
• Certifications and board reporting. The February 15 and April 15 filings and the board report are signed by named executives.
• Interpretation of your state's law. A question for counsel.

What Safeguard does not do

• It does not prepare or submit your examination response. Safeguard produces inventories, findings, policy results, exception records and exports. The ITPQ, the request log, management responses and every conversation with examiners remain yours.
• It covers software and supplier evidence, not the whole IT review. Access management for financial systems, backup and recovery, data center and network controls, endpoint protection, business continuity and IT governance committees sit outside it, so plan to evidence those areas from the systems that run them.
• It does not decide materiality or compliance. The readiness score is, in the docs' words, not an audit opinion or a certification. Whether you materially complied with Part 500 or Section 4 of your state's law is a judgment for your executives and counsel.
• It does not track your state's adoption of the model law. The NAIC model does not appear as its own framework entry in the docs' list at the time of writing, and state enactments differ. Map the clauses yourself.
• It does not replace penetration testing or infrastructure scanning. 500.5(a)(1) requires penetration testing by a qualified party; keep those programs.
• It does not review vendor contracts or SOC reports. TPRM tiers vendors, requests SBOMs and monitors them; reading a SOC 2 report, assessing exceptions in it and negotiating contract clauses stay with your team.
• It becomes one of your third-party service providers. If you use it, assess it under 4(F) and 500.11 like any other vendor. Safeguard's own posture is an architecture designed for FedRAMP High and a SOC 2 Type II audit in progress; ask for the current state through its Trust Center (GA).

Common mistakes

• Treating the ITPQ as a form. It sets scope. A late or thin questionnaire is the most common way to end up with a larger IT review than necessary.
• Producing populations you cannot reconcile. If the change count in your export does not match the source system, the examiner will spend time on the population instead of the controls.
• Fixing history. Adding approvals after the fact without dating them, or editing tickets, turns a control gap into an integrity problem.
• Showing raw scanner exports first. Thousands of rows with no aging, no SLA and no exceptions invite questions you cannot answer in the room. Lead with the plan and the aging summary.
• Ignoring open source inside your own applications. Externally developed code includes the components in your in-house builds. Without an SBOM you cannot show vulnerability monitoring reaches them.

FAQ

What is the IT review in a state insurance financial condition examination?

The part of the financial condition examination where an IT examiner evaluates your IT general controls and cybersecurity risk management, so the financial examiners know how far to rely on your systems. It follows the NAIC handbook's General Information Technology Review guidance and Exhibit C.

What is Exhibit C in the NAIC examiners handbook?

Exhibit C, Evaluation of Controls in Information Technology, is the examiner's IT tool. Part One is the Information Technology Planning Questionnaire, Part Two is the IT work program of risks, controls and test procedures, and an October 2026 exposure draft proposes a Part Three for prospective cyber risk aligned with NIST CSF 2.0.

Does the NAIC Insurance Data Security Model Law apply to my company?

Only through your state's enacted law. The NAIC's implementation map (status as of 1 April 2026) shows which states have acted, and it says it does not determine whether a state's law contains every element of the model. Check your state's statute and any department regulation or bulletin with counsel.

What does Section 4(F) of the model law require for vendors?

Due diligence in selecting a third-party service provider, and a requirement that the provider implement appropriate administrative, technical and physical measures to protect the systems and nonpublic information it can access or holds.

How does NYDFS Part 500 interact with a state insurance exam?

For New York licensees it applies alongside the domiciliary state's rules. Its duties overlap the IT review, and the April 15 certification under 500.17(b) needs supporting evidence kept for five years.

What do examiners look for in a vulnerability management plan?

The exposed work program asks whether the plan uses standardized scanning tools and industry scoring such as CVSS, scans endpoints, servers, network devices, databases, web applications and gateways regularly, sets remediation SLAs, and reports and ages open vulnerabilities.

Should we fix every finding before the examiners arrive?

No. Fix what is cheap, low risk and verifiable in time, such as stale documents and known-exploited vulnerabilities on exposed systems. Document design gaps with owners, dates and interim measures. Never alter historical records.

Can a compliance platform's readiness score be shown to examiners as proof of compliance?

Treat it as an internal gap-finding tool. Safeguard's docs, for example, say its readiness score is not an audit opinion or a certification. Examiners test controls and evidence, not scores.

The open source components in your aging report are the ones examiners ask about, so the faster a fix reaches production, the shorter that report and the conversation about it. The section below sets out how Safeguard closes that gap for the dependencies and images you build and ship.

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, and how you choose which tools Claude can use. During an exam, the same setup lets an evidence lead put questions to Safeguard from Claude, limited to the tools you allow, while approvals stay with people in the app.

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

The second demo shows the desktop app (GA) sending work to a computer running the Safeguard CLI, with each command that changes something approved before it runs. For a CISO preparing for fieldwork, that is a way to run a scan of an in-scope repository on a controlled machine while keeping a person in charge of every command.

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

To try it on your own applications, download Safeguard at safeguard.sh/download and read the documentation at docs.safeguard.sh. If you sell software to insurers rather than run one, the companion guide on the NAIC Insurance Data Security Model Law for software vendors covers the other side of the table.

Quick check

Sources

• NAIC Insurance Data Security Model Law (#668)
• NAIC implementation map for Model #668, status as of 1 April 2026
• NAIC Information Technology Examination (E) Working Group exposure: Exhibit C Parts Two and Three and handbook updates, October 2026
• 23 NYCRR 500.5 Vulnerability management (Cornell LII)
• 23 NYCRR 500.8 Application security (Cornell LII)
• 23 NYCRR 500.11 Third-party service provider security policy (Cornell LII)
• 23 NYCRR 500.13 Asset management and data retention (Cornell LII)
• 23 NYCRR 500.17 Notices to superintendent (Cornell LII)
• NIST Cybersecurity Framework 2.0 (CSWP 29)
• NIST SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning
• CISA Known Exploited Vulnerabilities Catalog
• CISA BOD 26-04, Prioritizing Security Updates Based on Risk
• Safeguard docs: Compliance
• Safeguard docs: Compliance frameworks
• Safeguard docs: NY DFS 23 NYCRR 500
• Safeguard docs: NIST CSF 2.0
• Safeguard docs: Requests and approvals
• Safeguard docs: Generate SBOM
• Safeguard docs: Policies and Gates
• Safeguard docs: Third Party Risk Manager
• Safeguard Gold Open Source

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