Executive Management – Compliance Guru

16 Jun 2022

Quick Bytes The Safe Systems Compliance Team 0 comment

FFIEC Cancels E-Banking Handbook

On May 13, 2022, the FFIEC very quietly rescinded the FFIEC Information Technology Examination Handbook (IT Handbook) booklet entitled E-Banking. The original booklet was released in 2003 and was accompanied by a flurry of activity by financial institutions to come up with a separate E-banking policy and risk assessment. In effect, the FFIEC is now declaring (admitting?) that these are no longer necessary because all the basic risk management principles that apply to E-Banking are already addressed in other Handbooks. Operational risk is addressed in the Business Continuity Management Handbook, information security risk is addressed in the Information Security Handbook, cyber risk is assessed in the Cybersecurity Assessment Tool, and third-party risk is addressed here, here, and here.

We agree with this approach, and have long held that separately addressing each new emerging or evolving technology was cumbersome, duplicative, and unnecessary. In our opinion, shifting the focus of the handbooks to basic risk management principles and best practices that can apply to all business processes makes more sense and is long overdue. Could the Wholesale and Retail Payment Systems handbooks be phased out next? How about the Cybersecurity Assessment Tool? Since cybersecurity is simply a subset of information security more broadly, could we see a phase-out of a separate cyber assessment? Or even better, could we see the Information Security Handbook include a standardized risks and controls questionnaire that includes cyber?

Admittedly this is only one less policy and one less risk assessment, but we’ll be watching this trend with great interest. Anything that can help ease the burden on overworked compliance folks is a welcome change!

01 Jun 2022

Ask the Guru The Safe Systems Compliance Team 0 comment

Have There Been Any Official Board Reporting Updates to the FFIEC InfoSec Handbook since 2016?

Hey Guru!

Do you have any additional blogs about FDIC changing the annual IT report to the board? I saw the article from 2012 and was wondering if there are any updates to that. Has the FFIEC updated its Information Security IT Handbook after 2016 in regard to this subject?
Thank you,
Lynn

Hi Lynn, and thanks for the question! We haven’t seen any official board reporting updates from regulators since the 2016 revision to the FFIEC InfoSec Handbook, most of what we’ve heard on this topic lately is anecdotal (e.g., feedback from recent IT audits and examinations). The popular consensus is that the volume of information expected to be communicated to the board has greatly increased. We believe it’s because of the relatively recent requirement for the board to provide a “credible challenge” to management, which requires more information on all aspects of information security. Combine that with the hyper-focus on cybersecurity, and “the buck stops with the board” mentality, and it’s almost impossible to imagine over-informing the board.

A bit of background on board reporting… the Examination Procedures section (Appendix A) of the 2016 FFIEC Information Security IT Handbook instructs examiners to:

Determine whether the board approves a written information security program and receives a report on the effectiveness of the information security program at least annually. Determine whether the report to the board describes the overall status of the information security program and discusses material matters related to the program such as the following:

Risk assessment process, including threat identification and assessment.
Risk management and control decisions.
Service provider arrangements.
Results of security operations activities and summaries of assurance reports.
Security breaches or violations and management’s responses.
Recommendations for changes or updates to the information security program

We feel that this is a decent framework assuming sufficient detail is added to each item, and the reporting is presented to the board in a manner in which they are most likely to understand it. Because each one is unique, that often means dialing the level of detail up or down depending on the specific comprehension level of your board.

We also recommend folks add a “Strategic IT Planning” section to the report, with updates on all significant IT initiatives, including how each of those initiatives aligns with enterprise-wide strategic goals and objectives.

You may also want to check out Appendix A, Objective 2 of the Management Handbook. Again, nothing new, but it does help define the broad scope of Board oversight from the examiner’s perspective. Remember, for every item listed in #2 of Objective 2, there must be one or more associated reports supporting the activity, and both the activity and the supporting documentation should be part of the board minutes:

Review the minutes of the board of directors and relevant committee meetings for evidence of board support and supervision of IT activities.

Wherever there is a lack of prescriptive guidance or there is room for interpretation in the guidance, risk managers must choose the path of least risk. For us, although the official guidance hasn’t changed recently, it’s much less risky to over-report information security activities to the Board than it is to under report. To date, we’ve never had an examiner criticize one of our customers for over-reporting!

29 Mar 2022

Ask the Guru, Vlog Tom Hinkel 0 comment

Vlog: Are Bank Regulators Considered Vendors?

In this special vlog installment of Ask the Guru, Tom Hinkel answers a question asked by an OCC bank examiner, “Are regulators considered vendors for banks?” Watch the video below to hear Tom’s thoughts on the matter.

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.

20 Oct 2020

Reading Between the Lines The Safe Systems Compliance Team 0 comment

Compliance Quick Bites – Tests vs. Exercises, and the Resiliency Factor

One of several changes implemented in the 2019 FFIEC BCM Examination Handbook is a subtle but important differentiation between a BCMP “test” and an “exercise”. I discussed some of the more material changes here, but we’re starting to see examiner scrutiny into not just if, but exactly what and how you’re testing.

According to the Handbook:

“An exercise is a task or activity involving people and processes that is designed to validate one or more aspects of the BCP or related procedures.”
“A test is a type of exercise intended to verify the quality, performance, or reliability of system resilience in an operational environment.”

Essentially, “…the distinction between the two is that exercises address people, processes, and systems whereas tests address specific aspects of a system.” Simply put, think of an exercise as a scenario-based simulation of your written process recovery procedures (a table-top exercise, for example), and a test as validation of the interdependencies of those processes, such as data restoration or circuit fail-over.

The new guidance makes it clear that you must have a comprehensive program that includes both exercises and tests, and that the primary objective should be to validate the effectiveness of your entire business continuity program. In the past, most FI’s have conducted an annual table-top or structured walk-through test, and that was enough to validate their plan. It now seems that this new differentiation requires multiple methods of validation of your recovery capabilities. Given the close integration between the various internal and external interdependencies of your recovery procedures, this makes perfect sense.

An additional consideration in preparing for future testing is the increased focus on resiliency, defined as any proactive measures you’ve already implemented to mitigate disruptive events and enhance your recovery capabilities. The term “resiliency” is used 126 times in the new Handbook, and you can bet that examiners will be looking for you to validate your ability to withstand as well as recover in your testing exercises. Resilience measures can include fire suppression, auxiliary power, server virtualization and replication, hot-site facilities, alternate providers, succession planning, etc.

One way of incorporating resilience capabilities into future testing is to evaluate the impact of a disruptive event after consideration of your internal and external process interdependencies and accounting for any existing resilience measures. For example, let’s say your lending operations require 3 external providers and 6 internal assets, including IT infrastructure, scanned documents, paper documents, and key employees. List any resilience capabilities you already have in place, such as recovery testing results from your third-parties, data replication and restoration, and cross-training for key employees, then evaluate what the true impact of the disruptive event would be in that context.

In summary, conducting both testing and exercises gives all stakeholders a high level of assurance that you’ve thoroughly identified and evaluated all internal and external process interdependencies, built resilience into each component, and can successfully restore critical business functions within recovery time objectives.