EP1039: Managing Cyber Risk and Third-Party Dependencies in Financial Services

I think that's a good idea. Financial institutions are in the pressure to modernize and adopt new technology and move faster. But they also need to keep critical services running. Why has resilience become the condition for success transformation today?

Well, the first thing is transformation only creates value if the business can depend on the service that's being transformed. So whether or not you're transforming to a new platform, you're doing a cloud migration, or you're changing the operating model the business is using, uncertainty around data, recovery. You can't just move the risk from one business to another. That just leaves it stranded somewhere else.

So when we think about resilience, uh, we think about resilience from is it resilient by design? Um it shouldn't just be a condition of transformation. It shouldn't operate as a separate work stream. You really have to look at at two things.

Uh one, how do we change? And then secondly, how do we ensure continuous operations while we're going through that transformation? So, what pressures are creating the biggest resilience challenges for financial services organizations today? So there's a combination of pressures, uh, I would say.

So there's things, many things firms are managing today, like aging technology, there's uh increased uh complexity around hybrid environments, reliance on third parties has become more and more top of mind. And add that to more sophisticated cyber threats. Um and and during this, you know, customers obviously expect services to be running all the time. So, in addition to this, I'd say uh regulators uh want to ensure you understand what your critical business services are and can just uh can withstand a disruption.

So it's it's not just a matter of um identifying one area or weakness, but understanding kind of the threat landscape across your suppliers, processes, and people. Many financial institutions need to modernize legacy systems, but cannot simply switch them off. How can they manage progress without creating a new operation risk? I'd say the starting point there is to understand the legacy environment and what it's actually supporting before changing a platform.

So it goes back again to understanding and having a clear view of what the critical business services are, what depends on those critical business services and the data involved that connect that business service, the applications, the people and the suppliers together. From there, uh obviously you can modernize from a critical business service and the impact that that service has versus purely treating it as a technical migration. It's not just something that IT owns, it's something that the business is responsible for.

So that includes uh defining an acceptable amount of disruption, agreeing on what recovery looks like during that process. And the thing that we see that um quite often is not done enough is the testing of those assumptions and testing the resilience plan as well. What is the difference between prevention and resilience, particularly when organizations are dealing with cyber threats? Sure.

So prevention is is essential, it's important, it's the first line of defense, um, but it can't be the whole strategy. Organizations need to have stronger controls. What is the difference between prevention and resilience, particularly when organizations are dealing with cyber threats? Prevention is essential, um, but it's it's not the entire strategy.

Organizations need strong controls to reduce the likelihood of an incident, but also need to assume that at some point uh a critical service may become unavailable for some other reason. So resilience is really about what happens next. Um, and can the organization identify the problem? Can they contain it?

Can they continue to operate while an incident occurs in a controlled manner? That's why security, business continuity, uh governance, and communications all need to work together from an overall business resiliency perspective. I would say right now we're shifting from uh how do we stop this from happening more to how quickly and confidently can we actually respond uh when something does occur. It's important to know, I'd say, that uh cyber recovery is not disaster recovery.

When you're looking at just uh disaster recovery, it it's quite different. Cyber recovery, the trigger point can be dynamic after the event, and the adversary can move. That makes recovery significantly more challenging. Prevention lowers the odds of something occurring, but resiliency lowers the damage that occurs when something does go wrong, and and you need to consider both.

That's about the pull quote that we need. Dora FCA operational resilience requirements and closer scrutiny of third parties are raising expectation. What are regulators looking for now? I'd say broadly speaking, uh regulators really want to see the evidence now versus just seeing the documentation that underpins your program.

Like I've mentioned before, this kind of stems all uh back to clearly understanding and documenting what your critical business services are and even having a business services framework around that, understanding what the impact of a disruption would do, what are the dependencies that support those services, and then what are the actions you would take under a pressure situation or an incident. The other area we see quite a lot right now is the increased expectation around testing and understanding third-party exposure and the assumptions that you've built around that third-party exposure.

That's another kind of key area that we see. Really, organizations need to demonstrate operational readiness and not just describe how they're doing it and what the policies are. So basically, you know, don't just show me your plan, show me the evidence of you testing that plan. What is the difference between meeting a compliance requirement and having genuine confidence and resilience?

So compliance is is really important from a baseline perspective, but it's not the same as confidence. Organizations will gain confidence by ensuring they're testing their policies, understanding the dependencies of them, uh testing against gaps and understanding uh what's missing from uh your business resilience posture. Compliance really provides a snapshot of looking backwards in terms of your your readiness. Confidence is more of a continual posture that you need to continually kind of look forward and ensure that you one, that you're auditable, obviously.

Um, and two, that you're responding to change that occurs after that compliance has been set. So forward looking more than backward looking. Some areas that we see that are critical is or concerning, rather to say, is uh organizations that have plans but haven't tested them. Or if they have tested them, maybe they've only tested them in very controlled conditions.

So, you know, by that I mean everyone was available for a test. They um, you know, all the stars aligned, so to speak, as opposed to running tests where you've got less staff, it's off hours, um, someone's not available, you have a key stakeholder that's um, you know, responsible for for recovery. And then, you know, how you actually test the decision making on top of it. So, you know, I kind of sum that up by saying like an untested plan is really just a hypothesis, it's not a verified plan.

And something we always suggest with customers is every exercise should really produce some new uh findings, uh a surprise or something that you didn't know before, or you're really not testing uh hard enough or deep enough. What should boards and executive teams be asking their technology and risk leader about resilience today? The first question should be uh what services are most critical to our customers? Uh, our people and our ability to continue operations.

That that's first and foremost. And then secondly, what do those services depend on? And how confident are we that we could maintain operations or recover from a serious disruption? That's really kind of the two key questions that uh I would ask on a board.

Then from there, what's really important is to ensure you have evidence to support that confidence and it's not just a matter of documentation. So it goes back to, you know, when was the last time you tested? What did you learn? What were the outcomes?

And how did you improve your resiliency posture based on those tests? So, you know, some things I would kind of drill down from there is is to kind of understand the the five to 10 top services that customers are most reliant on and are most critical to the business. When was the last time you tested them and under what conditions? Another good question with the reliance on uh technology providers, cloud providers is is asking if we were to lose our single largest technology provider, cloud provider for a 48-hour period, you know, would we be able to continue operations?

That's a really good barometer of readiness. And then if you're going through a transformation, uh a really good area to understand is of the transformational budget, what proportion of that is assigned to resilience or recoverability? And is it resilient by design? Is it secure by design?

If those, if that's not built into the plan, it's gonna cost you a lot more after. And then I guess the last thing I'd always want to know is is uh, you know, who has the authority to invoke a recovery and and have you gone through those progressions of decision making through your testing procedures? If if financial institution is reviewing its resilience strategy this year, where should it start? Uh in my opinion, I'd start with a clear business-led um baseline and ensure that you've got a clearly defined roadmap and a clear strategy for that roadmap that has been communicated across the organization.

So obviously, you got to identify the services and what matters most, ensuring that people understand that strategy and roadmap, um, as well as the processes that underpin it and the suppliers that you depend on to deliver that. So, really assessing the organization's preparedness and ability to recover during a disruption. So, from there, um, you know, it's not, you know, boiling the ocean. You want to prioritize the gaps and address them in order of priority and not try to just fix everything at once.

So having kind of a practical remediation plan against that makes it easier for the organization to adapt. So one thing that uh we believe in strongly is mapping the people, process, and technology, um, as well as understanding the facilities in question and the suppliers that support those processes. And then the other thing is is obviously continually improve and and ensure you have a repeatable process for improvement. Grand Duxbury Risk and Resilience Specialist 1111 systems.