On November 18, 2021, the FDIC, OCC, and Federal Reserve published a final rule titled "Computer-Security Incident Notification Requirements for Banking Organizations and Their Bank Service Providers." This guide is designed to break down the new rule and its expectations to prepare you before the rule goes into effect on April 1, 2022.

Requirements of the New Rule

The new rule includes two primary requirements:

  1. Banks must notify their primary federal regulator within 36 hours of determining a "notification incident" has occurred.
  2. Bank service providers, subject to the Bank Service Company Act (BSCA), must notify their customers as soon as possible when an incident occurs which may cause a disruption for four or more hours.

Why is the New Rule Needed?

If you are a community banker, you know the Interagency Guidance on Response Programs already requires certain incident notifications by the bank and their third parties. So, why was a new rule needed?

The answers boil down to two key concepts (page 6).

  • Timeliness. With phrases like "as soon as possible" alongside a 36-hour time limit, the agencies indicate timely notification is important because it provides early awareness of emerging threats and a better position from which to assess the risk of an incident.

  • Scope. Historical rules have focused on data breaches. While a continuing concern, there is growing concern around incidents which "disrupt or degrade" service capabilities. The new rule expands beyond the traditional scope of a data breach and brings attention to any type of computer-security incident which results in "actual harm."

The new rule facilitates improved oversight of incidents in real-time, allowing the agencies to implement more effective guidance to help the industry prevent, detect, and respond to significant threats.

Incident Definitions

There are three "incident" definitions in the new rule. Each definition plays a key part in understanding the final rule and shines some light on how the rule should be implemented.

1. Computer-Security Incident

A computer-security incident is "an occurrence that results in actual harm to the confidentiality, integrity, or availability of an information system or the information that the system processes, stores, or transmits."

Abridged from the NIST incident definition, a key word here is the term "actual." This is a change from the proposed version of the rule, which also included "potential" incidents and is designed to limit the scope of the rule by reducing the number of false-positive incident reports.

A computer-security incident does not have to be reported to the agency unless it is also a "notification incident."

2. Notification Incident

The definition of a notification incident is quite lengthy. According to the rule, a notification incident is "a computer-security incident that has materially disrupted or degraded, or is reasonably likely to materially disrupt or degrade, a banking organization's:

  1. ability to carry out banking operations, activities, or processes, or deliver banking products and services to a material portion of its customer base, in the ordinary course of business;
  2. business line(s), including associated operations, services, functions, and support, that upon failure would result in a material loss of revenue, profit, or franchise value; or
  3. operations, including associated services, functions and support, as applicable, the failure or discontinuance of which would pose a threat to the financial stability of the United States."

A notification incident is a very specific subset of computer-security incidents. Not only must the incident cause actual harm, but it must also do significant "material" damage to the bank's ability to do business or pose a threat to the entire country. This determination would be made during the analysis phase of the incident response process.

Banks must notify their primary federal regulator within 36 hours of determining a "notification incident" has occurred.

3. Bank Service Provider Incident

A bank service provider incident is "a computer-security incident that has materially disrupted or degraded, or is reasonably likely to materially disrupt or degrade, covered services provided to such banking organization for four or more hours."

Due to the increasing reliance of banks on their bank service providers, subject to BSCA, this type of incident notification would allow the bank plenty of time to determine if the incident experienced by the service provider would also be classified as a "notification incident" for the bank.

Bank service providers must notify their customers "as soon as possible" when they determine they are experiencing this kind of incident.

Notification Recipients

In the context of a rule like this, it only seems natural to ask the question, "who should be notified?" According to the final rule:

  • When a "notification incident" occurs, the agencies require the bank to notify "the appropriate agency supervisory office or other designated agency contacts" (page 34). In short, work with your regulator to determine who would be best suited to receive this report.

  • When a "bank service provider incident" occurs, the agencies require the bank service provider to notify "at least one bank-designated point of contact at each affected banking organization customer." If a contact is not defined, the notification should be made to the bank's CEO and CIO, or to "two individuals of comparable responsibilities" (page 41).

The notification is recommended to be provided via email or telephone, but the final rule plans for evolving technology and leaves the method relatively open-ended (page 33).

Notification Contents

This notification to the primary federal regulators is designed to exist simply as an "early alert." As such, "no specific information is required other than that a notification incident has occurred" (page 34). In a similar way, the rule does not describe the contents of the notification which must be provided by the bank service provider to the bank.

Nonetheless, one can infer from the intent of the rule that information beyond "an incident has occurred" will be requested or needed to meet the goals of the rule in helping determine the effects of the incident on both the bank and the greater banking industry.

Recordkeeping Requirements

The rule "does not impose any recordkeeping requirements" (page 48). That said, as with other legally required communication, it may be beneficial to document a record of the notification. If using an incident tracking system, like Tandem Incident Management, the communication can easily be noted via action step or handler note.

Estimated Impact of the Rule to Banks and the Industry

The estimated impact for this new rule on banks is "de minimis." The agencies have calculated a projected impact based on several estimates (pages 52 – 53 and 58), perhaps the most interesting being their estimate of 150 annual notification incidents being reported. This number is total, not per bank.

While these calculations do not include time spent responding to incidents, due to response being beyond the scope of the notification, or certain compliance costs (e.g., reviewing the rule, renegotiating bank service provider contracts, updating the Information Security Program, training personnel, etc.), it is clear the agencies believe the benefits will outweigh the costs. However, banks are encouraged to provide comments regarding actual implementation efforts and recommendations for how the agencies may be able to refine their calculations (page 57).

How to Address the Computer-Security Incident Notification Rule in Your Program

So, what do you need to do? Based on our current understanding of the final rule, there are three primary areas of your Information Security Program in which the final rule should be addressed.

  1. Information Security Policies. Update your "Incident Response" policy to reflect expected behavior and state the bank will provide notice to the primary federal regulator within 36 hours of determining a "notification incident" has occurred.

  2. Incident Response Plan. Update the response plan communication guidelines to document how, when, to whom, and by whom notice of a "notification incident" would be provided. Additionally, update the classification strategies and handling procedures to document how the bank plans to determine whether an incident is a "notification incident" or not.

  3. Vendor Management Program. Most of your contracts with bank service providers, subject to BSCA, should already include notification requirements similar to the ones expected by the new rule. In the event they do not, update the contract review process to ensure the new requirements are addressed. But keep in mind the rule requires bank service providers to "comply even where their contractual obligations differ from the notification requirement in this rule" (page 43).

If you use Tandem Policies, Tandem Incident Management, or Tandem Vendor Management, keep an eye on our Software Updates blog to see how we will be addressing these areas and how to include our recommendations in your program.

Summary

In summary, the agencies believe the final rule "largely formalizes a process that already exists, reflecting the collaborative and open communication that exists between banking organizations and the agencies" (page 46). While any rule comes with added regulatory burden, the intent of this rule seems to stem from a place of improving the banking industry's resilience. Encouragingly, it is obvious the agencies took the feedback of the banking community to heart, making changes to the final rule accordingly.

To learn more about the final rule, join our webinar on February 1, 2022, at 2:00 PM (CT): A Banker's Guide to Understanding the New Incident Notification Rule. For additional information and resources about how you can comply with this and other banking regulations, visit our website and learn more at Tandem.App.