Managed IT and Cybersecurity for Columbus Credit Unions

Which credit unions does NCUA Part 748 reach, and what does a charter change?

Three separate things decide what a credit union owes, and they are easy to blur together. The charter says who created it. That is either NCUA under the Federal Credit Union Act, or the Ohio Division of Financial Institutions under Revised Code Chapter 1733. Share insurance says who guarantees member accounts. Supervision follows from both: a federal charter answers to NCUA alone, while an Ohio charter answers to the Division and, if its shares are federally insured, to NCUA as well. Those three distinctions carry through everything below.

Share insurance is what turns on Part 748. The charter does not. Section 748.0(a) binds every federally insured credit union, and 12 CFR 741.0 and 741.214 carry the whole of Part 748 onto federally insured state-chartered credit unions by cross-reference. An Ohio-chartered credit union insured by the NCUSIF owes everything a federal charter owes here, including two dated duties: a written security program within 90 days of the effective date of insurance (section 748.0(a)), and an annual certification of compliance made personally by the president or managing official through NCUA's online Credit Union Profile system (section 748.1(a)). A compliance vendor cannot sign that certification in their place.

Where member accounts are not federally insured, Part 748 does not reach the credit union at all. Revised Code 1733.041 permits a credit union to take share insurance from NCUA, from a Chapter 1761 share guaranty corporation, or from any qualified private insurer. Those are three routes, and only the first leads inside Part 748. Outside it, GLBA duties run to the FTC instead, under the same Safeguards Rule and the same 30-day breach-notification clock our professional-services page covers (16 CFR 314); federally insured credit unions are excused from that FTC regime because 15 U.S.C. 6805(a)(2) assigns their GLBA enforcement to NCUA.

An Ohio charter adds a supervisory layer a federal charter does not have. Under section 1733.32(A), the Superintendent of Financial Institutions enforces the credit union laws through the Deputy Superintendent for Credit Unions, and the books and records of a credit union are open to inspection at all times. Section 1733.328 caps routine exams at once every 24 months for a credit union under $10 billion with a composite rating of one, but division (B) lets the Superintendent examine more often on reasonable cause or jointly with NCUA. Two clocks follow an exam: the directors must meet to consider the report and the president must notify the Superintendent of any action taken within 30 days (section 1733.32(F)), and the statute requires a financial report within 30 days of any Superintendent request, plus an annual report of the December 31 condition. Working out which regime actually reaches a specific credit union, NCUA Part 748 or GLBA through the FTC, is scoping work our virtual CISO engagements start with, since Part 748 is itself NCUA’s implementation of the same GLBA obligation, and the security work underneath either one covers much of the same ground.

What has to be reported after an incident, to whom, and how fast?

The cyber incident report is the one with the hard number. The rule took effect September 1, 2023, so its compliance date passed long ago. Section 748.1(c) requires a federally insured credit union to notify NCUA's designated point of contact "as soon as possible but no later than 72 hours" after it reasonably believes it has experienced a reportable cyber incident. Reasonable belief starts the clock. Confirmation is not required. Filing runs through cyberreports.ncua.gov, by phone at 1.833.CYBERCU, or by secure email to cybercu@ncua.gov. Section 748.1(c)(1) defines what counts across three prongs: a substantial loss of confidentiality, integrity or availability; a disruption from a cyberattack; or a disruption or unauthorized access caused by a third party such as a core processor, cloud host or other vendor. That third prong is worth reading closely. When the breach is at the core processor, the rule still places the report with the credit union.

A second, separate notice runs on its own trigger, and collapsing it into "72 hours to tell NCUA" is the most common error on this subject. Appendix B, paragraph II.A.1.b, requires notice to the NCUA Regional Director (and, for an Ohio charter, to the Division of Financial Institutions) as soon as possible once the credit union becomes aware of an incident involving unauthorized access to sensitive member information. There is no 72-hour ceiling on this one, and a single incident can owe both notices at once.

A third report can land on the same incident. Section 748.1(b) requires notice to the Regional Director within 5 business days of a catastrophic act, meaning any disaster that physically damages the credit union or interrupts vital member services for more than two consecutive business days. Ransomware that keeps core processing down into a third day meets that definition. NCUA proposed lengthening this window in December 2025, but no final rule has issued, so 5 business days governs today. A fourth report, Suspicious Activity, runs to FinCEN rather than NCUA under section 748.1(d): the filing window is 30 calendar days from detecting the activity, or 60 where the extra 30 are needed to identify a suspect, covering insider abuse of any amount, transactions of $5,000 or more with an identifiable suspect, and $25,000 or more regardless. The rule also sets a five-year retention period for each SAR, board notification of any filing, and confidentiality of the filing. Section 748.1(d) is worth reading in full with whoever runs the BSA compliance program. Meeting these clocks starts well before an incident: knowing what counts as a reportable event, having detection in place to notice it inside the window, and having someone accountable for making the call and filing the report is what our virtual CISO and Managed IT work builds ahead of time, not after.

What has to be in a written information security program?

Section 748.0(b) requires a written security program covering member-records protection, breach response, and threat identification. Appendix A to Part 748 is where the operating detail lives. It is NCUA's implementation of GLBA section 501(b), and the standard examiners work from. NCUA proposed in December 2025 to relocate both appendices out of the CFR into guidance; the comment period closed in February 2026 with no final rule, so both remain codified today, and either way the underlying GLBA obligation survives the move. Under Appendix A III.A, the board or a board committee approves the program and assigns responsibility for it; under III.F, management reports to the board at least annually on program status, risk decisions, service-provider arrangements, test results, and any security breaches.

Paragraph III.B is the risk assessment: identify foreseeable threats, assess their likelihood and damage, and assess whether current controls address them. It is not a write-once document, because III.C.3 sets testing frequency by that assessment rather than by a fixed interval. Paragraph III.C.1 lists eight specific measures to consider and adopt where appropriate: access controls, physical restrictions, encryption in transit and at rest, change-control procedures, dual controls and background checks, intrusion monitoring, an incident response program, and protection against environmental hazards. Consideration is mandatory even where adoption is not, so the reasoning behind a declined measure is part of what the record has to show.

III.C.3 also expects testing to come from an independent third party, or from staff independent of whoever built the program. Where one provider builds the program, runs the network, and then grades its own work, nothing independent is left to show an examiner. That constraint binds us exactly as it binds anyone else holding the contract. Most credit unions this size cannot answer, on the spot, which of the eight measures they adopted, which they declined, and why. That is exactly the question an examiner asks first. The Security Analysis at https://outreach.ttscyber.com/analysis is a $349 point-in-time assessment mapped to 38 compliance frameworks, built to answer it before an examiner does. It is a diagnostic. It does not stand in for the ongoing III.C.3 testing. The written program and its testing are separate engagements. Virtual CISO Services and Managed IT Services build and run them, which means if we build the program or run the network, the III.C.3 testing has to come from someone else.

Who owes the notice when the breach happens at a core processor or CUSO?

The obligations reach further than most owners assume. Appendix A applies to member information maintained by a credit union or on its behalf, and "service provider" under paragraph I.B.2.f covers anyone with access to it. Core processor, item processor, cloud host, managed IT provider, and document shredder all qualify. Paragraph III.D sets three duties over them: exercise due diligence selecting them, require appropriate safeguards by contract, and monitor them where the risk assessment calls for it, reviewing audits or equivalent test results.

Appendix B II.A.2 settles the question that gets asked mid-incident: where the breach is at a service provider's systems, notifying members and the regulator stays with the credit union, even though it may contract with the provider to send the notices on its behalf. That is why vendor contracts commonly require notice back as soon as possible, since every clock on this page runs from what the credit union knows. Member notice itself carries no fixed day count. Appendix B III.A requires a reasonable investigation followed by notice as soon as possible once the credit union determines that misuse of sensitive member information (a name paired with a Social Security number, account number, or access credential) has occurred or is reasonably possible. Notice can be delayed only on a law-enforcement agency's written request, and NCUA states plainly that anticipated embarrassment is not a reason to withhold it.

Ohio's breach statute sits on top of this, and the common claim that credit unions are simply exempt from it is only conditionally true. Revised Code 1349.19(F)(1) is a two-part test: the exemption runs only to an entity that federal law requires to notify customers of a breach and that a federal regulator examines for compliance with that law. Federal share insurance supplies both halves through Part 748 and 15 U.S.C. 6805(a)(2). A privately guaranteed Ohio credit union satisfies neither half, and falls under the full ORC 1349.19 duty: notice in the most expedient time possible and no later than 45 days following discovery, plus notice to the nationwide consumer reporting agencies without unreasonable delay above 1,000 affected Ohio residents. Ohio's cybersecurity safe harbor at ORC 1354.02 reaches credit unions as well, and a program reasonably conforming to GLBA Title V is one of its qualifying routes. That is one more reason the existence of the program is worth being able to prove. Proving it after the fact, rather than assembling it while a regulator or a reporter is already asking, is what the same virtual CISO and compliance work described above is built to keep current.

How do you monitor a system you do not run?

The core is someone else’s servers in someone else’s building. You will not be installing an agent on it, and you will not be reading its logs. What you can see is your side of the connection, and that side is bigger than most credit unions have ever mapped. Every vendor path terminates on equipment you own: the site-to-site tunnel to the core, the CUSO’s remote access, the link to item processing, the ATM or ITM vendor’s connection, and whatever remote support tool an integrator installed during a conversion weekend. Write that list down before anything else, because it is almost always longer than the answer people give from memory. Then narrow each path to what the service actually needs. That means a named rule per vendor rather than a broad allow, scoped to the hosts and ports in use, with logging turned on at that boundary. The failure this is aimed at is an ordinary one: a tunnel opened wide for a go-live, left wide for four years, reaching every host on the branch subnet because narrowing it afterward was never anyone’s ticket. Managed firewall protection and Network Operations Center work cover the firewalls, switches, access points and wireless these paths land on.

The other half of the vendor boundary is accounts, and it is the half that rots quietly. A domain account for the integrator. A guest account in your Microsoft 365 tenant for a support engineer who worked one project. A service account for a middleware connector nobody has signed into since the conversion. None of these came through HR, so none of them leave through offboarding. A third-party access review is unglamorous and it is the work: list every account that does not belong to an employee, name the internal person who owns each one, confirm it still needs to exist, confirm multifactor authentication applies to it, remove what is dead, and record the date you did it. Run it on a schedule rather than when something prompts you. That is system administration, cloud IT services, and the same onboarding and offboarding discipline you already apply to staff, extended to the people who are on your network without being on your payroll.

What you can prove about a vendor splits in two. One half is evidence you hold, such as firewall rules and their logs, which tunnels exist and what they reach, the dated access review, and the multifactor configuration. The other half is evidence you have to ask the vendor for. Appendix A III.D sets three duties over service providers: exercise due diligence selecting them, require appropriate safeguards by contract, and monitor them where the risk assessment calls for it, reviewing audits or equivalent test results. Both halves get asked for, and not only by an examiner. A cyber insurance renewal asks you to attest that multifactor authentication is enforced on remote access and privileged accounts, and the word doing the work there is enforced. Answering it takes two artifacts: the policy configuration showing enforcement, and the exception list underneath it. That list is the accounts excluded and the reason, because there is usually at least one service account or legacy sign-in path that somebody carved out and forgot. Pull the real exclusion list rather than trusting memory, then either close the gaps or answer accurately. Virtual CISO and Compliance-as-a-Service work covers the evidence tracking and control maintenance behind this, so the answer you give at renewal and the answer you give at examination come out of the same file.