From Set & Forget to Tenant Governance

Hey everybody. We will give everyone a couple of minutes to join. It looks like there are a lot of note takers in the waiting room, so we will let them in and then get started.

Can everybody see the screen I have pulled up? I just want to double-check before we begin. Great, thank you.

We can go ahead and get kicked off. I will keep an eye on people joining as we go. To introduce myself, my name is Cole. I am a Solutions Architect here at inforcer. I know most people who joined were probably expecting to see Dakota, but I am covering for her today. We will be running through the presentation From Set & Forget to Tenant Governance.

The conversation remains the same. We will walk through how to help with tenant governance, give you ideas on where you should go with setting tenants up, and show how you can run a managed service model that creates a revenue stream for the work you are already doing in the background.

As you may have discussed with Dakota on the previous session, I will keep an eye on the chat and Q&A as we go. If you have questions, please send them through. The slide deck is not too long, and PowerPoint is not my favourite format, so if we have time at the end, I will hop into inforcer and show how the platform helps with the managed service piece: renaming policies, detecting drift, pushing policies and quickly remediating changes.

Last time, Dakota introduced the idea that the tenant is the new server. Today, we will drill into why it is important to continue running your tenant with a managed service approach. You would not run a server without an RMM tool, so why run a tenant without a tool like inforcer or without a managed service wrapped around it?

That is the point of moving from set and forget to tenant governance. We want to keep updating tenants, running them like servers, and treating them as environments that need ongoing care. You would not run a server and never patch it. That would be a bad scenario because something will eventually go wrong. The same is true with a tenant. If you set it up and then do nothing, you are creating risk.

Today, we want to paint that picture and show how you can automate the process, how inforcer can help, and how you can bill for it. This is work you are already doing in the background, so let us figure out how to turn it into additional revenue.

For anyone who just joined and is wondering who I am, I am one of the Solutions Architects at inforcer and work directly with Dakota. I have been in the space for around six years, five of which were at Pax8 on the Microsoft consulting team. Microsoft is not new to me. I handled Microsoft 365, Office 365, Dynamics, Power Platform and Microsoft programme questions. I used to joke that I wish I could have gone to college for Microsoft licensing and programmes because there is so much to keep up with, and Microsoft changes things constantly.

I am Microsoft-focused and certified. I hold certifications including MD-102, AI-900, MS-900 and PL-900, and I am also working on the Copilot certification. Most of my work inside inforcer involves helping partners translate compliance frameworks such as NIST, ISO 27001, CMMC and CIS into practical, consumable baselines and policies. The goal is to help partners establish secure baselines and push policy at scale.

When you are building out security, the first step is to identify what secure looks like. From there, you tailor the experience to each customer so you are not overly restricting their day-to-day work. The mindset is: we have pushed these policies, everything is aligned to our golden image and standard, and now we can fine-tune for the customer. Day to day, we help partners architect that golden image so their customers have a secure but tailored experience.

For anyone who is less familiar with inforcer, we are headquartered in the UK but globally present, with offices in the US, UK, Australia and other regions. We are MSP-focused, which means we sell to MSPs rather than directly to end customers or internal IT teams. Our team includes people with MSP backgrounds, which helps us understand the pain points you go through and tailor conversations to where you are on your growth journey.

We have a strong Microsoft relationship. We are part of MISA, the Microsoft Intelligent Security Association, which is an invite-only programme. We are also one of the founding vendors for Intune for MSPs. When Microsoft Lighthouse was considered product-complete for certain needs, Microsoft leaned into the Intune for MSPs initiative to help with multi-tenant management. inforcer is one of the vendors helping MSPs solve that multi-tenant problem and make a revenue model from it.

If the idea that the tenant is the new server lands with you, the next question is how you manage it. If you are moving workloads into Entra ID and cloud services rather than building out traditional servers, you need to apply the same operational discipline you would apply on-premises: patch management, policy deployment, keeping things up to date, backing up configuration, change control and drift management.

The workflows you use on servers need to follow you into the cloud. You still need to make sure every discipline you apply to servers also applies to cloud tenants, because the tenant is the new server.

When we ask MSP owners how many servers they patch and monitor, the answer is never zero. You would not run a server without an RMM tool. That would be a serious issue. But when we ask how many tenants are running unpatched or unmonitored, the answer is often less clear. Many tenants are still effectively run in a set-and-forget model.

That is the gap. A server would never be treated as set and forget, yet many tenants are run that way. The remainder of this session is about the operating model: how to move from ad hoc configuration to continuous governance, and importantly, how to charge for that model.

The foundational truth behind the governance argument is that the Microsoft 365 tenant is not secure by default. It is functional by default. Microsoft has done real work on secure defaults, security defaults, sign-in safeguards and hardening legacy authentication, but the out-of-the-box tenant is not fully hardened.

That is where the gap begins. The tenant itself is not actively dangerous, but if you do not provide any work, configuration or ongoing management, you are waiting for someone to take advantage of that gap. Configuration is never truly complete. You always need to fine-tune policies as Microsoft makes updates. You need to follow patch by patch and push changes out where they make sense.

That could be a full-time job given the number of changes Microsoft makes. That is where inforcer helps: tracking changes, identifying which ones matter and helping you push them out. If you did a Microsoft hardening project in Q1, by Q2 it may already be drifting because of Microsoft changes. If you are not proactively checking and making changes, that tenant can fall out of alignment. This is not a one-time project. It is continuous work, and it should become a revenue stream.

There are three main forces that pull tenants out of shape. The first is your own engineers. Human error is a major driver of drift. People make changes, do not document them or are not sure what the consequences will be. If an engineer changes a policy, you need to know what changed and be able to revert it if needed.

The second force is the customer. This is the scary one. If the customer still has Global Administrator access, they may tweak a conditional access policy and forget to change it back. Hopefully, you own the Global Administrator accounts for your customer tenants, but sometimes tech-savvy customers still believe they should have control. A CEO may decide they do not want to use MFA because they are tired of signing in with Authenticator. That creates a significant security risk. If a Global Administrator changes a conditional access policy, you need to know and be able to show that the tenant is now out of alignment.

The third force is Microsoft itself. Microsoft releases new SKUs, updates policies and introduces features constantly. Release notes may contain hundreds of changes. Some updates are small, while others may introduce policy or security changes that you need to understand and address. You did not introduce that drift, but if Microsoft has provided a way to fix a gap, you still own the consequence if you do not apply it.

Those three forces — your engineers, your customers and Microsoft — pull tenants out of shape. There are ways to combat this, but doing it manually is not sustainable long term.

Think about whether you have made every relevant update across Entra, Intune, Defender and Defender for Business over the last year. There is no shame if the answer is no. The reality is that there is no good manual way to keep up with all of this. It is roughly a change a week, and that alone can become someone’s job. We have an internal team that tracks these updates and helps identify what partners need to know.

That is only four services. It does not include Purview, SharePoint, Teams, Exchange, Copilot or Power Platform. If you are not actively tracking changes, evaluating them, deciding which apply to each customer and rolling them out, you are not truly managing Microsoft 365. At that point, you are simply renting it on behalf of the customer and putting your logo on the invoice.

This should be continuous work. It is how you own the sales cycle, build governance, and create a recurring revenue stream.

Before we get into tooling, it helps to map where tenants stand. We call this the tenant governance maturity model. There are four levels, from set and forget to continuously governed. As we walk through them, think honestly about where you sit. Most MSPs are likely at level one or two. The goal is to move to level three and maintain towards level four, where the service becomes profitable and defensible.

Level one is set and forget. You have turned on the tenant, handed over credentials, and are billing monthly, but there is no baseline and no real monitoring. You are effectively reselling with extra steps. That is where many partners begin.

Level two is reactive. This is where many MSPs think they are, but often it still means only touching the tenant at ad hoc moments. You might have hardened it once during onboarding, but changes only happen when something breaks. Drift is not being managed consistently.

Level three is standardised. You have written down your golden baseline, applied it during onboarding and are tracking progress. Enforcement exists, but some elements may still be manual. This is the minimum level you should aim for when managing multiple tenants.

Level four is continuously governed. This is the ideal state. The baseline is continuously enforced, drift is detected and remediated quickly, tenants are assessed, gaps are reported, and you can upsell security packages. It is also the level that survives audits and supports recurring revenue.

The governance operating loop is what turns levels three and four into a repeatable model. The loop has four stages: baseline, detect, remediate and report. It is deliberately simple because simple processes survive contact with 50 customers and staff turnover.

First, define your baseline. This is your golden standard. It does not need to be tailored to each customer yet, but it needs to be secure. It should cover the major Microsoft pillars, such as conditional access, compliance policies, configuration policies, updates, anti-spam, Safe Links and other controls. You might anchor this to CIS, NIST or Microsoft baselines, but it needs to be something that works for you and your customers.

Second, detect drift. Compare every tenant against that baseline continually. That shows where drift and deviations are coming from. If your baseline and the customer tenant do not match, that is the gap you need to close. Without a multi-tenant management tool like inforcer, this step is manual and difficult to do at scale.

Third, remediate. Look at the detected drift and decide whether to align it back to the baseline, accept the deviation or deploy missing policy. This is where you decide whether something needs fixing or whether it is an intentional customer-specific difference. The important part is documenting the decision so an engineer can see what happened and why.

Fourth, report. Customers often ask what you are doing in the background if they have not spoken to you in a few months. You need to show them. White-labelled, branded reports help you take evidence into QBRs and show alignment, drift, assessments and progress. Reporting proves the value of the managed governance service.

That loop never ends. Any time a baseline changes, a new hardening project is created, or something like an Intune project is rolled out, you return to the same loop: baseline, detect, remediate and report. That is how you maintain governance over data and tenants while charging for both project work and tenant maintenance.

When a deviation appears, there are four actions you can take. The first is deploy. The policy is missing entirely, so you push a new policy out. This is common when onboarding a new tenant. You compare the tenant against your golden image and deploy what is missing.

The second action is align. The policy exists in both the baseline and customer tenant, but it has been modified. For example, your baseline requires MFA for all users, but the customer tenant has the policy disabled. You align it back to the baseline in one action rather than manually changing each tenant one by one.

The third action is accept a deviation. Every customer works slightly differently, and this is where you fine-tune. You may have a policy that is mostly right but needs one property to differ for that customer’s workflow. Accepting a granular deviation documents that the difference is intentional rather than unmanaged drift.

The fourth action is rename to baseline. Standardised naming matters because it keeps the team on the same page. If one engineer leaves a project for the day, another can pick it up without trying to reverse-engineer what was done. Naming is what makes standardisation work at scale.

Governance becomes real when it has a cadence. There are three rhythms to think about: daily, weekly and quarterly.

Daily, you want automated drift detection across every tenant. If a policy is added, removed or modified outside inforcer, the platform can send a notification the same day. You find out before an auditor, breach report or customer does.

Weekly, you need a remediation block. This is where your team clears the drift queue, aligns policies, accepts deviations or deploys fixes. It turns governance from heroics into routine. You do not want a 2 a.m. scramble; you want a predictable operational process.

Quarterly, you assess and report. You show the customer where they are against the chosen baseline or compliance framework and provide proof of progress. For example, if you are moving a customer towards CIS, you can show how alignment improved over time and what the next target is.

Doing this manually is difficult. You are dealing with hundreds of decisions multiplied across every customer. Customising a baseline for one customer is manageable. Doing it for 50 or 200 customers becomes unsustainable unless you have tooling and a dedicated team.

Every customer is different, but you can still standardise the process. You can push a CIS baseline and then map it to CMMC, HIPAA, PCI, ISO 27001 or other requirements where needed. This creates the foundation for upsell opportunities and helps you show auditors how you have maintained controls and prevented drift.

Microsoft does not give you a simple way to clone everything across every tenant. Without tooling, you are manually applying baselines repeatedly. If you are building Intune environments, that can mean clicking the same settings for hours in each tenant. inforcer helps replicate that work quickly and safely, letting your team return to higher-value work and take on more projects without adding overhead.

Now let’s talk about the economics of governance. Continuous governance is not only safer; it is the model that becomes profitable.

There are two common models. The first is fixed price, which is the set-and-forget trap. You charge a one-time hardening fee, then a flat management fee. Six months later, drift becomes real and you are doing ongoing configuration work for free. Drift quietly erodes margin every month until you are underwater.

The second model is a recurring per-tenant governance fee. The scope is the loop: baseline, detect, remediate and report. Drift is no longer a hidden cost; it is the product you are selling. As automation absorbs the volume, margins grow because engineers are not carrying all of the manual work. It is the same work, but one model bleeds margin and the other compounds value.

One of the highest-leverage tools for this model is tenant assessment. If you are moving towards level three or four maturity, you need a repeatable way to assess tenants. inforcer includes a tenant assessment engine that lets you create custom assessments. You can build assessments based on CIS, the Windows 11 Intune benchmark, ISO, NIS2, Cyber Essentials, Essential Eight or other needs.

These assessments can be branded and scheduled. They can be delivered to your inbox on a recurring basis and used for reporting as a service. You can run them against prospects or existing customers. For example, if you want to upsell an Intune project, you can run an Intune assessment, show the customer the gaps, define the project, and then build ongoing drift maintenance into the service.

The tenant assessment piece is a strong selling point because it lets you show customers that you can continuously update and assess tenants, support audit readiness and keep them in a better security posture.

There is also a missing governance layer that Microsoft does not provide out of the box. inforcer sits across all tenants and runs the governance loop. It maps compliance frameworks and aligned baselines, so you are not staring at a NIST PDF trying to determine which conditional access policy satisfies which control.

AI policy impact analysis is another part of that missing layer. Before pushing a policy change, the platform can explain in plain English what the change will do. That helps you and the customer understand the impact before deployment.

Tenant drift detection is also critical. If someone makes a change, Microsoft will not necessarily alert you. inforcer will. Microsoft gives you the platform; inforcer gives you the governance layer to manage it at scale.

I will now show how this works in inforcer. When you are in the platform, this is the home screen. You can onboard tenants through GDAP, Global Administrator or an onboarding link. Once tenants are in the platform, the Assess tab lets you run your own assessments or use the pre-built assessments included in the platform.

You can create custom assessments, such as an onboarding assessment or a tailored HIPAA assessment. You choose the relevant checks across areas such as Entra, Defender, SharePoint, Purview, Exchange and Teams. You can then run the assessment against a tenant and schedule it to be delivered daily, monthly or on whatever cadence you need. You can also add customer recipients so reports are sent directly to them.

At the moment, inforcer is focused natively on Microsoft 365 rather than Azure environments. The platform sits in the Microsoft 365 cloud and helps detect and report across SharePoint, Defender, Purview, Exchange, Teams and other Microsoft 365 services.

Once an assessment runs, you get a breakdown by category showing which checks passed and failed. Internally, your team can see PowerShell scripts or Microsoft UI guidance to fix issues. You can export the report and apply your white label.

From there, you move to the Align section and deploy policies from a baseline. For example, you can use the CIS library, select the policies that map back to an assessment, review impact and then deploy. The platform provides sanity checks before deployment, showing which policies will be pushed to which tenant with which settings.

Once policies are in place, the alignment screen handles the ongoing comparison between the customer tenant and your baseline. It shows aligned policies, recommended policies that exist in the baseline but not the customer tenant, existing customer policies and unaccepted deviations. This is where you fine-tune the customer environment by accepting deviations or aligning back to the baseline.

Drift reporting happens through the Automate page and policy change notifications. If a policy is added, removed or modified outside inforcer, a notification is sent. If you integrate with one of the supported PSA tools, the notification can become an actionable ticket. Your team can then return to the Align page, close the drift, align the tenant back to the baseline or accept the intentional deviation.

The overall model is assess, align and automate. That is where you live to maintain drift and provide real-time governance for customers.

With that, we can wrap up a little early. If there are any additional questions, I am happy to answer them. Otherwise, thank you for joining and listening. If you have further questions, please reach out to me after the session.