NCUA Cybersecurity Compliance: How Picus Supports Credit Unions

What Is the National Credit Union Administration (NCUA)?

The National Credit Union Administration (NCUA) is the independent federal agency that regulates and supervises federal credit unions and insures deposits at federally insured credit unions through the National Credit Union Share Insurance Fund.

Cybersecurity falls within the NCUA’s supervisory responsibilities because cyber incidents can affect member information, financial services, operational resilience, and the safety and soundness of credit unions. Federally insured credit unions are therefore subject to NCUA information security requirements, examinations, and cyber incident notification rules, including requirements established under NCUA Part 748.

What Is NCUA Cybersecurity Compliance?

NCUA cybersecurity compliance refers to the cybersecurity and information security obligations that federally insured credit unions must address under NCUA regulations and examination procedures.

Key expectations include maintaining an information security program, assessing cybersecurity risk, testing key controls and systems, overseeing third-party service providers, reporting relevant security matters to the board, and notifying the NCUA of reportable cyber incidents within 72 hours.

Compliance is not only about having documented policies or deployed tools. Credit unions also need evidence that their safeguards are appropriate for their risks and operate effectively.

What Is NCUA Part 748?

NCUA Part 748 is a section of NCUA regulations covering security programs, reportable cyber incidents, and other security-related obligations for federally insured credit unions.

Appendix A establishes guidelines for safeguarding member information, including risk assessment, security controls, testing, service-provider oversight, program adjustment, and board reporting.

Part 748 also contains the NCUA cyber incident notification requirement, under which federally insured credit unions must notify the NCUA as soon as possible and no later than 72 hours after reasonably believing a reportable cyber incident has occurred.

How Does the NCUA Evaluate Cybersecurity During Credit Union Examinations?

The NCUA evaluates cybersecurity through its Information Security Examination (ISE) program, which uses a risk-focused and scalable approach. Examiners assess management’s ability to identify, assess, monitor, and manage technology risk; whether the credit union has sufficient expertise; whether internal controls adequately safeguard member information; and whether the board provides appropriate governance over information systems and security.

Examination depth can vary according to the institution’s size, complexity, systems, and risk profile. This means credit unions should be prepared to demonstrate not only that cybersecurity policies and controls exist, but that their security program is appropriate and effectively managed.

What Are the NCUA Third-Party Risk Management Requirements?

NCUA third-party risk management expectations require credit unions to evaluate and manage risks created by service providers such as core processors, CUSOs, cloud providers, payment providers, and other technology vendors.

Part 748 calls for appropriate due diligence when selecting service providers and monitoring their safeguards where warranted by risk. Third-party incidents are also important under the NCUA cyber incident notification rule because certain compromises or disruptions at a provider can trigger a credit union’s own 72-hour notification obligation.

Credit unions therefore need effective vendor due diligence, contractual notification provisions, ongoing oversight, and current information about critical provider security and resilience.

What Other Cybersecurity Regulations Apply to Credit Unions Besides NCUA Part 748?

NCUA Part 748 is the primary cybersecurity regulation for federally insured credit unions, but additional frameworks and regulations may apply depending on the institution’s activities, data handling, and service-provider relationships.

GLBA (Gramm-Leach-Bliley Act) requirements are effectively incorporated into NCUA’s information security guidelines, which means credit unions must still implement safeguards to protect member information in line with GLBA principles.

Credit unions that process or store payment card data may also need to comply with PCI DSS requirements imposed by card networks.

In some cases, DORA (Digital Operational Resilience Act) may become relevant indirectly for credit unions that rely on EU-based ICT service providers or operate within global financial service ecosystems.

Additionally, NIST CSF 2.0 is widely used as a voluntary cybersecurity framework to support regulatory alignment and maturity benchmarking rather than as a binding regulation.

You can learn more in Picus’s GLBA compliance guide, PCI DSS compliance guide, DORA compliance resource, and NIST CSF compliance guide.

Cyber Risk for Credit Unions as Attackers Adopt Frontier AI Models

AI has made attacks much faster. A vulnerability that used to take weeks to exploit can now be exploited in hours. These are machine-speed attacks, where AI models find, weaponize, and use a technique on a timeline of hours instead of the weeks a human attacker would need.

What has been observed in the field confirms this:

• Volume: 35,850 CVEs were published in the first half of 2026, an increase of roughly 49% over the first half of 2025 [1].
• Speed: Nearly one in three exploited vulnerabilities is now weaponized within 24 hours of public disclosure [2].
• Capacity: Frontier AI models now discover vulnerabilities faster than vendors can patch them. In one disclosure program, only 516 of 29,439 candidate findings had been fixed upstream at the time of reporting [3].

A vulnerability in a VPN appliance, a core-banking integration, or a member-facing web portal can be public at 08:00, weaponized by 10:00, and exploited the same evening, with no patch available. The question that matters is not "when can we patch?" but "would our controls stop this, and would our SOC see it?"

A credit union can have an EDR, a firewall, a SIEM, and a documented testing program, and still be unable to show that any of them would stop or detect a realistic attack on member information. To an examiner, all of those controls appear "present." Only testing can show whether they actually work.

How Picus Supports NCUA Cybersecurity Compliance Against Machine-Speed Attacks

The Picus Platform supports NCUA compliance by continuously validating exposures, attack paths, and security controls against machine-speed attacks, and by producing the evidence credit unions need to assess risk, verify control effectiveness, prioritize remediation, and demonstrate security outcomes to management, boards, auditors, and examiners.

The sections below explain the NCUA requirements that Picus supports:

Part 748 Appendix A Section III.C.3: Testing Key Controls, Systems, and Procedures

Testing is a standing activity rather than a one-time exercise, and there is no fixed cadence attached to it. Scope and frequency follow the credit union's own risk assessment, so where risk conditions change often, testing is expected to keep pace.

How Picus Supports This Requirement

Picus Breach and Attack Simulation (BAS) continuously tests deployed prevention and detection controls. To be more specific, it measures whether EDR, SIEM, firewalls, IPS, and WAFs actually prevent or detect the attacker techniques they are intended to address, across endpoints, network, web, email, cloud, and AI security.

It runs real-world attack scenarios mapped to MITRE ATT&CK, drawn from the Picus Threat Library. Picus Threat Library is a catalog of adversary behaviors, techniques, and full attack chains curated by Picus Labs, with a 24-hour SLA on emerging threats that have a public PoC.

Figure 1. Picus Threat Library, MITRE ATT&CK-mapped threats

When a test identifies a gap, Picus provides mitigation guidance through the Picus Mitigation Library, which maps detected weaknesses to both vendor-specific and vendor-neutral prevention signatures and detection rules. Mitigations can be applied with a one-click fix, and the same attack is rerun to prove closure.

Figure 2. Picus Mitigation Library provides vendor-specific and vendor-neutral mitigations.

This whole cycle runs on signal rather than on a calendar. A new threat-intelligence report, a newly disclosed CVE, or a configuration change in the environment can each trigger the relevant test on its own, without waiting for the next scheduled assessment window. Because the trigger is the change in risk itself, the testing frequency adjusts to the credit union's risk conditions as they move, which is what Appendix A III.C.3 asks for when it ties the frequency and nature of tests to the risk assessment.

Part 748 Sections 748.0(a)–(b)(2) & Appendix A Section III.B: Security Program and Risk Assessment

Section 748.0 carries the binding requirement.

Section 748.0(b)(2) then states the objectives that the program is designed to meet.

The rule does not list which tools the program must include. It states the outcomes the program must deliver, which is keeping member records secure and preventing anticipated threats and unauthorized access.

Appendix A, paragraph III.B then sets out the risk assessment supporting that program:

Identifying threats and estimating their damage describes the risk landscape.

How Picus Supports This Requirement

Picus makes the risk assessment evidence-based by determining which identified exposures can actually be exploited in the credit union's own environment.

Picus Autonomous Penetration Testing executes real exploits where testing is safe and a public exploit is available for the vulnerability, showing which exposures, exposed credentials, and misconfigurations can be chained to reach critical assets.

Figure 3. Picus Autonomous Penetration Testing finds attack paths to critical assets.

Where live exploitation is unsafe or restricted, which covers 65–70% of assets in a typical estate, Picus Exposure Validation fills the gap by validating exposure even on critical systems and even when no public exploit exists.

As a result, credit unions can base their risk assessment on evidence instead of assumptions. Each material exposure gets a disposition of Patch, Mitigate, Monitor, or Accept with Evidence, based on whether it is actually reachable and exploitable in their environment and whether existing controls already neutralize it. Remediation effort goes to the exposures that can genuinely be used against member information, and the risk assessment itself carries the test results that support each decision.

Part 748 Appendix A Section III.E: Adjusting the Information Security Program

Appendix A, paragraph III.E names both the duty and its triggers:

Monitoring and evaluation have to run continuously, and the program is updated based on what they show. The list of triggers is long. New technology, new threats, changes to member information systems, mergers, and outsourcing all count. Any of these can happen between two scheduled assessments.

How Picus Supports This Requirement

Picus Swarm is built for exactly this requirement. It is a workforce of five specialist AI agents covering discovery, exploitation, validation, mobilization, and reporting, orchestrated by Numi AI.

Numi AI watches the same signals III.E names. When new threat intelligence reports an emerging attack campaign, or a policy changes in the environment, or a new asset appears, Numi AI decides that a validation workflow should run and coordinates the right agents from start to finish. The Discovery Agent identifies the affected assets, the Exploitation Agent attempts real exploitation to establish whether the exposure is reachable and exploitable, the Validation Agent tests whether the current prevention and detection controls stop or surface the associated techniques, the Mobilization Agent applies the fixes for what failed, and the Reporting Agent records the result.

Figure 4. Picus Swarm specialist AI agents orchestrated by Numi AI

The trigger is the change itself, not a date on a calendar. This is what makes the structure signal-driven, and it is the mechanism that lets a credit union monitor, evaluate, and adjust continuously rather than at review time.

Credit unions choose how much autonomy to grant. Workflows run in Manual, Supervised, or Autonomous mode, and every agent action is retained in an auditable record, so the adjustment history is documented as it happens.

As a result, Picus covers the monitor-and-evaluate side of III.E on a signal-based basis, and corrects what fails at the control layer. The evidence it produces gives management a current basis for deciding whether the program itself needs changing.

Part 748 Section 748.1(c): The 72-Hour Cyber Incident Notification Requirement

Section 748.1(c) sets the clock, and paragraph (c)(1)(i) defines what starts it.

A reportable cyber incident is defined as any substantial cyber incident that leads to one of three outcomes.

Notification must reach the NCUA as soon as possible, and no later than 72 hours. The clock starts when a federally insured credit union reasonably believes it has experienced a reportable cyber incident.

Meeting this deadline is easier when teams already know how their controls behave against the techniques that lead to these incidents. Records of that testing also matter after the fact. A breach can still happen to a credit union that was doing the right things, and when it does, the credit union has to account for the controls it had in place and the steps it took. Being able to point to what was tested, what was found, and what was fixed gives the credit union something it can put in front of the NCUA, rather than leaving that account as an assertion.

The credit union will also want to be sure the same breach does not happen again, which means acting on the weaknesses involved and confirming that those changes hold.

How Picus Supports This Requirement

Before an incident, Picus Breach and Attack Simulation runs the attacker techniques behind the incident types the rule describes and records whether the controls blocked them and whether the activity raised an alert. The resulting validation reports document what was tested, the gaps found, and the results of retesting after improvements. If an incident occurs, the credit union can use these records alongside its investigation findings when notifying the NCUA and answering the questions that follow, showing the validation work carried out to protect member information systems and sensitive data before the incident happened.

Picus findings also support incident-response exercises. Teams can practice how an alert is escalated, who checks which member information systems and sensitive data may be affected, and how that information reaches the people preparing the notification within 72 hours.

After the incident is contained and security controls are updated, teams can use Picus to test the techniques associated with the threat involved. Retesting checks whether the updated controls block or detect those techniques and reveals any remaining gaps. This helps the credit union reduce the risk of a similar incident and provides evidence of the effectiveness of the tested improvements.

Together with the incident findings, these results help the credit union explain what it tested before the incident, what it changed afterward, and how the updated controls performed.

Part 748 Appendix A Section III.F & NCUA ISE: Board Reporting and Examination Readiness

Appendix A, paragraph III.F sets out the reporting duty to the board.

Annual reporting is the minimum, not the target. The board needs the overall status of the program, not a list of finished tasks. One of the six subjects the report should cover is results of testing, so validation evidence belongs in the board pack.

Examiners look at the same ground through the ISE program, which NCUA has used since early 2023.

Two of these objectives turn on evidence a credit union has to produce. Controls and oversight have to be adequate to protect member information, and the board has to be governing security well enough to satisfy an examiner. Both are judged on what the credit union can show, not on what it has installed.

How Picus Supports This Requirement

Picus provides weekly and monthly technical reports that help teams review security control performance over time. They bring simulation results into a regular record that security teams, internal audit, and the people preparing the board report can draw on, so the annual report rests on a year of evidence rather than a snapshot taken before the meeting.

The technical report includes a security score overview, score trends, and detailed results by attack module and security device. It shows which threats were blocked or not blocked, which attacker objectives were achieved or prevented, and what was not tested. These details cover the results of testing that paragraph III.F asks the board report to address, and they also show reviewers where defenses worked and where protection needs attention.

MITRE ATT&CK tactic and technique coverage shows which attack behaviors were tested and how controls performed against them. Benchmarks compare scores with Picus customer, regional, and industry averages, which gives the board a reference point beyond the credit union's own numbers. The report also highlights commonly simulated threats and templates, helping teams identify areas to consider for further testing.

Figure 5. Picus MITRE ATT&CK results showing blocked, logged, and alerted actions across different tactics.

Teams can also create custom dashboards using widgets to focus on the security metrics that matter most to their credit union. By selecting and arranging widgets, they can bring relevant results into one view, making it easier to review control performance, follow progress, and highlight areas that need attention.

Figure 6. Picus dashboard widgets showing security scores, trends, and MITRE ATT&CK coverage.

These records give the credit union something concrete to put in front of the board and the examiner. The board sees the overall status of the program and the testing results behind it, and the examiner reviewing the adequacy of controls and oversight over member information sees the same evidence. Comparing results across weeks and months helps reviewers assess how the tested safeguards perform and whether protection improves over time, rather than only that testing took place.

Meeting NCUA Requirements with Signal-Driven Validation

NCUA wants controls that work, not controls that are written down. A yearly test cannot show that, because controls break in between. Log sources move, and detection rules go quiet. Network changes loosen segmentation. New attacker techniques stay untested until a real attack tests them.

On top of that, attacks in the AI era run at machine speed. A vulnerability can be public, weaponized, and exploited on the same day. Defense has to run at that speed too, and a calendar cannot do it.

Signal-driven validation is what machine-speed defense looks like. The change starts the test, not the calendar. A new attack campaign, a new exploited CVE, or a policy change is enough to trigger it, so the answer arrives in hours rather than at the next assessment.

Picus runs this loop. Breach and Attack Simulation tests whether controls block and detect. Autonomous Penetration Testing shows which attack paths are real. Exposure Validation tells you if an exposure is exploitable when running a live exploit is not an option. Picus Swarm with Numi AI handles the test, the fix, the re-test, and the report when a signal comes in.

You end up with evidence that is current whenever the board, an auditor, or an NCUA examiner asks.

See how Picus can help your credit union turn NCUA cybersecurity requirements into signal-driven, defensible security evidence. Book a demo to see the Picus Platform in action.

References

[1] Zero Day Clock, "Zero Day Clock: Vulnerability exploitation, measured," Zero Day Clock. Accessed: Oct. 7, 2026. [Online]. Available: https://zerodayclock.com/

[2] Zero Day Clock, "The Collapse," Zero Day Clock. Accessed: Oct. 7, 2026. [Online]. Available: https://zerodayclock.com/collapse

[3] Anthropic Frontier Red Team, "Anthropic's coordinated vulnerability disclosure dashboard," Anthropic. Accessed: Oct. 7, 2026. [Online]. Available: https://red.anthropic.com/2026/cvd/