Since the effective date for the incident notification rule for banks, we have received several questions asking about whether an incident would be classified as a "notification incident" or not. For example:

  • Would a one-hour core system outage be considered a "notification incident?"
  • Would a bomb threat / robbery be considered a "notification incident?"
  • Would a third-party breach from 10 years ago be considered a "notification incident?"
  • Would an incident affecting 10% of our customers be considered a "notification incident?"
  • Would malware be considered a "notification incident?"

Each of these are very valid questions. If you work for a bank, how exactly would you determine which of these incidents must be reported to your federal regulator, per the legal definition? Let's take a look.

The Legal Definition

To determine if an incident must be reported to a federal regulator, an incident must meet two qualifiers:

  1. It must be a "computer-security incident." This 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."

  2. It must be a "notification incident." This is "a computer-security incident that has materially disrupted or degraded, or is reasonably likely to materially disrupt or degrade" a bank's operations, including those which would:

    • "Disrupt or degrade" the bank's ability to "carry out banking operations [or deliver] products and services to a material portion of its customer base."
    • "Result in a material loss of revenue, profit, or franchise value."
    • "Pose a threat to the financial stability of the United States."

(For the full definition, see the final rule: https://www.federalregister.gov/d/2021-25510/p-331)

The word "material" shows up four times in this definition. While there is not an exact definition of the term, context clues and the word's use in other legal contexts tells us that we are dealing with something serious or extreme.

This is evidenced by the terminology used in the examples provided by the agencies, including words like large-scale, extended, widespread, failed, unrecoverable, etc. These terms communicate an idea that the types of incidents to be considered as "notification incidents" are very serious and possibly even systemic in nature.

What Does This Mean?

It is not as simple as "these incidents are notification incidents, and those incidents are not."

This is a decision which will need to be made on an incident-by-incident basis.

Consider some of the examples above:

  • An incident which affects 10% of the bank's customers. Does "10%" meet the definition of "material" for you? What exactly is affecting them? How serious is it? How soon will it be resolved? Which 10% of your customers are affected? Is it a random 10%? Is it your top 10%?

  • An incident which causes a one-hour core system outage. Does this meet the implications of being a "material" incident, if it was only out for one hour? On the surface, this isn't "extended" or "unrecoverable," but what does the root analysis show? What caused the one-hour core outage? Is it likely to happen again? Are there any trickle-down effects from this?

  • An incident involving a bomb threat / robbery. Where did the bomb threat / robbery occur? Was it one time at one branch, or a simultaneous attack on your data centers? What are the chances the malicious actor gained access to bank systems or data as part of this event?

Obviously, none of these scenarios are something you want to have happen. Anytime something goes wrong, that's a problem. The question is: Is it serious enough to consider a "notification incident?"

When in Doubt, Report It.

If we pay attention to the purpose of reporting a "notification incident" over the compliance aspect, we can focus on the fact that the agencies are using this information as an "early alert" of emerging threats in the industry. Something which may not seem like a big deal to you could be one piece of an obvious large-scale attack when looking across the industry. If several banks report the same incident, the regulators can act more quickly and help with the response process. Keeping open lines of communication with your federal regulator is beneficial for both you and them, so if you ever have a question about whether to report an incident, go ahead and report it.

Notification Incident Decision Tree

Due to the nature of "notification incidents," I cannot give you a silver bullet solution to answer the "is it or is it not" question. Each incident will need to be analyzed to determine if it qualifies. That said, I can give you a tool to help guide you through the thought process. Follow the decision tree below to help you figure out if your situation would be best classified as a "notification incident."

For additional information, visit our blog on The New Incident Notification Rule: What Banks Need to Know. To take your incident response practices to the next level, check out Tandem Incident Management. This product has been designed to help you create your incident response plan and put it into action with the incident tracking component. To see how Tandem can help you, visit our website: Tandem.App/Incident-Management-Software.