Welcome to StartupRad.io, your podcast and YouTube blog covering the German startup scene with news, interviews and live events. Music. Hello and welcome everybody. This is Joe from StartupRad.io, your startup podcast, YouTube blog and internet radio station from Germany, Austria and Switzerland. Today, I do have another expert interview with you, talking about Dora again.
We have been in the past hearing one guest who was talking about third-party assets on your website that you need to take care of. This time, I do have Giles here as a guest. Hey, how are you doing? Hi, nice to see you. Thanks for having me on. Totally my pleasure. You are Director of Services EMEA at NetSpy, and we will be talking a little bit broader about DORA and what you should do.
I do have a few questions to guide you through this interview, and hopefully it will be very useful for everybody of us. But before we get started, can you introduce yourself a little bit to our audience? Keep in mind, most people will just listen to us. Of course. So I'm Giles, and I look after a number of different testing services. So I am a security tester. And before that, involved in IT infrastructure for a long time in my career.
So in terms of my profession now, what I do is something called red teaming. And that is an expression of security testing. it's essentially organization-wide resiliency testing. And it's the type of testing that sort of DORA asks us to undertake and Tiber2 and other frameworks, things like CBEST, for instance, in the UK, and other frameworks globally. It is essentially, for want of a better way of putting it, I'm a hacker, but in a good way. Yeah.
You are, can you say, an ethical hacker? Correct. Yes, absolutely. An ethical hacker. I see. So today we're talking about DORA. No, it's not a first name of a lady. It's the Digital Operational Resilience Act from the European Union. And before we do get started, right now, it's already in force. But we do know the way bureaucracy work. Likely next year, the first checks will be done by authorities, by auditors, and so on and so forth.
So this is the time to really get your stuff done, to really get down to business. If you appear or think you have some holes in there. And for this reason, we go a little bit broadly over the whole regulation and tell you potential places where you may have to work on before you get audited. Should we start with government and risk management?
Please. Governance structure. Have I established a clear governance framework for digital operational resilience and are roles and responsibilities well defined? And that is a pretty interesting question. And what kind of answer should an entrepreneur have except for yes, of course? Yeah, that's a really interesting one. I think it's about the evidence base and the rationale behind it. And I think that's the kind of some of the core aspect to this.
So if you can prove the rationale of that structure and sort of why you've made the choices that you have, I think that's a key component of it. Reasoning behind things, if that makes sense. It's not just the process, and I think that's one of the things that is critical to this. It's about the reasoning for the process and sort of the evaluation, the showing you're working, if you will. But I think this is really trying to prize out, if that makes sense.
So that means if an auditor asks you, why did you do that? You should have a pretty good reason. But I do believe most will have thought it through at this point. Then we're talking about risk management strategy, having a comprehensive risk management framework to address all potential ICT risks. Can you first tell us a little bit what ICT risks are and then what you would expect from such a risk management strategy if you would look at it from an outside perspective?
So I think there is a... A significant amount of this that is kind of understanding your organization and sort of where you sit within the market, where you intend to be in sort of three, five, ten years time, for instance, and sort of where you need to integrate to be able to understand what those risks might be. The component parts of your business and what keeps you operational is really important.
You know, what are the cogs that keep the business turning from an IT perspective, the critical, important functions, to use the sort of the terminology there? These are the component parts of the business that you absolutely must keep running and operational. And that's why operational resiliency is a big part of this risk management approach, if you will.
Actually, funny thing in German, it's called information and communications technology, information and communications technology, IKT-risiko. So that should give a little bit more hint about that. but please go on. The approach in terms of the strategy and the vision is you have to understand all of your assets that form part of that ICT estate and the processes and components and the human element as well, if you will, that go into that to be able to drive the business.
And that accurate mapping of it is essentially the most fundamental component of that strategy, if you will. Yes, sure. Risk-venture framework, when would it be comprehensive to address all potential ICT risk? Thank you. Without understanding your entire estate and all of your ICT systems and the usage of them and sort of how they integrate to the business, it's an incredible challenge to be able to make it complete.
So a strong asset inventory or a strong understanding of your own ICT systems is critical to be able to understand the risk to them or the potential risk to them. I have one question. You said it's important to have like overall overview. I do believe a lot of people tend to forget one or two tools. Do you have any experience where people usually forget some ICT assets, meaning physical or digital tools, software, IT?
Yeah. So I think shadow IT as a concept is something that people talk often about, which is parts of the infrastructure that have been sort of created dynamically or by individuals or users that are unknown. And I think that's one of the key missing elements from a lot of people's asset inventories. So you have to have an element that is through known mechanisms, things like sort of databases that you might have of assets that exist already.
But you also need to have the ability to dynamically map them and to be able to dynamically understand the component technology assets of your business on a continuous basis. So there are a number of sort of platforms and sources and tools that aim to do that dynamically and to varying degrees of success in the market.
But doing an evaluation of those as part of your component infrastructure and looking at the efficacy of those is is a really important task as part of this kind of this overall framework development is you need to be able to assess the tools you use. In fact, it kind of almost the next level, if you will, that assess how you work. It's a bit of a non-answer almost sometimes, but the approach... You need to be able to know what you don't know and how do you quantify that?
And I think that's the tricky question here is how do you map the unknown and how do you rate a tool that allows you to do that? Often people lean into things like SaaS platforms that sort of offer a, for want of a better way, a magical solution to these problems. I think validation and checking and due diligence, again, another core concept of this act and what it tries to instill, key components of that.
So you need to make sure that you are checking and validating the software that you use, even that you use to understand your business and evaluate itself, if that makes sense.
So you shouldn't have any freelancers who do have developed proprietary tool they transfer data and then put it back into your system that that's the kind of risk we're talking about plus getting your data into a third-party software and not be aware of that do you have because this shadow it is always a pretty difficult topic especially to figure out Oh, if you have something like that, I once talked to a guest and they say, yeah, look at the company credit card bills.
If there's software charge, that could be a good hint. Do you have any other ideas, suggestions how somebody may find, may learn more about potential shadow software where they could find hints about it? Yeah, there are elements. So some of this might be externally facing, for instance, so internet facing and available to the public, and you may not be aware of it.
So there are tools and techniques and processes that you can do to dynamically scan and to sort of search for assets that might be linked to your business in some way.
You know products like this are often called things like attack surface mapping for instance these are what they aim to do is look for traces of your organization externally so then that you can take sort of reparatory action or some form of action to investigate where they may have come from what the background might be credit card data is in fact quite an interesting one because company assets company finance are tracked already in a lot of organizations so that gives you that audit trail.
Other sources of data, things like in the sort of the computer sort of identity sense, for instance, things like cloud services will hold databases of users. Perhaps you can track what those users, what resources they're creating. The same for sort of on-premise systems like Active Directory, for instance. Those are means by which you can have a look at what resources are being spun up, but that's not dynamic. That's fairly static.
The regulation talks about ICT risk assessment how frequently should you do that and how I mean there are of course different methodologies but how would you go about figuring out what methodology one should use that's an interesting uh an interesting topic um you have to assess it Again, I think that's a really important thing.
And I think this is kind of, again, this is the territory of non-answer again, where you're expected to do the due diligence, but often there's not a great deal of guidance on it. And to be able to prove and validate that and argue the case for it, again, is one of the key things. But in terms of the. In terms of the sort of the way that you manage that due diligence on third party suppliers, existing and new ones, a lot of organizations.
For instance, that I've spoken to are re-evaluating contracts as a result of this act. So that's kind of a one-time monolithic sort of evaluation of those organizations and how they treat their own security as part of that supply chain risk piece.
But also when you are updating or changing contracts or when you are refreshing service contracts with those organizations, that's when you should be doing this assessment, for instance, or at least on a yearly basis or an annual basis to make sure that you are regularly reviewing and revisiting them. And I think the review and revisit is another core component to this is you can't treat something as trusted if you've done this forever, if you know what I mean.
So if you've done your due diligence once, that doesn't mean that that due diligence continues year after year, year after year. Organizations can become insecure that you deal with as a supplier, for instance, over the course of their lifetime. So what you need to be doing is making sure that you're continuously checking those, understanding their downstream processes for sort of how they manage their own vulnerabilities, their own risk management approaches, their own processes.
And that's one of the big challenges around this act is organizations are now presented with how do they present information about how and where they are vulnerable to their clients without giving away data that is sensitive or controlled under other legislation, things like GDPR, for instance. And that's a very tricky question to get an accurate and clear answer on. And I think that's been one of the challenges for organizations trying to solve this.
When we're talking about DORA here we're talking about incident reporting and management can you help us to understand this field first step how do you, identify an incident. What is the level? Again, it's a little bit subjective here. When is it an incident? Yeah, absolutely. So you have to need to have a reasonable level of confidence that this is a operationally affecting incident, cyber security or otherwise.
So, you know, for instance, the one that a lot of people lean towards is cyber security incident or a breach, for instance. You need to have a good degree of confidence of that is a genuine breach, for instance, and be able to report that as soon as possible, ideally within 24 hours. So you need to have a strong ability to respond to these types of events and identify them, triage them, and treat them as quickly as possible, i.e.
Identify them as quickly as possible. And then you've got a responsibility at that point to do the notification process and follow through the rest of your incident response plan. And that can vary depending on what type of incident you face. So in a lot of breaches, for instance, you see things like ransomware affecting organizations. That type of breach is very, very fast moving, typically, in the market for a lot of organizations.
So there's a real challenge with the timing of being able to identify something like this, respond to it, and sort of recover from it, as well as going through the notification process at the same time. And I think that's where we'll see a real stretch for organizations to meet that compliance standard. How do you show that you can do the identification process and adapt and prevent and recover from a threat at the same time, for instance? So it's a really tricky thing to get right.
It needs to be documented. You need to be able to, again, justify it. You need to be able to talk about why you believe that the method and approach that you're using is appropriate. Because when you come to audit, you will need to go through that process. You will need to meet the challenge of, you know, these questions being asked of your organizations and why you've chosen that.
If you don't have a robust set of evidence behind it, about behind why you've made the choices, then there is a high likelihood that, you know, you'll need to take some measure afterwards. So if you've got good justification, you may well have to take less action to sort of get up to the right standard for next year and years after that. So the improvement plan will be much reduced, if you will.
I see. We've been talking about communicate, communication, reporting of incidents, of course, to the relevant authorities and the stakeholders. But what kind of channels would you use? Because I do believe it's not secure enough and not sufficient to just send an email. Hey, guys, look at this. Something happened.
Yeah, absolutely. So in these types of incidents, especially in a cybersecurity incident where the systems you use to actually send those emails may be compromised in and of themselves, there is a balance between sort of using the systems that are breached and some other out-of-band method, like a telephone call or an SMS or a reporting platform or something similar. So some nations, for instance, will have direct report that you can do through a website, for instance.
Those are methods that are often used. If you are in a market that is heavily regulated already, you will often have a contact or a representative or an agency, if you will, or a TCT in the sort of the Tiber terms that you would make contact with. So you would have a familiar contact normally. Typically, they would be a first point or a local law enforcement agency if it's relevant as well. That's a tricky one with the balance of sort of when and where you are allowed to do that in some regions.
But I won't go too far into that because there be dragons. Plus, we're just trying to provide here a high-level summary for the audience that they can start thinking about. But where may they be a weakness not to be found in your first audit? Because that's what everybody wants to avoid. And that's why we are here and talking today. I would like to go a little bit over to the topic of third-party risk management. You've been already talking about adjusting the contract with vendors here.
I'm pretty confident everybody now has already the class, the, the, the, the, um, the required criteria in their evaluation, third-party ICT providers, and so on and so forth, how would you proceed with existing vendors, that may be a little bit late to come by or promise something and didn't deliver yet because that's a problem for you and not necessarily for them? Absolutely. So there is guidance to say that you need to have good termination procedures in place as well, for instance.
So the ability to terminate contracts with the sort of supply chain or with third parties when they are shown to not be complying. And I think that's a you need to be able to pull that plug and have a process for it and be resilient against the impact that that might have. And I think that's especially seen for managed service providers or managed security service providers, especially in the ICT realm, which is a common practice.
Outsourced IT, outsourced security operations center or outsourced endpoint detection and response are all things that you may have to terminate them and the agreement with them if they're unable to provide sufficient improvement or documentation or evidence. Of course, you should have by now at least looked and adjusted the contract and service level agreements. Do you think there is a minimum of clauses you must put in this contract with third parties to align with DORA? Absolutely.
So their ability to share their own security process with you, i.e. Their vulnerability management, their own sort of incident response procedures, and sort of what the expected SLAs around those are, so that they are communicating to you if they present a risk to you. And I think that's one of the core elements. In terms of the other pieces, so contractually speaking, you mentioned that they've, sorry, contractually speaking, you know, these things are negotiated already.
At that point, it's data management, I think, and it's handling of your data and segregation of your data and evidence of that would be another key component as well. How do they deal with your data in relation and how do they protect that data? So I've seen in a number of examples, for instance, large service providers are now providing that level of attestation to their clients, for instance, and that's part of the negotiations that are ongoing for them.
Let us go a little bit into the ICT tools and systems, the integrity, system integrity. Everybody needs to ask themselves, are my current systems resilient enough to withstand operational disruptions as outlined in DORA? But what would that mean for me as a maybe smaller startup fintech here? Yeah, absolutely. So I think as a smaller organization, the cost overhead of compliance and being able to show compliance, build the process is a big consideration for them.
Equally, the nature of a startup or a scale-up is that they are dynamic organizations. They need to be able to adapt and respond, and they are the guerrilla fighters, if you will, of the business world. And that's one of the things that makes this quite tricky is because you're asking them to build a rigid structure and to do things that may prevent some level of innovation. And I think that's part of the pushback that some organizations have said.
Cost is kind of probably going to come first for a lot and then complexity afterward, I would say, for the implementation and the challenges for them. You're talking about rigid systems, dynamic startups here. I was wondering, do you have seen any good solutions, any good systems? How do startups do work with backup and recovery? Because they tend to change a lot of what they're doing and how they're doing this.
And their backup and recovery needs to adjust. So how do they keep pace with their current development in terms of backup and recovery? That's a really interesting question. And one that I think the hard part is to design a system when you are a small organization and have the scale that you will reach in mind and understand how to build for that scale.
And for backup and recovery, the system that applies to a smaller company with five people, for instance, to one that has a thousand people or anywhere in between, it's tricky to get that scaling right. What you need to be able to do is build the.
Build the backup scalability and the recovery scalability into every machine in a granular way so this is where a lot of organizations are turning to things like SaaS platforms that offer that backup and retention dynamically without them really doing any sort of thought there are some pitfalls to that approach you're outsourcing the risk to another vendor rather than sort of doing the full process yourself for instance if you so finding
a good place to retain the original backups is a good start. Looking at how you can backport new iterations of systems or new generations of architecture into that is a key component. Things like immutability, for instance, are another element that people often think about and talk about is whether or not those backups can be changed. The regular review of what you are doing as part of that backup and generational changes and the transformation journey are – it's very difficult.
You have to track it over its lifespan, if that makes sense. So you have to kind of understand those systems as they evolve and start to plan forward. Spelled out in every aspect. And I do believe after the first audits, there will be some issues coming up. People will discuss it on events. And over time, it will be an established enforcement. As well as rules and guidance people can adhere to. But right now we do have a little bit of wiggle room in some areas.
And that's why we try to cover as much space as we're doing here. Talking about monitoring and testing, especially penetration testing, you've been talking about. I do know there is some guidance here in Germany, especially from BSI and other associations. What kind of standards and certifications would you use and recommend for your clients to do that?
Yeah, it's an interesting one. So under the Tiber standard that's been across EU for some time now for a number of years, there were originally some guidelines around qualifications that organizations and the team members within them would have to have to conduct tests under the Tiber framework. But actually those are not enforced anymore. And there's a bit of a gap there. Although a lot of the organizations will still refer to them as the kind of the standard that is expected.
What i would tend to advise is look for organizations that have individuals tested, tested and accredited as well as the organization itself to a recognized industry standard level, so for instance for the tlpt or the similar standards threat-led pen test under dora or essentially advanced testing or advanced red teaming intelligence-led red teaming.
The typical standard is something like a sort of a crest certification like a cc sam or a cc sas for operators and managers you're looking at something that has a bit of a history and a legacy for instance other other similar standards exist as well and there's a lot of emergent organizations now that are bringing really good forward thinking standards to the to the fore, um i would also expect organizations to perform due diligence tech and so would so would uh so and
that's what the standard advise is so looking at the individuals who are conducting testing whether it's advanced or basic if you will um and their experience and capability so sort of five years of experience testing against financial services organizations for a uh an experienced red team operator is considered uh to be the appropriate amount to amount to conduct tlpt or timer in these instances. Need to validate those and sort of do those checks.
Again, understand the justification for it, and the best approach and the approach that I've seen most welcomed is to talk to your authority, your regulator, if you will, and sort of run your approach past and say, we've checked these, do these meet your standard, are there any other standards that you would like us to meet?
So again, no fixed qualifications at this moment in time, but look for accredited, credible, longstanding institutions, if you're in any doubt, and do the due diligence on the individual testers themselves that will be performing work on your ICT systems, critical, important functions. And that's kind of the right approach. I do believe something very similar would be required for the resilient testing, except level of testing to demonstrate digital operation resilience.
I would be a little bit more interested in threat intelligence. You already talked about real time threat intelligence. How is the best practice to integrate that as far as you've seen?
It's a really interesting um concept so the threat intelligence plays an important part in understanding how to design against threats to your resiliency so having a constant feed and knowing the types of organizations that or or threat actors or groups that might be targeting your your organization or one similar to you on a continuous basis is really really important, That helps you design against them, if you will. The.
There is a difference between sort of continuous threat intelligence and that element, as well as something that might be a standalone report or a point in time assessment. You need to have continuous feeds of what's directly interacting with your systems. For instance, that's what a lot of threat intelligence providers will now do. So they'll be looking at who's actually actively scanning your networks. What can that be attributed to?
Likewise organizations that are able to sort of get into the sort of the dark recesses of the internet deep web dark web those types of things and look for evidence of threat actors targeting your organization and then there's also things like sort of nation state or nation state linked groups that might be targeting you for strategic advantage for instance a lot of financial sector organizations will be targeted because they're prime targets for nation state level groups.
So having the feed and the understanding of what's going on on that side of things, who they might be, what they might be targeting, have they made some kind of public announcement, or have they affected similar organizations is really, really important.
Equally, that information source, that threat intelligence source could be a platform or a vendor or a threat intelligence team you have yourself or threat intelligence capability you have of your own or it could be your peers in the market it could be the other financial institutions or similar types of institutions or the ICT institutions that provide services into them,
is sharing information. And that's another core core tenet of this is actually sharing that information about near misses, incidents, events between the different parts of the ecosystem is another source of really valuable threat intelligence. And there needs to be a good way to share that in a private way and not expose each other's vulnerabilities and issues for competitive advantage, for instance.
That sounds like a lot of lunch appointments you're recommending here yeah i think uh i think uh everyone's waistlines would have increased i think that's the side effect of uh of this i see we'll be back with policies and procedures after a little break for our sponsor okay we are back here with giles um we are still talking about dora giving you a high-level overview here of steps you should and could have taken. As we said, it's not really yet enforced. It's not yet audited.
That's why we give you a very broad, very high-level overview of the steps. We would take questions we would ask. Therefore, you could go through and start thinking, hmm, did I miss something? Is everything in there? I will also link for the German authorities here. They have some guidelines for the enforcement of, have some guidelines for DORA. I'll link it here in the show notes. Unfortunately, it is not in English.
Nonetheless, let's talk a little bit about policy and staff training because one kind of reinforces the others. We assume you currently have policies for operational resilience reviewed, but how often, how frequently do you need to adopt them to evolve in order to keep current? The world changes rapidly. So all the time is the optimal answer, but possibly also equally not the realistic one. So as a minimum, you'd need to be sort of annually reviewing as an absolute minimum.
But if you're undergoing major change as a business, you're taking on new initiatives or you've acquired, say, for instance, mergers and acquisitions are a thing that happens all the time. Perhaps you've got an influx of new people in the team. When there's a major event like that, then you need to start building that in. Much like if you were building a new product or developing something new, you'd want to test that when there's a major update to it.
You'd do the same for your business and its people and your culture to make sure that that is well understood, adopted, part of the onboarding process, if you will. So, yeah, major changes and at least annually. Yeah, and staff training should take place on a regular basis. I vividly remember that I had a few years ago a company here in the interview that offered this kind of testing. They just sent out mails and looked who clicked on the links.
And I remember the answer, most clicks came from top management, but they are also the fastest ones to learn. I think there'll be a lot of required trainings and don't make it like a boring online presentation, a YouTube video or something like that. Make it interactive. That usually helps a lot more, especially I can tell from my past, especially if you get your staff, a group of people together, try to do the penetration testing themselves or at least give some ideas.
It's really interesting how dark some people's thoughts can get here. Talking a little bit about cross-border compliance. Assuming you're a little bit bigger company, but even in financial services, if you have a few hundred employees, you're not really necessarily that big, but you can have operations in multiple EU countries or outside of EU countries. How does DORA apply there?
That's a it's an interesting um dilemma for a lot of organizations so we uh have had the privilege of working with global organizations that are facing this same challenge so it may be that for instance um you face the challenge of multiple regulatory compliance so it could be different regions you have to comply to and a common practice for a lot of organizations when they start to get a bit larger or a bit more global in this side uh is to look at the most stringent requirement and try
and comply to that or try and go for the kind of the path of most resistance where it comes to the compliance journey. And that's a typical approach. If you are. Sort of taking kind of taking this as a fairly sweeping legislation as it is and with lots of lots of kind of enforcement power, it's likely that this legislation will probably be the most stringent standard that you face.
Targeting DORA and the ACT and the various articles underneath as the primary component is probably the most sensible approach. There are other standards of a similar nature, but I would suggest that this is probably the most complex for a lot of organizations to undertake and target this first in this instance. Data localization. Of course, Because it's always preferable to have the data within the country where you're regulated, where you're located.
Are there specific requirements to store the data, for example, within the European Union to ensure compliance? Absolutely. So the data itself, much like some of the kind of the elements around sort of GDPR and what that brought in for a lot of global sort of companies, if you will, having that data where it is relevant stored in the European Union is the right approach in this instance. And so it should be residing there and you should be able to sort of see, as we say in the UK, farm to plate.
So when you have a meal and maybe you have meat or whatever it might be, you know where that data has been held throughout its lifecycle. So being able to trace that back and make sure that you understand its location in full and that your suppliers are able to give you that information as a key component to that. So that goes downstream as well as for yourself, if you see what I mean.
So cloud providers, for instance, often will allow you to put your data in specific regions if that's the way that you operate. So that's the right approach in this instance. If you are consuming services, SaaS services, or web-based products, by the way of putting it, that are based in other regions, that's a good reason and a good time to do a review and understand whether or not they're compliant to this legislation.
I see. The last topic that I have here is pretty funny because it's areas of uncertainty. We've learned throughout this interview, which we're now asking you questions for more than 40 minutes, that we do have a big area of uncertainty, which kind of is all around Dora because it's not enforced yet. There are some guidelines. There will be some incidents. There will be some learnings. There will be a lot of lunches we've learned. And over time, this will disappear.
But right now, we're trying to help you a little bit here. Where would you say the implementation guidelines are still ambiguous? How or where are they for you? And how would you seek clarification? That's a really interesting topic for a lot of organizations at the moment. So, for instance, things like the RTSs themselves are due to be published fairly soon. I think that's around March time that we're looking to see those.
And there are still quite a few big question marks around things like a lot of organizations are interested in pooled testing, for instance, and the kind of the role of service providers that a lot of organizations will use for. There are still, dare I say it, quite a few question marks, lacks of answers, even from sort of the kind of the top down, the authorities themselves about sort of how that will play out. And that shows the complexity of this and what's trying to be achieved.
So it's trying to tie organizations together to get them to communicate and to be able to share that data in a collaborative way. But the reality of that is very difficult to implement. Sorry, could you remind me of the question again? Yeah, sure. We've been talking about unclear guidelines and how you would seek clarification for them.
Yeah, absolutely. So in terms of the way that you would be able to seek guidance for such a thing, speaking to the authority that you have in your region or when that's assigned and sort of getting the guidance directly from them is definitely a good thing to do. So being communicative, almost over-communicative, and asking those questions is the right approach.
And it's been something that's worked for sort of organizations trying to get themselves ready for Tiber testing in years past, for instance. Talking, asking the question of your authority once they've been enshrined, hopefully in March, will be the right way to make sure that you've got the right information and the right point of contact, if that makes sense, or the right structure and the right approach.
For what level of compliance would you aim usually you should aim for good enough to pass, an audit you should also take the opportunity to look a little bit through the cyber security of your organization, what kind of level would you recommend for your clients to implement in order to not really get in any big trouble? Do everything as best as you can, ask as many questions as you can, and then you should be at least okay?
Well, it is possible to ask too many questions and to force yourself down a path that's too complex. So I would start with the questions to understand the size of that delta to start with. In terms of the.
Do the best that you can approach um i think it's difficult to go wrong but that you know the reality the commercial reality of that can be can be quite challenging um it could cost quite a lot to be able to do the best you can and you may not get business support for it or investment or funding whatever it might be so the minimum level is probably the realistic level for a lot of organizations in this instance um but have a plan a plan
rather to improve beyond that point and a structured set of goals that you want to exceed that. Start with that minimal and work your way up. And in continuous improvement and showing that continuous improvement in your approach, your thinking, your documentation and the process and building that out over time is the right way to stay ahead of that curve. If you treat this as point in time, I'm good for now.
Nothing changes, that the world changes around you. You will find that there is a compliance gap 12 months, 18 months, 24 months away so make sure that you are hitting that minimum at least to start with as much as possible and then planning forward to try and get better over time and i think that's what this is trying to encourage i was aiming for the continuous improvement as well as i've seen a lot of consulting projects
in the past they they really blow up they they became much much bigger than you would expect and that's what you've been referring to with the exploding costs so um Basically, you should aim at a level where you feel secure that you've done enough. And as you said, you can ask too many questions. And guys, keep in mind, this is not a regulatory or legal advice here. That is just a place to start doing your own homework. Josh, I do believe I bothered you with a lot of questions here.
We talked a lot of high-level stuff, and I do believe some people listening to this really got some value added out of it because they have now some areas where they can think and rethink their approach to DORA. Thank you very much. Thank you. That's all folks. Find more news, streams, events, and interviews at www.startuprad.io. Remember, sharing is caring. Music.