Hot Topics – Compliance Guru

18 Aug 2023

From the Field, Hot Topics, Resources The Safe Systems Compliance Team 0 comment

Third-Party Risk Management Final Guidance – An In-depth Analysis

Background

In July of 2021, the three primary bank regulators (OCC, FDIC, and Federal Reserve) proposed new guidance on third-party risk management (TPRM). According to the agencies, “The proposed guidance provides a framework based on sound risk management principles that banking organizations may use to address the risks associated with third-party relationships.” In June of 2023 all three (OCC, FDIC, Federal Reserve) jointly adopted the final guidance, stating that: “The final guidance offers the agencies’ views on sound risk management principles for banking organizations when developing and implementing risk management practices for all stages in the life cycle of third-party relationships.” The agencies issued this simultaneously to “promote consistency in supervisory approaches”, something we fully support and have long advocated. It replaces each agency’s existing guidance on this topic and is applicable to all banking organizations supervised by the agencies (currently all financial institutions except credit unions).

Analysis

Since third-party relationships represent a significant amount of residual enterprise-wide strategic, operational, and information security risk to many financial institutions (we refer to this as the ‘inherited risk’), and because we believe regulators will greatly increase their scrutiny of your risk management efforts in this area, we’ve taken the last couple months to take a deep dive into the details of the guidance, and the potential implications to your TPRM program. The following is a summary of our observations.

The agencies are advising a 5-step continuous life-cycle, wrapped in a formal, 3-phase governance process:

Each of the 5 phases consists of one or more sections, each of those with one or more statements:

Planning – 1 section, 11 statements

Due Diligence & Third-Party Selection – 14 sections, 40 statements

Contract Negotiation – 17 sections, 61 statements

Ongoing Monitoring – 1 section, 14 statements

Termination – 1 section, 6 statements

and

Governance – 3 sections, 29 statements

In total, there are 161 statements to evaluate, and they range from what we’ve interpreted as strong recommendations (“It is important for contracts to stipulate…”), to what we’ve determined are general observations and best practices (“May want to consider whether the contract…”).

Implications

In addition to factoring the “must have vs. nice to have” interpretation of each statement into the analysis, institutions will also need to determine the applicability of each individual statement to your organization. No fewer than 13 times in the guidance they mention some variation of “…commensurate with the banking organization’s risk appetite and the level of risk and complexity of its third-party relationships.” This is the applicability filter through which your “implement/do not implement” determination will pass. Simply put, although you should be familiar with each statement and its implications, you may not necessarily need to adopt them all. Indeed, if you currently have and maintain a compliant third-party management program, many are very likely already in place.

However, the single most important take-away for us is how the statements are distributed throughout the sections, which we believe give a pretty good indication of how the regulators will evaluate your TPRM program on the exam side. The vast majority (~70%) of statements are clustered in what can be referred to as “pre-engagement” phase, or before you formally engage (by contract or otherwise) with the third-party; the Planning, Due Diligence and Contract phases:

Does this mean that ~70% of your third-party management efforts going forward should be pre-engagement? We think that is a reasonable assumption, and we anticipate that sooner or later the regulators will also align their expectations in that direction. And since most compliant TPRM programs very likely already address the On-going Monitoring and Governance areas, the biggest challenge for most folks will be:

Evaluating each of the 112 statements in this pre-engagement phase, and determining,

Whether the statement is already addressed somewhere in your current program,

If not, deciding whether or not to implement it given the criticality, complexity, and nature of the service(s) provided by the third-party given your risk appetite.

Pre-engagement vs. Pre-initiative

Although significantly expanded here, due diligence and contract considerations have, to a greater or lesser degree, always been in place. However, the biggest challenge for most institutions will be in the Planning phase. There are only 11 statements in this section, but they all address the risks of the business initiative itself, NOT the third-party! These statements include items such as:

“Understanding the strategic purpose of the business arrangement…”

“Identifying and assessing the benefits and the risks associated with the business arrangement…”, and
“Considering the nature of the business arrangement…”

While most folks would consider these types of strategic (“why” instead of “how”) discussions to be beyond the scope of a traditional TPRM program, it is clear that regulators are certain to look for them going forward. Make sure to build this pre-initiative “why” phase into your program.

Summary

As with all things in the compliance space, be sure to document your entire decision-making process and don’t hesitate to reach out to our experts for assistance. As the guidance also states, “A banking organization may involve experts across disciplines, such as compliance, risk, or technology, as well as legal counsel, and may engage external support when helpful to supplement the qualifications and technical expertise of in-house staff.”

The agencies have indicated that they plan to develop additional resources to assist smaller, less-complex community banking organizations in managing relevant third-party risks, and we’re keeping an eye on this. In the meantime, we have created an interactive tool that lists all sections and statements, allows you to acknowledge each statement, add your notes, and track your overall progress. Click here for a copy.

We also offer a complimentary high-level regulatory compliance evaluation of your existing vendor management program. Click here to request more information.

We will be hosting an in-depth webinar and analysis on this new guidance on September 20^th. A registration link will be available on our webinar page within the next week.

21 Mar 2023

Hot Topics The Safe Systems Compliance Team 0 comment

The State of the (Credit) Union According to the NCUA Chairman

Last month, NCUA chairman Todd M. Harper delivered his “State of the (Credit) Union” during the 2023 Governmental Affairs Conference. Harper covered multiple areas of interest to credit unions including:

The State of the Credit Union System
Credit Risk
Interest Rate Risk
Liquidity Risk
Consumer compliance
Minority institutions, and
Community development

But in this post, we’ll focus on 3 topics directly related to information security: cybersecurity risk, the need for centralized vendor authority, and Fintechs.

Cybersecurity Risk – Ransomware, social engineering, phishing, and other known risks continue to keep him (and many CU admins and ISO’s) awake at night, but the unknown threats are the biggest concern. He encourages CU’s to continue to assess their cyber threats and control maturity levels by utilizing the Automated Cybersecurity Evaluation Toolbox. The NCUA also recently approved the new cyber incident notification rule that sets parameters for what constitutes a reportable incident, and the minimum notification requirements.

Vendor Authority – Unlike the other federal regulators, the NCUA does not have the ability to examine significant third-party providers. Called the Report of Examination (or RoE) by the FDIC, OCC, and Federal Reserve, this report is very similar to the IT examination that non-CU depository financial institutions undergo. In fact, it is based on the exact same FFIEC URSIT methodology. Chairman Harper strongly believes that the NCUA should be granted the authority to supervise credit union service organizations and key vendors.

Financial Technology – This is closely related to vendor authority; the chairman believes critical third-party Fintechs have insufficient oversight by regulators, and that the agency should have the ability to enforce Fintech compliance with laws and regulations. This is largely consistent with what the Treasury Department recommended late last year.

The chairman also referred to recent changes in how the NCUA will conduct examinations. A summary of those changes is here. Simply put, this new supervisory initiative will be tailored to your credit union’s size and complexity.*

When you consider the pending third-party risk management guidance expected to drop later this year, it would seem there is rapidly becoming a regulatory consensus on the need for increased scrutiny of third-parties providing services to financial institutions. This is an area we are watching closely, and proactive Credit Union information security officers should plan to prepare for deeper dives by the NCUA into how they are managing their significant third-parties as well.

* Perhaps ironically, this “size and complexity” approach also provides the most effective defense against examination findings that may apply to larger CU’s, but not necessarily smaller institutions.

06 Dec 2021

Hot Topics The Safe Systems Compliance Team 0 comment

UPDATE – New Proposed Cyber Incident Notification Rules Finalized

Last updated March 30, 2022.

Currently, financial institutions are required to report a cyber event to their primary federal regulator under very specific circumstances. This requirement dates back to GLBA, Appendix B to Part 364 and states that FI incident response plans (IRP’s) should contain procedures for: “Notifying its primary Federal regulator as soon as possible when the institution becomes aware of an incident involving unauthorized access to or use of sensitive customer information…”. Customer notification guidance is very similar. Institutions should provide notice to their customers as soon as possible: “If the institution determines that misuse of its information about a customer has occurred or is reasonably possible.” (It’s important to note here that a strict interpretation of “…access to or use of…” would generally not include a denial of access (DDoS) type of attack, or a ransomware attack that locks files in place. We strongly suggest modifying the definition of “misuse” in your incident response plan to say “…access to, denial of access to, or unauthorized use of…”.) However, with the issuance of the final rule (officially called “Computer-Security Incident Notification Requirements for Banking Organizations and Their Bank Service Providers”) institutions will have additional considerations that will require changes to your policies and procedures.

Background

Late in 2020 the FDIC issued a joint statement press release with the OCC and the Federal Reserve announcing the proposed changes. As is the case for all new regulations, they were first published in the Federal Register, which started the clock on a 90-day comment period, which ended on April 12 of 2021. (We took an early look at this back in July.)

The new rule was approved on November 2021 by the OCC, Federal Reserve, and FDIC¹ collectively, with a proposed effective date of April 1, 2022, and a compliance date of May 1, 2022. Simply put, it will require “…a banking organization to provide its primary federal regulator with prompt notification of any “computer-security incident” that rises to the level of a “notification incident.”

To fully understand the requirements and new expectations of this rule, there are actually three terms we need to understand; a computer security incident, a notification incident, and “materiality”.

Keys to Understanding the New Rule

A computer-security incident could be anything from a non-malicious hardware or software failure or the unintentional actions of an employee, to something malicious and possibly criminal in nature. The new rule defines computer security incidents as those that result in actual or potential harm to the confidentiality, integrity, or availability of an information system or the information the system processes, stores, or transmits.

A notification incident is defined as a significant 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.

The third term that needs to be understood is “materiality“. This term is used 97 times in the full 80 page press release, so it is clearly something the regulators expect you to understand and establish; for example, what is a “material portion of your customer base”, or “material loss of revenue”, or a “material disruption” of your operations? Unfortunately the regulation does not provide a universal definition of materiality beyond agreeing that it should be evaluated on an enterprise-wide basis. Essentially, each banking organization should evaluate whether the impact is material to their organization as a whole. This would seem to suggest that these material threshold levels would need to be defined ahead of time, perhaps as a function of establishing Board-approved risk appetite levels or perhaps it could be tied to the business impact analysis? Future clarification may be necessary on the best approach to establishing the determination of materiality in your organization, but since the term is at the centerpiece of the rule, and initiation of the 36 hour threshold for notification doesn’t begin until it has been established, we can definitely expect materiality to be a part of the discussion in the event of regulator scrutiny in this area.

Any event that meets the criteria of a notification incident would require regulator notification “as soon as possible”, and no later than 36 hours after you’ve determined that a notification event has occurred. It’s important to understand that the 36 hour clock does not start until there has been a determination that the incident has been classified as a notification event, which only happens after you’ve determined you’ve experienced a computer-security incident.

The Safe Systems Compliance Team has created a detailed decisioning flowchart to assist with your understanding of this new rule. Click here for a copy of the flowchart.

Notification 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.” No specific information is required in the notification other than that a notification incident has occurred. The final rule also does not prescribe any specific form or template that must be used, and there are no recordkeeping requirements beyond what may be in place if a Suspicious Activity Report (SAR) is filed in connection with the incident. The agencies have all issued additional “point-of-contact” guidance:

For FDIC institutions:

Notification can be made to your case manager (your primary contact for all supervisory-related matters), to any member of an FDIC examination team if the event occurs during an examination, or if our primary contact is unavailable, you may notify the FDIC by email at: incident@fdic.gov.

For OCC Institutions:

Notification may be done by emailing or calling the OCC supervisory office. Communication may also be made via the BankNet website, or by contacting the BankNet Help Desk via email (BankNet@occ.treas.gov) or phone (800) 641-5925.

For Federal Reserve Institutions:

Notification may be made by communicating with any of the Federal Reserve supervisory contacts or the central point of contact at the Board either by email to incident@frb.gov or by telephone to (866) 364-0096

One final note, we’ve received indications that at least some State Banking regulators will require concurrent notification of any incident that rises to the level of a notification incident. Check with your State regulators on if (and how) they plan to coordinate with this new rule.

Third-party Notification Rules

In addition to FI notification changes, there will also be new expectations for third-party service providers, like core providers and significant technology service providers (as defined in the BSCA). Basically, it would require a service-provider to “…notify at least one bank-designated point of contact at affected banking organization customers immediately after experiencing a computer-security incident that it believes in good faith could disrupt, degrade, or impair services provided subject to the BSCA for four or more hours.”

Furthermore, if you are notified by a third-party that an event has occurred, and the event has or is likely to result in your customers being unable to access their accounts (i.e. it rises to the level of a notification incident), you would also be required to report to your regulator. However, it’s important to note here that not all third-party notification incidents will also be considered bank regulator notification incidents. It is also significant that the agencies will most likely not cite your organization because a bank service provider fails to comply with its notification requirement, so you will likely not be faulted if a third-party fails to notify you.

Next Steps

There will undoubtedly be clarification on the specifics of rule implementation as we digest feedback from regulatory reviews next year, and we’ll keep you posted as we know more. In the meantime, aside from having internal discussions about what constitutes “materiality” in your organization, the new rules will likely also require some modifications to your Incident Response Plan (IRP), and possibly to key vendor contracts. For FDIC institutions, the “as soon as possible” regulator notification provisions of FIL-27-2005 already in your IRP will have to be amended. For all critical vendors, ensure that contracts contain verbiage committing them to the 4 hour outage criteria for notification, and that you’ve identified a contact person or persons within your organization to receive the alert.

¹ As of this date the NCUA has not signed off on these rules, although they may at some point.

22 Jul 2021

Hot Topics The Safe Systems Compliance Team 0 comment

New Proposed Cyber Incident Notification Rules

Update: Since publishing this post, these rules have been finalized. We have a new post covering those details here.

We first wrote about incident notification over ten years ago, and based on feedback from our cyber testing experience, financial institutions are still struggling with the issue of whether or not to notify their customers and primary regulators. The conversation often comes down, to “do we have to notify?” Some institutions may choose to notify out of an abundance of caution, but most won’t unless it’s absolutely required, as regulator notification opens the door to additional examiner scrutiny, and customer notification may result in increased reputation risk. To confuse the issue a bit more, notification requirements are currently defined differently for a regulator than for a customer. And all this is about to change!

Notification Rules Background

Financial institutions are currently required to report an event to their primary federal regulator under very specific circumstances. This requirement dates back to GLBA, Appendix B to Part 364 and states that FI incident response plans (IRPs) should contain procedures for: “Notifying its primary Federal regulator as soon as possible when the institution becomes aware of an incident involving unauthorized access to or use of sensitive customer information…”

Customer notification guidance is very similar. Institutions should provide notice to their customers as soon as possible: “If the institution determines that misuse of its information about a customer has occurred or is reasonably possible.” (It’s important to note here that a strict interpretation of “…access to or use of…” would generally not include a denial of access (DDoS) type of attack or a ransomware attack that locks files in place. We suggest modifying the language of “misuse” to “…access to, denial of access to, or use of…”.)

Announcement of New Proposed Notification Rules

Late last year the FDIC issued a joint press release with the OCC and the Federal Reserve¹ announcing the proposed changes. The working title is a mouthful: Computer-Security Incident Notification Requirements for Banking Organizations and Their Bank Service Providers. As is the case for all new regulations, the proposed notification rules were first published in the Federal Register, which started the clock on a 90 day comment period that ended on April 12 of this year. When (or if) the rules will become law will depend on how long it takes regulators to compile, digest, and reconcile the comments received, which can take as long as 6 months to a year from the end of the comment period.

3 Key Terms of the New Regulator Notification Rule

One of the new rules “…would require a banking organization to provide its primary federal regulator with prompt notification of any computer-security incident that rises to the level of a notification incident.” There are actually three terms we need to understand here: a computer security incident, a significant security incident, and a notification incident.

A computer security incident could be anything from a non-malicious hardware or software failure or the unintentional actions of an employee to something malicious and possibly criminal in nature. Computer security incidents are those that:

Result in actual or potential harm to the confidentiality, integrity, or availability of an information system or the information the system processes, stores, or transmits; or
Constitute a violation or imminent threat of violation of security policies, security procedures, or acceptable use policies.

In addition to the GLBA NPI guidance, banking organizations are already required to report certain instances of disruptive cyber-events and cyber-crimes through the filing of Suspicious Activity Reports (SARs) within 30 days, but no regulator notification is required unless these criteria are met. Even so, if notification is provided, the concern is that the 30-day window may not be timely enough to prevent other events.

This new rule would define a significant computer security incident as one that meets any of these criteria:

Could jeopardize the viability of the operations of an individual banking organization
Result in customers being unable to access their deposit and other accounts
Impact the stability of the financial sector

The proposed rule refers to these significant computer security incidents as notification incidents — the two terms are synonymous, so any event that meets the above criteria would require regulator notification “as soon as possible”, and no later than 36 hours after you’ve determined that a notification event has occurred.

We’ll see what the final rules look like, but at the moment there are no proposed changes to the customer notification requirements.

New Third-Party Expectations

In addition to FI notification changes, there will also be new expectations for third-party service providers, like core providers and significant technology service providers (as defined in the BSCA). Because these vendors are “…also are vulnerable to cyber threats, which have the potential to disrupt, degrade, or impair the provision of banking services to their banking organization customers,” it would require a service-provider to “…notify at least two individuals at affected banking organization customers immediately after experiencing a computer-security incident that it believes in good faith could disrupt, degrade, or impair services provided subject to the BSCA for four or more hours.” Presumably, if you are notified by a third party that an event has occurred, and the event has or is likely to result in your customers being unable to access their accounts, you would also be required to report to your regulator.

Reviewing the submitted comments, there are still many questions to be answered and terms to be clarified, but with cybersecurity dominating the news recently we can definitely count on regulatory changes to the “do we have to notify?” discussion coming fairly soon.

¹ As of this date the NCUA has not signed off on these proposed rules changes, although they may at some point.

12 Nov 2020

Hot Topics The Safe Systems Compliance Team 0 comment

Hot Topic: Ransomware on the Radar (Updated)

Both the State banking regulators and the Treasury Department have issued recent advisories to financial institutions regarding the ransomware threat. Ransomware is defined as a form of malicious software (“malware”) designed to block access to a computer system or data, often by encrypting data or programs, in order to extort ransom payments from victims in exchange for decrypting the information and restoring victims’ access to their systems or data. In some cases, in addition to the attack, the perpetrators threaten to publish sensitive files belonging to the victims, which can be individuals or business entities affiliated or associated with the financial institution.

US Department of the Treasury

First, the Treasury, via the Office of Foreign Assets Control (“OFAC”) and the Financial Crimes Enforcement Network (“FinCEN”), issued a pair of advisories in early October. FinCEN provided general information about the threat of ransomware and the existing requirements for filing Suspicious Activity Reports (SAR’s) for any ransomware payments conducted by, at, or through the financial institution. Because most ransomware demands involve bitcoin (also referred to as “convertible virtual currency” or CVC), conversion of the bitcoin into funds and transmitted via the ACH, wire, or credit card networks, institutions facilitating the transactions may run afoul of anti-money laundering and/or anti-terrorism laws.

In a related advisory, OFAC reminded institutions of the risks (i.e. sanctions and financial penalties) associated with facilitating ransomware payments on behalf of victims targeted by malicious cyber-enabled activities. Taken together, the two advisories discourage financial institutions from participating in transactions involving ransomware payments. Although this may seem like common sense, the increasing use of cyber insurance to control the financial risks of ransomware may remove the institution from being in the driver’s seat when it comes to negotiating with the ransomware perpetrators. Many (if not most) cyber insurance carriers require that, in order to cover a potential claim from a cyber event, they be notified early in the event, and that they take the lead role in any negotiations with the perpetrators. The FinCEN advisory also reminds institutions that any payments negotiated by third-parties on behalf of the institution remain the responsibility (i.e. liability) of the institution.

State Bank Regulators

Finally, starting this past October we’ve seen multiple occurrences of a Ransomware Self-Assessment Tool (R-SAT) being delivered to financial institutions subject to State oversight (i.e. all state chartered institutions). Developed by the Bankers Electronic Crimes Task Force, State Bank Regulators (CSBS), and the United States Secret Service, the R-SAT was created “…to help financial institutions assess their efforts to mitigate risks associated with ransomware and identify gaps for increasing security.” Although the email accompanying the document states that “…The tool does not establish new regulatory expectations,” institutions are being advised to complete the 16 question assessment and be prepared to discuss it with the state examiners at their next visit. (Although there are only 16 questions, most have multiple components, making the actual number of required responses closer to 60 – 65.)

This is causing confusion among many institutions, because anything requiring completion prior to an examination essentially becomes a defacto requirement. So how should institutions react to this new assessment? Is there anything new to be gained by completing this assessment that may justify the additional time commitment?

Since this is very new, we’ve reached out to IT auditors as well as our regulatory contacts at the state and federal level to get their opinions. It appears that the intention is to possible expand usage of this assessment beyond State examiners, as the document states that “This could also assist other third parties (such as auditors, security consultants and regulators).” So far though, the auditors and federal level examiners appear to be blindsided by this as well, so more to come on that, but our initial impression is that the questionnaire seems more of a conversation starter about ransomware best practices as opposed to a prescriptive checklist of “must-do” items. Indeed, the document is organized around the five functions of the NIST Cybersecurity Framework; Identify, Protect, Detect, Respond, and Recover.

Next Steps

Regarding the OFAC advisories, you and your cyber insurance company need to be aware that if they are involved in facilitating ransomware payments on your behalf, you must also consider whether you may be in violation of regulatory obligations under Financial Crimes Enforcement Network (FinCEN) regulations on payments to specially designated nationals. Our experience is that most cyber insurance carriers are not up to speed with current guidance, potentially putting you at risk.

Regarding the R-SAT, until we receive more feedback from the field, our position is that (as with everything else) taking a risk-based approach is best. That means completion of this document should be “optional” IF:

If your existing information security risk assessment already identifies all reasonably anticipated risks and threats and associated controls, then ransomware is already addressed. (Ransomware is simply one malware threat in the cyber-threat universe.)
If you’ve been completing the FFIEC CAT each year, you should have a pretty good idea of your risks and controls (including protective and detective), and how they’ve been trending over the past few years.
If you’ve been conducting a gap analysis based on the results, you’ve already addressed any misalignments between your current cyber risk profile and your desired profile. (In fact, question #2 on the R-SAT asks, “Has a GAP analysis been performed to identify controls that have not been implemented but are recommended in the standards and frameworks that you use?”)
If your Incident Response Plan has expanded the definition of “misuse of data” to include not just unauthorized access to data, but also unauthorized denial of access to data.
And finally, if your BCMP assesses the probability and impact of destructive malware, and if you’ve been periodically incorporating a ransomware scenario into your annual BCMP and Incident Response testing exercises, you’ve already validated your ability to respond and recover from a ransomware attack.

Our advice would be to consider completing the R-SAT if you feel you haven’t adequately addressed ransomware elsewhere, and then only as a stopgap until you’ve enhanced your InfoSec risk assessment, your BCMP and Incident Response Plans, and conducted a cybersecurity gap analysis. But if you’ve already checked those boxes, (and unless you have extra time on your hands) we strongly recommend calling the state examiner’s attention to your existing and on-going cyber threat identification, detection, response and recovery efforts, and leave it at that.

UPDATE

We reached out to, and have heard back from, a State examiner on how they intend to utilize the R-SAT. Here is a summary of their reply:

“…we intend to use this as a consultative tool in appropriate situations with our banks and credit unions.”
“…we will not be requiring compulsory use.”
“We are hoping that the conversations with institutions will entail questions/conversations such as “have you looked at it”, “do you find it helpful”, “these are items that can enhance your current process.”
“We do believe that most of this should already be in place from an incident management and business continuity stand point.”
The approach outlined in this article is “consistent with their thoughts.”

All State examiners may not have the exact same approach, so we’ll continue to update this as feedback comes in.

(Note: As stated earlier, we are awaiting more feedback from examiners and auditors in the field, so you may want to bookmark this page and check back periodically for any updates.)

11 Mar 2020

Hot Topics The Safe Systems Compliance Team 0 comment

FFIEC Issues Statement on Pandemic Planning

Background

Similar to the Joint Statement on Destructive Malware issued in January in response to heightened geopolitical cyber risks from foreign actors, the FFIEC just released an Interagency Statement on Pandemic Planning in response to the current COVID-19 epidemic. Similar to the Destructive Malware statement, this statement does not impose any additional regulatory expectations on financial institutions, it’s intended instead to “…remind financial institutions that business continuity plans should address the threat of a pandemic outbreak and its potential impact on the delivery of critical financial services.” It is actually an update to the 2007 Interagency Statement on Pandemic Planning, which was in response to the H5N1 epidemic in 2006. This release seems to be part of a consistent pattern with all recent statements, they are reactive in nature and serve to put already existing expectations and best practices into the context of current events.

Pandemic events pose unique challenges to financial institutions. They don’t target infrastructure or technology-based interdependencies, but instead impact another critical asset; the employee. The only change since the 2007 statement is that many institutions are even more dependent today on third-parties for support and delivery of critical services. This makes evaluation of third-party Pandemic contingency planning more important now. Of course other areas have changed for the better. Electronic banking is more available (and more utilized) now than in 2006, so most customers have account access without having to physically access one of your branches.

Pandemic and your Business Continuity Strategy

As you evaluate your current BCM for Pandemic-related elements, the statement suggests your current BCM plan should provide for:

A preventive program

Monitoring of potential outbreaks
Educating employees
Communicating and coordinating with critical service providers and suppliers
Providing appropriate hygiene training and tools to employees.

A documented strategy to scale your response to the current 6-stage CDC framework:

Plan on maximum absenteeism (as high as 40%) during the peak and immediately following the Acceleration phase (phase 4).

Specific facilities, systems, and procedures designed to provide continuation of critical operations in the event that large numbers of staff are impacted by the event.

Social distancing to minimize staff contact
Telecommuting
Redirecting customers from branch to electronic banking services
Conducting operations from alternative sites
Consideration for the impact of customer reactions and the potential demand for, and increased reliance on, online banking, telephone banking, ATMs, and call support services.

A testing program designed to validate the effectiveness of the facilities, systems, and procedures identified.
An oversight and update program to continually monitor and adjust your Pandemic program.

The Business Impact Analysis & Risk Assessment

As we mentioned in an earlier post, the new BCM Handbook eliminated the separate Pandemic section, but this statement makes it clear that regulators still expect institutions to assess Pandemic alongside all other reasonably foreseeable threats. Both your Business Impact Analysis (BIA) and your Risk & Threat Assessment should incorporate the potential effects of Pandemic. The BIA should take a non-threat specific approach to essential processes and functions, allowing you to identify interdependencies among critical operations, departments, personnel, services, and the processes and functions with the greatest exposure to interruption. Make sure you’ve included critical employees and third-parties in your impact analysis, and that the end result is a prioritization of business processes.

The risk assessment is where specific threats are identified, analyzed, and ranked according to impact and probability. The end result of this analysis should provide a listing of disruptive events by severity. Events with high impact and high probability are considered high severity and should receive top priority for resource allocation, and should also be tested more frequently. Pandemic is typically considered a low probability, high impact event, but during phases 3 & 4 may need have to have probability reevaluated. Doing so may result in a temporary assessment of high probability / high impact, allowing management to properly prioritize resource allocation in preparation for, and in response to, the Pandemic event.

Tests and Exercises

Finally, make sure to use the results of both the BIA and the risk assessment to inform your testing exercises. Make sure exercises validate your succession planning and cross-training by purposely excluding certain key individuals from active participation in the exercise. There will likely be a high reliance on remote access telecommuting during both the early stages (2 & 3) of the event, as well as the latter reactive stages (4 & 5). Have you identified employees with job duties capable of being performed remotely, and tested their remote access capabilities, including sufficient capacity, bandwidth, and authentication mechanisms? Do their remote access devices meet your current security standards, including AV/Anti-malware status and patch levels? Have you validated your call-trees and communication plans, including with critical third-parties? Are your employees versed in communicating a consistent message to customers during the event?

As of the date of this post, we’re somewhere between a phase 3 and phase 4. Financial institutions should use this Interagency Statement not just as a reminder of pandemic best practices, but as a clarion call to revisit their entire BCM and reevaluate all aspects of your resilience and recovery planning.

12…19 Next →