What a fintech CTO should report to the board on security

If you are the CTO of a US fintech and also the qualified individual under the FTC Safeguards Rule, you owe your board a written security report at least once a year. It must state the overall status of the information security program and your compliance with the rule, then cover the material matters: risk assessment, risk and control decisions, service providers, test results, security events and your responses, and the changes you recommend. Five slides and a few pages of backing notes will do, if every number traces to a record you already keep.

This guide is for the CTO who wants the update to be honest without scaring anyone. It is not legal advice; your counsel should confirm how the rule applies to your licences and products.

Key takeaways

• 16 CFR 314.4(i) requires the qualified individual to report in writing, regularly and at least annually, to the board or equivalent governing body. The content list is short and specific; build the report around it.
• The qualified individual can be an employee, an affiliate or a service provider (314.4(a)). Nothing in the text bars the CTO, but the board should know where the CTO approves exceptions to controls the same team builds.
• Since 13 May 2024 the rule also requires notice to the FTC within 30 days of discovering a notification event that involves at least 500 consumers (314.4(j)). Your report should say whether any occurred.
• Sponsor banks, card brands and state regulators layer their own expectations on top. One report can serve all of them if you structure it by the rule's own headings.
• A startup board needs five things: overall status, top risks with trend, third party and open source exposure, incidents and near misses, and the plan with the ask.
• Safeguard's executive dashboards and exports (GA), SBOM generation and vulnerability management (GA), the compliance and GRC suite with the GLBA framework (GA) and the Third Party Risk Manager, TPRM (GA), produce most of the numbers. The judgement, the narrative and the program stay yours.

The situation

The board has given security its own slot for the first time. Maybe a new independent director asked for it. Maybe the sponsor bank's last review mentioned "board oversight of information security" and someone noticed you had never presented. Maybe the Series B lead wants it as a standing item. Either way, you have a date, and you have about a week.

You are in an unusual position. As CTO you run the systems. As the qualified individual you oversee and enforce the security program for those same systems. As the compliance owner you also answer the sponsor bank's questionnaire, the card network's assessment and whatever the state licence examiner sends. Three hats, one report.

A bad week looks like this. A vulnerability count from one tool, a vendor list from a spreadsheet last touched in spring, an incident log that lives in a chat channel. The deck has forty findings and no decisions. A director asks "are we compliant?" and you say "mostly". The meeting ends with the board more worried than when it started, and nobody has approved the hire you needed.

A good week looks different. The report follows the rule's own headings, so the minutes show the board received what 314.4(i) requires. Every number comes from a dated system of record. Risks are business outcomes with owners and decisions. The last slide asks for two or three specific decisions, and the board makes them. If you are still building the basics, our guide to security at Series A covers what to put in place first.

The rule behind it: what 16 CFR 314.4(i) requires

The FTC's Standards for Safeguarding Customer Information, usually called the Safeguards Rule, live at 16 CFR Part 314. They apply to non-bank financial institutions under the FTC's jurisdiction, which covers a large share of US fintechs: lenders, payment and money services firms, finders and others engaged in activities that are "financial in nature". Whether your company is in scope depends on what it does, so confirm that with counsel before you lean on any of this.

The FTC rewrote the rule in a final rule published on 9 December 2021 (86 FR 70272), effective 10 January 2022. The Federal Register summary lists five main changes. The second is the one that matters here: provisions to improve accountability, "such as by requiring periodic reports to boards of directors or governing bodies".

What the annual report must cover

Section 314.4(i) says you must require your qualified individual to report in writing, regularly and at least annually, to your board of directors or equivalent governing body. If you have no board or equivalent, the report goes in a timely way to a senior officer responsible for the program.

The report must include two things:

1. The overall status of the information security program and your compliance with this part. That is one honest paragraph: where the program stands, and whether you meet each element of 314.4.
2. Material matters related to the program. The rule lists examples: risk assessment, risk management and control decisions, service provider arrangements, results of testing, security events or violations and management's responses, and recommendations for changes in the program.

Three words carry weight. "In writing" means a deck presented verbally is a weak record; send a written report with the board pack and make sure the minutes record that the board received it. "At least annually" is the floor; a short quarterly update plus the full annual report means the annual one holds no surprises. And "compliance with this part" means the board is entitled to hear where you are not compliant, such as multi factor authentication missing on some systems, with the plan.

Who can be the qualified individual

Section 314.4(a) requires you to designate a qualified individual responsible for overseeing, implementing and enforcing the program. That person may be employed by you, by an affiliate or by a service provider. If you use a service provider or affiliate, you keep responsibility for compliance, you designate a senior member of your own staff to direct and oversee that person, and you require the provider to maintain a program that protects you.

Nothing in the text stops the CTO from being the qualified individual. Many startups start there, and investors often ask about it; see the security questions investors ask at seed and Series A. But be candid with the board about one structural point. Several controls in the rule let the qualified individual approve an alternative. Under 314.4(c)(3) the qualified individual can approve compensating controls where encryption is infeasible. Under 314.4(c)(5) the qualified individual can approve in writing access controls that are reasonably equivalent to multi factor authentication. When the CTO is the qualified individual, the person approving the exception may also be the person whose roadmap benefits from it. Disclose each such approval in the report so the board can see and question it.

Section 314.4(e)(2) also requires qualified information security personnel sufficient to manage your risks. If the CTO is the only person doing security, the report is the place to say whether that is still enough.

The small institution exception

Section 314.6 says that 314.4(b)(1), (d)(2), (h) and (i) do not apply to financial institutions that maintain customer information on fewer than five thousand consumers. Those are the written risk assessment, the continuous monitoring or testing schedule, the written incident response plan and the board report.

Most fintechs with a board slot for security are past that line or will be soon, and sponsor banks and investors tend to expect the report anyway. If you have no formal board yet, our post on SOC 2 oversight for startups without a board covers the governing body question. If you are under the line, say so in the report and say when you expect to cross it. Do not skip the report on the strength of the exception without counsel confirming your count.

The FTC breach notice

A 2023 amendment (88 FR 77499, published 13 November 2023) added 314.4(j). Section 314.5 makes it effective 13 May 2024. If you discover a "notification event" involving the information of at least 500 consumers, you must notify the FTC as soon as possible and no later than 30 days after discovery, using the form on the FTC's website.

A notification event is acquisition of unencrypted customer information without the individual's authorization. Information counts as unencrypted if the key was accessed by an unauthorized person. Unauthorized access to unencrypted information is presumed to be acquisition unless you have reliable evidence that it was not. And the event is treated as discovered on the first day it is known to any employee, officer or other agent other than the person committing the breach.

That last point matters for your report. The clock starts when anyone on staff knows, not when the CTO hears about it. Your incident section should state, for each event in the period, whether it was a notification event and whether you notified.

The rest of 314.4, in one table

The report summarises the whole program, so here is every element of 314.4 and the record that usually shows it working.

What else applies to a fintech startup

The Safeguards Rule is the floor. A fintech usually answers to several other parties, and each one reads your board report differently.

Your sponsor bank

If you offer accounts, cards or payments through a partner bank, you are a third party to that bank. On 6 June 2023 the Federal Reserve, the FDIC and the OCC finalised the Interagency Guidance on Third Party Relationships: Risk Management (88 FR 37920, published 9 June 2023). It sets out how banking organisations should manage third parties across the life of the relationship, scaled to risk, complexity and size. The guidance is addressed to the bank, not to you, but its expectations reach you through your contract, the bank's due diligence requests and its ongoing monitoring.

Watch one current change. On 15 September 2026 the OCC, the Board, the FDIC and the NCUA proposed new third party risk management guidance (91 FR 58536). The notice says the agencies plan to rescind and replace the existing guidance, with more emphasis on tailoring oversight to the risk of each relationship. Comments close on 16 November 2026. Your sponsor bank's requests may change once a final version lands, so treat the 2023 text as current and the proposal as direction of travel.

The bank will ask whether your board oversees information security. A 314.4(i) report with minutes is the cleanest answer; keep a copy ready for its next review.

Card networks and PCI DSS

If you store, process or transmit cardholder data, or can affect the security of that environment, PCI DSS applies through your acquirer or the networks. The current version is PCI DSS v4.0.1, published in the PCI Security Standards Council document library. Requirement 12 covers the security policy and program governance; read the v4.0.1 text for the exact responsibilities it places on executive management. Your report should name who owns PCI scope, state the current status (self assessment questionnaire or report on compliance) and flag any scope change. Our post on cutting PCI scope before you comply covers that choice.

State licences

Money transmitter, lending and other state licences often bring their own exams, and some states have cybersecurity rules for licensees. This guide does not summarise state law. Ask counsel which of your licences carry a board reporting duty of their own, list them in an appendix with any open exam findings, and fold them into the same report rather than writing a second one.

A structure the board will recognise

NIST's Cybersecurity Framework 2.0, published 26 February 2024, added a Govern function that reads like a checklist for board oversight. Four outcomes are worth borrowing:

• GV.RR-01: organisational leadership is responsible and accountable for cybersecurity risk.
• GV.RM-02: risk appetite and risk tolerance statements are established, communicated and maintained.
• GV.OV-01 to GV.OV-03: strategy outcomes and risk management performance are reviewed and adjusted.
• GV.SC-04 and GV.SC-07: suppliers are known and prioritised by criticality, and supplier risks are understood, recorded, assessed, responded to and monitored over the relationship.

You do not need to adopt the framework to borrow its language.

Step by step: build the report in a week, with or without Safeguard

The steps assume you keep the basic records the rule requires. If you do not, the first report is where you say so and set the plan.

1. Fix the reporting period and the as of date. Use the period since the last report, or the last twelve months for a first report. Every number in the report uses the same as of date. Write it on every page.
2. Pull the risk assessment. Take the current written risk assessment required by 314.4(b). Note its date. If it is more than a year old, or the business has changed materially since (new product, new state, new processor), say a refresh is due and when.
3. Pull the control status against 314.4(c). For each safeguard (access controls, inventory, encryption, secure development, MFA, disposal, change management, logging), mark it in place, partial or not in place. List every exception the qualified individual approved under (c)(3) or (c)(5).
4. Pull testing results under 314.4(d). Penetration test date and summary, vulnerability assessment dates, and the trend of open findings by severity. If you run continuous monitoring instead of the periodic schedule, describe what it covers.
5. Pull the service provider list under 314.4(f). Every vendor that touches customer information, with criticality, contract status, date of last assessment and any open issues. Include your sponsor bank, your processor, your cloud and your core SaaS.
6. Pull the incident log under 314.4(h). Every security event in the period, including near misses, with the 314.4(j) decision for each.
7. Draft the written report. Use the outline in the template below. Keep it to six to ten pages plus appendices.
8. Build five slides. One per item in the next section. Each slide carries one number, one trend and one decision or ask.
9. Pre-read with one director. Walk the audit or risk committee chair through it a few days before.
10. File and minute it. Send the written report with the board pack. After the meeting, make sure the minutes record that the board received the qualified individual's report under 314.4(i), and record each decision.

Template: the written report outline

Copy this outline. Each section maps to a clause, so the report shows on its face that it covers what 314.4(i) asks.

Before it goes in the board pack, check that every number has an as of date and a source, every risk has an owner and a decision, every approved exception is listed, every security event has a 314.4(j) decision, and counsel has read the incident section.

Which five things belong on the slide

Directors read the slide before the report. Put these five things on it, in this order.

1. Overall status in one sentence

"The program covers every element of the Safeguards Rule. Two are partial: MFA on legacy admin tools, and annual vendor reassessments. Both close by Q1." That is the 314.4(i)(1) statement in plain words. If the answer is worse, say it in the same shape.

2. Top three risks, with trend

Three risks as business outcomes, each with a trend, an owner and a decision. "A flaw in a widely used open source library in our payments service could expose card tokens. Trend: down. Owner: payments lead. Decision: reduce; fix within policy windows." The full risk register goes in the report.

3. Third parties and open source

The count of critical vendors, how many were assessed this year, and one sentence on open source: what share of serious findings sit in third party components, and how fast you clear them.

4. Incidents and near misses

A small table: events in the period, by severity, with one line each on what happened and what changed. State whether any notification events occurred and whether the FTC was notified. If there were none, say "none" and say how you know (monitoring coverage).

5. The plan and the ask

What you will do in the next period, and what you need the board to decide. Two or three asks at most. The asks section below shows how to frame them.

A worked slide, illustrative

The numbers below are invented and rounded. Use the shape, not the figures.

How to present open source and vendor risk without jargon

Directors at a fintech understand credit risk, counterparty risk and concentration risk. Open source and vendor risk map onto those ideas cleanly. Use the analogy, then the number.

Open source is supply you did not buy

Most of a modern application is open source code the company did not write, and each package is a supplier with no contract and no SLA. The board needs three facts, not a scanner export:

1. Do we know what we run? Say whether you keep a software bill of materials (SBOM) for each product, and how often it updates. CISA's 2026 Minimum Elements for an SBOM describe what a complete one contains, if a director asks what "complete" means.
2. Which flaws matter? Explain that you rank findings by whether they are known to be exploited (CISA's Known Exploited Vulnerabilities catalog), how likely they are to be exploited soon (FIRST's Exploit Prediction Scoring System, EPSS, which estimates the probability of exploitation in the next 30 days), and whether your code actually calls the affected function. That is why the count on the slide is small.
3. How fast do we fix? Median days to fix by severity, and how many findings sat past your policy window at quarter end.

Vendors are counterparties

Your processor, sponsor bank, cloud, identity provider and core SaaS are counterparties with access to customer information. Section 314.4(f) asks you to choose them carefully, contract for safeguards and reassess them based on risk.

Show one line per critical vendor: what it does, what data it touches, when you last assessed it, and anything open.

A translation table for the room

Concentration is the question they will ask

Expect "what if our processor or our cloud goes down?" Keep one slide in reserve listing the vendors whose failure would stop the business, and the fallback, even if it is "we would be down; here is the cost per day".

How to report incidents and near misses

The rule asks for security events or violations and management's responses. Report them to show the program works, without hiding them or dramatising them.

Define your terms once

Put three definitions in the glossary:

• Security event: anything that could have affected the confidentiality, integrity or availability of customer information or the systems that hold it.
• Incident: a security event that did affect one of those, or that triggered your response plan.
• Notification event: the 314.4(j) term. Acquisition of unencrypted customer information without authorisation, presumed where unauthorised access occurred unless you have reliable evidence otherwise.

Report near misses on purpose

A near miss is an event your controls caught before harm: a phishing attempt blocked by MFA, a pull request held because it added a known exploited flaw, a vendor breach that did not touch your data. Each is one line, and together they show the controls work.

The incident table

For each event, state whether you made a 314.4(j) decision, who made it, and on what evidence. If you notified the FTC, give the date. If you decided an event was not a notification event, record why, because the presumption in the rule runs against you.

Tie incidents to changes

Section 314.4(g) asks you to adjust the program in light of events, and CSF 2.0 (ID.IM-02, ID.IM-04) says the same. The last column of the table is how you show it: every incident produces at least one change.

What to ask the board for

The rule's last item, recommendations for changes in the program, is your mandate to ask. A security update with no ask wastes the slot. Good asks are specific, priced and time bound.

Approve a risk appetite statement

GV.RM-02 calls for risk appetite and tolerance statements that are established and communicated. If you have none, the first board report is the place to propose one. Keep it short:

• Critical vulnerabilities in internet facing systems are fixed within a stated number of days.
• No customer data is held by a vendor that has not been assessed in the last twelve months.
• Exceptions to MFA or encryption require written approval by the qualified individual and are reported to the board at the next meeting.
• The company accepts a stated level of downtime per quarter for non critical systems.

Once approved, every later report measures against it.

Fund people or time

If 314.4(e)(2) staffing is thin, say so, and present the choice: hire one security engineer, retain an outside firm, or accept slower fix times and fewer vendor reviews, each with your own cost estimate. Do not promise that a tool replaces a person.

Decide on a structural question

Some decisions belong to the board: whether the qualified individual stays the CTO as the company grows, whether to cut PCI scope with a processor's hosted payment page, whether to accept a specific vendor concentration. Ask for a decision, or a date for one.

How Safeguard does this

Everything above works with spreadsheets and the tools you have. If you use Safeguard, most of the numbers in the report come from one place, with dates, and drill through to the records behind them. The flow below uses only what Safeguard's offering files and docs describe.

1. Keep an inventory of what you ship. SBOM generation and analysis (GA) builds a software bill of materials for each project in SPDX or CycloneDX, and continuous scanning updates it on push, on a schedule or on release. That is the "do we know what we run?" answer, and it supports the inventory element of 314.4(c)(2).
2. Track vulnerabilities with exploit context. Vulnerability management (GA) matches components against sources including NVD, GitHub Security Advisories, OSV, CISA KEV and vendor bulletins. Safeguard's docs say it rescans projects daily as new CVEs are published. The Vulnerabilities tab groups findings as Critical, High, Medium, Low and Exploitable. Reachability analysis and prioritisation (GA) ranks findings using EPSS, KEV status and whether the vulnerable code path is called. This is the source for the "serious flaws past deadline" number.
3. Record risk decisions where the finding lives. On a vulnerability, the docs show Accept Risk with an expiration date and a business justification, submitted for approval, and Mark False Positive with a justification. Those records are your "risk management and control decisions" for section 3 of the report. Policies, gates and guardrails (GA) can enforce your fix windows in CI with Block, Warn or Notify actions, with approval handled through exceptions.
4. Open the executive dashboard. The executive risk dashboard (GA) spans the whole platform rather than one project. Safeguard's docs describe a security score from 0 to 100 (severity, fix rate, policy compliance and component health), a vulnerability summary with severity trend, and a Top Risks list covering critical vulnerabilities in production, actively exploited CVEs, compliance violations and aging vulnerabilities. Trend charts show mean time to remediation. Every number drills through to the underlying results, which is useful when a director asks "which four?".
5. Export or schedule the report. The dashboard docs list PDF export of a formatted dashboard report and scheduled weekly or monthly email reports. Data exports (GA) cover formats including CSV, Excel, PDF and JSON, so the appendix tables can come straight from the platform with the as of date intact.
6. Turn on the GLBA framework in the compliance suite. The compliance and GRC suite (GA) has tabs for Overview, Frameworks, Controls, Evidence, Monitoring, Tests, Policies, Questionnaires, Risks, Vendors, Trust Center and Connectors. The docs say GLBA is on in your workspace unless you switch it off in Compliance › Manage. Its page lists scan requirements tied to 16 CFR 314.4(b), (c)(2), (c)(3), (c)(4) and (f), which a scan of your products decides, and catalog controls including one for the qualified individual and one for annual board reporting, which you evidence with uploads, policies or attestations. No automated tests map to GLBA directly; the docs say you can link tests to its controls yourself.
7. Read the readiness score honestly. The docs define a framework's readiness score as the share of in scope requirements that pass, either on a scan or on a person's attestation naming its evidence. Requirements waiting for evidence count as not yet passing. The docs also say the score "is not an audit opinion or a certification". Put the score in the report as an internal measure with that caveat, never as a compliance claim.
8. Start policies from templates. Open the framework on Compliance › Frameworks, then its Policies tab, select New policy and choose Start from template. The standard set includes incident response, vendor risk management and vulnerability management policies. You still adapt and approve them.
9. Generate a compliance report for the period. The compliance docs show a custom report flow: navigate to Reports, click Create Report, select the compliance framework, configure scope and date range, then generate and export. Pre-built reports include a vulnerability summary and an SBOM completeness audit.
10. Run vendor oversight in TPRM. The Third Party Risk Manager, TPRM (GA), keeps a vendor directory with contacts, contracts and SLAs, and categorises vendors by risk tier (Critical, High, Medium, Low), with suggested SBOM requirements per tier. You can request SBOMs from suppliers with templates and track each request through sent, viewed, in progress, submitted and validated or rejected. Each vendor gets a risk score from 0 to 100 where higher is better, built from vulnerability, compliance, component and operational risk using EPSS and KEV. Monitoring alerts on new critical vulnerabilities, KEV additions, risk changes and SBOM expiry to email, Slack, Teams, PagerDuty or a webhook. That is the service provider section of the report, and the GV.SC-04 ranked list.
11. Fix faster, under your control. Autonomous remediation (GA) can open fix pull requests for vulnerable dependencies, one repository at a time or in bulk. It ships switched off, with every category set to Manual, so you decide what runs on its own. The "median days to fix" line on your slide is where it shows up.

The dashboard security score and the TPRM vendor score both run 0 to 100 but measure different things; never put them on one scale.

Requirement, what Safeguard does, what you still own

What stays with the CTO

Even with every number automated, most of the report is judgement, and the rule puts it on the qualified individual: which three risks go on the slide and how you describe them; the compliance statement, which only you and counsel can make; each risk acceptance; the call on whether an event is a notification event; and the program itself (training, access reviews, the response plan, penetration tests, vendor contracts), which software can track but not do. Above all, telling the board where your CTO hat and your qualified individual hat pull in different directions.

What Safeguard does not do

• It does not act as your qualified individual or write the board narrative. It supplies dated numbers and records. The written report, its judgements and its recommendations are yours.
• It does not decide notification events or file with the FTC. The 314.4(j) determination, the 30 day clock and the notice itself stay with you and counsel.
• It covers software and connected systems, not the whole program. Physical security, HR processes, training delivery, customer data disposal practices and paper records sit outside what it scans. You evidence those yourself, and many GLBA catalog controls need your own uploads or attestations.
• Its readiness score is not an audit opinion or a certification. Safeguard's docs say so directly. Do not tell the board, the sponsor bank or an examiner that a score means you comply.
• It does not replace a penetration test. 314.4(d)(2) gives you a choice between continuous monitoring and periodic testing. Continuous software scanning is part of the monitoring picture, not the whole of it, and it does not test your running systems the way a penetration tester does.
• It does not assess vendors beyond their software and the data you load. TPRM scores vendors on what their SBOMs and your records show. Financial health, contract terms, the vendor's own staff and their physical controls need your due diligence.
• It does not give legal advice on whether the Safeguards Rule, a state licence or a card network rule applies to you.

Common mistakes

• Presenting a scanner export. Directors cannot act on forty CVE IDs. Give three risks, one trend and the fix rate.
• Saying "we are compliant" without the elements. The rule asks for status and compliance with Part 314. Show each element as in place, partial or not in place.
• Skipping the written report. A verbal update with slides is not the record the rule describes. File a written report and minute it.
• Hiding exceptions the CTO approved. When the qualified individual is also the person who benefits from an exception, disclosure is your protection.
• Leaving near misses out. Zero events reads as luck or blindness.
• Treating the 30 day clock as starting when you heard. Under 314.4(j)(2) it starts when any employee or agent knew.
• An ask with no alternative. "Fund a hire" lands better next to "or accept these slower fix times".

FAQ

What must a Safeguards Rule board report include?

Under 16 CFR 314.4(i), the overall status of the information security program and your compliance with Part 314, plus material matters such as risk assessment, risk management and control decisions, service provider arrangements, results of testing, security events and management's responses, and recommendations for changes. It must be in writing and at least annual.

Can the CTO be the qualified individual under the FTC Safeguards Rule?

The rule says the qualified individual may be employed by you, an affiliate or a service provider, and does not exclude the CTO. Disclose where the CTO approves exceptions to controls the same team builds, and confirm your setup with counsel.

Does the board report apply to small fintechs?

Section 314.6 exempts institutions that maintain customer information on fewer than five thousand consumers from the board report and three other requirements. Check your count with counsel, and note that sponsor banks and investors may expect a report regardless.

When do we have to notify the FTC of a breach?

Since 13 May 2024, if a notification event involves the information of at least 500 consumers, you must notify the FTC as soon as possible and no later than 30 days after discovery, using the FTC's online form. Discovery is the first day any employee, officer or agent knew, other than the person committing the breach.

How do I explain open source risk to a board?

Call it supply you did not buy. Then give three facts: whether you keep an ingredient list (SBOM) per product, how you rank flaws, and how fast you fix them.

What should I ask the board for in a security update?

Two or three specific decisions: a risk appetite statement, funding for people or time with alternatives shown, or a structural question such as who the qualified individual should be next year.

Does our sponsor bank's third party guidance apply to us directly?

Not directly. The 2023 guidance is addressed to banks; it reaches you through your contract and the bank's oversight. A September 2026 proposal would replace it.

Can a compliance tool's readiness score go in the board report?

Yes, as an internal measure with a clear caveat. Safeguard's own docs say its readiness score is not an audit opinion or a certification. Never present any tool's score as proof of compliance.

Most of a fintech's open source exposure, the second item on your board slide, comes down to how quickly fixed versions reach production and what you do when no fix exists yet. The section below is how Safeguard handles that part, so the "days to fix" line on next quarter's slide moves for a reason you can explain.

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 mobile app demo is a real Android session: you send work to a computer running the Safeguard CLI, then approve the command on the phone with Allow once, Allow for turn or Deny. The app is available on iOS and Android. For a CTO preparing a board slot between meetings, the same pattern keeps report prep moving without handing over control; it does not replace sitting down with the full report.

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

The Claude demo shows how to connect Claude to the Safeguard MCP server with OAuth and choose which tools Claude can use. Safeguard is listed in the Claude connector directory as a community connector. Once connected, you can draft parts of the report in plain language against your own Safeguard data, while you still check every number and write the judgement yourself.

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

Quick check

Sources

• eCFR: 16 CFR Part 314, Standards for Safeguarding Customer Information
• Federal Register: Standards for Safeguarding Customer Information, final rule, 9 December 2021 (86 FR 70272)
• Federal Register: Standards for Safeguarding Customer Information, final rule, 13 November 2023 (88 FR 77499)
• Federal Register: Interagency Guidance on Third Party Relationships: Risk Management, 9 June 2023 (88 FR 37920)
• Federal Register: Proposed Third Party Risk Management Guidance, 15 September 2026 (91 FR 58536)
• NIST: The NIST Cybersecurity Framework (CSF) 2.0, CSWP 29
• PCI Security Standards Council: document library (PCI DSS v4.0.1)
• CISA: Known Exploited Vulnerabilities Catalog
• FIRST: Exploit Prediction Scoring System (EPSS)
• CISA: 2026 Minimum Elements for a Software Bill of Materials
• Safeguard docs: ESSCM Dashboard
• Safeguard docs: ESSCM Vulnerabilities
• Safeguard docs: Compliance
• Safeguard docs: Compliance frameworks
• Safeguard docs: GLBA framework
• Safeguard docs: Third Party Risk Manager

To try the flow above, download Safeguard or read the docs.

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