Most credit unions know the 72-hour rule exists. Fewer have thought carefully about when the clock actually starts, and that is where the exposure sits.

It does not start when you confirm a breach. It does not start when you finish an investigation. Under Part 748, it starts when you form a reasonable belief that a reportable cyber incident has occurred.

And it can start with a phone call from a vendor.

When does the NCUA 72-hour clock start?

Three triggers, and the third is the one that catches people.

You detect something yourself and form a reasonable belief it is reportable.

A reportable incident is confirmed through your own investigation.

A third party notifies you that sensitive data has been compromised or business operations disrupted by a cyber incident. The NCUA's guidance is explicit: in that situation, the credit union has 72 hours to report.

Reasonable belief is a lower bar than confirmation. You do not get to run a full forensic investigation first and start counting afterward. The clock is already running while you are still working out what happened.

The NCUA is also clear that it expects notification as soon as possible within the window, not at hour 71. Missing it does not automatically bring a penalty, but it reliably brings an examiner finding and a requirement to revise your incident response procedures.

Why is a vendor incident the hard case?

Because the NCUA wrote the third-party trigger into the rule deliberately, and because the typical reportable event is not the one most incident response plans rehearse.

The plan usually assumes an intrusion you detected on your own network. The disclosure that actually arrives comes from outside, concerns systems you do not control, and is described in language written by someone else's legal team.

And vendor disclosures are usually vague at first. "We experienced a security incident affecting a subset of customers." "We are investigating unauthorized access to certain systems." That notice starts a clock, and the first thing you need to establish is whether your members' data was in scope.

That determination depends entirely on your own records. Which files went to that vendor, over what period, containing what. If answering that takes three days of manual reconstruction, the 72 hours are gone before you know whether you had anything to report.

This is the same structural problem healthcare faces with business associate breach notification: a clock that starts on someone else's disclosure, and a determination that requires records you should already have.

What counts as a reportable cyber incident?

The NCUA's own examples are more expansive than most incident response plans assume:

• An unauthorized intrusion into a network information system
• Sensitive data exfiltrated from the credit union or a contracted third party
• Internal breach or data theft by an insider
• Member information compromised through card skimming at an ATM
• Ransomware, or an attacker locking the institution out of its own systems

Note the second one. Exfiltration from a contracted third party is explicitly on the list. A vendor losing your members' data is your reportable incident, not just theirs.

What examiners are actually finding

Two patterns show up repeatedly in 2026 examinations.

Generic incident response language draws a finding. A plan that says "in the event of a cybersecurity incident, the IT team will respond accordingly" is not sufficient. Examiners expect scenario-specific playbooks, including one for vendor incidents, that specify who does what, in what order, within what timeframe, and how the 72-hour obligation gets triggered and fulfilled.

Vendor oversight is documentation, not intention. Credit unions do not have NCUA's supervisory backstop over third-party providers the way banks do over some of theirs. That places the monitoring burden squarely on the institution, and examiners want to see what your program detected and when, not that you collected a questionnaire response last year.

Is the FFIEC Cybersecurity Assessment Tool still current?

No, and this one catches institutions that are otherwise well run.

The FFIEC retired the Cybersecurity Assessment Tool in 2025 with no single mandated replacement. Examiners now expect institutions to map their program to a recognized successor, such as the CRI Profile, NIST CSF 2.0, or the CISA Cybersecurity Performance Goals, and to document that mapping.

Running the retired CAT without a documented transition is a finding that was avoidable. It is unrelated to the 72-hour clock, but it shows up in the same exam.

What can you actually do about it?

Four things, in rough order of how much they change the outcome.

Write the vendor-incident playbook specifically. Not incident response generally. The version that answers: a vendor just told us something vague, who picks up the phone, who determines scope, who decides whether reasonable belief has been formed, and who files.

Put notification obligations in the contract. Your 72 hours start when they tell you. If a vendor takes two weeks to disclose, your clock starts late and your members' exposure started earlier. Contractual notification timelines are the only lever you have on that.

Know what you sent, before you need to know. The scope determination is the slow step in almost every vendor incident. It is also the one that can be made fast in advance and essentially cannot be made fast afterward.

Test it with the vendor scenario, not just ransomware. Tabletop exercises are already expected under the NCUA's Information Security Examination procedures, and most of them rehearse an attack on your own systems. The vendor scenario exercises a different muscle: not detection and containment, but scope determination against a disclosure you did not write and cannot verify from the inside.

Does a file transfer platform help with the 72-hour rule?

Only with one piece of it, and it is worth being specific about which.

No product makes you compliant with Part 748. That comes from your written security program, your board oversight, your incident response plan and your testing. Nothing purchasable substitutes for those.

What software affects is the scope determination. Every external exchange produces a structured, append-only, tamper-evident audit event exported to storage you control, so "what did we send this vendor, over what period, and who accessed it" is a query rather than a reconstruction project. Access is identity-bound and short-lived, so a vendor's access ends rather than persisting past the engagement.

In a 72-hour window that starts with someone else's vague phone call, the difference between a query and a reconstruction is often the difference between reporting accurately and reporting late.

More on audit evidence and identity-bound access.

The short version

The clock starts at reasonable belief, not confirmation. A vendor's disclosure can start it. And exfiltration from a contracted third party is explicitly on the NCUA's own list of reportable incidents.

The question worth asking before the next exam is not whether your incident response plan mentions the 72-hour rule. It is whether, on the morning a vendor calls with something vague, you could establish what you sent them and when, inside the window that is already running.

Request a demo

Sources

• NCUA, Cyber Incident Notification Requirements (third-party trigger, reportable incident examples)
• Federal Register, Cyber Incident Notification Requirements for Federally Insured Credit Unions (Part 748 amendment, effective September 1 2023)
• First Call, NCUA IT Requirements for Credit Unions: 2026 Compliance Guide (examiner findings on generic IR language)
• TorchLight, Credit Union Cybersecurity Readiness Checklist (FFIEC CAT retirement and successor frameworks)