How to Answer an NCUA Exam Finding on Patching and Vendor Software

To answer an NCUA examination finding on patch management, first work out whether it was written as a Document of Resolution item or an Examiner's Finding, then send back a corrective action plan that names an owner, a date and a piece of evidence for every gap the examiner cited. The plan should put patching on a defined clock that moves faster for vulnerabilities known to be exploited, run every delay through a written exception, and extend the same clock to the software your core, digital banking and card vendors run for you. Close it by showing, at the next contact, that the process ran for months, not that a spreadsheet was cleaned the week before.

This guide is for the CISO or information security officer who has the exam report on the desk and owes the board and the examiner a credible response. It walks through what NCUA's rules actually ask for (12 CFR Part 748 and its Appendix A), how NCUA communicates findings, how to build the plan, how to bring vendor software inside it, what evidence closes the item, and where the 72-hour cyber incident rule comes in if a patching gap turns into an incident. Nothing here is legal or regulatory advice, and nothing here tells you what your own finding says. Your examiner, your counsel and your board decide that.

Key takeaways

• Read the category first. NCUA's Office of Inspector General describes Document of Resolution items as needing action immediately or on a compressed timeframe, while Examiner's Findings can be fixed in the normal course of business.
• The rule is principle based. Part 748 Appendix A sets no patch deadlines. Your written policy does, and the examiner tests you against it.
• The FFIEC Information Security booklet gives the checklist. Section II.C.10(d) lists the patch processes examiners look for, including documented exceptions and disaster recovery patching.
• Time to patch should depend on exploitation. CISA's Known Exploited Vulnerabilities (KEV) catalog and FIRST's EPSS scores belong in the clock.
• Vendor software is in scope. Appendix A III.D expects due diligence, contract terms and monitoring of service providers.
• Closing evidence is history, not a snapshot. Months of records close findings; a one-time cleanup does not.
• Safeguard's part is the software layer. Software composition analysis (SCA) and vulnerability management with EPSS and KEV are GA. Policies and gates with exceptions are GA. Third-Party Risk Manager (TPRM) SBOM requests and monitoring are GA. Portal audit trails are GA. The local runner for code that cannot leave your network is GA. SBOM generation, reachability analysis and the compliance and GRC suite are GA. Autonomous remediation is GA and ships switched off, with every category set to Manual.
• Some work stays yours. The response letter, the board report, vendor contracts and the decision about what the finding means remain the credit union's job.

The situation

The exit meeting or joint conference is over and the report has landed. Somewhere in it is language about patch management: perhaps systems running out of date software, perhaps no evidence that patches were tested and tracked, perhaps no view of what the core or digital banking provider patches on your behalf. There is usually a request for a response with corrective actions and target dates.

The examiner wants a plan that fixes the cause and evidence it worked. The board wants to know how serious this is and whether it will come back. IT operations want to know how much new work lands on them.

A bad week looks like this: the team pulls scanner exports into a spreadsheet, finds nobody can say which version of the online banking platform is in production, promises a 15 day window for everything critical, then learns the core provider patches quarterly under a contract silent on security updates. The plan goes out with dates nobody can hit.

A good week ends with the finding classified, the scope agreed, timelines the team can meet, a named patch owner for every vendor system, and evidence collection started so the next contact sees a track record.

NCUA's 2026 supervisory priorities letter says the agency will keep enforcing information security laws and that examiners shift focus to each credit union's risk profile, with risk-focused procedures for credit unions above $50 million in assets. It also notes credit unions may record the final exit meeting or joint conference and asks that any recording be shared with NCUA. If yours was recorded, it is the best record of what the examiner meant.

What the rules behind the finding say

Patch findings rarely quote a single sentence of regulation. They rest on a stack: the regulation, the FFIEC handbook examiners use as a reference, and public guidance on how patching should work. Knowing each layer helps you answer the cause, not the symptom.

What 12 CFR Part 748 and its Appendix A require

Section 748.0 requires each federally insured credit union to have a written security program designed, among other things, to ensure the security and confidentiality of member records and to protect against anticipated threats to them. Section 748.1(a) requires the president or managing official to certify compliance with Part 748 annually through NCUA's online information system. A patching finding is, in effect, a finding that part of that certified program is not working as written.

Appendix A, the Guidelines for Safeguarding Member Information, is where the detail sits. It implements sections 501 and 505(b) of the Gramm-Leach-Bliley Act for credit unions. The parts that matter for patching:

• III.A, Involve the Board. The board or a board committee approves the written information security policy and program, and oversees it, including assigning specific responsibility and reviewing reports from management.
• III.B, Assess Risk. Identify reasonably foreseeable threats, assess their likelihood and potential damage, and assess whether policies, procedures and systems are sufficient to control them. Unpatched software is a foreseeable threat by any reading.
• III.C, Manage and Control Risk. Design the program to control identified risks in proportion to their sensitivity and the credit union's complexity. Among the measures to consider are procedures to make sure member information system modifications are consistent with the program (III.C.1.d) and monitoring to detect attacks (III.C.1.f). III.C.3 asks you to regularly test key controls, with the frequency set by the risk assessment and tests done or reviewed by people independent of those who run the controls.
• III.D, Oversee Service Provider Arrangements. Exercise due diligence in selecting providers, require them by contract to implement appropriate measures, and, where the risk assessment indicates, monitor them, including by reviewing audits, summaries of test results or equivalent evaluations.
• III.E, Adjust the Program. Monitor, evaluate and adjust the program for changes in technology, threats and outsourcing arrangements.
• III.F, Report to the Board. At least annually, report the overall status of the program, including risk assessment, risk management decisions, service provider arrangements, test results, security breaches and management's responses, and recommended changes.

Two things follow. Nothing in Appendix A sets a patch deadline in days; your written policy does, and the examiner tests whether you follow it. And a plan that fixes servers but leaves the board report and vendor contracts untouched answers only part of the finding. Appendix A defines a service provider as anyone permitted access to member information through services provided directly to the credit union, so your core, digital banking and card processors almost certainly qualify.

What the FFIEC Information Security booklet says about patch management

NCUA examiners use the FFIEC IT Examination Handbook as a reference, and its Information Security booklet is the most specific public text on what a patch program should contain. Section II.C.10(d), Patch Management, says management should use automated patch management tools to keep network components updated, run vulnerability scanners periodically, and, if the institution develops or maintains software in house, have a process to patch that software too.

It then lists the processes a patch program should establish:

1. A monitoring process that identifies when patches are available.
2. A process to evaluate patches against the threat and network environment.
3. A prioritization process across classes of computers and applications.
4. A process for obtaining, testing and securely installing patches, including in virtual environments.
5. An exception process, with documentation, for patches management decides to delay or not apply.
6. A process to make sure production patches also reach the disaster recovery environment in time.
7. A documentation process so inventories and disaster recovery plans are updated when patches are applied.

It also asks for backups before patching and defined patch windows. Section II.C.11, End-of-Life Management, adds the risk of unsupported systems, since a vendor that stops supporting a product stops sending patches. Most patching findings map to one or two missing items on this list.

NIST SP 800-40 Rev. 4, CISA's KEV catalog and EPSS

NIST SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning (April 2022), frames patching as preventive maintenance: a cost of doing business rather than an optional project. It defines enterprise patch management as identifying, prioritizing, acquiring, installing and verifying the installation of patches, updates and upgrades. That five step sequence is a clean spine for a corrective plan, and citing it shows the examiner the plan rests on a recognized standard.

CISA's Known Exploited Vulnerabilities catalog describes itself as the authoritative source of vulnerabilities exploited in the wild and tells organizations to use it as an input to their prioritization. FIRST's Exploit Prediction Scoring System (EPSS) publishes, every day, a probability that each published CVE will be exploited in the next 30 days. Together they let you set a faster clock for the small share of vulnerabilities attackers actually use.

BOD 26-04 as a reference point, not a rule for credit unions

CISA's Binding Operational Directive 26-04, Prioritizing Security Updates Based on Risk, was issued on 10 June 2026 and revokes BOD 19-02 and BOD 22-01. It binds federal civilian agencies, not credit unions. It is still a useful model because it sets remediation urgency from four variables: whether the asset is publicly exposed, whether the CVE is in KEV, whether exploitation can be automated, and whether exploitation gives partial or total control. Its Table 1 timelines run as short as three days with forensic triage for the worst combinations, and as long as fixing on the next system upgrade for the lowest. If your examiner asks why you chose your tiers, pointing to a federal model you adapted is a stronger answer than a round number.

How an NCUA exam communicates a finding and what response it expects

NCUA writes up problems in two forms, and the difference sets your timeline.

A Document of Resolution (DOR) item, as NCUA's Office of Inspector General described it in memorandum OIG-26-08 (June 2026), is a problem significant enough that the examiner would recommend escalating to the next level of enforcement if it is not corrected. DOR items are ones management must begin to address immediately or within a compressed timeframe, and the DOR describes the problem with supporting facts and outlines the corrective action needed to resolve it.

Examiner's Findings, in the same memorandum's words, are problems management must address that do not currently threaten the credit union's viability or represent systemic violations. Management can decide the timeframe and approach for correcting them in the normal course of business.

In practice that means:

• If patching is in the DOR, the corrective action and timeframe are largely set. Raise any date you cannot meet before the board signs, then evidence against the DOR's own wording. Expect follow-up before the next full exam.
• If it is an Examiner's Finding, you set the plan and dates. Vague or missed dates are how a finding becomes a DOR item next cycle.
• Either way, take the plan to the board or committee and minute it, as Appendix A III.A and III.F expect.

If the wording is unclear, ask the examiner in writing what evidence would show the item resolved, and keep the answer with the plan.

Step by step: answering the finding with whatever tools you have

This sequence works with spreadsheets and the tools you already own. It takes the NIST five steps and the FFIEC process list and turns them into work.

1. Classify the finding in a single page

For each cited item, record: DOR item or Examiner's Finding; process gap (no exception process) or instance (these servers are out of date); systems you patch or a vendor patches; and the evidence cited. Keep the examiner's words verbatim so nobody paraphrases them into something easier.

2. Find the cause, not the list

Unpatched hosts are a symptom. The cause is usually missing inventory, no agreed timelines, no test environment, no owner for vendor systems, invisible delays or no capacity. Name it, because the examiner will look for it.

3. Fix the scope with an inventory

You cannot set a clock on things you have not listed. Build an inventory with four groups:

The second group is often missed. If you build or customize anything, FFIEC II.C.10(d) expects a process to patch it, and most of that code's risk sits in the open source components it pulls in.

4. Set timelines by severity and exploitation

Write a short timeline standard. The table below is illustrative only, with round numbers you should replace with ones your team can meet and your risk assessment supports.

Two rules make the table work. The clock starts when the vulnerability is identified on your asset or added to KEV, whichever is first. And a KEV listing shortens the clock even for a vulnerability you were already tracking. Both ideas come from BOD 26-04 and adapt well to a credit union.

5. Write the exception process

FFIEC asks for a documented exception process. Make it concrete: who can request one, who approves by risk level, what compensating control is required, the maximum duration, the review date, and where the record lives. An exception without an expiry date is just a permanent gap with a signature.

6. Build the plan and take it to the board

Use the template in the next section, then present it with the cause analysis and what you need (budget, staff time, vendor negotiations). Minute the approval; under Appendix A III.A board oversight is part of the fix.

7. Run it and report on time

Monthly, produce the same short report: open vulnerabilities by tier and age, timeline compliance, open exceptions and expiry dates, vendor items. Keep every month's version; that series closes the finding. Send any progress reports the examiner asked for in the same format each time, and if a date will slip, say so before it passes, with a new date approved by the same body.

What belongs in a corrective action plan for patching

A corrective action plan has to answer four questions for every gap: what changes, who owns it, by when, and how anyone will know. Here is a template your team can fill in today.

• Scope. "All production and DR systems processing member information, all software we develop or customize, and vendor systems in tiers 1 and 2" is testable. "Critical systems" is not.
• Timelines. Put the timeline standard in an appendix, show KEV and EPSS are inputs, and say how often you pull them.
• Exceptions. Name approvers, a maximum length and a review cadence, and report every exception to the board committee.
• Evidence. Name the artifact before the work starts. If you cannot, the action is not specific enough.
• Dates. Set early dates for process changes and realistic ones for the backlog. A backlog that takes time to burn down is easier to defend when the process that stops new debt is already live and measured.

How to show vendor-supplied software is covered

This is often the weakest part of a credit union's patch program, and examiners know it. NCUA has said for years, in Letter 07-CU-13 and its enclosed supervisory letter, that it gives examiners a standard framework for reviewing third party relationships, and it lists electronic services such as data processing, internet banking, credit card and bill pay among them. The letter expects due diligence to account for the critical nature of the service, the vendor's expertise, staffing changes, regulatory changes and risk mitigation.

The 2023 Interagency Guidance on Third-Party Relationships was issued by the Federal Reserve, FDIC and OCC. Its preamble notes commenters asked for NCUA to join, and NCUA did not. It is a useful model, not a rule that binds you.

Build a vendor patch matrix

For each vendor system that touches member information, record:

• System and version in production. If you cannot state it, that is the first action.
• Hosting model. Vendor hosted, you host, or shared.
• Who applies patches. Vendor, you, or both, and for which layers (application, database, operating system).
• The vendor's patch commitment. Timelines by severity, how exploited vulnerabilities are handled, and how you are told.
• What evidence you receive. Release notes, attestation, independent audit, SBOM, vulnerability disclosures.
• Contract coverage. Whether the contract requires security updates and notice, and the renewal date if it does not.
• Tier. Based on data access and criticality.

Ask the right questions

For tier 1 and 2 vendors, ask in writing:

1. What are your patch timelines by severity, and how do you treat vulnerabilities on CISA's KEV list?
2. How fast will you notify us of a vulnerability in software we run or you run for us?
3. Can you provide a software bill of materials (SBOM) for the version we use, refreshed each release?
4. Which components reach end of life in the next 24 months, and what is the plan?
5. What independent testing covers your patch process? Appendix A III.D.3 names "audits, summaries of test results, or other equivalent evaluations", so ask for those by name.

Who holds the clock

For hosted systems the clock is the vendor's, but oversight is yours: keep the contract term, the vendor's audit summary, your review of it, and a log of how the vendor handled any KEV-listed issue in its product. For vendor software you host, two clocks run in series, the vendor's time to release and your time to apply. Track both, and if applying waits on vendor certification, write that into the exception record.

What evidence closes the finding at the next contact

The examiner will test whether the new process works and whether it is sustained. Evidence that tends to close patch findings:

Organize it in one folder per corrective action line, matching the numbering in your plan. Examiners have limited time. A binder that follows the plan's own order is faster to test than a shared drive.

What happens if a patching gap becomes an incident: the 72-hour rule

A patching finding raises a fair question: what if the gap is exploited before you close it? Section 748.1(c) requires a federally insured credit union to notify NCUA's designated contact of a reportable cyber incident as soon as possible and no later than 72 hours after it reasonably believes one occurred. Where the incident comes through a third party, the clock runs 72 hours from the third party's notification if that is sooner.

Three parts of the definition matter here:

• 748.1(c)(1)(i)(A) covers a substantial loss of confidentiality, integrity or availability of a network or member information system from unauthorized access to or exposure of sensitive data, disruption of vital member services, or serious impact on operational systems.
• 748.1(c)(1)(i)(B) covers a disruption of business operations, vital member services or a member information system resulting from a cyberattack or exploitation of vulnerabilities. That is the clause an unpatched system most directly falls into.
• 748.1(c)(1)(i)(C) covers disruption or unauthorized access facilitated through a compromise of a credit union service organization, cloud service provider, other third-party data hosting provider, or a supply chain compromise. That is the clause a vendor's unpatched software falls into.

NCUA's reporting page says the 72-hour notice is an early alert and does not require a detailed assessment within that time. NCUA Letter 25-CU-02 updated the reporting channels and added a secure webform; the page also lists a phone line and a secure email address. Keep those in your incident plan.

For your plan, that means three links. Your response program (Appendix A III.C.1.g and Appendix B) should treat exploitation of a known, unpatched vulnerability as a likely trigger. Vendor contracts should require notice fast enough for your own 72 hours. And exception records should be quick to retrieve, because after an incident the first question is who approved the delay and what compensating control was in place.

How Safeguard does this

Safeguard covers the software layer: components inside the applications you build and the software vendors ship you, their vulnerabilities, the gates around fixing them, and the records. It does not patch servers or network devices. The flow below comes from Safeguard's docs.

1. Inventory the software you build or customize

Software composition analysis (SCA, GA) and SBOM generation (GA) build a full transitive inventory of open source components for each project, in SPDX and CycloneDX formats. In the web app, you connect repositories or container images from Integrations and Safeguard creates the project and its SBOM. The docs describe daily continuous scanning of all projects, so a newly published CVE re-evaluates your inventory without a new build.

If your policy or your network rules mean source code cannot go to a cloud service, the local runner (GA) is built into the CLI. It runs scan jobs on your own machine, uploads only the resulting SBOM and findings, and opens only outbound HTTPS connections. The docs show this install and first run:

# macOS and Linux
curl -fsSL https://cli.safeguard.sh/install | bash

# start the interactive terminal, then type /login
safeguard

For a server without a terminal UI, the docs show:

safeguard runner start --workspace ./path/to/repo
safeguard runner status

These snippets are copied from the docs; we did not run them for this post.

2. Prioritize by exploitation, not only severity

Vulnerability management (GA) groups findings into Critical, High, Medium, Low and Exploitable, meaning known exploitation in the wild, with sources including NVD, GitHub Security Advisories, OSV, CISA KEV and vendor bulletins. Each finding shows CVSS, EPSS, exploited status, the affected component, the fixed version and reachability; reachability analysis and prioritization (GA) adds whether the vulnerable code path is called. Filter by EPSS range, exploitable status and fix availability, or ask the docs' example question, "Show me critical vulnerabilities in production that are actively exploited". That is your KEV tier.

3. Turn your timeline standard into policies and gates

Policies, gates and guardrails (GA) put the standard into the pipeline. Per the docs, you go to Settings › Policies, click Create Policy, define conditions in the visual builder or YAML, and set severity and actions. Conditions in the docs include vulnerability severity, CVSS score and EPSS score, and there is a "No Critical Vulnerabilities" template.

Each policy has one action that decides what a failure does to the gate:

A sensible mapping for a credit union: Block on KEV-listed vulnerabilities with a fix available in internet facing applications, Warn on high EPSS, Notify on the rest so the metric pack captures them. Policy outcomes (Passed, Failed, Warning, Not evaluated, Error) are turned on per workspace by Safeguard, so confirm yours shows an Outcome column. To fail a CI job on a gate, the docs show:

safeguard ci scan --wait --fail-on-gate <gate name or id | all>

It exits non-zero when the gate is Failed, Error or Not evaluated, and zero when it is Passed or Warning.

4. Run exceptions through a recorded approval

Approval runs through exceptions, which is what FFIEC II.C.10(d) asks for. Per the docs, a developer clicks Request Exception, selects the policy and finding, gives a business justification and an expiration date, and submits. Approvers are notified, decide, and the audit trail records it.

For findings you will not fix yet, the Mitigations tab records the type (Risk Acceptance, False Positive, Workaround Applied, Not Applicable), justification, approver, an optional expiry and evidence. The docs describe reminders 14 and 7 days before expiry, a History tab per mitigation, and Reports › Mitigations exports as PDF, CSV or Excel. That export is your exception register.

5. Fix faster where a fix exists

Autonomous remediation (GA) can open fix pull requests that move a vulnerable dependency to a fixed version, singly or in bulk. It ships switched off, with every category set to Manual, so nothing changes until your team turns it on. For a small development team it shortens the gap between "finding identified" and "fix ready for testing", where in-house timelines usually slip.

6. Bring vendor software inside the clock with TPRM

Third-Party Risk Manager (TPRM, GA) handles the vendor side, for the software vendors ship you:

1. Vendor directory. Under Vendors, click Add Vendor, record the products you use and set a risk tier (Critical, High, Medium, Low). Contract management links contract documents, dates, SLA terms, security requirements and SBOM obligations to each vendor.
2. SBOM requests. From the vendor, click Request SBOM, pick the products, choose a template, set a deadline and send. Bulk requests work across selected vendors. Status moves from Sent to Viewed, In Progress, Submitted, then Validated or Rejected, and the docs describe automatic reminders 7 days before the deadline, at the deadline, and an escalation 7 days after.
3. Validation. A received SBOM is checked for valid SPDX or CycloneDX format and required fields, then scanned for vulnerabilities. If it fails, Request Revision sends the vendor what to fix.
4. Risk score. Each vendor gets a 0 to 100 score where higher means lower risk, using EPSS and known exploited vulnerabilities among other factors, with risk acceptance and remediation tracking alongside.
5. Monitoring. In Settings › Monitoring, alerts fire on a new critical CVE, a CISA KEV addition, a risk score drop or an aging SBOM. Re-scans can run daily for critical vendors.
6. Reports. Scheduled monthly vendor reviews or ad hoc reports, exported as PDF or Excel.

The KEV alert matters most here: when a component in a vendor's SBOM lands on KEV, you can write to the vendor and track it as a vendor patch item.

7. Keep the record with Portal audit trails

Portal audit trails (GA) log SBOM, access and administrative activity, including policy changes, each with timestamp, actor, action, resource and result. Per the docs, go to Settings › Audit Logs, filter, and click Export for CSV, JSON or PDF, or send logs to a SIEM. The page notes its REST endpoints are not yet available, so use the in-app export.

8. Map it to the controls examiners ask about

The compliance and GRC suite (GA) gathers evidence against frameworks. The docs list a GLBA framework, which maps to the FTC Safeguards Rule text rather than NCUA's Part 748 Appendix A, and we found no framework named for Part 748 in the docs. Treat the suite as the evidence store and map the Appendix A sections yourself, using the table below.

What remains the credit union's job

• The response letter. Its wording, commitments and signature are management's. Draft it with counsel if the finding is a DOR item.
• Board reporting. Appendix A III.A and III.F require board oversight and an annual report, with patch metrics and exceptions in it.
• Vendor contracts. Patch timelines, notice terms, SBOM obligations and end-of-life commitments are negotiated and signed by you.

What Safeguard does not do

• It does not write your response to NCUA or interpret your finding. It produces records and reports you can attach; deciding what the finding requires and committing to dates is management's job.
• It does not patch infrastructure. Operating systems, network devices, firewalls, hypervisors and firmware need your patch tooling and change process.
• It does not see inside vendor software without the vendor's help. Vendor coverage depends on the vendor supplying an SBOM or access. A refusal is a vendor risk you record, not a gap a tool closes.
• It does not scan the configuration of member-facing systems it is not connected to. A misconfigured hosted platform is outside what it can observe.
• It does not replace independent testing. Its reports support your tester, but Appendix A III.C.3 expects the test from people independent of those who run the controls.
• It does not notify NCUA. Alerts can help you spot a reportable event sooner, but the 72-hour report is the credit union's decision and filing.
• It is not legal advice. Neither is this post.

Common mistakes

1. Promising timelines you cannot meet. A 15 day window for every critical finding reads well and becomes a missed commitment by month two.
2. Fixing the list, not the cause. Patching the sampled hosts without fixing the inventory or exception process brings the same finding back.
3. Leaving vendor software out of scope. "Vendor responsibility" is not an answer to III.D. Your oversight of the vendor is the control.
4. Exceptions with no expiry. Every exception needs an end date and an approver, or it is a permanent gap.
5. Ignoring the DR environment. FFIEC names it, and a stale DR site is the first thing restored in a crisis.
6. Treating CVSS as the only signal. Severity says how bad a vulnerability could be; KEV and EPSS say whether attackers use it.
7. Evidence assembled the week before. A tidy snapshot invites questions about the previous six months.
8. Forgetting in-house code. If you build or customize software, FFIEC asks for a process to patch it, open source components included.

FAQ

How do I respond to an NCUA exam finding on patch management?

Classify it as a DOR item or an Examiner's Finding, find the cause, set a timeline standard by severity and exploitation, write a documented exception process, build a corrective action plan with owner, date and evidence for each gap, take it to the board, and collect monthly evidence from day one.

What is the difference between an NCUA Document of Resolution and an Examiner's Finding?

According to NCUA's Office of Inspector General, DOR items are significant enough that the examiner would recommend escalating enforcement if they are not corrected, and management must begin addressing them immediately or on a compressed timeframe. Examiner's Findings are problems that do not threaten viability, and management can set the timeframe in the normal course of business.

Does NCUA require a specific patch timeline?

No rule in 12 CFR Part 748 sets one. Appendix A asks you to assess and control risk, and the FFIEC Information Security booklet asks for prioritization and documented exceptions. Your board approved policy sets the timeline, and the examiner tests whether you meet it.

Does BOD 26-04 apply to credit unions?

No. BOD 26-04 binds federal civilian agencies. Credit unions can borrow its model, which sets urgency from public exposure, KEV status, exploit automation and technical impact, as a defensible basis for their own tiers.

How do I show NCUA that vendor software is patched?

Keep a vendor patch matrix listing each system, its version, who applies patches, the vendor's commitment, the evidence you receive and the contract terms. Review audit summaries or equivalent evaluations, as Appendix A III.D.3 suggests, and track vendor responses to KEV-listed issues.

Can I ask my core or digital banking vendor for an SBOM?

Yes, and many vendors can supply one. Ask for it for the version you run, with a refresh on each release. If the vendor declines, record that, ask for alternative evidence such as audit summaries, and consider it at renewal.

Does an exploited unpatched vulnerability trigger NCUA's 72-hour rule?

It can. Section 748.1(c)(1)(i)(B) includes disruption caused by exploitation of vulnerabilities, and (C) covers compromise through third parties or the supply chain. Whether a specific event is reportable is a judgment for you and counsel; when in doubt, NCUA's notice is designed as an early alert.

How long does it take to close an NCUA patching finding?

It depends on the category and your dates. Process changes can go live in weeks; a credible evidence series takes months.

What happened to the FFIEC CAT?

The FFIEC sunset the Cybersecurity Assessment Tool on 31 August 2025. NCUA's ACET page points credit unions to ACET and to assessment tools from CISA, CIS and NIST. Your patch plan should rest on Part 748 and the FFIEC booklet, not on a retired tool.

Safeguard cannot patch what your vendors host, but it can shorten the gap for the open source code you build and ship, which is the in-house software line of most patching plans. The section below explains the remediation options that apply to that code.

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 is a real CLI session: safeguard is asked to fix the lodash CVE in a repository, reads the finding and advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, prints a summary and pushes nothing. For in-house code, that is the "fix ready for testing" step of your timeline, with a person approving every change.

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

The second demo connects Claude to the Safeguard MCP server with OAuth and shows how you choose which tools Claude can use. For an information security officer, that means asking in plain language for the open KEV items or the exceptions expiring this month while drafting the monthly metric pack, with access limited to the tools you allow.

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

Quick check

Sources

• eCFR: 12 CFR Part 748, including Appendix A, Guidelines for Safeguarding Member Information
• NCUA OIG-26-08, Limited Review (June 2026), definitions of Document of Resolution and Examiner's Findings
• NCUA Letter 26-CU-01: NCUA's 2026 Supervisory Priorities
• NCUA: Cyber Incident Reporting
• NCUA Letter 25-CU-02: Cyber Incident Notification Requirements, Update to Letter 23-CU-07
• NCUA Letter 07-CU-13: Evaluating Third Party Relationships
• NCUA: ACET and Other Assessment Tools
• OCC Bulletin 2024-25: FFIEC Cybersecurity Assessment Tool sunset
• FFIEC IT Examination Handbook, Information Security, II.C.10(d) Patch Management (archived October 2026)
• FFIEC IT Examination Handbook, Information Security, II.C.11 End-of-Life Management (archived October 2026)
• Interagency Guidance on Third-Party Relationships: Risk Management, 88 FR 37920 (GovInfo)
• 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
• CISA Cybersecurity Directives
• FIRST: Exploit Prediction Scoring System
• Safeguard docs: Vulnerabilities
• Safeguard docs: Policies and Gates
• Safeguard docs: Policy outcomes and actions
• Safeguard docs: Mitigations
• Safeguard docs: Generate SBOM
• Safeguard docs: Local Runner
• Safeguard docs: TPRM Vendor Management
• Safeguard docs: TPRM SBOM Requests
• Safeguard docs: TPRM Risk Assessment
• Safeguard docs: TPRM Monitoring
• Safeguard docs: Portal Audit Trails
• Safeguard docs: GLBA framework
• Safeguard docs: Claude MCP connector
• Safeguard Gold Open Source

Related reading: assess a digital banking vendor's software risk at a credit union, how to write a vulnerability remediation SLA policy, what a written vulnerability management policy should cover, the FFIEC CAT is retired: what replaced it and keep a contract promise of no known exploited vulnerabilities.

Try it yourself: download Safeguard or read the Safeguard docs.

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