Cyber Security for Banks: Threats, Regulations, and Best Practices

Cybersecurity at a bank is a supervised obligation with a board-level accountability structure, not an IT budget line. Examiners assess it, the notification deadlines are measured in hours, and the largest exposures usually sit at third parties rather than inside the institution's own perimeter.

This covers the threats that actually produce losses, the regulatory framework, and what a defensible program looks like.

The Threats That Matter

Threat lists are easy to produce and mostly useless. These are the ones that account for most realized loss at financial institutions.

Phishing and social engineering. Still the dominant initial access vector, because it targets people rather than systems and scales cheaply. Modern versions are well written, reference genuine transactions, and frequently arrive from a compromised legitimate account — which defeats the older advice about spotting bad grammar and unfamiliar senders.

Ransomware. Now routinely combined with data exfiltration, so a clean backup restores operations without removing the extortion leverage. The operational question is not only whether you can recover, but what happens when the attacker publishes.

Business email compromise. Covered in depth in our post on wire transfer fraud, and worth naming here because it is a cybersecurity failure that produces a payments loss — which is exactly why the two functions must not operate separately.

Third-party and supply chain compromise. Core processors, cloud providers, and fintech partners hold concentrations of customer data far larger than most institutions hold themselves. A breach there is the institution's incident regardless of where it occurred.

Credential stuffing and account takeover. Passwords breached elsewhere, replayed against online banking at scale.

Insider risk. Both malicious and accidental — the misdirected file and the departing employee taking a customer list cause more incidents than deliberate sabotage.

DDoS. Frequently used as cover, generating noise while something else happens elsewhere.

The Regulatory Framework

GLBA requires a written information security program with administrative, technical, and physical safeguards appropriate to the institution's size and complexity, designed to ensure the security and confidentiality of customer information, protect against anticipated threats, and protect against unauthorized access likely to result in substantial harm. The banking agencies implement this through interagency guidelines, and board approval and oversight of the program is explicit.

The computer-security incident notification rule requires a banking organization to notify its primary federal regulator as soon as possible and no later than 36 hours after determining that a notification incident has occurred — broadly, one that has materially disrupted or degraded operations, or is reasonably likely to. Bank service providers carry a parallel obligation to notify affected banking customers.

Customer notification under the GLBA interagency guidance is a separate obligation from regulator notification, as are state breach notification laws, which vary in trigger and timing.

Examination is conducted against the FFIEC IT Examination Handbook. Institutions should be reading the same booklets examiners work from — Information Security, Business Continuity Management, Outsourcing Technology Services, and Architecture, Infrastructure, and Operations.

NOTE TO EDITOR: The FFIEC announced the sunset of its Cybersecurity Assessment Tool, and institutions have been migrating to other frameworks such as the NIST Cybersecurity Framework or the CRI Profile. Confirm the current status and what the client's courses reference before publishing any statement about which assessment framework applies.

Governance

The board approves the information security program, receives regular substantive reporting, and is expected to understand the institution's material cyber risks well enough to challenge management. Reporting that consists of a green dashboard is a finding.

The information security officer should have independence from IT operations, so the person assessing controls is not the person operating them. Examiners look for this separation specifically.

Risk assessment identifies the institution's information assets, the threats to them, and the controls in place, and it should drive the program rather than accompany it.

Incident response requires a documented plan with defined roles, escalation criteria, notification decision points mapped to the 36-hour deadline, communications templates, and legal and law enforcement contacts. A plan that has never been exercised is an assumption.

Structured coverage of this framework is available through our cyber security training, the Certificate in Cybersecurity, and Cybersecurity Management.

Controls That Earn Their Place

• Multifactor authentication on remote access, administrative accounts, email, payment origination, and customer-facing online banking — with phishing-resistant factors for the highest-risk functions, since SMS codes are vulnerable to SIM swapping
• Privileged access management — administrative rights granted narrowly, reviewed regularly, and logged
• Network segmentation, so a compromised workstation does not reach core systems
• Patching on a defined cycle, with internet-facing systems prioritized
• Endpoint detection and response with someone actually monitoring the alerts
• Email security — authentication protocols, attachment and link handling, and external-sender marking
• Backups that are offline, tested by actual restore, and verified to be outside the blast radius of a domain compromise
• Logging and retention sufficient to reconstruct an incident
• Vulnerability scanning and penetration testing by an independent party, with findings tracked to closure
• Security awareness training with simulated phishing, where results drive targeted follow-up rather than punishment

Third-Party Risk

Most institutions' largest data concentrations are held by vendors. Due diligence should cover the provider's security program, independent assurance such as a SOC 2 Type II report, incident notification commitments written into the contract with specific timeframes, subcontractor management, and business continuity capability.

Two failures recur. Contracts without notification timelines — the institution learns of a vendor breach when a journalist calls. And assurance reports collected but not read — a SOC 2 with exceptions relevant to the institution's use case, filed without anyone examining the exceptions.

The supervisory position is unambiguous: using a third party does not diminish the institution's responsibility to conduct the activity safely and in compliance with law.

Where Programs Actually Fail Examination

Not on technology. On evidence.

The recurring finding is a program that is documented but not demonstrable — policies exist, but there is no record that user access reviews were performed, that the incident response plan was tested, that vendor due diligence was refreshed, that penetration test findings were remediated, or that the board received and discussed substantive reporting.

The remediation is almost always about producing evidence of operation rather than buying additional tooling. An institution that can show, for each control, who performed it, when, and what the result was, is in a strong position regardless of how modest the technology stack is.

Coordinating With Fraud and BSA

These three functions see different parts of the same events and frequently do not talk.

A phishing campaign against customers is a security incident, produces fraud losses, and may generate BSA filings. An account takeover is detected by security telemetry, resolved under fraud procedures and Reg E, and reported on a SAR. A ransomware payment decision raises sanctions questions that belong to the BSA and OFAC function, not to IT.

Institutions that run these separately produce three partial pictures. The workable arrangement is shared detection and a standing forum — even a brief weekly one — where security, fraud, and BSA compare what they are seeing. The customer-facing patterns almost always appear in one function's data before another's, and the institutions that connect them early are the ones that get ahead of a campaign rather than tallying its losses.

This coordination is also increasingly an examination expectation rather than a good practice. Supervisors ask how the institution's fraud, information security, and BSA functions share information, and an answer that describes three separate reporting lines with no intersection is a governance observation waiting to be written.

Testing, Not Assuming

The distance between a documented program and a functioning one is measured by what has been tested. Four exercises separate institutions that discover problems on their own schedule from those that discover them during an incident.

Restore from backup, end to end. Not verifying that a backup job completed — actually restoring a critical system to a usable state and timing it. Institutions routinely discover at this point that recovery takes days rather than hours, that a dependency was never backed up, or that the backup credentials live only on the system being restored.

Tabletop the incident response plan with the people who would actually run it, including executives and communications. The value is in the decisions the plan does not address: who declares an incident, who talks to the regulator, who decides whether to take a customer-facing system offline, and what gets said to customers in hour three.

Test the 36-hour clock specifically. Walk a realistic scenario from first detection to the notification decision and see how long it takes to reach someone with authority. Institutions frequently find that the determination point — when do we know this is a notification incident — is nobody's defined responsibility.

Run a phishing simulation and then examine what the click produced, rather than only reporting the click rate. The useful question is not what proportion of staff clicked; it is what a clicked link would have reached, whether the credentials would have worked, and whether anything would have alerted.

Findings from each of these should be tracked to closure with owners and dates, and the exercise itself should be documented — because the record that a test occurred, and what it found, is exactly what an examiner asks for and what most institutions cannot produce.

A note on scale. Community institutions frequently conclude that a defensible program is out of reach because they cannot staff a security operations center or fund continuous monitoring. That is the wrong comparison. Supervisory expectations are explicitly proportional to size and complexity, and a small institution with documented risk assessment, enforced multifactor authentication, tested backups, a rehearsed incident response plan, disciplined vendor oversight, and evidence that each of those operated is in a stronger position than a larger institution with more tooling and no records. What examiners assess is whether the program fits the risk and whether it demonstrably runs — not how much was spent on it.

Frequently Asked Questions

What does GLBA require for information security?

A written information security program with administrative, technical, and physical safeguards appropriate to the institution's size and complexity, designed to ensure the security and confidentiality of customer information, protect against anticipated threats, and protect against unauthorized access likely to cause substantial harm. Board approval of the program and ongoing board oversight are explicit requirements.

What is the 36-hour incident notification rule?

Under the interagency computer-security incident notification rule, a banking organization must notify its primary federal regulator as soon as possible and no later than 36 hours after determining a notification incident has occurred — one that has materially disrupted or degraded operations or services, or is reasonably likely to. Bank service providers must notify affected banking customers under a parallel obligation.

Is regulator notification the same as customer notification?

No. The 36-hour rule addresses notification to the primary federal regulator. Customer notification obligations arise separately under GLBA interagency guidance and under state breach notification laws, which differ in what triggers them and how quickly they require notice. All three tracks must be assessed independently.

Who should the information security officer report to?

Not to IT operations. The role requires independence from the function it assesses, so that the person evaluating controls is not the person responsible for operating them. Examiners review reporting lines specifically, and an ISO reporting to the head of technology is a common structural finding.

What is the most common cybersecurity examination finding?

Programs that are documented but not evidenced — policies and plans exist, but there is no record showing that access reviews occurred, that the incident response plan was tested, that vendor due diligence was refreshed, or that penetration test findings were remediated. The fix is producing evidence of operation, not additional technology.

How much responsibility does a bank retain for a vendor breach?

All of it, from the supervisor's perspective. Using a third party does not diminish the institution's responsibility to conduct the activity in a safe and sound manner and in compliance with law. Examiners review the institution's oversight of the vendor, and in some cases examine significant service providers directly.