Wayne Scott: 0:00

It's like buying a car from a manufacturer and they go outta business and the car disappears. You wouldn't do it, would you? But we do it every day with software. We do it every day. With cloud services.

Tom Raftery: 0:10

So critical software doesn't usually fail with sirens flashing. Sometimes it fails because a supplier disappears, support dries up, or a cloud service simply goes dark. Good morning, good afternoon, or good evening, where everywhere in the world. Welcome to episode 123 of Resilient Supply Chain Stories and strategies that Keep business moving. I'm your host, Tom Raftery. In this episode, I'm joined by Wayne Scott, GRC solutions lead at Escode. Wayne works with regulators, major banks, and critical service providers on supplier failure, service deterioration, concentration risk, and stressed exit planning. We'll unpack why outsourcing a service does not mean outsourcing responsibility and why the real question for business leaders is simple. If a critical provider failed tomorrow, could you keep operating? Let's get into it. Yeah,

Wayne Scott: 1:10

Long time listener. First time caller.

Tom Raftery: 1:14

Would you like to introduce yourself, Wayne?

Wayne Scott: 1:15

Yeah, of course. yeah. My name is Wayne Scott. I'm GRC solutions lead at Escode. We're the world's largest, source code and cloud escrow provider. I, myself, I'm, I have an unusual job really, I, I handle our relationships with the global financial services regulators. I write our consultation paper responses on any new regulation around the wonderful topic of resilience, but I focus on, three non-cyber related risks of supplier failure, service deterioration, and concentration risk. But I spend a lot of my time, advising globally, systemically important banks, financial institutions and their big providers on policies and standards and procedures around something called stressed exit planning.

Tom Raftery: 2:03

Okay, we'll get into all that. Let's start off, first off, for a lot, a lot of people listening might not be aware of what code escrow actually is, so can you give us a 101 on that?

Wayne Scott: 2:15

Yeah, of course. Yeah. it's an old school British invention. It's the idea really that, if you wanna keep things working, you've gotta have, oversight and accountability and documentation and reporting behind it. So sitting behind every bit of software, every cloud services source code. it's what makes software run. but, you know, if a, supplier fails, if they go into administration or bankruptcy, or if they get to taken over by a, you know, maybe unscrupulous new supplier who wants to downsize them or rightsize them or forced migration over it, so you know that software that you are using then becomes a risk on some level. But, if the supplier completely disappears. under a standard licence arrangement, you don't have access to the source code. That source code's needed to maintain the service going forward. So what we do is we store all that information that you need to carry on using that service going forward under the a legal agreement, an escrow agreement. And then what we do is we do a knowledge transfer. Essentially document how to use that source code, how to rebuild it, all the ingredients involved in a shopping list for and where to buy them. and then finally we test, can somebody follow that instruction manual? Can we test, can it be rebuilt in something called a scenario test? It's all the stuff that you need to carry on using whatever the most important software is or cloud service is going forward.

Tom Raftery: 3:40

And I mean, you talk about financial services, should people outside of financial services care about it?

Wayne Scott: 3:47

yeah, the vast majority of these software companies do operate horizontally, don't they? And it may just be just one software, sorry, one financial services market. They might go for banking, insurance, and accountancy, or legal or, Everybody only really uses one operating system. You've got large accountancy packages in the UK that deal with 40% of, the invoices in this country. And CRM software that accounts for, 27% of the entire market. If you depend on software and the supplier operates in the market, they're subject to market forces. Then escrow is, applicable across the board. So everything from critical national infrastructure, financial services, energy, defence, refuse collection, if it's important that the thing carries on ongoing and it uses software, we're in scope for use.

Tom Raftery: 4:42

And what business processes would you say are most exposed if a critical software provider fails or deteriorates?

Wayne Scott: 4:51

Well, within financial services, it is pretty well defined. You know, anything that handles or touches money, anything that, underpins the sort of infrastructure of things. Anything that touches people or customers, those kind of things. Increasingly there's a better definition of things, of these things. Everything used to be critical or noncritical, but now this concept of important business systems and services is being introduced across the board. The stuff that connects the important things together, it doesn't necessarily perform a critical function. but if it disappears, there's disruption and it falls down. Within financial services, definitely it's getting a more mature, attitude on an understanding of the criticality and importance and stuff like that. Also, anything that's gotta. a long implementation or deployment time or procurement process. You know, The standard operating procedure for a, a FinTech or even any kind of technology company is to be sticky, to be hard to remove, to not be interchangeable, to not be substitutional, So if you take a look at how many times a, an application is upgraded, maybe over a two year period, or are patched or fixed or somewhere along the way, if that procurement process, is longer than the average upgrade process, then that's a risk, you know, because if they disappear, that service is gonna deteriorate over a, x amount of time, a period.

Tom Raftery: 6:22

And why has this become so much more urgent in the last few years? What changed?

Wayne Scott: 6:29

Well, you know, obviously I, little bit biassed. I'd say there's always been urgent. But if you look at, massively, oversimplifying this here, if you look at the root causes of the financial services crashes in 2007, 2008, that was a concentration of very risky debt. in countries and organisations. But all we've really done over the last, x amount of years is introduce a new kind of risk, a new concentration risk in the form of technology, in the form of software, in the form of cloud. And that's just carried on and gathered speed under this wonderful banner of outsourcing over the last few years. And has obviously set to continue. It's been rather conclusively proven that, following every economic shock, companies fail. Operational risk instances increase. It might not be linked, but there's a correlation between it too. And, all of these companies, are subject to market forces. Nobody's immune from takeover. Nobody's immune from financial instability or insider trading or internal fraud or, cyber attacks, those kind of things. And when when these risks happening, quick succession, they compound and combine and eventually materialise a lot further on down the line. Bigger and bolder and much, much worse. And, if you kinda look at what we've had over the last eight years or so, you know, we've had some of the biggest economic shocks in the history of economics in rapid quick succession. Brexit, Covid, wars, genocides, high energy prices, austerity I'd argue is a problem, entire countries losing power. Bank failures, rise of far right politics, tariffs, more wars. None of this is good for financial stability, nevermind societal stability. None of it's good for financial stability and if this kind of financial instability hits the technology supply chain, what initially starts as a operational contagion, like cloudflair that was not even a, an important piece of software and it caused damage to a certain extent globally. But if it's it, if it's critical software, it starts off as operational contagion and, really does have some potential to turn into financial contagion, which is better known as crashes and recessions and things like that. Yeah. And nobody's immune to it. You can't stop it. Stop these things from happening. It's components of the market.

Tom Raftery: 9:00

And you mentioned the geopolitical issues. A lot of the things we've seen in the last couple of weeks and months, we've seen a lot of the cloud and digital infrastructure coming into the frame as potential targets. We had attacks on, I think it was an Amazon data centre in the Middle East. Does that change how firms should think about software and cloud concentration risk?

Wayne Scott: 9:26

It, it does, it does. You know, particularly in the Middle East, there was a lot of work that went on around, data sovereignty, keeping the data in country. That rapidly changed when those things kind of happened. And I understand it. You know, we're a kingdom. they're a kingdom. I, I get it, sovereignty, I understand it. But when, the politics and the risks actually matures and it, you, it's not even, it's not even a, black swan, is it really? It was kind of predictable. It's as Michelle Wucker would call it a grey rhino. You could see that kind of dust cloud on the horizon. You kinda have to prepare it for it before it hits. so yeah, it does change it, it changes it rapidly and it highlights that interconnected nature of things really quickly and pretty quickly, rapidly shows what's important.

Tom Raftery: 10:56

Yeah. And, and. Are you seeing firms still treating now supplier risk, cyber risk, and geopolitical risk as separate issues given that you just said they're increasingly linked?

Wayne Scott: 11:10

Am I seeing them treated as separate issues? I think the problem. within our field is that they're kind of being bundled together. Certainly the risks, the risks that we deal with, supply failure, service, deterioration, concentration risk often problematically, like still remains within cyber security, and cybersecurity are not too interested in it. It's not sexy, is it? You know, it's an instruction manual and legal agreement and process and stuff. It's not cybersecurity, it's not hacking into a mainframe. It's not the ma the matrix. There's no AI involved in it. So very frequently these risks, get, put on the back burner and, and decided to deal with, a little bit later on down on the line. That exposes all institutions to risks somewhere along the way. I often say to any financial institution, let's just take cyber out of the mix. Cyber's really important. Probably the most important thing, but these particular type of risks should be sitting at board level, C-suite in and around there because, risks only get mitigated when somebody's head's on the block heads, heads on the block is maybe not the right term, until there's a severe motivation to change, let's call it.

Tom Raftery: 12:27

Sure, sure, sure, sure, sure. And why do firms keep concentrating risk even when they, they know better.

Wayne Scott: 12:35

Cost effectiveness, economy of scale, new functions, new features. There was a big push to get out to the cloud, wasn't there? SaaS all the way along the way, except insurance, bided their time, if you know what I mean. There was also then a hidden cost of change, which, a lot of people weren't really aware of on there as well. When you outsource something very frequently, a lot of companies will outsource the thinking about it too. They'll outsource that risk, but forget that you still own that risk. It's still your responsibility to mitigate, particularly when it comes to, SaaS services, the cloud providers. purposely, but actual pun intended, they cloud the issue. they talk about, cybersecurity as if it's resilience. There's been a real branding of cybersecurity as a cyber resilience recently, it's the same thing, in my opinion. What that does is, there's this thing called like a shared responsibility model where the supplier and the owner, own different parts of the risk. But when it comes to supplier failure, that still firmly remains with the end user. They still responsible for it, certainly within financial services, so. They can't forget about it. And everybody's got this big faith in these, big companies, big suppliers in technology in general, don't we? We often, forget what we know. Very, very frequently forget what we've learned. But, technological change happens all the time, you know? I remember MySpace. I remember, uh, Betamax, I remember Kodak film, you know,

Tom Raftery: 14:15

Yeah. Yeah.

Wayne Scott: 14:16

Market dominant forces, dominated, saturated, but stagnated anywhere along the way. Here one day, maybe not gone the next, but, gone over a period of time. And, you know, we had to think of the permanence of software, uh, and, and services. But companies fail all the time. All the time.

Tom Raftery: 14:35

Yeah. Yeah. And then, then when you kind of think of vendor lock-in versus concentration risk, where do they kind of come, in people's order priorities to fix or avoid?

Wayne Scott: 14:50

It's changing. They're both on a par with each other, except maybe in the US. US concentration risk as a concept doesn't really exist in any regulatory programmes. The idea that big companies can do bad things, it's not really represented, throughout their regulatory programmes at all, which can be problematic in itself as well.'cause a lot of the big tech companies are actually based there as well. So they're subject to maybe a little less scrutiny. because of that. It was on, on the cards to change. It seems to have been parked and shelved for some reason. No comment. But that vendor lock in that lock in stuff, it's risky, isn't it? I know I'm oversimplifying it, but you should be able to move stuff in and out easily. Yeah. You know, it's infrastructure at the end of the day, isn't it? that's what it is. it's critical. You should be able to move stuff in and out. It's the opposite of the old business model for all tech companies. But, as technology progresses, as innovation increases, there's gonna be a need to move things in and out quicker. yeah. And all of those tech companies are exposed to financial risks, should they fail to innovate as well really.

Tom Raftery: 16:06

And where do firms usually lose visibility? Direct suppliers, fourth parties, cloud layers, support models,

Wayne Scott: 16:18

Oh.

Tom Raftery: 16:19

data portability, somewhere else?

Wayne Scott: 16:21

Gosh. All across the board there really. Financial services are doing a good job at the moment. Obviously I'd like them to be a lot further ahead. It's in the benefit of my pension, but, you know, I'd like, I'd like them to be further ahead. Fourth parties isn't happening as much as it should be as yet. Yeah. I don't think, as part of these regulatory changes, everybody has to go out there and amend all the licence arrangements, DORA addendums or SS2/21 addendums, or whatever you want to call them. I don't think they were, comprehensive enough to be able to get the suppliers to do all of these things. The right contractual levers weren't used. Early doors. It has changed third party risk management in a lot of these companies was not much more than a rebranding of procurement. They are learning the lessons now. They're getting these multifaceted sort of fusion of different skill sets as part of operational resilience over time. And you're getting a lot more savvy with it, a lot more as they go along. And it's starting to happen outside of financial services as we see. Yeah, I don't feel like I've answered your question there, Tom. Have I?

Tom Raftery: 17:38

I, I think so let, let's take it from another angle. When companies map dependencies for the first time, what tends to surprise them?

Wayne Scott: 17:48

Okay. So, very frequently, the application may contain elements of other applications that they weren't aware of. Okay. Occasionally that maybe the supplier wasn't necessarily aware of. A lot of these, suppliers also grow by acquisition over a long period of time. Yeah, so sometimes the source code to the core application is owned by one entity within the same group, but the bespoke elements are owned by another entity

Tom Raftery: 18:19

Sure.

Wayne Scott: 18:20

Also then there's components within the build process that are like proprietary tools that, that the supplier doesn't necessarily consider, you know, it's just their normal process. Now, they're integral to that build process. but not always made available to the customer, or not available to the customer as part of the standard licence arrangement. We found all sorts of stuff, open source being in there, applications that weren't necessarily owned by any party involved, you know, completely missing source code to critical applications. It's infrequent, but it's frequent enough to be worrying, let me put it that way. When a company buys another company, they follow a sort of standard operating procedure, don't they? They go, what do they call it? They call it right sizing nowadays, but you know, it's still downsizing to me. They have a look through the staff, they go, okay, that guy John and that guy Paul, they're on a bit too much money. Yeah. What we'll do is we'll replace them, with one person. Let's call him Ringo. This could be a good analogy. Let's call him Ringo. okay. Ringo's great. He's a Beatle, he's no John or Paul. But you know, it's really standard. It's really standard, uh, on the way, it happens. And when those big companies come in and they move people on, and there's always a loss of skillset across the board. There's, you know, nobody knows that, that product like John, and often they come back. Yeah. if they're still with us, we start looking at things like COBAL and stuff like that, you know. The supply chain of, capable developers is decreasing of that. And what else? You know, there's a lot of different components that are involved in SaaS services. A lot. The end user isn't necessarily aware of, significantly more from databases and bell scripts and, we have to produce entire architecture maps, of what it is that's in the cloud, and how it all connects together, and that knowledge would've normally existed within the financial institutions. If they still built the software themselves. We uncover a lot. There's a lot there. And then there's this like fourth layer, this they were sort of fourth parties underneath it. Everybody thinks this the supply chain goes out and out and out and out, but it doesn't, it actually contracts underneath. There's a load of critical suppliers, systemically important in that fourth party layer, that right now are not necessarily being picked up, not subject to regulatory scrutiny. That really needs to be identified and probably addressed at some point. There, there is certain regulatory drivers in, in the up and coming future to address that.

Tom Raftery: 21:01

Where is software escrow genuinely useful versus where is it not enough on its own?

Wayne Scott: 21:09

We used in this, this stressed exit planning stuff alright, now, a stressed plan is is there to move safely away from a supplier in unexpected circumstances They're called different things in different places. Unplanned exit, forced separations, what, whatever. It's the same thing, more or less. The latter stage of the stressed exit plan is basically just the procurement process, identifying alternative suppliers, onboarding them, integration, training, all that kind of stuff. But the thing is that you've gotta carry on using that, software to bide the time, to be able to make that informed decision on whether to own the risk or to move away. And that's where escrow scenario tested escrow agreements are useful because, you know, if you've got a supplier failure and it's already matured disruption, you've gotta find somebody and find somebody quick at great expense, right? Whilst you down, whilst you are out, while the customers are affected, while your organisation's affected by the share prices are affected while the market is affected. Okay. That's no good. there's no RTO on that, right? It's everybody running around panicking for a long, long period of time. Where escrow comes in handy is, is it extends this temporary period. It allows you to keep the service running for as long as you need to. I'm not aware of another, another way of doing it. And I've looked, I really have. Escrow is only really useful for critical services. I'm not looking to put your PDF generator into a, an escrow agreement, but if you depend on it and it causes a disruption, and if it goes down one day, and you phone them up to get some support and they've gone outta business and that's gonna cause damage, that's where we come in handy. Particularly with SaaS services, there's a real potential for damage with SaaS services.'cause they can go instantly off. Yeah.

Tom Raftery: 23:11

Yeah.

Wayne Scott: 23:12

And it can be something as minor as, they forget to pay the hosting fees. And that's a credit card getting outta date. That's how it can be. But, you know, one of the biggest costs to SaaS providers is the hosting fees. I think they get about 90 days or something like that before they get turned off. So the time you know, report, profit cycles, submitting your books to Companies House, that happens every year. There could be like a nine month, 12 month, 15 month lagging detection of financial instability in that particular supplier. No regulatory requirement to report it. No mechanism as you, as a customer to that. Hey, have you still got all your big customers? Hey, can I take a look at your commission structure for your salespeople? You haven't got that kind of oversight and it can mature and realise and present itself on the day that everything goes off. It's like buying a car from a manufacturer and they go outta business and the car disappears. You wouldn't do it, would you? But we do it every day with software. We do it every day. With cloud services.

Tom Raftery: 24:17

What about AI then? It's obviously the topic de jour, everyone is on about it, but is it genuinely useful, for example, in identifying supplier risk earlier?

Wayne Scott: 24:28

I'm, sure it is. I'm sure it is. Somewhere along the way. AI does wonderful, wonderful way of marketing itself. Hallucinations we call'em errors, don't we? faults. Flaws,

Tom Raftery: 24:45

Mess ups.

Wayne Scott: 24:46

Yeah. Yeah, that's, it's a wonderful bit of marketing, isn't it? Yeah. Yeah. There's a few of those along the way, but you know. AI is only as good as the data that goes into it and the applications where you can see making right now, in short term, and when I say short term in the next year or so, it's only good where the data's good and most organisations are, admit their data is terrible on some level. Yeah, you can see it being extremely useful within financial services and extremely useful within science. the sciences. It's clearly useful within marketing, and elements of, generation of images and stuff like that. The application outside of that is gonna be problematic, but, you know, it's really, it's gonna take some time. Not problematic, of course it'll be problematic, but it's really useful within code developments as well, isn't it? That's where I concern myself with this, with AI. Isn't in the application of AI where it's gonna be used more on the ramifications on the market when it's rapidly adopted. AI is a disruptive technology. Not like your average marketing company that wants to be a disruptor, I mean a proper one. It drives obsolescence. It will drive obsolescence. And it's not like that Kodak example, with digital film that I mentioned earlier where it takes like 30, 40 years to mature. It could be instantaneous, couldn't it? Yeah. Something could come out on a Thursday afternoon, that, massively undermines the value of software companies really quickly. And we're seeing examples of it at the moment. We're seeing examples we've had of, I won't call them close calls, but, there, there was a, some plugins announced just before Christmas that wiped off for about 30% of the value of one of the world's largest CRM companies. There was a, blog announced a little earlier this year that claimed some AI could handle reprogramming and reading and understanding of COBOL and that wiped about 30 billion off IBM's value. IBM nobody ever got fired for buying IBM. And you know, there's some pretty high profile stuff going on at the moment with Mythos and, and Glasswing and stuff. This is just gonna carry on, Yeah. There's gonna be what they call in financial services adjustments to the value of these big companies. Yeah. What happens when, you've got a critical piece of software that takes 18 months to two years to move away from, where the supplier is maybe valueless or, and bare minimum is haemorrhaging customers to the competition. What does support of that application look like going forward to you, as part of the critical national infrastructure or as part of the financial services community. They're all gonna move, but they need to carry on using the stuff that they've already got in place. It's predictable, isn't it? There's gonna be winners and there's gonna be losers. Yeah. There'll be some big winners and there'll be some big losers. That's why there's this arms race going on, isn't it, Tom? You know, that's why everybody wants to master AI. You know, innovation is a threat to market, market dominant forces.

Tom Raftery: 27:59

Yeah.

Wayne Scott: 27:59

I am not being very positive here. Are I Tom? Ah.

Tom Raftery: 28:05

No worries. No worries. What would you say if we, we take a step back and kind of take a, 10,000 foot view of, the space, you know, what are most leadership teams misunderstanding about software and service provider resilience?

Wayne Scott: 28:22

Our, our relevance here is when we tell people what we do, they get it and they get it quickly. And they're just like, oh my Lord, we need to do this. It's just such an obvious thing. Hey, I need access to the spare parts of, to my car. It's better if we have more than one garage on the planet that can service it. And let's get a Hayes car manual while we're at it, guys, maybe a couple of mechanics on site. it's obvious. And there's this little penny drop that goes on as people start to understand what we do. They are now increasingly recognising, our services as something called a key control. As something that can control the damage, of a supplier failure 'cause you can't stop it. It's unpreventable. So you just gotta limit how long something's failed for. That impact that it initially has, its ability to get worse, and the cost of fixing it, including fines. And that's what we do. That's what we've always done for the last 42 years. What's happening is, is across financial services, they're starting to recognise, that these risks do need to be mitigated and managed. It's interesting because the first line people, are making decisions on cost, seemingly second line in compliance or accepting those decisions. And then when it's going to audit, audit's saying, no, no, no, no, no. And nobody wants a call from audit Tom. They're coming in. So that three lines of defence model is working to a certain extent. It's the stuff that's, is getting caught in that third line. And that's sort of in year costs then, isn't it? Stuff that hasn't been planned for, let's get these plans in place and stuff. That certainly what's getting missed. And, you know, the whole cloud stuff, the, the whole SaaS stuff, it needs to be treated, more critically than on-premise stuff. Yeah.'Cause of that instant-off risk.

Tom Raftery: 30:32

What would you say? I mean, you, you're raising a, an interesting point, which we haven't dug into yet, and, and, and there's a danger around digital dependency that a lot of boards probably don't realise they have, and it is what you talked about there. It's that cloud infrastructure. I mean, a lot of systems are depending on the same hidden layer, whether it's AWS or Google Cloud or, Azure. you might have five or six services from different companies, but all using the same. Foundation.

Wayne Scott: 31:08

Yeah.

Tom Raftery: 31:09

how do firms become aware of that, and what do they do about it? How do they mitigate that risk?

Wayne Scott: 31:13

And, and, and this is it. This is exactly what needs to go on. These kind of conversations, these kind of conversations. It's been recognised, it's been definitely been recognised by the financial services regulators. So what's happening here in the UK and under DORA the Digital Operational Resilience Act, there's these two definitions that have come along. Under Dora is called CTPP, Critical Third Party Providers. Here in the UK it's called Critical Third Parties. And what this is this is the, direct regulation of some of the world's largest software providers. In Europe they've released the list, I think there's 21 of them. And you, you know, we're talking Microsoft and Google and Tata Consultancy Services, Colt Telecom, they're all big names. Yeah.

Tom Raftery: 32:02

Yeah.

Wayne Scott: 32:02

The UK list hasn't been announced as yet. It's due very, very soon, but I, I've been saying that for about five months so, but that's, that's soon in regulatory terms. And there'll be a, a similar set of companies on the UK's list. So this is almost like treating these large software providers as if they're financial institutions, making them conform to the same operational resilience regulations as the banks and insurance companies, investment management, pensions companies have to do. Externally, these large suppliers are ecstatic about this change. Internally it may well involve some change, for it. So it's been recognised. The big suppliers, the critical third parties, should I say, they're gonna need to be able to more comprehensively demonstrate their cybersecurity and all the other operational resilience elements of it, but also look at their own fourth parties as well. Look at their suppliers. Under DORA, it actually goes to nth suppliers, so, you know, you've gotta go another layer down there as well. And stressed exit plans are part of that as well. Supplier failure, service deterioration, concentration risk, and it's, gonna spread out. It's gonna spread out to the other industries. It's gonna spread out to the critical national infrastructure. I don't, I'm not predicting the future here. It is pretty obvious it's going on. You've got something called the Cybersecurity and Resilience Bill here in the UK, which is remarkably similar to SS1/21 and SS2/21 within financial services. You've got the CER in Europe. Now that's essentially operational resilience regulation, but the European Union has decided to map everything first. So every element of the critical national infrastructure has had to detail their third party suppliers and send the information into the regulator relevant authorities and they're gonna make a decision on what the regulation looks like going forward. Digital infrastructure, act in singapore. Kingdom of Saudi Arabia has just done some wonderful stuff, with the communication space and technology regulation that they've got as well. Applying this across everything, anything that uses technology going forward. The processes are the same. Map the risk, own the risk, test them, learn the lessons, keep it cost effective. it's so necessary. It's so necessary. It really does need to happen, particularly within the public sector. Public sector is a downward financial pressure, if you like. Everything's gotta get cheaper. You know, it was ravaged by austerity, and I'm not trying to be political, but it's pretty hard to deliver the same level of service, with increasing funds over and over again. And, you know, it has been identified. Supplier failure has been identified as a risk on the UK National Risk Register. for the last two issues of it. Strangely, the impact of it has been listed as low. And estimated that the uptime for a supplier failure could be instantaneous, or could take as little as weeks. There's a 1-5% chance of it happening. Me personally, I think that's a massive number, but what's really unusual about that risk register is that, it's made the assumptions that these stressed exit plans are in place. That's what it says. The impact has made the assumption that the plans are in place. We're the largest provider of these plans on the planet, and I tell you, they're not in place with us. Yeah. It needs, looking at, it's, it's, it's certainly something I'm, I'm attempting to raise at the moment, through all the formal channels. But I, I would just say anything within UK public sector, the government's, assuming that you've got these plans in place, ask your suppliers. Just double check. And then give us a call. Bit of selling.

Tom Raftery: 36:03

Wayne, if, if listeners take away one practical lesson from this conversation, you know, what should they do different starting tomorrow morning?

Wayne Scott: 36:11

Yeah. Okay. I mean, you know, if you're in financial services, just ask if escrow is on your control framework. Dead simple. Just ask the question. Yeah. If you're, outside of financial services, critical national infrastructure, whatever, just ask your supplier, how would we deal with your failure? Do you have any plans on how we could carry on using your service should you no longer exist? Just ask the questions. That's the start of the process, getting the conversation going. A lot of these suppliers as I've already mentioned are operating, horizontally. They probably got some of these plans in place. Yeah, they're probably available to you, but they're only available if you ask.

Tom Raftery: 36:57

Yeah.

Wayne Scott: 36:58

Yeah, and, I'd just be asking those type of questions. and can you tell me your third party supply chain, please? See, I'm being a bit mean here somewhere along the way. because. a lot of this, a lot of tech companies don't have regulatory horizon scanning teams. They don't look at what's coming down, and how it's gonna affect their business. They do wait for their customers to ask them about things. Yeah. And, you know, you don't necessarily change something unless customers start to ask you to change these things. So it's not all their faults, but a vast majority of these regulatory changes are common sense. Yeah. And when you start to get pushback from suppliers or what is common sense that should start be ringing alarm bells, really. What's wrong with an instruction manual? what? What's wrong with a shopping list?

Tom Raftery: 37:53

Right Wayne we're coming towards the end of the podcast now, is there any question I didn't ask that you wish I did or any aspect of this we haven't covered that you think it's important for people to be aware of?

Wayne Scott: 38:04

No, I don't think so. You know, I really appreciate you having me on. I know I have a tendency to ramble. I seem to breathe through my ears sometimes, don't I? But you can tell it is one of my favourite subjects. You know, this is a severe but plausible risk and, I really want, certainly, you know, our country definitely to have a look at this because when software disruption hits, it, it does affect not just people's money but people's lives.

Tom Raftery: 38:30

All right, Wayne, if people would like to know more about yourself or any of the things we talked about on the podcast today, where would you have me direct them?

Wayne Scott: 38:38

Well, quite simply, uh, go to, escode.com, E S C O D E dot com and all of our details are there. Interestingly, you've most probably already got an arrangement with us, some kind of escrow agreement in place on some level, so you'll have an account manager, but yeah, just Google us there and you'll find us there.

Tom Raftery: 38:57

Wayne, that's been really interesting. Thanks a million for coming on the podcast today.

Wayne Scott: 39:00

Appreciate your time, Tom. Thanks a lot.