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 is a very valid question. 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:
- 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.”
- 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:
a) “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.”
b) “Result in a material loss of revenue, profit, or franchise value.”
c) “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 no exact definition of the term, context clues and the word’s use in other legal contexts tell 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 considered “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 decision will need to be made on an incident-by-incident basis.
Consider some of these examples:
- An incident that 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 that 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 that the malicious actor gained access to bank systems or data as part of this event?
Obviously, none of these scenarios is 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 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 that 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 chart to help you figure out if your situation would be best classified as a “notification incident.”
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 at Tandem.App/Incident-Management-Software.
As a millennial, Alyssa Pugh grew up with technology at her fingertips. She has more than 10 years of professional technical and information security experience. She earned a B.A. in Technical Communications and has achieved the CISM and Security+ certifications. Alyssa currently serves as the GRC Content Manager for Tandem, an information security and compliance application. Alyssa has presented multiple conference sessions on topics including risk assessments, business continuity, third-party oversight, and cybersecurity.