Computer-Security Incident Notification Requirements
for US Banks
How to prepare your organization to comply with the US Financial Interagency Rule
The United States’ three federal bank regulatory agencies, the Office of the Comptroller of the Currency (OCC), the Board of Governors of the Federal Reserve System (Board), and the Federal Deposit Insurance Corporation (FDIC), approved requirements for US banks around reporting cybersecurity incidents.
Here is what every banking organization needs to know about incident notification.
Automate financial regulatory and contractual obligations with the BreachRx platform
Tailor your incident response plan in minutes so you know exactly what to do by when and take the legal crisis out of your incident response
Who Must Adhere to the Computer-Security Incident Notification Requirements
The Computer-Security Incident Notification Requirements apply to all banking organizations and bank service providers regulated by the OCC, the Board, and the FDIC, with the exception of designated financial market utilities.
| What is a banking organization? | The definition differs for each of the three agencies: OCC: A national bank, federal savings association, or federal branch or agency of a foreign bank. Board: A US bank holding company, US savings and loan holding company, state member bank, the US operations of foreign banking organizations, and an edge or agreement corporation. SEC: An FDIC-supervised insured depository institution, including all insured state nonmember banks, insured state-licensed branches of foreign banks, and insured state savings associations. |
| What is a bank service provider? | A bank service company or other person that performs “covered services,” which are services subject to the Bank Service Company Act. |
| How does the new rule get enforced? | Each of the three agencies is responsible for enforcing the rule among the organizations under their supervisory authority. Depending on the agency, enforcement actions can typically include prompt corrective action directives, civil monetary penalties, and written agreements. |
Incident Notification Requirements for US Banks
The US financial interagency rule defines two levels of incidents:
| Computer-Security Incident | An occurrence that (1) results in actual harm to the confidentiality, integrity, or availability of an information system or the information the system processes, stores, or transmits, or (2) violates or imminently threatens to violate security policies, security procedures, or acceptable use policies. |
| Notification Incident | An occurrence that materially does or is likely to disrupt or degrade the ability to:
|
The types of incident that require a response and the type of response required differ for banking organizations and bank service providers as follows:
| Banking Organizations | Bank Service Providers | |
| Type of incident that requires a notification | Notification incident | Computer-security incident that materially disrupts or degrades covered services for four or more hours |
| Whom to notify | Applicable federal regulator | At least one bank-designated point of contact at each affected banking organization (if not designated, then the CEO and CIO or two individuals of comparable responsibilities) |
| When to notify | “As soon as possible” and no later than 36 hours after determining that a notification incident has occurred | As soon as possible after determining that a computer-security incident has occurred |
| How to issue the notification | To the agency’s designated point of contact through email, telephone, or similar methods authorized by the regulator | To an email address, phone number, or other means provided by the banking organization for the designated point of contact |
| What to include in the notification | General information about the incident | General information about the incident |
| Additional points | The 36 hour clock doesn’t start until the organization determines an incident has occurred and that it meets the threshold for notification | No notification needs to be issued for disruptions of service due to scheduled maintenance, testing, or software updates if previously communicated |
Examples of Incidents That Can Trigger a Notification Under the
US Financial Interagency Rule
For banking organizations, examples of notification incidents that can trigger a notification include:
Ransomware Attack
An attack in which hackers use malware to steal data and hold it captive in exchange for a ransom payment. A ransomware attack that targets a core banking system or backup data qualifies as a notification incident.
Distributed Denial of Service (DDoS)
An attack that overwhelms a server, service, network or infrastructure with fake visitors to create a traffic jam. A DDoS attack that disrupts customer account access for more than four hours qualifies as a notification incident.
Failed System Change
If a banking organization plans a system upgrade or change that fails and leads to widespread outages for customers and employees that prevents access to user accounts, then it qualifies as a notification incident.
For bank service providers, examples of computer-security incidents that require a notification include the following – if they cause actual harm, materially disrupt or degrade covered services, and do so for at least four hours:
Watering Hole Attack
An attack in which hackers monitor individuals and infect websites they visit to access their computer and network, allowing the hacker to view, alter, steal, or destroy any data the victim can access.
Exfiltration
A part of most cyber attacks that occurs when hackers gain unauthorized access to move data to their own servers or devices.
Drive-By Download
An attack in which hackers install a malicious program on a user’s computer (often by hiding it within a legitimate website or application) to gain access to hijack the device or steal data that lives on it.
How Banks Can Prepare to Comply with the
Computer-Security Incident Notification Requirements
The final rule from the US financial agencies is one of several guidelines banks must follow. It’s important to take a proactive approach to keeping track of these laws and maintaining response plans. This requires ensuring visibility into data and assigning responsibility over incident response. From there, it’s critical to prepare for three phases of incident response:
Readiness
Proactively prepare incident response plans before an incident occurs to be ready to meet response timelines and reduce the associated costs.
- Review the requirements outlined in regulations and contracts.
- Develop clear incident response plans for each one.
Response
Take action quickly when an incident occurs to maintain compliance with regulations and retain customer trust.
- Identify what happened and when, and the potential impact.
- Determine if it meets the threshold for notification.
- Issue notifications as required.
Ongoing Management
Regularly revisit response plans to keep them up to date with the latest requirements and ensure that stakeholders know their responsibilities.
- Introduce a dashboard to monitor and report on response plans and updates to regulations and contracts.
- Provide stakeholders access to stay aligned on changes.
Prioritize Proactive Incident Management
Banking organizations and bank service providers are subject to a variety of regulations within the US and globally, making proactive preparation and tracking of these requirements a top priority.
These efforts should include understanding the requirements of each regulation, outlining incident response plans, and assigning responsibilities to be ready for a quick and confident response when an incident occurs.
Organizations must revisit these efforts regularly to keep up with changes to existing regulations and the addition of new ones.
Minimize your regulatory and contractual risk surface with the BreachRx platform
Stop using spreadsheets and documents to keep track of the legal tasks you need to accomplish during an incident response.
