Welcome and roadmap
Hello everyone. Welcome back to the Compliyer 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 a 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 with 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 NIST CSF and NIST 800-171, when you need each one, and also how they map onto the Microsoft 365 stack, and more critically, right, 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 Migliore.
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 NIST, CIS, CMMC, and even ISO 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 roadmap 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 800-171 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 800-171 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 kind of prove compliance, right?
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 2.0
NIST CSF was originally developed for critical infrastructure back in 2014. Version 2.0 shipped earlier in 2024, it broadened the audience to kind of 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 find 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, it 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 There's like 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 800-171. It is a fundamentally different framework than CSF. CSF is voluntary, and it's outcome-based. 800-171 is mandatory and prescriptive.
NIST SP 800-171
So, if you handle what the government calls controlled unclassified information or CUI in a non-federal system, you must meet these requirements, right? 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 the Microsoft 365 tenant, then 800-171 will apply. There are 110 security requirements organized into 14 control families.
So, some of them you already are probably doing right. We have access control, audit logging, incident response. Others are more involved, so think configure configuration management, physical protection, personnel security, etc. And one more thing to kind of remember here, too, about 800-171. It is the foundation, as well to CMMC level two. So, if your customer needs CMMC certification, and a lot of them will, you're going to encounter 800-171 whether you want to or not. I will say too, 800-171's rev 3 update definitely tightened a lot of the language and now kind of better aligns with the broader NIST 853 category and catalog, which is really nice.
So, even if you kind of don't really want to start with or 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.
CSF implementation tiers
So, CSF has this concept called the implementation tiers, and people often confuse them with the maturity model. It's not really like the CIS controls implementation groups, right? 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, right?
Risk two or tier two 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 two sector. Tier three is repeatable, right? 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 four 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 MSPs' customers kind of live today somewhere between the tier one and two. Where we want to take them is tier three. And I would say tier four is aspirational. It's there for as a big goal, but it's frankly overkill if you're not a massive enterprise. When you crack open 800-171, you're going to see that every one of the 110 requirements is split into two categories.
We have basic and derived.
Basic and derived requirements
Derived basic requirements are the high-level objectives, right? 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 controls families. So think like limited system access to authorized users, broad and outcome focused. And then we have derived requirements. So 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. NIST kind of gives you both the outcome and the implementation guidance. And the 110 figure you hear is kind of the total of both basic and derived combined.
So wanted to kind of segment out this quote for a reason, right? If you're wondering why we're bothering spending an entire episode on this is the answer.
Why NIST matters
So NIST has effectively become definitely like the most common framework in North America second to CIS, I would say. Federal regulators specifically though, right? Reference it. So cyber insurance carriers explicitly ask it under and on their underwriting questionnaires and they offer better premiums to organizations that can demonstrate NIST alignment. So, enterprise procurement teams build vendor risk questionnaires on top of NIST controls and I would say state and local governments are increasingly mandating NIST alignment for their specific 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, right? So, adopting NIST early is a strategic move, not just a compliance exercise. So, that's why we're spending today on this framework specifically, I would say. And this is a slide I definitely want everyone on like watching this to kind of internalize.
Recommendations vs requirements
The single most important distinction in the entire presentation, right? CSF is recommendations. 800-171 are requirements. So, CSF will give 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 also just because it dramatically shortens cyber insurance questionnaires, but it is voluntary, right? And then 800-171 on the other hand is the law of the land if you handle CUI.
So, DFARS clause 7012, that's the Defense Federal Acquisition Regulation Supplement, requires it. So, CMMC levels two requires it as well. So, if you fail an audit against it, you can lose the contract. You can face fines under the False Claims Act and also you can be suspended even from federal procurement entirely if that's kind of what you're focused on today. So, two completely different beasts. They share the NIST brand, sure, and a lot of the underlying security thinking, but operationally they live in different worlds within the scope that they're being looked at.
So, you'll likely end up doing both CSF as your daily maturity model and then 800-171 as that contract specific compliance lift, I would say, for sure. 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.
Why NIST should be your first framework
I would say almost every US compliance regime traces back to NIST publications. CMMC, we've talked about already a few times, which is that cybersecurity maturity model certification for DoD contractors. That's built directly again on NIST 800-171. And then we have FedRAMP, which governs cloud services sold to federal agencies. That's built on NIST 800-53. Then we have FISMA, which is the Federal Information Security Modernization Act, which is also 853. The HIPAA Security Rule has an official mapping to NIST 800-161.
You know, there's a lot of different mappings and connections in between. So, what does this mean practically, right? If you do NIST well, you've done 70 to 90% of the work for any of these other frameworks. The vocabulary transfers, the controls transfer, the evidence transfers. You'll find yourself answering procurement questionnaires pretty much in half the time because the answers are already documented over time. So, I do tell every prospect and customer the same thing, especially like working with inforcer, right?
NIST and Microsoft 365
We have CIS as the foundation, but that can actually map out to being NIST as your foundation for your government contractor customers as well, which is really nice. You know, and if you've ever made any type of future compliance lift, it'll be a lot faster for you to do that. So, one thing I love about NIST is that you don't have to pay. There's no paywall. It's completely free. You don't need to buy a license, etc.
You don't need a like a consultant to access the source material. Or All you have to do is head to nist.gov/cybersecurityframework. Everything is right there. So, the full CSF 2.0 core document, the quick start guides organized by audience. There's one specifically actually for small businesses and one for enterprise risk management, one for supply chain. There are even implementation examples showing exactly what each subcategory looks like when it's done well, which is good. And then here's the good news for anyone who already has invested in 365, right?
The platform was essentially built to be NIST friendly, I would say. Microsoft maps our entire security stack to NIST in their official compliance documentation. So, on 800-171 side, Entra ID handles your access control and identification and authentication families. You know, Exchange Online with Defender for Office 365 covers a chunk of system and information integrity. SharePoint and OneDrive properly configured with sensitivity labeling handle that media protection and, you know, configuration management for CUI data. And if we're looking at Purview even, right?
Purview's classification engine and DLP policies enforce data handling. So, it's a lot of great positive features that are a part of the M365 stack today that's explicitly mapped out already to what is going on and what's required. So, even if you're looking at the CSF side as well, right? Those six functions map across a platform almost one-to-one. Because if we're looking at Entra ID and Purview and then identify as an asset inventory and risk, Purview's data map is the bulk of that stack.
You have conditional access. You have Entra Defender. Detect is also a Defender XDR across endpoints. And you also have respond and recover live in Sentinel for SOC workflows, etc. So, pretty nice. So, let's ahead and get specific about inforcer. I want to be straight up with you currently about how this works cuz it does matter, right?
How inforcer operationalizes NIST
inforcer ships a pre-built CIS policy library, and because CIS safeguards have been published mapping or have published mappings to NIST CSF and NIST 800-171, applying CIS-aligned baselines gives you NIST coverage just by mapping, right? So, it's really nice because you know, we're obviously not pretending that CIS is NIST, but we're using the official crosswalk to allow you to translate between them, and that's how inforcer makes NIST operational inside of 365. You know, what does that get you operationally?
You have a one-click application of NIST-aligned baselines across every tenant you manage. You get continuous drift detection. inforcer will manage those settings and alert you the moment the tenant falls out of alignment. You have a multi-tenant compliance dashboard that rolls up posture across your entire customer base, so you can instantly see which tenants are aligned and which need attention. And every inforcer policy maps back to the specific NIST control reference, so you have a really great paper trail as well.
So, critically here, what's really great is there's no more spreadsheets, right? There's no more spreadsheets and screenshots when an auditor or an insurance carrier asks to show me your NIST coverage, you don't dig through PowerPoints from 18 months ago. You export the inforcer report and be able to look at it that way. And if you take nothing away from this episode, I would take this or recommend taking this, right?
Key takeaways
NIST CSF is your maturity language. You adopt it as a way you talk about cybersecurity inside your organization and with your customers. It gives you a shared vocabulary with executives, auditors, insurance carriers, and procurement teams. And it's a really great you know, way. It's free. It's well supported. It makes your default frame for security conversations really great and straightforward. NIST 800-171 is your compliance lift, right? So, but I guess only where a contract demands it.
So, I wouldn't try to retrofit 110 controls across every tenant you manage. I would target it precisely where CUI lives and where DFARS or CMMC obligations apply because trying to do 171 universally will definitely burn you out and burn out your customers, too. So, and then overall, right? You can use inforcer as that enforcement engine that makes it both achievable at scale because of the CIS 10 NIST mappings baked into our policy library. So, applying inforcer baseline simultaneously moves the needle on CSF outcomes and 800-171 control coverage.
So, it's one enforcement engine, multiple frameworks of evidence, and that's kind of the playbook, right? Strategy at the top, and contract-specific lifts where required, as well as technical enforcement through inforcer, as well. So. I hope that was informative. This is at the point in our webinar where we ask for questions, but this is a recorded YouTube series. So, I hope you did find benefit. Thank you so much for joining me on our series, and we do hope that you continue on and watch, the final episode, which is our wrap-up of kind of tying in all of the frameworks we went over during this webinar series.
Thank you so much.