Comply or Cry

Comply or Cry - Episode 1: Why Everyone's Crying

In this first episode, Microsoft 365 Solutions Architects Dakota McElligott and Tim Oelkers map the landscape: why frameworks exist, what they want, and the critical difference between what you're required to do versus what's merely recommended.

Hello everyone. Let's give everyone just a couple of minutes to join. But welcome to everyone that's already here. And there's a thumbs up. It's already a good sign. That means everyone can hear us. Love. Yeah, I always ask. Hi Tim. Hi Stuart. Love how you're already straight on the uh the chats which is great. Thank you for the reactions. Appreciate we will kick off guys in just we'll do it like 3 minutes past or so. Just give everyone just a bit more time to join. Number is steadily rising. I'm sure it'll keep going for a bit longer. Oh, I think we should get started. Um, well guys, it's great to meet you. Um, everyone that's on the call currently. Uh, this is being hosted by myself and and Dakota, but we're we're here really just to talk around about compliance regulations and frameworks, which is the big deep dive that we're going to be doing here. Um, but we'll start off with some introductions because I think that's always good. I'll pass over to to Dak to go through that with you guys. Um, but just to go introduce myself, I'm Tim, one of our solutions architects here. I've been in the MSP space for around 11 years as a solutions architect. Um, and for the far past kind of five years, I've been focused in the MSP space in central London mainly on financial vertical. So very familiar with some of those crappy frameworks we have to adhere to like N2 directive, DORA that's now come out and a few others. And we kind of took took it upon ourselves to decide this is a good opportunity to go through some of these frameworks but over to yourself D for an intro. Hi everyone, nice to meet you. My name is Dakota Mcelli. I have been at inforcer since last year in October and before that I worked at Center for Internet Security or CIS. Um, when I worked at CIS, I worked on the development of the benchmarks, controls, implementing them into our tools and then also helping our customers as well implement them and use those recommendations. Um, so that's my foundational compliance background and then from there uh got a wide-scope overview of about 30 different frameworks because CIS on-ramps to those other frameworks. So had to kind of learn those uh like the back of my hand because I had to talk about them pretty frequently. Um, pretty in-depth experience with FFIC um from a banking perspective as well. So that's a fun little tidbit I didn't know about Tim and I having something in common in addition to Microsoft 365. Um, but yeah, so a lot of fun. Uh I don't think you probably will hear this often, but I do love compliance. So I'm excited to be here today and talk about that with you all. You're absolutely crazy. I love it. Awesome. Awesome. So I will go ahead and take control of the slide deck and then we will move forward. So just to get started, right? Um let's level set why the series even exists. Um compliance frameworks as we've kind of talked about already uh have absolutely exploded um over the last few years. So at the same time, Microsoft 365 has ended up right in the crosshairs of almost all of those frameworks. Um and that's not accidental, right? Identity, email, data, devices, they all live within Microsoft 365. Uh so regulators have noticed that. Um, and the goal of this series isn't to overwhelm you all with a bunch of acronyms and be like, "This is what you need to do exactly to be um, adherent to XYZ." It's to really give you a map and kind of guidance on where to start and where to go from a foundation that you've actually built. Um, you know, we're the goal too is to also give you a way to understand why these frameworks exist, um how they relate to each other and then also just how Microsoft 365 actually fits into that greater picture. Um right because you can't necessarily be wholly compliant to like let's say HIPAA just based on Microsoft 365. Obviously there's a lot of other things that uh work into that. But we're really just trying to focus on and help you and assist you with the Microsoft 365 puzzle piece. Absolutely. So this again didn't happen out of nowhere, right? Uh we had uh supply chain attacks, those changed the rules. Uh suddenly risk wasn't just your own controls, but it was every single vendor that you trust. Um and then ransomware went from just like an IT problem to a board level incident and then regulators responded to that with mandatory controls instead of actual guidance. Right? So at the same time, organizations rushed into the cloud faster than governance models could actually keep up. And now we're at this really odd place where it's like, where do we go from here? Uh, and now obviously I have to say the token word. It'll probably be mentioned multiple times today. AI has quietly added a new problem of data leakage. Uh, so most organizations don't even realize it because how are you tracking shadow AI? What does that visibility look like? Um, so the key takeaway here, right, frameworks exploded as a reaction, not because regulators love paperwork. Um, I don't know anyone that loves paperwork, but because the risk model fundamentally changed. It's going to continually change from here as well. Um, so we need to prioritize and level set where to go from here and kind of create a canonical control set from all of these different requirements. So I guess rolling into that really nicely guys is where do we start with with what we can manage and for us most of the things we work with with customers is the Microsoft 365 control plane. Um and every single one of these frameworks touches the pillars you see in front of you. So identity and access, data protection, devices, logging and detection, all of those functions are fully available and usable for these frameworks that we're touching or talking about throughout this series. And this whole idea and concept spec sorry, especially for what we're doing today is to give you guys an idea of where things sit because as Dak already said, not every single element of a framework is just Microsoft 365. Some of its operational controls. So, what are your policies that you've written into employment contracts? Are we making sure that our vendor list is meeting safeguarding protocols and meeting those standards? But what we do want to make sure we're touching on when we come around these sort of topics is where can firstly inforcer help you guys in meeting some of these control plane requirements for those frameworks, but also making sure you guys know exactly where things sit. And this brings me on to one of the areas we really want to touch on, which is what is a requirement versus recommendations. Because most people think every single framework we look at is a requirement, whether it's legal or otherwise. And the reality is that's not always the case. Not all frameworks are created equally. That's first and foremost important thing to be fully aware of. And understanding the distinction changes the way that we prioritize what we implement. So for both me and Dak we've got experience in the financial industry and understanding some of those frameworks and it's really important to know that actually they are regulated firms and so there are regulations we have to adhere to and again not all of it is Microsoft 365 specifically but there are areas in which we do have to make sure there are regulations that are met and a lot of that and in fact almost all of it really sits with the IT department to a degree outside of compliance risk and legal and HR every single point has a touching pillar with an MSP or an internal IT department and it's important for us to understand where we sit and what we should be doing and how we can help our customers ensure that those regulations are in place. But you can see in front of you, you've got your requirements which are legal, your recommendations which are guidance. The legally mandated compliance is the biggest pain in our ass. It's the most stressful point that most of our customers go through. Most people think of it as a point in time kind of audit that's done when we talk about regulations, but with the latest controls and mandatory requirements, that's seriously excelled. We've now got to the point where we're mandated to do something. It's not just a one point in time measurement now. We actually have to have continuous proof, continuous monitoring of those services. And a really good example of that is platforms like, well, a really good example is ourselves. SOC 2 Type 2 is an example. It's a continuous monitoring of making sure we're adhering to those requirements within the SOC 2 framework. So where you might have a point in time for an original framework, we then also have to make sure that we are mandated and continuously monitoring what we've implemented. And this applies to the majority of those legal requirements. It's transitioned from a point in time. Cyber Essentials on its own as an example is just a point in time reference, is really easy to get. Sometimes we recommend we don't make mistakes or mislead the regulators but we absolutely do make sure it's a point in time, whereas Cyber Essentials Plus now starts looking at continuous monitoring and that's the same with DORA, NIS 2 directive and other controls. And you look at recommendations which is our guidance and this is where Dak specializes the most with CIS. It's best practice guidance, where should we start and how do we implement these changes. Sometimes it's not just again Microsoft 365 specific but there are controls that are recommended as guidance and this stems from all of these measurements, NIST, CSF, the maturity-based self assessments is what really drives our success here but it's guidance-led. And this is why people like Dak and the controls for CIS are so important to us because we understand how we implement those measurements. So what are the three outcomes for every framework and what do they care about? And I think this rings true for everything. Correct me if I'm wrong. But the first one's controls. Put the technical and administrative controls in place to protect your environment. And they're things like MFA, Conditional Access, data loss prevention, endpoint protection, you name it. It's pretty much everything. Then it's policies and roles defining who can do what under what conditions. So yeah, it sits with Conditional Access to a degree, but what level of access do we do? So most MSPs, particularly the ones probably on the call today, we implement privileged identity management in our own environments for elevated access to control ourselves. And we use things like GDAP and Partner Center to control our access to our customer environments. And this is where we define policies and role delivery. So policy assignments. Last point is evidence. How can we prove what we're implementing? And auditors, regulators, and just general best practice guidance that we follow often say, "How can we prove what's in place? Have we got audit logs? Have we created snapshot evidence of what we've implemented and continuously monitored that result as a result?" Sorry. And then the last point is reporting. Can we make sure that what we're presenting is measurable and it's accurate and we can provide that on a regular basis? I think you're up now, Dak. Awesome. So, this series is deliberately modular, right? We separate it into digestible pieces for you all to participate in. Whether you want to watch every single episode that we are launching throughout this webinar series, um but you don't necessarily need to watch every single one, right? Unless you want the entire full picture, really understand what's relevant to you. Um, episode one today is about orientation, right? Really getting you to understand exactly why we're pushing this series and why now. Um, understanding why people currently and organizations, MSPs are struggling and then how to really think about frameworks without, you know, that internal panic of wow there's so many, if I have a customer that's looking for CMMC and then this customer is looking for NIST like where is the baseline? Um, so from there right after we're going to zoom into DORA, CIS, Cyber Essentials for the UK, NIST for the US and then also globally regulated environments as well and then we'll finish by pulling it all together. Um and then kind of seeing what it exactly looks like to make it real at scale. Um so not just compliance on paper, right? Really being able to understand that big picture. So think of this set list. We really want you to participate in all, especially if you're a global reaching MSP, but also kind of like a choose your own adventure based on your role, your region, risk profile, what's really important to you. Um, obviously, we hope that we're entertaining enough for you to join all of them, even if it's not relevant to you, just so you have the knowledge on it. Um, because we're going to try and make it fun, interactive, digestible, etc. But, um, that was kind of the idea behind it being a whole series. So now right it's kind of deciding what frameworks matter to you, which ones do I want to join in particular. Uh one of the biggest mistakes I personally see, um not just with MSPs, this even was happening with my past experience at CIS, right, organizations will make the mistake of assuming that regulations only matter if they're written for their country, right, but in reality especially if you have a global reach, for instance GDPR that hit us internationally. I mean, US cares about that. There's protections in California where privacy that every single state in the US has to take into account when they're working with California customers. It has a global reach. The UK uses Cyber Essentials. The US leans heavily on NIST and CIS. But underneath all of them, right, you keep seeing patterns of identity controls, access management, audibility, evidence, right? The intention here isn't to necessarily learn everything unless you want to. Um, it's know which episodes matter the most to you. Understand how they all connect to that same control plane. Um, I will say like because CIS is a part of the inforcer platform, that's really what we pride ourselves in. Obviously, I'm biased because I come from CIS, but um they have a really really great neural network that connects out to about 30 different frameworks, right? So, it's really nice because not only if you're adhering to CIS controls as recommendations, you can also use that work to map out to about 30 others. Obviously, it's never going to be one-to-one. No framework is. Some of them are pretty close, but I think every framework has their different scope and focus. So, it is really nice to be able to utilize CIS to kind of branch out to the others. Um, and that's kind of the last I'll be on my soap box talking about CIS, but I did want to say that's why I love that it's in the inforcer platform. Um, but again, right, really focusing on the episodes that matter to you, joining those based on your current customer scope and what's happening within your environment is definitely super important. That question for you. Do you find that most frameworks and regulation businesses look to CIS for those recommendations? Um, you know, I was kind of in a silo where that was exactly what I was dealing with every single day. So maybe a little biased based on my experience, but I do think it's a great place to start not only for customers that don't have a security framework requirement. So if you're not focused on critical infrastructure, right, where you have like a HIPAA requirement or you have FFIC, etc., it's a really great place to still get consensus-based guidance on recommendations. So it's not just an internal decision between a few engineers. This is what good looks like. It's actually using a baseline of experts. So, um, I typically will recommend it especially to newer customers, customers without a set framework, more immature internally with SOPs. Yeah, absolutely. Okay, cool. And then I will give it back over to you. Thank you. I just realized it's my turn, so apologies. Um, yeah. So, as we kind of highlighted, some of those that you guys want to pick and choose, by all means, sign up. They're on our website as an FYI. I should have added a link and I didn't do that. So, please jump onto the website and sign up to any of those frameworks that you want to look at more or have a bit of a deep dive into. But the idea of this that we it would be silly for us not to include it, but where does inforcer sit for you guys and how can you leverage parts of our product and software and our own team to help leverage those frameworks? And there's three areas. It's very similar to the defend, govern series that we've done previously. But it's all about giving you the tools to make sure we've got the configuration in place. So we set the policies, we've enforced it. So the way we always use terms with customers we work with, like yourselves, is making it sticky. Um, and those enforcements is making sure those policies stick. So that's drift detection, allowing yourselves to be confident that what you're implementing for your customers is maintained itself. That's part of that continuous monitoring that we're now seeing as mandated controls in some of those frameworks. And the last point is proving the evidence, which for this particular scenario is proving that what you've implemented on those policies, you've got continuous monitoring in place, but you can prove evidence that they're 100% aligned to that framework that you've configured. We only have to date the CIS kind of library that you guys can leverage as those configurations. But it doesn't stop any of you on this call creating those policies and configurations for the other benchmarks and frameworks that are in place and then aligning that framework to your customers. Collecting that evidence has never been easier when we can use things like the alignment report to demonstrate we've implemented X. We can guarantee it's implemented on this customer or this business industry standard. So take the opportunity to look at what you've already got currently in inforcer. Identify some of those industry verticals that you do need to meet those regulations or frameworks towards and then leverage your technical skills but also what's available on the web and what we can offer to you today to make sure you've got those configurations in place. And that's where that configured, enforced, and proven sits for ourselves. We want to make sure you've got the tools to implement the right controls and the right standards. Awesome. So, um, by the end of this episode series, right, um, and hopefully this episode too, this is kind of what we want you to be leaving with. First, obviously clarity on the requirements versus recommendations. Um, and then also what's legally mandatory and then what's just best practice recommendations. Um that sometimes you can even use as an on-ramp to legally mandatory frameworks um because obviously those drive very different prioritization, I'll say, um but they do still kind of work symbiotically together. Um and then second right we want a compliance map, understanding which frameworks actually apply to you personally for your organization and then figuring out why and where to go from there. Um and then also right we want to see Microsoft 365 um not just as a mess of portals as it can be interpreted sometimes just because of how many tabs exist in the admin center um but as a connected control plane across identity, data, devices, logging, visibility, auditing, etc. Um and then finally right we have that mental model. Uh we do have a whole series that Tim actually led of defend, govern, proof. Um if you walk away thinking, okay, now I understand how compliance in terms of M365 works. I see how they map together. I see how they fit into my individual use case. And then this is how I'm going to prioritize it from here. Uh then we've done our job. Definitely.

Comply or Cry - Episode 2: DORA

DORA is law, not guidance. In this episode, Tim Oelkers tells you exactly what's required - incident reporting timelines, ICT risk management, third-party oversight - and which M365 controls satisfy it. Plus: where M365 stops and your wider programme must take over.

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. Some more thumbs up for that would be awesome. Even better. Cool. I would say, can you see me? But it's daunting as it is, so we'll leave that one. Sweet. We'll give everyone just another minute or so just to join and then we'll make a start. Sweet, numbers slowly 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 re-watch 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 at the end I’ll do my best to respond to them or I’ll reach out to you privately where required, depending on time. This is episode two of the compliance cry series. It’s focused seriously and strongly around the Digital Operations Resilience Act. 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, although I could be slightly wrong. This is again part of that compliance cry series that we’ve got running and it’s really designed for those, and I’m assuming anyone on this call today, who has customers focused on the financial sector in the EU. So thumbs up please to confirm you’re all having to deal with EU regulations. Yeah, got quite a few of you there. Sweet. Very relevant to what we’re dealing with today. This episode is designed to cover the Microsoft element, what we as MSPs have to deal with, whether we’re actually impacted, talk more about the journey that DORA is on, where it started, what we need to deal with, and the areas we need to focus on. I’ve been dealing with DORA for about 18 months now and I’ve got a couple of opportunities and links I can give you, including an Excel readiness check sheet and an HTML report that gives you an overview of what’s relevant to you. To get started, it’s fair to start with what is DORA. This is EU law and regulation designed to reshape the industry by taking fragmented country-specific rules and creating a single consistent framework. DORA stands for Digital Operational Resilience Act and it’s an EU regulation reshaping the financial services sector for managed ICT risk. We’ve seen too many cyber incidents and IT outages hit banks and insurers over the past several years, and the EU has created a unified rulebook where MSPs and ICT services are being redefined. Two key areas under DORA are Regulatory Technical Standards and Implementing Technical Standards. These are where our primary focus lies in the ICT space. RTS covers controls, governance and evidence, while ITS focuses on incident response. Think left of boom versus right of boom. RTS ensures controls and governance are in place and evidence can be produced. ITS focuses on how incidents are handled once something goes wrong. For MSPs, this matters because we are at the forefront of the IT foundations for our customers, especially financially regulated firms. We’re pivotal in testing, third-party configurations, policy implementation beyond Microsoft, including firewalls, networks, switches, VLANs, and more. Every part of the IT estate must meet the same RTS and ITS standards, be measured, and be demonstrable. Auditors will expect a checklist and documented evidence. I will share a modern work checklist with you after the session. We’re managing multiple customers, and audits will happen, so we must be ready. DORA is EU regulation 2022/2554, effective from 17 January 2025. It ensures banks, insurers, investment firms, and IT service providers can withstand, respond to, and recover from IT disruptions. It applies to 21 types of financial entities and extends to third-party MSPs and the entire IT supply chain, including print management and SaaS vendors like Bloomberg. The entire supply chain supporting EU-regulated financial firms must comply. MSPs are especially at risk because we hold administrative access to critical systems. With DORA in place, MSPs are now prime targets, so we must meet the same security standards as financial firms. DORA harmonises IT risk rules across EU member states, eliminating fragmented country-based regulations. For MSPs, this simplifies compliance but raises the baseline significantly. There are five key DORA pillars: risk management, incident reporting, digital resilience testing, third-party risk management, and information sharing. Risk management focuses on identifying and mitigating IT risks through governance and continuous monitoring. Incident reporting requires detection, classification, and reporting of IT incidents within strict timelines using standardised templates. Digital resilience testing includes penetration testing, disaster recovery, business continuity, and threat-led penetration testing. Third-party risk management is critical for MSPs, requiring registration of IT providers, contractual compliance, evidence, and exit strategies. MSPs must prove internal controls such as DLP, employee processes, and vendor compliance. Information sharing involves sharing cyber threat intelligence within trusted communities to strengthen collective defence. These pillars also create service opportunities beyond financial services. I don’t have chat access right now but I’ll review it at the end. Looking at Microsoft 365, it underpins nearly all financial services organisations and is therefore directly in scope. Under DORA, systems supporting critical business functions must be governed, monitored, and resilient. MSPs need a multi-tenant management solution with a single pane of glass. Identity, email, device compliance, threat detection, data protection, and collaboration are all mapped to DORA controls. Identity is the new perimeter, and misconfigurations create attack surfaces. Security controls map to prevention, detection, and response. Prevention includes conditional access, MFA, DLP, Intune compliance, and sensitivity labeling. Detection and response include Defender for Endpoint, audit logging, and incident reconstruction. MSPs are directly in scope because financial clients must verify DORA compliance and MSPs must verify their own supply chains. Scope is determined by customer EU presence, not MSP location. Non-compliance risks include loss of financial clients and reputational damage. MSP obligations include cooperation with regulators, business continuity planning, contractual compliance, exit strategies, and supplier verification. Penalties include fines up to €5 million for MSPs, mandatory remedial actions, public disclosure, and contract loss. DORA extends beyond Microsoft 365 to networks, SaaS, supply chains, on-prem systems, and backup and recovery with strict RTO mandates. MSPs must do significant work per customer, but automation opportunities exist. Where inforcer fits is supporting DORA compliance through security baselines, drift detection, compliance reporting, multi-tenant management, and remediation. Inforcer maps to DORA pillars through baseline enforcement, drift detection, audit-ready reporting, and evidence generation. Information sharing is also encouraged, similar to how inforcer supports community collaboration. To wrap up, we’ll provide an HTML report on DORA and Microsoft 365, an MSP readiness dashboard, control checklists, and a 90-day readiness plan. There is a lot to do, and we’ll support you through it. Thank you for your time and I’ll now open up for questions.

Comply or Cry - Episode 3: CIS Controls v8

Not legally required, but one of the most practical frameworks available. This session maps CIS Controls v8 directly to M365 configuration - identity, endpoints, logging, data protection - and explains why 'configured' and 'enforced' are not the same thing across multi-tenant environments.

Comply or Cry - Episode 4: Cyber Essentials

Cyber Essentials is a condition of many UK public sector contracts - and assessors will find gaps if you're not ready. This episode covers what the certification actually requires inside M365, what sits outside it, and how to stay audit-ready between renewals without the last-minute scramble.

Comply or Cry - Episode 5: NIS2 - Driving Pain

NIS2 expanded scope, tightened timelines, and put board-level accountability on the table. If your clients are in energy, health, transport, or digital infrastructure across the EU, this session covers what they must demonstrate - and where M365 controls either deliver or fall short.

Comply or Cry - Episode 6: NIST CSF 2.0 & 800-171

NIST is the common language of enterprise security - and 800-171 is mandatory for anyone in the US defence supply chain. This episode maps the Identify–Protect–Detect–Respond–Recover functions directly to M365, and shows what auditors, insurers, and procurement teams will want to see.

Hello everyone. Welcome back to the complier cry series. This is the series where we make compliance frameworks practical for the Microsoft 365 tenants that you actually manage. Today we are covering NIST. So NIST is the framework that gets name dropped in every cyber insurance questionnaire I would say every enterprise procurement document and every federal contract especially in North America. And yet most conversations I have a lot of MSPs and IT teams don't really have an idea of how to actually operationalize it inside of a Microsoft 365 tenant. So that is what we will be fixing today. By the end of the session you're going to understand the difference between N CSF and NIS 80071 when you need each one and also how they map onto the Microsoft 365 stack and more critically how to enforce them at scale using the inforcer platform. So, let's go ahead and get into it. For those who did not join the CIS session, quick intro. My name is Dakota Miguel. I am a Microsoft 365 solutions architect at inforcer. My day job is helping MSPs design and govern secure Microsoft 365 environments across hundreds and sometimes even thousands of tenants. I do spend a lot of time at the intersection of compliance frameworks and the Microsoft 365 platform itself. That means I am constantly translating standards like NIS, CIS, CMMC and even ISO into actual tenant settings, conditional access policies, defender configurations, the stuff that actually moves that needle. So my promise for this session, we're not going to really focus on a lot of theoretical stuff. It's mostly concepts that are grounding something that you can configure in Microsoft 365. Here is our road map for today. So, we're going to go ahead and start with the basics, cover what NIST actually is because people throw that acronym around without realizing NIST publishes hundreds of standards, right? So, we're going to narrow that down to the two that matter the most for you, I would say. Obviously, we'll touch on I think 853 a little bit in this conversation, but 8171 and CSF is top of mind. And then we're going to just spend some real time on each, what CSF 2.0 looks like in its new form and what 800171 actually requires if you ever touch federal data. After that, we're going to answer the why bother question. Why NIST is the right foundation even if you're not in defense or government work. Then we're going to go ahead and map both frameworks onto Microsoft 365. Which services line up with which controls? And then finally, we're just going to show how inforcer operationalizes all of this so you're not maintaining spreadsheets and screenshots to prove compliance. We will also go ahead and stick around for the inforcer section at the end. That's where this kind of gets a little bit more concrete for anyone running multiple tenants. So let's go ahead and get started with NIST CSF, the cybersecurity framework. NIST CSF was originally developed for critical infrastructure back in 2014. Version 2.0 shipped earlier in 2024 and it broadened the audience to all organizations not just power plants and pipelines. So two things here to internalize about CSF. I would say number one it's voluntary, right? So it's voluntary and it's outcome based. Voluntary means no regulator is going to fine you for not adopting it. Outcome based means it's telling you what good security looks like, but it's not actually telling you how to achieve that. So that distinction is definitely going to matter later in this presentation as well. NIST CSF 2.0 also introduced a new function, govern. So we used to have five functions, now we have six. And govern kind of sits at the center and covers strategy, oversight, supply chain risk, and also policy. Identify, protect, detect, respond, and recover are the original five. And those map roughly to the life cycle of a security incident. So underneath the six functions you have 22 categories things like asset management, identity management, awareness and training. And then under those we have more than 100 subcategories that get into the specifics. So subcategories are where you start to see actual implementation guidance and they're what we're going to actually map to M365 services later in our conversation. So this is the other NIST standard that you need to know. It is the special publication 800171. It is a fundamentally different framework than CSF. CSF is voluntary and it's outcome based. 800171 is mandatory and prescriptive. So if you handle what the government calls controlled unclassified information or CUI in a non-federal system, you must meet these requirements. So CUI is the gray area data. It's not classified, it's not top secret or confidential, but it's also not public. So think technical drawings, research data, contract details, infrastructure schematics. If your customer is a DoD contractor or any federal supplier and that data lives in their Microsoft 365 tenant, then 800171 will apply. There are 110 security requirements organized into 14 control families. So some of them you already are probably doing. We have access control, audit, logging, incident response. Others are more involved. So think configuration management, physical protection, personnel security, etc. And one more thing to remember here too about 8171. It is the foundation as well to CMMC level 2. So if your customer needs CMMC certification, and a lot of them will, you're going to encounter 800171 whether you want to or not. I will say too, 800171’s Rev 3 update definitely tightened a lot of the language and now better aligns with the broader NIST 853 category and catalog, which is really nice. So even if you don't really want to start working on Rev 3, I would recommend it because one, it's going to be the new standard and new expectation and also it maps out really prescriptively and more easily to NIST 853. So CSF has this concept called the implementation tiers and people often confuse them with a maturity model. It's not really like the CIS controls implementation groups. Tiers describe how rigorously and holistically you apply CSF across your entire organization. So there are four of them. Tier one is partial. So cybersecurity activities happen but they're ad hoc and reactive. Somebody puts out a fire when the fire happens. Risk is not really understood at an organizational level. Tier 2 is risk informed. So leadership is aware of cyber risk, there are some policies but practices vary across teams. There's no consistent process and a lot of small businesses kind of live in the tier 2 sector. Tier 3 is repeatable. So practices are formally defined, documented and funded. The whole organization follows the same playbook and this is where most mid-market organizations should aim to land. Tier 4 is adaptive. So practices evolve based on lessons learned, threat intelligence, and information shared with peers. So you're not just following the playbook, you're improving it continuously. Where most MSP customers kind of live today is somewhere between tier 1 and 2. Where we want to take them is tier 3, and I would say tier 4 is aspirational. It's there as a big goal, but it's frankly overkill if you're not a massive enterprise. When you crack open 800171, you're going to see that every one of the 110 requirements is split into two categories. We have basic and derived requirements. Basic requirements are the high-level objectives. They come from FIPS publication 200, which is the federal minimum security standard. And then basic requirements tell you what must be protected for each one of the 14 control families. So think like limited system access to authorized users, broad and outcome focused. Then we have derived requirements. Derived requirements are the prescriptive controls. They come from NIST special publication 853 which is the catalog of every security control NIST has ever defined. So derived requirements tell you how to achieve the basic objectives. So under limit system access to authorized users, you'll have specific derived requirements like enforce session lock after 15 minutes of inactivity or terminate sessions after a defined condition. So the takeaway here is you don't have to invent how to comply. This gives you both the outcome and the implementation guidance and the 110 figure you hear is the total of both basic and derived combined. So wanted to segment out this point for a reason. If you're wondering why we’re bothering spending an entire episode on NIST, this is the answer. NIST has effectively become the most common framework in North America, second to CIS I would say. Federal regulators reference it, cyber insurance carriers explicitly ask about it on their underwriting questionnaires, and they offer better premiums to organizations that can demonstrate NIST alignment. Enterprise procurement teams build vendor risk questionnaires on top of NIST controls and state and local governments are increasingly mandating NIST alignment for their suppliers as well. So even if you have zero government customers today, the moment you want to sell into a regulated industry, get cyber insurance or land a Fortune 500 customer, you're going to be asked NIST-shaped questions. So adopting NIST early is a strategic move not just a compliance exercise. And this is a slide I definitely want everyone watching this to internalize. The single most important distinction in the entire presentation: CSF is recommendations, 8171 are requirements. CSF gives you that maturity language. Nobody's going to audit you against CSF. There's no certifying body for CSF. You adopt it because it makes you better at security, because it gives your business stakeholders a common vocabulary and because it dramatically shortens cyber insurance questionnaires, but it is voluntary. Then 800171 on the other hand is the law of the land if you handle CUI. DFARS clause 7012 requires it. CMMC level 2 requires it as well. So if you fail an audit against it you can lose the contract, face fines under the False Claims Act, or even be suspended from federal procurement entirely. So two completely different beasts. They share the NIST brand and underlying thinking, but operationally they live in different worlds. You’ll likely end up doing both: CSF as your daily maturity model and 800171 as that contract-specific compliance lift. So here’s the strategic argument for why NIST should be your first compliance framework even if no one is forcing you to adopt it yet. Almost every US compliance regime traces back to NIST publications. CMMC is built directly on NIST 800171, FedRAMP is built on NIST 853, FISMA aligns to 853, and HIPAA maps to NIST standards as well. Practically, if you do NIST well, you’ve done 70–90% of the work for other frameworks. The vocabulary transfers, the controls transfer, and the evidence transfers. You’ll answer procurement questionnaires in half the time because the answers are already documented. I tell every prospect and customer the same thing, especially when working with inforcer. We have CIS as the foundation, but that maps to NIST for government contractor customers, and any future compliance lift becomes much faster. One thing I love about NIST is that it’s completely free. There’s no paywall. You don’t need a consultant just to access it. Everything is available at nist.gov/cybersecurity framework, including CSF 2.0, quick start guides, and implementation examples. Then here’s the good news for anyone already invested in Microsoft 365. The platform was essentially built to be NIST friendly. Microsoft maps their entire security stack to NIST in official documentation. Entra ID handles access control and identity. Exchange Online with Defender for Office 365 covers system and information integrity. SharePoint and OneDrive with sensitivity labels handle media protection and configuration management for CUI. Purview handles classification and DLP. Across CSF functions, Entra ID and Purview map to identify, Conditional Access, Intune and Defender map to protect, Defender XDR handles detect, and Sentinel supports respond and recover. So let’s get specific about inforcer. Inforcer ships a pre-built CIS policy library, and because CIS safeguards have official mappings to NIST CSF and NIST 800171, applying CIS-aligned baselines gives you NIST coverage through mapping. Inforcer uses that crosswalk to make NIST operational inside Microsoft 365. Operationally, that gives you one-click application of NIST-aligned baselines across every tenant you manage, continuous drift detection when tenants fall out of alignment, a multi-tenant compliance dashboard showing posture across customers, and policy-level mapping back to specific NIST controls for audit evidence. Critically, there are no more spreadsheets or screenshots. When auditors or insurers ask for NIST coverage, you export an inforcer report instead of digging through old documentation. If you take one thing away, it’s this: NIST CSF is your maturity language. It’s how you talk about cybersecurity internally and externally. It gives a shared vocabulary with executives, auditors, insurers, and procurement teams. NIST 800171 is your compliance lift, but only where contracts demand it. Don’t try to apply all 110 controls everywhere. Target it where CUI exists and where DFARS or CMMC obligations apply. Trying to apply it universally will burn you out and your customers too. Overall, you can use inforcer as the enforcement engine that makes both frameworks achievable at scale. Applying inforcer baselines improves CSF outcomes and 800171 control coverage simultaneously. It’s one enforcement engine delivering multiple frameworks of evidence. Strategy at the top, contract-specific lifts where needed, and technical enforcement through inforcer. I hope that was informative. This is normally where we would take questions, but this is a recorded YouTube series. Thank you so much for joining, and we hope you continue on to the final episode where we tie together all the frameworks covered in this series.