Webinar: Establishing Operational Resiliency for the New Computer Security Incident Rule and Beyond

This informative webinar by our experts examines the new joint rule regarding computer security incidents notification requirements for banking organizations and their bank service providers. Topics of discussion include:

• The rise in incidents and notification requirements in the US financial system
• Highlights of the new joint rule
• Specifics of the new joint rule
• Integration with other notification regimes
• Operational resilience and business continuity
• How to comply by May 1, 2022 

*Read the full webinar transcript below.

Introduction

Thank you for joining our webinar on establishing operational resiliency for the new computer security incident role and beyond. Today, we’ll examine the new joint rule regarding computer security incidents notification requirements for banking organizations and their bank service providers. I’m pleased to introduce Kayvan Alikhani, co-founder and CEO of compliance AI, to get us started.

Kayvan Alikhani (Kayvan)

Thank you so much Ronjini. I’m pleased to introduce my co-panelists, Michael Delune coming with extensive experience both as a general counsel compliance officer and law professor and Rick Dupree with strong and extensive experience in risk within the financial sector. Thank you so much for joining me. There is a impending or imminent rule going into effect in the next couple of weeks which is a joint effort by the Fed, the Treasury, OCC and the FDIC, collaborating on a new set of requirements around incident reporting that organizations specifically within the banking and financial sector need to follow.  

What led to this rule? What does this mean? What are the specifics? How does this contrast and compared to other notification protocol standards and regimes that already exist in various jurisdictions? And finally, how can you as a financial service organization, be compliant with this requirement? What does this mean to you? And of course, the May 1 deadline.

So starting off, there’s a Bank Secrecy Act already in place. In it, there’s a pretty straightforward definition of guidance for response programs for unauthorized access to any customer information. We’ve had that on the books for a while, and it basically requires a set of awareness that needs to be provided to agencies when certain incidents occur. But apparently, the BSA Act was not sufficient. What was not covered is all computer security incident reporting requirements for the agencies and the supervisory requirements that need to be alerted as a result thereof. 

So, Rick, what changed? What changes happened in terms of incidents and the patterns that led to this rule? What type of incidents are driving this new rule?

Rick Dupree (Rick)

Well, as you mentioned, there’s already an ecosystem of notification requirements across multiple regs and laws, BSA being one, FinCen with respect to certain reporting, anyway. And, of course, at the state levels which we’ll get into more of this detail later. A lot of the privacy requirements, data breach, notification requirements are primarily around PII data, etc. So, in my opinion, there’s two drivers here. There’s an actual increase in fincrime globally, with cyber, by far, leading the way. Ransomware is a particular concern, DDoS attacks, those types of entity level attacks, where you don’t have to bring down entire systems. You may have seen in the news recently Israel had its largest DDoS attack in history. Then an increased reliance on vendors and the concentration risk across critical vendors, not only at individual institutions, but at an industry level as well, such as cloud etc. Additionally, there are the targeted attacks and an increase in targeted attacks of these critical vendors, which we call supply chain attacks.

So that’s A, then B is because of all this. I think due to all the other notification requirements that you referred to, there is a growing concern from the regulators that financial services institutions are under reporting incidents, and not necessarily because it’s intentional, but because it’s so complex, and there’s so many requirements. So what they’re doing is creating that obligation here [in this new joint rule], which is a bit of a catch 22. As you have increasing requirements for notification, you’re going to have increased notifications in addition to the ecosystem of existing notification requirements. This introduces a lot of operational complexity within your organization, especially if you look at all the different silos of notification requirements, whether it’s legal or compliance or risk or what have you. And that really introduces this operational complexity, which impacts potentially downstream operational resilience as well as business continuity. So, again, I think it’s two driving factors here. One is just the true increase in financial crime, and two, it is just regulators not having a high level of satisfaction that regulated firms are reporting what they should be reporting.

Michael Delune (Michael)

Okay, I’m just setting out the way that I perceive this rule which is that it really exists at the intersection between two existing trends. One of them is the increased scrutiny over financial crimes and the broadening of the definition to also include cyber crimes over financial institutions. Also, something that I’ve seen directly with our regulators, is an increase in interest and incident management practices. And I’m even going to define it more broadly as issue management practices. And if you look at the rule and the purpose of this rule, it plugs right into those those two topics.

Kayvan

Speaking of rules, this is not the first time we’re taking a stab at this. I remember during the Obama administration walking down the memory lane, and 2014 ’15, and ’16, the formation of the Cybersecurity Alliance, the private sector, cybersecurity, information sharing executive order that was put out in 2015 really talking about, hey, this information needs to be shared more of like a carrot incentive. We’re all in this together. There’s no competitive advantage in hiding your breach or not hiding your breach, the more everybody knows, the more everybody would benefit. And of course, there were very specific guidelines provided by the cybersecurity infrastructure security agency or CISA. Around this topic, Michael, why this and why now? What does this mean? What are the keys? Start with the highlights? And what challenges do businesses face in complying with this new rule? And how would you compare and contrast this to what’s already available?

Michael

Let me start with a high level of the rule. And we’re going to get into the details of the rule, but my elevator speech would be that simply the regulator’s wants to become aware of certain incidents that may impact either a specific bank or the financial system as a whole short kind of establishes this notification requirements to get to that objective to notify the regulators. And then you might wonder, well, what, what are they going to do with the information once they do receive it? They’ve been pretty open and have a stated purpose. There’s a few of those actually. First, they want to have early awareness of incidents, which will be especially true if it’s going to turn into a systemic incident that will impact the financial system. They want to improve their threat assessment capabilities. They also want to have enough information to issue alerts to financial institutions of emerging threats and emerging incidents. For anyone working at a financial institution, you probably have experienced receiving those notices from the regulators, such as viruses, threats, and so on. And there is also an effort by the regulators to encourage participation with the OCC IP program. I think it’s time for the Office of Cybersecurity and Critical Infrastructure Protection, an agency which is able to offer certain technical and other assistance to financial institutions, once approved by the regulators in the event of a major event. So we’re kind of plugging into that effort as well. And quite frankly, they’re also going to use it simply for data collection, just so that they can be more informed about what the existing trends are. That, in turn, dictates governance and impacts their own rule making initiative. So looking at some of the key dates, here, we have two (April 1, 2022 and May 1, 2022) dates. And why do they have two days? The only day that truly matters is May 1 2022, in the realm of regulations, and this was issued back in November, 2021. This is fairly short notice. I think that this is partially indicative of the regulator’s perspective that implementing this rule should not present a heavy burden on financial institutions. But I don’t want to understate this either. I think that there are still some significant challenges in adopting the rules and truly implementing them from an operation standpoint. You have to, for example, identify who your bank service providers are. You have to give them notice of whom to contact. You’ll need to adopt and amend policies and procedures. So there’s kind of a larger picture to be considered there, and that can take some time. 

Rick

If I can add to that, I think we’ll touch on this later as Michael hits on a point that is important. A lot of people who have read the ruling and the dates, this is atypical with respect to the finalization of the rule versus implementation of it, and effective date and compliance date, the very short window here. And to Michael’s point, if the regulators understand that most regulated firms have issues, management practices in place, and notification processes, they wrote that rule in a way to align a lot of the verbiage, such as how you define incidents, in those existing requirements. But also to Michael’s point, and this is what concerns me in particular, is just the operational risk associated with just adding more and more notification requirements that aren’t exactly the same as the other notification requirements. I mean, in spirit, some of them are, well, they’re all similar in spirit, but the actual operationalizing exam is going to be a challenge, I think, for a lot of firms.

Kayvan – POLL QUESTION

Absolutely, and I think right now, going from here, it’ll be interesting what readiness people have in regards to reporting security incidents? So, to poll our audience, which of these issues are top of mind for your organization? Or are you just very much ready to go? Or you just like the level of risk and the adrenaline rush of not caring about any of it. Looking forward to getting answers on this.

Thankfully, nobody’s laughing in the face of danger. With some emphasis, of course, on cybersecurity and privacy, followed by resiliency. Thank you for that. And as we take a deeper look at this rule coming in, who should care? What organization is truly being addressed or the subject of this rule? Maybe you can walk us through that? 

Michael

Sure. Happy to do so by the way. I was just observing the poll results, and it seemed relatively evenly distributed. And I think that makes sense. Because I was thinking to myself, well, which one is the most important to me? And I think they’re all equally important. Reminds me of my children, when they asked me, “who do you love the most Dad?” and I love them all the same. So I think that makes sense. Because all three of those topics are at this point in this day and age, quite equally important.

With respect to the coverage of the rule, we have the three major federal prudential banking regulators that issued the rule. So we have the Federal Reserve, the OCC and the FDIC. And with that, comes all the types of institutions that are subject to their jurisdiction, which include national bank, savings associations, US branches and agencies of foreign banking organizations, agile at corps, and holding companies sit in long holding companies, state banks, etc. It doesn’t matter if you are a member or a non member bank, you’re subject to the rule. Somewhat conspicuously absent from coverage, by the way, would be credit unions. It’s not unusual for the NCUA, which oversees credit unions into join these types of rule making. But this time around, they opted not to join. Unfortunately, I don’t have any insight as to what the reasoning was. But nevertheless, I find that somewhat notable.

Something else that’s notable in terms of coverage is the coverage over bank service providers. So certain organizations which provide certain types of services to financial institutions are subject to effective jurisdiction to a point where they are examined by the federal banking regulators under the BSBA or the Bank Service Company Act. So here, what we’re seeing is kind of an arm flags by the regulators of their jurisdiction or authority over bank service providers requiring them to give notice to the institutions as we’re about to discuss.

I want to make sure that we understand the definition of bank service provider, because one might read it and think, “If I’m watering the plants at the bank, I’m a bank service provider?” and that’s intuitive, but also in real life, not the case. This is a very much a defined term under the BSCA. I’m going read it because it’s important.

The types of services that are covered are check and deposit sorting and posting, computation and posting of interest and other credits and charges, preparation and mailing of checks, statement notices and similar items, or any other clerical bookkeeping accounting, statistical or similar functions performed for depository institutions.

Now, there are some types of service providers that I think fall easily within this category. If you’re poor banking provider for the core platform for the bank, clearly covered. But there’s all kinds of edge cases for which I don’t have a clean answer as far as whether or not default within with or without the scope of the BSCA, and therefore this rule. For example, let’s say that you are providing cloud services to a financial institution. Is that really related to check processing and accounting system, etc? Perhaps not depending on the actual function. Yet, if you had a system downtime for a long time, could that impact the operations of the bank? Perhaps, yes, still, because of the jurisdictional limitation here of the regulators still may not be subject to this rule? I find that interesting.

Kayvan

I’m sure there’s going to be further clarification and conversation around the definition of bank service provider. I was also keen to learn more about where FinTech or operator mortgage lending would probably fit into the service provider? Or subsidiaries or parts of the organization’s national bank or as an organization, technology in general would probably fall into that bracket as well.

Rick, did you want to add in terms of color to who’s being subject as part of this federal mandate? Especially interesting to me is the appearance of state banks being that this is probably not their charter, right? They’re not chartered by the agencies that are setting the rule, but it seems like they’re indirectly or directly impacted as a result of this.

Rick

One good thing about this rule is there is less ambiguity, I’d say, than in previous roles. And Michael outlined some of the requirements. But in two areas, the financial institution organization itself, whether it’s a FinTech or bank, the rule is pretty clear about your primary regulator being the OCC, the FDIC or the Fed, right? But that doesn’t mean that if your primary regulator being a state regulator or Department of Banking; but you have access to a sponsor, bank, or other means to the US financial system or the payment system directly. Because to Michael’s point, there is a kind of systemic risk underlying concern here that they’re trying to address. So that’s A. And then B is the bank service provider side, I think the example of cloud is a very good one. I would work with your compliance and legal teams. It’s not in black and white with respect to “yes, we’re in” or “yes, we’re out”. “Are we in?” or “How much are we in?” If so? And if so, how much of an obligation do we have? Is it absolutely required? Is it a potential best practice? And then prioritizing, in the vendor space, in particular. Like a cloud vendor, which is probably a critical vendor. Maybe focus on critical vendors versus non critical vendors, like maintenance, as Michael brought up. So, that’s what I would recommend. Even though it’s there, in the rule itself, I was very happy to see some very prescriptive language with respect to applicability. As rules always are, there’s some gray, and I’d work with your legal and compliance teams in particular.

Kayvan

So let’s get down to it. What is a computer security incident that would qualify for reporting? What does that notification look like? Can we have some examples of that? So, Rick, did you want to give us a framework for what we are looking to define that security, incident definition and some examples of it as well?

Rick

I’ll start and I’m sure Michael has some to add as well. But when I went through the rule, the good news is that the agencies wanted to use standard industry terminology when defining computer security incidents. There are so many source documents that you could reference that define a computer security incident and other types of incidents. And so what the rule did was they went out and they looked at standard industry terminology and aligned to that. So I’m going to refer to my notes here. But under the new rule,  an incident is defined as an occurrence that results in actual harm to an information system, or the information contained within it. And that is very much in line with, let’s say, the NIST’s definition of security incident, which is, again, referring to my notes here, an occurrence that actually or potentially jeopardizes the confidentiality, integrity or availability of an information system, or the information the system processes stores or transmits. Or that constitutes a violation or imminent threat, a violation of security policies, security procedures or acceptable use policies. Which of those two do you think is easier to comply with?

So I think they did a great job of really targeting, definitions. For example, they replaced actual or potential harm with actual harm. And they removed reference and non compliance with internal policies. And this, again, just makes the rule easier to implement. That’s with respect to the definition of computer security incidents. So I was very happy to see that. A notification incident is very similar again to what you probably have in place. So basically, a computer security incident would be defined as an incident, what causes the BFSI’s ability or impacts your ability to deliver products and services. Examples of that could be DDoS, which we referenced earlier, or credential dumping, command and control attacks, system failures. Pretty standard with respect to what any incidence response plan would define, or issues management standard that you have in place. In this role, in particular, they reference incident service providers. And basically, for service providers an incident they defined specifically as a breach of confidential data, or a loss of integrity or availability of systems, that is likely to persist four or more hours. So again, it’s much more prescriptive than I’ve seen in the past and that’s, that’s good. But you still have to fold that into your other inventory of requirements.

Kayvan

It sounds like the word harm itself is subjective to your definition of “what is harm?”. I think that allocation gets very close to that. And then the examples you’re bringing are very specific. And, Michael, do you want to add something to this? Or would we get a little bit further into essentially the actual canal, this happened to you? How do you notify the regulators of an incident? 

Michael

Let me add to this a bit, because after all, this is the heart of the rule, the core of the rule itself. So those definitions matter a lot. The way it works is that you have a notification incident, which is basically a subset of a computer security incident. And I find it fascinating that the regulators structured the rule such that it begins with the bank service provider, assuming there is one, which then notifies the bank (not the regulators) but the bank, an incident has occurred. And then it is up to the bank to make some type of assessment of the impact onto its operations or onto its customers. And if the impact is material enough, then it kind of triggers the requirement to notify the regulator’s. Stepping back, I think it makes sense because the financial organization of the bank is in the best position to make that determination about the ultimate impact on its operations and its customers. Another interesting component of those definitions is the fact that there is a materiality standard that applies to the definition of an incident. What strikes me as odd is that what may be material to a $100 million bank may not be material to a $100 billion bank. 

Therefore, and maybe this was not quite intentional the way they defined it, but let’s imagine the incident impacts a thousand customers or the order has a financial impact of $100,000. That might be material to a small institution and will not be material to a large institution. Hence, you may have the same actual events, yet different outcomes in terms of whether or not notification is required. I find that  interesting. 

Kayvan

Similar to an envelope not containing a from and/or to address, when am I supposed to notify, in this case, the regulator? How do I notify them? And what do I include, such as what type of anonymity or tokenized, headerless data do I provide without revealing information about my customers or any proprietary information?

Michael

If you’re a banking organization, the requirement is to notify your regulator as soon as possible but no later than 36 hours after you’ve determined that the incident rises to the level of a notification incident. The language is important here: It says “as soon as possible, but no later than.” The “as soon as possible” tells me that just giving notice at hour 35 may not necessarily be enough, especially if it is a very significant event. Or if there is connection, for example, if you’re a large bank and the incident has a systemic impact on the financial system. These are also, I like to call them calendar hours, not business hours. So there’s all kinds of interesting hypotheticals. If you discovered this on a Friday before Memorial Day weekend, you’ll have to give notice over the weekend under the rule.

The relief here is that the clock only begins to tick once the organization makes the determination the incident rises to the level of notification of the Senate. And that’s important because you may not know right away. I don’t think financial institutions should abuse that. And institutions should still, make that determination within a reasonable time. But there is a little relief there. Now, if you’re a bank service provider, then the requirement is simply to provide notice as soon as possible, once you determine that there is a reasonable likelihood that an incident occurred. So that’s pretty strict. If you’re a bank service provider, you have to compare the new rule to what you have in your contract, which may or may not read the same after a very long contractual negotiation. As we discussed, is the notification requirement immediately? As soon as possible? Promptly? Within a day? You have to give enough time for them to do their own investigation. So all that is contractual gets very separated from this regulatory requirement to simply provide notice, as soon as possible.

Then moving on to the method of notification, the regulation is fairly generic here. It basically states on email or any other method. So telephone is okay, email is okay. Or just about any other method, which the regulator’s authorize. My recommendation here is therefore not to send a letter, even though that’s perhaps the way we used to do those types of regulatory notices They want to know right away, so that they can actually act on it is the intention. And then finally, on content, they are also on purpose quite vague, because they don’t want to impose a heavy burden on the institution. And it is acknowledged that the institution is simply not going to know all the facts at the time of the notice. So they only expect a fairly generic description of the issue. It doesn’t need to include a detailed root cause analysis, or anything like that.

Kayvan

And Rick, about delivery of notice, getting that letter from the organization. Is it about now embedding this into the operational plan? And, what happens if someone is on vacation, or it’s Friday afternoon, we don’t have coverage. This all adds to that operational risk, right?

Rick

Yes, and that operational complexity and operational resilience overall. So I agree, if you can send by email, don’t send by letter. Send from a centralized email box. You’d be surprised how uncommon it is today to send from a centralized email box rather than Rick Dupree at bank.com. So you want it sent and managed from a centralized mailbox. The content of the notice, I think to Michael’s point, you have flexibility here. And that’s good. But that doesn’t mean you operationalize with flexibility. You make a decision operationally how to adhere to this. Maybe templates with respect to the notice, for example, we’ve decided this is what we’re going to provide a new situation and here’s the template. Don’t leave it open to everyone who sends the notification to determine what they provide. You need to standardize that for your organization. It’s nice to have the flexibility, but that’s really intentional. Then for you, as an organization, within those kinds of parameters or goal posts, to operate within those parameters in a way that you know will be consistent.

Kayvan

We remember CFPB publicly making available the complaints? Organizations like this would actually build insights in terms of the type of complaints being filed against different organizations. And then, there’s a pretty good level of insight in terms of the temperature reading. What type of anonymity can we expect? I’d read it in anticipation of this webinar, I couldn’t still get the clear picture of, okay, I now received this information as a regulator, I received it from 30,000 businesses and multiply that by the number of incidents, what am I going to do with this information? Where am I going to publicize this? Is there any place where organizations can go and see their name and the number of incidents that have happened over a period of time? Or is this entirely private and internal to the regulatory agencies?

Michael

I expect or actually, in the rule making itself, the regulators were very specific in that the communication to the regulator will be a CSI – Confidential Supervisory Information. So I would not anticipate that they’re going to publish the name of the bank. That said, if there’s something that is systematically impacting the system, then they’re likely to issue more generic notices about some major event that impacts the system. But no lists of banks to my knowledge.

Kayvan

And I imagine an auditor then coming in or some sort of review that looks at “Hey, you did have these incidents that actually made it to the news but we weren’t notified.” So enforcement actions ensue as a result, and then you’ll see your name in the news at that point, right?

Michael

Perhaps, depending on the nature of the enforcement action.

Rick

Just don’t let it get to that point.

Kayvan

Yes, you don’t want to get to that point. So this is not new. Incident reporting has already been in place. Before we talked about the ESA, we talked about state-level rules and regulations around this as well as international. So how does this compare/contrast and fit into the overall regime of other notification requirements that have already been on the books, Michael?

Michael

Well, it’s just one more layer. There is this whole inventory of notification requirements. And by the way, that inventory is not going to be the same for every institution; It varies depending on many factors. And, it will trigger certain notifications. Some go to regulators. Some go to consumers. Some are focused on whether or not PII is involved, and others don’t care if PII is involved. So different rules apply to each requirement. And therefore you need to know what those are. These are simply your compliance obligations.

I’ll give you a few examples. If you have any meaningful operations in California, or at least if you have customers in California, you’re subject to the Civil Code requirements to give notice to the customers of certain breach of those customers’ information. And most states have by now adopted similar requirements. If you are subject to the GLBA, which is most of those financial institutions, then there are certain requirements A. to notify regulators and B. fall under the GLBA response guidelines to notify the customers if PII is implicated. On top of that you have start filing requirements. So the same event might trigger more than one regime to make sure you notify your customer, your regulator, FinCEN under the SAR and so on. And by the way, if you’re a bank service provider, you must follow your contract in addition to following this new rule. And you may even be required to provide a separate notice under your contract of an incident.

Kayvan

Yes, so it’s an additive pile on not a replacement. Now you have yet another notification process to consider when something happens that qualifies for the level of harm as indicated by the rule. Interesting. And so, looking at this, As a business, I have a business continuity plan. I already have an operational plan. So Rick, how does this impact me? Do I have to start rethinking my operational plan? What is the impact, practically speaking, on a business from a resiliency and continuity perspective?

Rick

Well, I think we’ve touched enough on just the increased operational complexity. With respect to business continuity, the last two years in particular have been a wake up call with respect to the the limitations of business continuity plans as a risk mitigation tool. They worked very well, I think, for a lot of banks, who pivoted from working in branches to working from home. So that was an example, of a lot of smaller organizations or startups that may not have had that practice in place — the business continuity plan that they tested on a scheduled basis with everyone using issued laptops, VPN, etc. So there’s absolutely a place for business continuity plans. But as we’ve seen, in the last few years in particular, this broader concept of operational resiliency is not just about mitigating very specific risks. For example, if my system goes down, I have a business continuity plan to address that. If we have a natural disaster in an area, we have a business continuity plan to address that. Whatever the case may be such as some redundancy and technology or whatever. And those again, great for historically, well-defined incidents that we can expect to occur — fire, tornadoes, earthquakes, natural disasters in particular. But whatever we noticed as a deficiency was just broader operational resiliency, taking into account global pandemics taking into account, vendor reliance in another country. India, the famous example thereof, the beginning of the pandemic where India basically gave everyone two days notice. So a lot of them were sending employees home, and they didn’t have work from home capabilities. So that impacted a lot of banks, larger banks in particular. So it’s really about this: operational complexity and addressing that in your process, whether it’s a formal operational resilience plan, which you see some organizations putting into place, is in addition to your business continuity, but it’s not just relying on a business continuity plan. It’s a broader operational resiliency.

Kayvan

Speaking of those really creating that action plan, what am I supposed to be doing? How am I going to review that on an ongoing basis? This becomes very much yet another update to your action plans or new action plans as it relates to the new rule.

Rick

Yes. There’s some examples here. This may not apply to everyone, you want to inventory all your obligations, not just with the new joint rule, but the inventory of obligations that you have. And then you need to monitor when those change. You also should leverage existing notification processes, enhance them if needed, or if it makes sense, fold this into a lot of those existing processes. Look at your incident management or issues management plans, your incident response plans, look, again, across all of those programs and processes that you have. Find where there is synergy. Where you can fold this in. Where can you enhance because now you have a very different specific requirement that doesn’t necessarily fit into an existing notification process. So you have to enhance it. Also explore technology automation. And then from my perspective, you want this as a data input into your broader enterprise risk management program to inform your risk profile. Those are my recommendations with respect to an action plan.

Kayvan

It seems that we should have been prepared for something like this as a result of the other regimes already in place. This seems to be more of the same to incorporate into the operational plan and action plan. Right?

Rick

Right. And, Michael, I know you mentioned SLA, you mentioned vendors and contracts. That’s a big list potentially, here is potentially re-doc-ing all your vendor contracts, so you need to look at that as well.

Michael

I’ve a few thoughts in terms of implementing the rule from a more tactical standpoint. I see that there are a lot of institutions that actually do not maintain a list of their ESCA covered vendors. Because many institutions only add ESCA covered vendors every five years, how did they have their core providers for 30 years? Because of that they don’t maintain a clean list. So that’s where you start; you have to identify who those vendors are. And then once you’ve identified those vendors, then you share whom to notify at the institution in the event of an incident. Like Rick mentioned earlier, use group inboxes, don’t use specific persons, because people move, go on PTO, etc., so make sure that there is a way to effectively receive those notices.

Regarding the vendor contracts, one of the biggest questions that comes out of the rule is, do I actually need to amend all my vendor contracts? The short answer is “no”, you don’t have to; it’s not an obligation of the rule. In fact, the regulation specifically states that this requirement exists independently of any contractual obligation. Now, although there’s no need, perhaps that it’s a good idea to revisit your contracts and perhaps harmonize them with the rule. If anything, when you negotiate new contracts in the future, I know I intend to do is when I’m negotiating contracts, I’m going to point to the rule, when trying to incorporate a provision that mandates certain notification. I’m going to try to actually match what is legally required.

Kayvan – POLL

And so looking at a second poll, what type of technologies do you use today to help manage this process, both being notified of new requirements, changes in existing requirements, and obligations as part of new and changing requirements. Is your process fully automated, almost there, in the works or spreadsheets are phenomenal. Let’s just keep it that way. 

I’m very interested in this one. I’m sure many will report they are using spreadsheets stored and shared on local drives.

31% state “spreadsheets are great”. And then you have the expected semi manual or in the works. I would have thought that there would be some level of readiness, but the rule hasn’t come out yet. So maybe that’s a direct answer to the fact that we don’t know what impact will this will have from an automation perspective.

Really looking at what we just heard from Michael and Rick, in terms of the different regimes, the obligations that are required, the contrast between them and the fact that now you have something else to do, such as keeping track with notices of some updates to this rule or to similar rules. And, the ability to stay abreast of these changes throughout the organization becomes more and more of a must have. Within organizations the idea of trying to track and report on changes via a manual process seems Herculean, and unnecessarily complicated, time consuming, error prone and frankly, super expensive.

Looking at it as a solution provider, specifically from a regulatory tracking perspective, what has changed? How does this impact your organization? At what level, whether federal, state, independent, or international levels, how they compare and contrast against each other becomes more and more important to consider and incorporate technology to help with that.

Automation will become necessary to keep tracking with notification requirements. What was the number of hours you mentioned? 36 hours notification from incident to recording? Or was it after they’ve determined the level of harm determination to reporting?

So that requirement outlines the SLA from which to work backwards. If the number of ACEs continue to, unfortunately, remain as high as they are today, that really deserves a level of automation so that you don’t fall back and run out of time. Speaking of running out of time, we’re at 10 minutes to the hour. So I wanted to open it up to questions and use our panelists to help to answer those questions. Go ahead.

Q&A Section

SHEILA – Compliance.ai marketing team

Let’s open the floor for some questions. I have a few questions that have come in so far. And please, if you have any additional questions, add them in, and we’ll ask these questions to our experts. 

Question 1: Does the rule require notice to state regulators as well or only federal?

MICHAEL – Federal only, so FDIC, OCC, FRB. It doesn’t mean that it’s not a good idea to give a courtesy notice to your state regulator as well, which we normally would. 

RICK – I’d agree with that. Again, as I mentioned earlier, that’s where the requirement is. Depending on your primary regulator, who you’re licensed with for your activities, whether you’re directly plugged into the US financial systems or not, I think that’s a conversation with your legal and compliance department.

SHEILA – Compliance.ai marketing team

Question 2: What would be an example of an incident which would require notice under this rule, but not under the GLBA response guidelines?

MICHAEL – So the GLBA response guideline would only apply if PII information is implicated, right? So you could have a situation where there’s a computer incident, let’s say a widespread system outage, which occurs, maybe there’s a failed upgrade or what not. There was no breach. No information was stolen. Therefore no PII breach, yet, it would trigger notification to the regulators under this rule. But because no PII is implicated, and it would not require notification on the GLBA. And it could be a flip example as well. Let’s say that there is an event that involves PII, but doesn’t involve any computers. Then it could trigger a notification, the GLBA, but not this rule. For example someone has a big, big pile of paper on his desk with customer names, and that gets stolen. Well, that’s his desktop PII, he is definitely covered by GLBA not at all under this rule.

RICK – And if I can add to that, what I extract out of that is that overlap. So you have to be very clear with respect to, especially under this new rule, it’s not just about notification specific to this new rule because of a computer security incident. It’s additional notifications because of the privacy component of it. And then again, as you’re operationalizing those two processes, where do they overlap? How do you start with one but make sure that you actually satisfy the requirements of the other and that’s the challenge.

SHEILA – Compliance.ai marketing team

Question 3: If notifying a regulator via the phone, can a voicemail be left or is it required to speak to a live person?

MICHAEL – It’s such a simple question yet with no clean answer because the regulator’s don’t tell us. So, what I would do if I were the institution giving notice, I would keep trying until I get some type of warm body. I always prefer to give some type of email written notification, so that when I get audited by the examiners later re. compliance with the rule, I can provide firm evidence of compliance. If I hit a voicemail, I would do two things. First, I would keep calling other persons in that agency until I get to warm body. Or worst case, let’s say it’s Sunday, you know, you’re not going to reach anyone. I would surely leave a voicemail, but then I would follow up with an email to provide written evidence of a communication.

SHEILA – Compliance.ai marketing team

Question 4: Could an institution be cited by the regulators for failure to give notice, if their service provider failed to give a notice to the institution?

MICHAEL – It could depend. So the institution will not get into trouble solely because their bank service provider failed to give notice. That’s an obligation of the bank service provider. That said, it seems to me that if there is an event that required notice, the institution is going to be impacted and will feel the impact. Therefore, the moment the institution on its own, makes a determination that an event has occurred, there’s no safe harbor there, and the obligation to notify the regulators at that point would still be triggered, even if the service provider.

RICK – I agree with that 100%. I think that if I remember the requirement is for four or more hours of downtime for your vendor. So you’re going to notice that. Someone in the organization is going to notice that. And just because they didn’t send an email to that group mailbox, per your agreement per user, per your SLA, per the rule, it doesn’t mean you’re off the hook at that point. Now, you may have, at that point, the clock starts, as opposed to when they would have emailed or contacted you, but you still aren’t out of the requirement to notify.

KAYVAN – Ultimately, this notification, I think is a kind of like an “all in it together”. The more these notifications arrive, the more patterns can be formed. The more the cybersecurity infrastructure can be improved to prevent similar attacks from happening. This has been in the works. And this is yet another step right to this type of record.

RICK – I think that’s a really good point we haven’t touched on. This is going to force a lot of, to Michael’s point earlier, reviewing and preparing, SLAs with your current vendors, including larger vendors, where you may be a small player. You’re not a big client. You didn’t get the SLAs you wanted. Rather than four hours, they gave 24 hours, or eight hours. This will help normalize across certain vendors, which I think is a good thing.

SHEILA – Compliance.ai marketing team

All right, well, due to time, we must wrap up. If you have any other questions, please send it our way. Visit our website at compliance.ai or email us at sales@compliance.ai for any additional information or questions you may have.

Thank you so much for joining us.

Tags: business continuity, operational resilience, webinar