About Us | Contact Us
View Cart

FDIC and OCC Release New Incident Notification Rules

By Adam Reynolds | Monday, January 31, 2022 - Leave a Comment

An update to your Incident Response and Business Continuity Plans will be required . . .


. . . but will not replace any previous rules!
A new article meant to inspire thought about IT Governance…


Note: We have included a copy of the publication for your full review at the end of the article. Click here to go to it.

A final rule published by the FDIC, OCC, and the Federal Reserve is coming into effect May 1st and is changing the notification requirements for our primary federal regulators. This rule will not only require a change in our Incident Response Plan, but also in our Business Continuity Plan as well. Previous notification requirements focused on incidents involving security and confidentiality, such as customer information disclosures, but now the notification requirements are focusing on availability and operational aspects as well. The rule does not change any previous requirements for notifications, but now requires notification within 36 hours of a newly defined incident type, notification incidents.

The rule has two parts, the first defining requirements for banks to notify their primary federal regulators, and the second for bank service providers (those providing covered services subject to the Bank Service Company Act) to notify banks during actual and potential material service disruptions for four or more hours.  In this article we will be focusing on the first requirement in the rule, but it is important to know for the second requirement your bank service providers will be required to have a bank-designated point of contact for notification, and this notification could lead to the requirement to notify the primary Federal regulator by the bank.  Originally this was to be two points of contact but removed with consideration for smaller institutions, so be sure to have a continuity process to watch for these notifications if there is only one contact. It is our expectation that financial institutions will need to update contracts with vendors to codify this requirement, especially if your vendors are not supervised by the regulators. Vendor inventories will also need to include a flag for vendors covered by this regulation.

The rule now requires financial institutions to notify their primary Federal regulators as soon as possible, and within 36 hours, of notification incidents, which are defined as “a computer-security incident that has materially disrupted or degraded, or is reasonably likely to materially disrupt or degrade, a banking organization’s:

  • 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;
  • 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
  • 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.”

We will focus on the first two statements (i and ii) as most reading this will not have operations where failure or discontinuance would pose a threat to the financial stability of the United States (<$50B). This new rule can then be condensed by asking three questions. First, has an incident occurred that resulted in actual harm to the confidentiality, integrity, or availability of an information system or the information that the system processes, stores, or transmits (a computer-security incident)? This type of incident is defined in the rule as a “computer-security incident” as it involves an information system or the data that resides on such a system, but that would not necessarily translate to an incident as defined in a typical Incident Response Plan (it is clarified in the rule the definition includes incidents from whatever cause, as it is the effect of the incident that is important). While an incident that affected confidentiality or integrity of those systems would normally trigger the incident response plan, an incident that affected only the availability of such systems may not and is why the Business Continuity Plan needs updated to address this rule as well.

If such an incident did occur after asking the first question, there are then two qualifying questions to ask to determine if notification is necessary. The first question is if the incident has materially disrupted or degraded, or is reasonably likely to materially disrupt or degrade, your ability to carry out banking operations, activities, or processes, or deliver banking products and services to a material portion of your customer base, in the ordinary course of business. And the second is if the incident has materially disrupted or degraded, or is reasonably likely to materially disrupt or degrade, your 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. If either of these two statements are true, notification is required. It is also important to remember this does not include minor incidents, it must (or potentially) affect a material portion of your customer base or include a material loss of revenue, profit, or franchise value. If in doubt as to whether it is a notification incident for purposes of notifying your primary Federal regulator, it is encouraged to contact your regulator (see provided examples at the end of this article).

Adam Reynolds, CISSP
Lead Non-Technical Auditor

 

This notification is required after the organization has determined that a notification incident has occurred. As noted in the rule, the agencies do not expect that an organization would typically be able to determine that a notification incident has occurred immediately upon becoming aware of a computer-security incident. Rather, the agencies anticipate that a banking organization would take a reasonable amount of time to determine that it has experienced a notification incident. Finally, the rule does not define any particular notification approach, stating “A simple notice can be provided to the appropriate agency supervisory office, or other designated point of contact, through email, telephone, or other similar method that the agency may prescribe. The notifications, and any information related to the incident, would be subject to the agencies’ confidentiality rules.”

Of course, with this new requirement, updating your incident response plan and business continuity plan will be required as well. One way to accomplish this would be by creating a new section in the plans, titled Primary Federal Regulator Notification.  This section would need to apply to any incident classification in the incident response plan, and any incident effecting the two statements (i and ii) above in the business continuity plan. Within those sections, then ask the three questions above to determine if notification is required and define the notification process.  And as with any update, it’s also important to test the plan afterwards to ensure the team is familiar with any changes. Please visit our Template Library for a copy Incident Response Plan and/or Business Continuity Plan boilerplates to address this new requirement.

The following is a non-exhaustive list of incidents that generally are considered ‘‘notification incidents’’ under the final rule:

  • Large-scale distributed denial of service attacks that disrupt customer account access for an extended period of time (e.g., more than 4 hours);
  • A bank service provider that is used by a banking organization for its core banking platform to operate business applications is experiencing widespread system outages and recovery time is undeterminable;
  • A failed system upgrade or change that results in widespread user outages for customers and banking organization employees;
  • An unrecoverable system failure that results in activation of a banking organization’s business continuity or disaster recovery plan;
  • A computer hacking incident that disables banking operations for an extended period of time;
  • Malware on a banking organization’s network that poses an imminent threat to the banking organization’s core business lines or critical operations or that requires the banking organization to disengage any compromised products or information systems that support the banking organization’s core business lines or critical operations from internet-based network connections; and
  • A ransom malware attack that encrypts a core banking system or backup data.

In addition to this article we would like to give you the opportunity to download the new rule. Click the button below to get the PDF.


Original article by Adam Reynolds CISSP. Lead Non-Technical Auditor, infotex

Interested in any of infotex’s services? Visit offerings.infotex.com to request information!


same_strip_012513


 

Latest News
    Another awareness poster for YOUR customers (and users).  Now that we have our own employees aware, maybe it’s time to start posting content for our customers! Check out posters.infotex.com for the whole collection! Download the large versions here: Awareness Poster (Portrait) Awareness Poster (Landscape)   You are welcome to print out and distribute this around […]
    The joint cybersecurity advisory includes the 15 most exploited vulnerabilities reported in 2021… An article review.  While a lot of attention is focused on previously undisclosed or “zero day” attacks, some of the most likely attack vectors are vulnerabilities that have been widely known for weeks or even months.  That’s according to a new joint […]
    Threats are changing, EDR can help us adapt . . . Today’s advanced persistent threat (APT) understands that the IT landscape has changed. In the post-COVID age, more and more organizations have adopted some form of work from home.  While WFH offers many conveniences, it also imparts increased risks. BitSight conducted a 2021 study of […]
    The Five Precepts of IT Vendor Management Webinar-Movie We’re going back to basics on Vendor Management. This webinar will give you a training tool to help out that new person that is starting to take on the gargantuan task that is Vendor Management.
    A new way of helping people “read” new guidance… Look for more in the future! To save you time, we are proud to present “Adam Reads” . . . recorded versions of our Guidance Summaries! Below you can find an embedded player for the audio file. If you are having issues with that working, you […]
    You think you’ve finally found stability in your to-do list. Your goals are set, and you’re even making great progress on them all. Audit findings: all addressed. Management requests: Under control. Heck, you might even be able to leave the office five minutes early at least once this year. Then BAM! A press release from […]
    Software Bill of Materials (SBOMs) are becoming more and more important. . . We are all very familiar with one aspect of the software supply chain – updates.  New features, bug fixes, and performance upgrades are a regular occurrence to any device’s lifecycle, however what if these kinds of updates also include deliberately malicious code? […]
    Another awareness poster for YOUR customers (and users).  Now that we have our own employees aware, maybe it’s time to start posting content for our customers! Check out posters.infotex.com for the whole collection! Download the large versions here: Awareness Poster (Portrait) Awareness Poster (Landscape)   You are welcome to print out and distribute this around […]
    According to a new survey, more organizations than ever are reporting problems with cybersecurity staffing… An article review. While pandemic related mandates and restrictions are gradually being lifted across the country, many organizations are still feeling the effects in one important area: staffing.  That’s according to ISACA’s annual State of Cybersecurity survey, which asked over […]
    Understanding Banking Trojans… Another Technical Article by Tanvee Dhir! What are Banking Trojans? A trojan is a malicious program that masquerades as a genuine one. They are often designed to steal sensitive information from users (login passwords, account numbers, financial information, credit card information, etc.). A banking trojan is a malicious computer program designed to […]