When we started building the inforcer Blueprint Library, we weren't trying to create another security framework.
Frameworks like CIS, Cyber Essentials, Essential Eight and NIS2 already provide valuable guidance, and compliance matters. But after years of working with MSPs and Microsoft 365 environments, we found ourselves asking a different question:
Are we building security around the framework, or around the customer?
Most MSPs don't manage frameworks, they manage customers. A framework gives you the destination, but it doesn't always give you the most practical route to get there.
Frameworks weren't built for one customer
Every framework has to cater for a huge range of organizations. A recommendation that makes sense for an enterprise with dedicated security and compliance teams doesn't automatically translate to a 50-person business supported by an MSP. That doesn't make it wrong, it just means context matters.
Take MFA. CIS recommends applying it broadly, and the objective is right: protect identities, reduce risk. But mature Microsoft 365 environments rarely run on one policy for everyone. Admins, guests, service accounts and contractors all need different treatment, which is why MSPs build persona-based Conditional Access policies instead of a one-size-fits-all approach.
That's the philosophy behind the Blueprint Library too. We run every recommendation through the lens of real-world MSP operations:
- Does it improve security?
- Does it align with Microsoft's own guidance?
- Does it make sense for the majority of customers?
- Can it actually be operationalized and supported at scale?
If yes, it belongs in a Blueprint. If not, we'd rather MSPs make an informed decision than chase a compliance percentage. Security is the goal. Compliance usually follows from getting that right.
Frameworks are an input, not the answer
Frameworks provide guidance. MSPs still need to decide how that guidance turns into something secure, maintainable and supportable for a real customer, and that's where Blueprints come in.
We use frameworks like CIS as an input, then combine them with Microsoft's own guidance and the hands-on experience of our team, several of whom are Microsoft MVPs supporting Microsoft 365 environments every day. The result is a set of opinionated best practices built for MSPs, not because we think we're smarter than the frameworks, but because MSPs need something they can actually deploy, support and maintain.
Microsoft doesn't stand still, so neither do we
Microsoft moves fast. New features appear and settings change long before they're reflected in any benchmark. A good example is the expiration of Intune Secure Boot certificates, something no benchmark accounts for, but something we saw coming and helped partners prepare for. Because the Blueprint Library is actively maintained, we rolled the policy into our baselines instead of leaving every partner to research it themselves.
That's the real difference between a benchmark and a living baseline. A benchmark tells you what mattered when it was published. A living baseline evolves as the platform does, which is why we keep shipping updates and documenting every change.
More than security
We also think about what it takes to run Microsoft 365 well, not just securely. Every MSP ends up configuring the same quality-of-life settings: single sign-on preferences, application defaults, first-run experiences, Teams permissions, and other usability tweaks that make an environment easier to support.
None of that moves a compliance score, but it's still part of a well-managed environment. If we already know what most customers end up configuring anyway, there's no reason it shouldn't be in the Blueprint from day one.
Frameworks and Blueprints aren't competing
Frameworks define what good looks like, or what's required. Blueprints help MSPs actually deliver it, and following the Blueprint Library keeps you compliant with the frameworks that matter to your customers, whether that's Cyber Essentials, NIS2 or another framework entirely. That's the principle behind Blueprints: we want to support every framework, just done the right way, with the customer and the MSP at the centre.
The best outcomes never come from blindly following a benchmark. They come from understanding your customers, your platform, and building security that works for both.
Want to see inforcer Blueprints in action?
Discover how an inforcer Blueprint can help you deliver consistent, reliable security at scale. Book a demo today.
Share this
Delivering Copilot without the risk: inforcer new releases
