Welcome
Hello everyone. Hopefully you can all hear me. Can I get some thumbs up if you guys can hear me? Oh yeah, cool, great. Excellent. And you can see the screen. Let's have more thumbs up for that would be awesome. Even better. Cool. I would say can you see me, but as daunting as it is, so I'll leave that one. Sweet. We'll give everyone just a just another minute or so just to join and then we'll make a start.
Sweet. Number slightly rising. Less is better. Sweet. Well, I mean, it is recorded, so we can always come back to this at a later date or they can always come back and rewatch the recording, but I think we should get started, guys. So, just to kind of start things off nice and easily for you. I don't expect this to take a solid hour. But if you've got any questions, please put them in the chat.
And then at the end, I'll do my best to response kind of respond to them or I'll reach out to you guys privately where required depending on time, etc. But this is obviously episode two of the comply cry series. It's we're focused seriously and strongly around the Digital Operational Resilience Act. So, for those that don't know, this has already been out for quite a while, at least a year, I think, January from memory last year.
I could be slightly wrong, but I'll see that in a minute.
What DORA is and why it exists
But this is again part of that Comply or Cry series that we've got running and it's really designed for those and I'm assuming anyone on this call today has customers who focus on the financial sector in EU. So, I don't know if we could get some thumbs up, please, to confirm that you are all having to deal with EU regulations. Yeah, got quite a few of you there. Sweet. Yes, so very relevant to what we're having to deal with today.
So, this episode is designed quite literally to cover the might soft element, what we as MSPs have to deal with. Are we actually impacted? Talk a bit more about the journey the door is in terms of where it started, what we're looking to deal with, areas we need to focus on. And where I've been dealing with Dora for the past kind of, let's say, 18 months or so, I've got a couple of opportunities and links I can give you from areas of what I've worked on in the past, an Excel sheet, which is kind of like a readiness check sheet for you.
I've also taken that and compiled it into a kind of a HTML report that kind of gives you guys an overview of exactly what is relevant to you guys. So, to get started, I think it's better to start with what is Dora. And for those who don't know, this is in specifically designed by Microsoft to a degree of not Microsoft, sorry, EU laws and regulations to reshape the industry. So, take all of the random tools, let's put it, from different countries, the posture that they've and create a single consistent framework.
And that's essentially where Dora has come from. So, it's been labeled Dora, Digital Operational Resilience Act. And it is an EU regulation that's reshaping our entire financial services sector for managed ICT risk. And the best way probably to describe it is we've seen too many cyber incidents and IT outages hitting banks and insurers in the past kind of several years. And it's got to the point where as an EU collective, the Amear Collective, we've there's an approach that's been made to make a unified rulebook.
An area where we, particularly as MSPs and ICT services and risk, it are basically being redefined and reshaped. So, to kind of put it into perspective for you guys, this is the two key areas under DORA that I think's worth talking about more than anything.
Technical standards: left and right of boom
And is regulatory technical standards and implementing technical standards. And these are the two specific unique differences within DORA that are probably our most primary focus, particularly in the ICTA space. And you can probably read this on the screen, but I'll read out some of it to you. It's a legally binding how-to comply rules detailing DORA's requirements. And this is the controls, governance, and evidence part. And I'll show you a bit later on in a couple more slides around the mappings of these specifically.
But it's really important to understand the two key areas around DORA that we have to focus on. So, the regulatory technical standards and the implementing technical standards are essentially really key to us. And I would almost see this as two slightly different ones. It's if you've seen any of the webinar series we've done in force there, think of RTS as more your left of boom controls, your governance piece, making sure the controls are in place, the governance is there, and we can produce evidence around those controls and governance.
And the implementing technical standards is that incident response. It's almost right of boom. If we had an incident, what are the formats, controls, and procedures that we're implementing as a result of those control as a result of those breaches or configuration issues, shall we say? And for you guys as MSPs, the reason why this matters so much is we're at the forefront of the ICT or the IT foundations that we build for our customers. We, particularly in this call, and I would imagine this is for all of you that are on here, where we support financially regulated firms, we're pivotal in testing results, third-party registration of configurations.
We work with third-party vendors to make sure those are in place. The policies we implement, not just Microsoft specific, but firewall policies on a network infrastructure level to specific controls built on a switch and a VLANs that are configured. All of those elements are all included in that DORA framework or regulate regulations that we need to consider. And every single one of those, and I'll again I'll show you some things beyond Microsoft 365 a bit later, but each one of those elements we have to have the exact same RTS and ITS standards.
And we have to be able to measure it and demonstrate it. And the key thing here is when we talk about delivering this and demonstrating it to auditors is we essentially kind of need a checklist and a bit of a paperwork spec of what areas we need to align and control towards. I do have a check sheet for modern work, which I will give to you guys at the end, so this will come out in an email.
So I'm not leaving you empty-handed with anything. I do want to make sure you've got something that you can refer back to as we look to kind of really be focused on the regulations. And we are going to get to the point where companies that we support now, and there is nearly 64 of us on this call, and I'm sure it'll rise a bit later, but we're all going to be managing, let's say a minimum of 10 or more customers.
At some point one of you guys is going to end up with an audit, and we're going to need to make sure we're ready for it because there isn't an area of oh sorry, we didn't realize. We are going to be told we have to have this ready, and we need to be able to demonstrate it properly. So, what is the what is DORA specifically? And it's important to kind of get some of the terms out clearly, I would probably say, but it's a regulation EU 2022 2554.
Who DORA applies to
It's a regulation that strengthens the digital resilience of financial entities, and it's been effective since the 17th of January 2025. It's designed to ensure banks, insurers, investment firms, and IT service providers, aka yourselves on the call today, can withstand, respond to, and recover from IT disruptions. And this applies to 21 types of financial entities. I don't have a full list of those, but I do and I will share that with you at the end. It's a design to extend to third-party MSPs.
So, this includes not just MSPs specifically, but it is any IT vendor that provides some level of support. And believe it or not, guys, that includes companies that provide print management or printers or some form of technology as a service. Bloomberg is a really good example. They have to adhere to these same resilient acts. They are providing a level of technology through these financial entities. So, pretty much the entire supply chain that works with an EU-regulated financial firm will have to adhere to these same operations.
And the ones that are most at risk are the guys that are on this call today. It's the ability for us we've got to make sure that we are looking at ourselves and paying making sure the paint the picture we paint for us is as secure as we would be making our financial customers. And we are even more at risk because we also provide and have the keys to the kingdom for some of their key applications, you know, administrative access to on-prem servers, additional access to Bloomberg, Global Relay if you're using archiving and journaling.
We actually have logins, which means we are almost as you know, risk averse or risky as any other financial company. And in fact, we're probably a higher target now that with DORA in place and financial services becoming more and more stricter that actually we're going to be the prime focus of areas of breaching. And that means we essentially need to have the same level of security and foundations in there. And the idea of this act is to harmonize as it says there already the IT risk management rules across all EU member states.
So, when I said to you earlier, every single country had their own fragmented rules. Absolutely accurate. You know, probably the strongest of those was probably closer to Switzerland and then maybe looking at Germany, but there was a lot of lax rules and controls in place that perhaps weren't enforced across different country states. So, enforcing this is meant that we all now look to one single consistent framework. No longer are we looking at kind of fragmented services and for MSPs, I'm sure you'll all appreciate that was a pain to begin with.
We had to go through and look at different countries and understand their regulations. Having this consolidated is actually going to make it slightly easier. It doesn't stop financial companies that have organizations or offices in other countries like Japan, Australia, the US, we still have regulations and rules we have to adhere to there as well, but it does start to consolidate where that residency sits specifically. So, let's talk about the key areas within DORA. There are five pillars that we need to think about.
Five pillars that we have to work towards and identify. And each one, because they directly affect what financial customers demand from us, it's a well, from themselves essentially affect us specifically.
The five pillars of DORA
And the first one's risk management. So, identifying, as- assessing, and might- mitigating IT risks. And it starts with that comprehensive framework that we have in place already. That means governance, oversight, and continuous monitoring. So, this is where probably you're leveraging enforcement, I'll say this towards the end is making sure that what we implement, we can detect regularly. So, we might have network solutions that monitoring our network such as Orvik and other products from vendors like that, where we can trace what's going on the network and that would be the same on device endpoints where we might leverage Defender for Endpoint Suite and the XDR to monitor the traffic that's going on the endpoints as well.
And that's applies across the board for the services and infrastructure that we do. The one's incident reporting. So, we need to be able to detect, classify, and report on major IT incidents to regulators. This is something that most particularly if you're part of the UK now, this is areas that we've always had to deal with, but it's very much enforced now as a requirement as part of Dora. There are regulations in different industries or countries, I should say, where incident reporting to regulators was not necessary requirement and it was a discretion.
Maybe we should, maybe we shouldn't. Naturally, a lot of kind of businesses would always go and speak to regulator if it was a huge breach where clearly data has been leaked like customer information, but this now makes it far stricter. We have set timelines. We have templates of standardization of what a regulator is required to be received. So, it might be a global admin account now has been breached and someone's had access for a week but hasn't received any data, that's still part of a standardized template and it still has a strict timeline on when we should be providing that information.
In some instances, it's as soon as 7 days in terms of delivery and it's worth looking that up specifically and understanding it. It could be sooner. I'll be honest, I'm pretty sure it's around 7 days for a clear-cut breach data leakage. And that gives us time to create those reports and provide information, but we do have a responsibility to report it sooner. The next one is digital resilience testing. So, this is where penetration tests kick in, disaster recovery plans, business continuity designs and configurations.
We do have leads every 3 years as a requirement for lead penetra- threat lead penetration testing. So, TLPT is a huge conversation point that's being had around digital resilience testing and I know there are lots of banks and organizations that having further discussions around that every 3-year model because in some instances if you are registered in the UK, that's actually a yearly requirement. But outside of the UK, we're now saying it's a 3-year critical systems.
And this is everything. It's not just can I breach the environment externally, we're also looking at internal pen test as well. So there's much more kind of broad spectrum required broad spectrum requirements for digital resilience and testing specifically. Then our fourth pillar is third party risk management. And this really is where we sit. So we're already responsible for the first three and we're actually responsible for all five. But the one that really hits us and they have to make sure we're as prepared for is third party risk management.
So maintain register all of our all IT providers in full contractual compliance and ensure exit strategies are in place. So we should already be and if we're not, we will be approached by our current financial firms to make sure we have specific compliance requirements in our own organization. And that's got guys is going to stem from our current employee contracts, employee processes, our own internal policies that we're writing. But it's also providing evidence. We will be challenged and we will be asked to provide evidence that we have things like data loss prevention in our own organization.
Data leakage is covered. So where we're using third party platforms for documentation like IT Glue, guess what? They're also part of this third party risk management because it's a product that we use as MSPs. So we have to now be completely resilient in terms of what do we deliver for our customers in a financial services firm and how do we manage their data specifically? And this is where we're going to be updating our contracts, providing exit strategies.
These are all controls that they will put into place and almost enforce. So if there's a breach with that MSP, what's the contract strategy? What's the strategy to exit that organization so that we can continue to maintain safety and security as a financial services firm. That risk is huge for us. We need to make sure that we've got all of our items and eggs in one basket but also the controls in place to make sure that we know what we're delivering and how we're delivering it.
The biggest success when it comes to this fourth pillar is you guys on this call today have the confidence to say to your customers, we have these controls in place. And it's got to the point and we're already well over a year into having this enforced, but if we don't have these measurements in place today, we don't really know where we sit. So, part of the end of this session of webinar and when we send you the HTML file that I've got or PDF so to speak, I've got a 90-day DORA readiness plan for you guys to walk away with where you guys get yourselves prepared, ready to go so that in the next 3 months you could confidently say to your customers, pillar four we're already meeting, we're already hitting the mark for as we speak.
And the fifth pillar is information sharing. So, this sits with Purview, data governance, the curve Purview and Copilot workshops we've been doing already, but it's sharing cyber threat intelligence. So, we're taking it one step further. We're looking at what the threat intelligence is within trusted communities, and we need to make a collective defense mechanism or structure around the financial sector. And this is really encouraging regulations, regulatory businesses to share information, but it's part of that DORA five pillar piece.
And actually, we're a big area of confidence and trust for this. You know, there's a level of expe- expectation I should say for anyone internal to an IT team, bank or financial services firm, and also the MSPs to make sure that we're providing the right cyber threats. So, if you sign up to DORA today to receive information, as a community they will be providing information to share around cyber threats, latest intelligence that perhaps we should be working on to improve our financial customers' environments and services.
I'd also just take a spin on this before I move to the next slide, but I'd also consider how can we benefit our current customers that aren't necessarily financial services because realistically this these set of five pillars, yeah, we have to enforce and we are regulated by financial firms, but if you finish the 90-day plan I'll send you later and you've got these controls in place, there is nothing really to say is this potentially an opportunities for us to provide a service to a legal industry vertical or a construction industry vertical.
There are opportunities here that you guys will be able to see for other customers and prospects that you're working with outside of the financial sector and I just want to make sure you're thinking that through alongside this. I'll just be transparent as well. I don't actually have access to see any chats. So if you are communicating, I promise I'll have a look right at the end. I'm not ignoring you as an FYI. So where does DORA sit with 365?
And for me, as part of working here at inforcer, my goal is to give you the ideas and the information around where it all sits within the modern workplace. That's what inforcer is. We support and we service Microsoft 365 multi-tenants. But DORA's a lot more than that and again I'll show you that in just a bit. But for now, where does that sit with modern work? Microsoft 365 is essentially the backbone for almost every single financial organization.
Probably a very small sub-1000 companies will be using other platforms like Google as an example. But this underpins the majority of financial services.
Where DORA meets Microsoft 365
And under DORA, every IT system supporting critical business functions must be governed, monitored, and be resilient. And for you guys here as the MSP, and this is why you're on this call today, we need a multi-tenant management solution that can actually see a single pane of glass of what's going on, email collaboration, identity, our critical IT services. And we have most of that sat in Microsoft 365. So misconfigurations create exploitable attack surfaces and these areas that we need to make sure we're resilient on, we're monitoring.
And most of that starts with left of boom, which is drift detection. So, where does that sit for Dora? So, you'll see on the right-hand side there, we've got six pillars, maybe seven if you had Teams separately. You've got six pillars of controls that are mapped with Dora. So, identity and access management, email security policy with Exchange Online, device compliance and endpoint management, threat detection and response. Granted, you may not be using Defender, you might have another third-party antivirus, but bear in mind if you do, you also need to hold them to account to these Dora regulations.
Purview, data protection and compliance. And again, you might have another third-party that also offers that. So, things like Global Relay for journaling will also have these kind of controls that need to be mapped. And then SharePoint and Teams, which is your collaboration and governance. Everything in these elements are 100% mapped to some form of controls within Dora. And we need to make sure that these are protected and secure. And we already know with many conversations we have and why you're on this call again today is it's all about the identity being that new perimeter, that new area that we have to manage.
And this is why these sort of controls for Dora take place. We have so many breaches, cyber breaches, not just in the financial sector, but across multiple industry verticals. And actually, most of it stems from email and identity. And email sits in identity in terms of what we receive. Phishing campaigns are based on the licenses and the identities of the targeting. So, it's really important that we have a good, strong understanding of what we're delivering. And all these is worth mentioning is mapped.
And we need to make sure we've got the right controls. And there are four points to these security controls that are mapped to Dora. And that's prevention and protection. And I would say this is left of boom.
Prevention, protection, detection and response
So, our conditional access policies for risk-based authentication, controls to protect what's going on with identity, MFA enforcement across all user accounts. Again, going back to data governance, it's data loss prevention policies are enforced, are in place, and guess what? Dora requires those. They do provide recommendations and guidance. Intune device compliance with baselines. If your endpoints are managed in Intune, then again, it's mapped to Dora, and we have the right controls in place for prevention and protection.
And then the last one which we all struggle with, and I would love thumbs up if you agree with me, is applying sensitivity labeling and encryption. It's a difficult conversation, but it's very much something that's required as part of financial services. So, question for you all on the call, do you have financial services firms that do have sensitivity labeling in place already, or have started a project for this? To be fair, I can't see if you're giving me thumbs up, cuz all I can see is one person.
Let's try that again. One, two. I can see two thumbs up. That is terrifying. Okay. Cool. And one hand up. Thank you. So, we've got three companies that provide sensitivity labeling for financial firms. Probably got quite a lot of work cut out for ourselves. Oh, there's another one. Four, five. Okay. Looks like you've all started listing in again. And then the other area to focus, which again is more on right of boom, guys, is detection and response.
So, this is Defender for endpoint threat monitoring. It's unified audit logging, which is kind of a requirement for incident trials and tracking. It's where detection response sits on providing an understanding of what's happened, understanding the scope and the landscape, and what took place when a breach was in place. And it's detecting it first, and then providing a measured and secure and safe response. And it sits with a lot of those a lot of this kind of sits with the audits and the logs that we retrieve and the monitoring we do.
So, Defender for Endpoint, the XDR solution that Microsoft offers is a really good foundation for us to use. It's a single pane of glass. It's an area where we can focus our information and our resources on when we talk about detection and response. And we do use quite a lot of SOC companies and I'm sure most of you would agree that we do for our financial firms have a dedicated SOC or seen-based solution that they can use.
And that's really sits with them detection and response. And the better that our prevention and protection is on the left, so left of boom, the less alerts and the less risks that we have to deal with on detection and response, which makes our financial services customers significantly more secure, protective, and preventative. So, talking a bit more about DORA is great. But where does this really sit for you guys specifically? And why MSPs are directly in scope.
I think we've said all along that this really does target us, but it really sits with understanding why we think or why we know DORA applies to ourselves.
Why MSPs are directly in scope
So, MSPs are classified as IT third-party service providers. Financial clients must verify DORA compliance. And DORA has a trickle-down effect. You must also verify your own third-party suppliers. So, again, it's not just IT in this instance. It's actually the supply chain of a financially financial services firm. So, if they're trading with Bloomberg trading screen and all those other bits and pieces, again, they're held to account when it comes to third-party suppliers. And the customer location EU, it determines not a scope and not a loca- determines the scope, not necessarily a location.
So, if they have any office, if they have any person or an individual that sits in this EU scope, the EMEA scope, quite frankly, they're all applied to them. So, DORA will be held to account with someone that's perhaps sat in France for two weeks is doing trading. To degree that Dora requirement, he actually does sit with that individual business. It's not necessarily country and regional specific. And then last area is non-compliance risks. Losing financial sector clients entirely.
So, if we don't have the right compliance in place as an MSP, we essentially have to say goodbye to our financial customer firms because they do need to meet Dora requirements. And so, there are levels and expectations where we have a minimum requirement and that minimum requirement is going to be exactly the same as the customers we have for financial services firms. And that's where that trickle down effect sits in. So, I want to talk about the key obligations for you guys.
And I've broken this down into the five specific areas because it really does sit with you for the majority of those five pillars and trying to marry up with the five pillars.
Key obligations for MSPs
First one's cooperation and auditing. We have to fully cooperate with inspections done by finite financial regulators and lead Believe it or not, if they come to us and approach us with making sure that we meet regulations, we need to make sure that we're cooperative because if we don't, there are some levels of accountability against the financial customer that you're supporting. We need to make sure that we have all the audit information in place. So, if you are not already aware, 7 years minimum required in unified logging.
Get it turned on today. Again, using Forcepoint to do so. Business continuity. Implement and test contingency plans with documented recovery capabilities. This is not just for your customer. This is also for yourselves. Business continuity plans should technically be created by the financial services firm and we should be helping them on that journey. But we absolutely have to have BC in place for ourselves. We've also got contractual compliance. And I said this to you earlier and I showed you on the slide earlier.
We actually now have to make sure that our contracts with our customers in the financial sector have compliance requirements met. Again, it's in the HTML for you guys to read a bit later on. But, what does that look like? Do we be proactive and update our compliance contracts? The answer is our contract, sorry. The answer is yes. Because we're liable at the moment. So, if our financial services firms don't know what they're doing, they don't have these conversations we're having today, then we should be being proactive and updating our own contracts to make sure we meet compliance requirements for DORA.
It's mandatory It's a mandatory requirement. Last two is exit strategy. So, ensure an orderly transition plan exists for critical services. Now, this isn't getting rid of a customer in any means. It's understanding that if they were to transition away, we cannot be left held accountable. So, for your own safety, your own regulations, your own compliance as a company, we need to make sure that when or if and well, if being the word, not when, if they chose to leave, what are the steps that we need to make sure that we have no accountability the moment they go?
It's not a decision we're going to lose a customer, and that's not the approach I'm taking. My concept for you guys is just to think about when we do that transition and if we do that transition, what does it look like and how does it work? And then our last one is supply chain verification. There is more than this, guys. This is just a handful of them to start with, but verify that your own vendors also comply with DORA standards.
And this is your responsibility. So, you need to go to your vendors. So, that's going to be your IT guru. It's going to be your RMM. To the great going to be in full swing. Good news is we're pretty much there. It's going through and making sure that we comply with DORA standards as well. Because if we're hosting, managing, reviewing information like this, it's a responsibility that sits with you guys to make sure your supply chain is also protected.
And I hate saying this showing this slide, but we'll brush over it really quickly. There penalties and consequences, guys. So, for financial entities, it's fines of up to 10 million euros. Believe it or not, for MSPs, it's also up to 5 million euros. It's mandatory remedial measures from regulators.
Penalties, and DORA beyond Microsoft 365
For critical IT providers, up to 1% of average daily worldwide turnover will also be fined against and public disclosure of breaches and identifi- and identities. We are liable at that point. And for specifically for the MSP, it's loss of financial sector clients and contracts. And also, it's reputational damage for ourselves. So, it's really important we take the approach of making sure we implement the right measures. And again, we'll show those towards the end. But it There is an impact and it has an impact across everyone within that supply chain.
Because IT providers, it will also affect our supply chain, which is why it's important to also measure. So, brushing over it quickly cuz I hate talking about it, but what is it beyond Microsoft 365? And there are six key areas that we need to consider. And obviously, there's a lot more under each of these bullet points think about, but network infrastructure. We've got our firewalls, VPNs, perimeter security, switches. Those sort of network controls are 100% covered in DORA.
Again, it's an IT estate. It's not just an individual cloud Excuse me, modern cloud so- solution and service. Third-party SaaS solutions. So, are they using a CRM, ERP, accounting platforms? Again, trading, so Bloomberg, all of those are also covered in DORA. Supply chain oversight. Subcontractors, compliance verifications, all of those again covered inside the DORA requirements. Governance documentation. On-premises systems, so active directory, file servers, legacy applications. This is where we're going to start seeing a massive change in our financial services that perhaps have a thousand little tiny Linux Ubuntu or Red Hat boxes sat in Azure that haven't been updated for the past 20 years where they've been lifted and shifted.
Guess what? They're going to be held to account with DORA. So, there going to be new restrictions blocking them down, locking them further. And then the other one's back up in recovery, immutable backups with 2-hour recovery targets. Can you believe that? They'd actually set mandates for some of these requirements and controls. So, if we've got backup solutions in place, we have 2-hour recovery target requirements for a handful of those security environments and controls. So, think about the business continuity to plans.
What you're seeing today on this call and what we're discussing right now is actually a whole large piece of work that us as MSPs are going to have to do for each of our financial services firms, and where we support more than one, we have an opportunity to do some level of automation, but there's a lot of work we have to do, and it's an opportunity for us to approach our customers around DORA, have those conversations, make sure the compliance pieces are in place.
So, without anything can as always it's always important to understand where does inforcer sit. So, what can we do to support you guys and support the DORA compliance? So, again, following that kind of five-pillar tier, and I know there's going to be more than just this, but security baselines is a hot topic when it comes to supporting the DORA compliance.
How inforcer supports DORA compliance
So, taking in 365 is you guys have a standard set of controls for your financial vertical, really helps to define how secure your customers are. And again, tenant alignment reporting inforcer will help you to prove they're aligned to the correct security standards that they need. You've got drift detection. So, like any detection and response solution, we have to have continuous monitoring. And on Left of Boom, it's monitoring those security risks and those security policies. So, if someone makes a change, we need to know about it, not just for evidence's sake, but also to make sure that we're not opening gaps of vulnerability.
You've got your compliance reporting. So, branded audit reports and the evidence DORA compliance to regulators. Leveraging our assessment engine or our tenant audit report with policy tags to say these policies meet DORA, for example. All of those elements really helps to drive a successful compliance report that we can also present to our regulators and inspectors that come and approach us. And it's also multi-tenant management. So, manage hundreds of M365 tenants from a single pane of glass.
If you've got 50, 60, 70, 80, 90, 100 financial sector firms, we need to be able to maintain and control that sensibly. We're MSP, we don't have 15,000 employees to manage a handful of financial services firms. We have hundreds of customers and we've got lots of work we have to do. So, we need to be agile and our multi-tenant management solution allows us to be agile. The next one's auto remediation. So, the ability to identify the drift and go back into the platform and then manually change that control.
Also, configuration at some point will be in place which will be helping us manually, but at the moment, we get the drift detection, we're able to go in and we're able to reverse those changes that take place. I just want to talk promise you I'm wrapping up very shortly, guys, but enforcement map to DORA pillars. So, it's really useful to see where we map to some of those five pillars that we spoke about earlier. So, risk management, baseline enforcement, drift detection, and risk-based tenant assessments at tenant audit report ticks the box towards Microsoft 365 in DORA for ICT risk management.
Your incident reporting, real-time alerting on policy changes and configuration on all of these, that's that drift detection piece, allows us to make sure we are reporting on the correct incidents. It also is leveraged with unified logging with Purview. You know, we've got the ability to make sure that policy's in place and we're meeting a seven-year requirement as an example. That contributes towards that incident reporting. You've got your resilience testing. So, resilience testing is far more than just Microsoft 365 as we've already discussed, but we can make sure we've got custom tenant assessments that can prove that customers are mapping to the right security controls and frameworks that are recommended within Dora.
Then you've got your third-party risks, so audit-ready compliance reports for regulatory regulations and financial clients. We need to make sure that we've already audited our third-party risks. What are inside our supply chain that we need to make sure is being met with financial regulations, and make sure we've got compliance reports. Companies like in fourth or another vendors will have trust centers you can leverage make sure they've got their own protection in place as well. And actually, it might be an opportunity for you guys to build your own trust center with your own reporting, so it's easy for your financial services firms to collect that information.
And the last one's information sharing. Standardized reporting enabling transparent posture communication. We have to be transparent. Where we work with cyber where we work sorry with financial firms and they have cyber threats and breaches, there needs to be a level of a community-driven support model. Where we talk about breaches in the financial sector, it applies and it impacts the global economy. So, it sounds really cheesy and it sounds like, well, we don't really need to do it cuz we're just a small 15, 20, 30-man band MSP, but if you guys see a breach, sharing that cyber threat globally on a community level will help improve the security posture for financial services firms.
And that's why it's part of Dora. It's enforcing information sharing around breaches so that we can prevent it with other and other firms. I think it's a really smart approach, very similar to how inforcer is bringing MSPs into a big community on Discord is we want information sharing so that we can all support one another in terms of the best security standards. It's not just about you guys, it's about protecting your customers. And this rings very true to people that have to follow the Dora regulations.
So, to wrap it up for you, this is what we're going to provide you.
Readiness resources and Q&A
So, I have a HTML report that talks around DORA and Microsoft 365 and what MSPs need to know. The regulation, when it's when it was enforced, the scope, what are you in scope for, what needs to what maps and impact sorry that there are for you, and then how 365 controls are mapped to DORA. I don't want you to walk away today with I've got loads to do, where do I start? I want to make sure you've got as much information as you have ready.
One of the other things I've got is my DORA MSP readiness dashboard. So, this gives you a full breakdown you'll see with DORA controls, contract checklist, instant classification and risk registers. You guys need to make sure you're already ready to support them. And on the HTML page you'll see you've also got a 90-day readiness plan which I've not got a snapshot of. But, it's an opportunity for you guys to start that leverage and start that journey with you guys as customers.
So, without further ado, are you guys ready to tackle DORA would be my question. I'd like to think the answer is no because there's loads to do and there's lots to look at. But yeah, thank you very much for your time. I'm going to give you guys 5 minutes if you've got some questions. I'd love to try and answer some of them. And where I think I've got no I no way of answering them, I'll come back to you and go from there.
I can see actually Shingle's note taker was added. By Shingy's note taker. So, that's not really helpful. But, I do see some Q&A. So, 1 second. Jesus, there's lots. Will the assessment function get a DORA focused assessment? Yes, Daniel, the answer is you will do at some point. It won't be until after this two directive which we're releasing first. How far down the chain does DORA apply? How far is too far? Jonathan, the answer is I genuinely don't know.
I think it goes quite deep. And I would be inclined to suggest we it really probably targets the IT team and their supply chain. I don't necessarily think it goes past that. But to be transparent, I'd need to read the documentation a bit further to really understand the deep dive. And your other follow-up question, if the UK-based company has separate UK-based MSPs to do UK-based company and UK-based MSP have to comply with DORA, the answer is yes.
They absolutely do. Are the DORA requirements covered in ISO standards? I believe that it's partially covered, but I'll have to check with you, Ollie. So, I'll come back to you and let you know. If you fail a DORA audit, what time frame you get to get compliance? So, my understanding is it's very similar to SOC 2 type 2 and ISO 27001 in that it's almost a continuing monitoring for up to 12 months. So, you'll be given a 12-month window to make sure you have those things in place.
In terms of if you fail, you're not technically allowed to fail. So, it would be more a case of we're already working on the road maps, which again, is very similar to ISO. You might end up with things similar to the naming convention of non-conformities. It's been around for just over a year. I don't even think DORA really understand the measurements they need to put in place just yet. So, there'll be levels of interpretation thereafter. Cool.
I think I've answered all your questions, guys. Any anything else, please reach out to us directly. If you are a prospect and you want to know more, then obviously book a demo and have a chat with us further. And we'll get those HTML and Excel sheets sent to you shortly, but thank you very much for joining and have a good rest of the day.