Inforcer — apply M365 changes safely

approved

Using Inforcer to deploy, standardise, and roll back Microsoft 365 configuration across client tenants instead of clicking through portals per tenant.

Audiences: customer, ae, tech · Tags: m365, policy-management, inforcer · Last verified: 2026-07-16

Teach module

# Teach — Inforcer for M365 change management

## Core truths

- Inforcer lets an MSP define M365 policies (Intune, Conditional Access, Exchange, and related workloads) centrally and push them to many client tenants from one console.
- Policies are managed as versioned templates: you build a baseline once and deploy it repeatedly, rather than reconfiguring each tenant by hand.
- Deployments are tracked, so you can see which tenants have which version of a baseline and where configuration has drifted from the standard.
- Rollback is a first-class concept: if a pushed change causes problems, you can revert a tenant to the previous known-good state instead of manually undoing settings.
- Tenant-by-tenant portal administration does not scale: it produces inconsistent configuration, undocumented changes, and no audit trail.

## Common myths to correct

- "Scripts do the same thing" — scripts apply changes but rarely track drift, versions, or provide safe rollback, and they depend on the one engineer who wrote them.
- "We are too small to need this" — drift and undocumented changes hurt 5-tenant MSPs as much as 100-tenant ones; the cost is just less visible.
- "Baselines remove flexibility" — baselines set the floor, and per-tenant exceptions remain possible; the point is that exceptions become deliberate and documented.

## Pitfalls

- Pushing a new Conditional Access baseline without a break-glass account excluded can lock administrators out of tenants.
- Deploying to all tenants at once instead of piloting on an internal or low-risk tenant first.
- Treating the baseline as finished: Microsoft moves settings and adds features, so baselines need scheduled reviews.
- Assuming every tenant starts compliant: run a drift report before the first deployment so you know what will change.

Apply module

# Apply — discovery, objections, and talk tracks

## Discovery questions

- How do you currently make a security or configuration change across all of your M365 tenants?
- If a client asked you today to prove their tenant matches your security standard, how long would that take?
- When did a portal change last break something for a client, and how long did it take to work out what changed?
- Who on your team knows the exact Conditional Access state of every tenant right now?
- How do you onboard a new client tenant to your standard configuration today, and how many hours does it take?

## Objections and responses

- "We already have scripts for this." — Scripts deploy; they do not audit, version, or roll back. Ask who maintains them and what happens when that person is on leave.
- "It is another subscription cost." — Compare the licence cost with engineer hours spent per tenant per change, plus the incident cost of one bad manual change.
- "Our clients are all different." — Baselines cover the common 90%; documented per-tenant exceptions handle the rest, which is exactly what auditors want to see.

## Talk tracks

- "One change, every tenant, with a rollback button" — frames the core value in one sentence.
- Position drift reporting as the client-facing win: you can show clients evidence their tenant matches the agreed standard.
- For business owners, translate configuration drift into risk language: unknown settings are unaudited risk.

Convert module

# Convert — CTAs and next steps

## Approved CTAs

- Book a free baseline drift review: we compare one of your tenants against our hardened M365 standard and show you the gaps.
- Offer a standardisation project: bring all managed tenants onto the agreed baseline within an agreed window.
- For internal enablement sessions: assign each engineer one tenant to run a drift report on this week.

## Next-step framing

- Customer webinars: end on the drift review offer, positioned as evidence-based and low-commitment.
- AE sessions: the goal is booking the drift review conversation, not selling the tool by name.
- Tech sessions: the next step is piloting a baseline on the MSP's own tenant before any client rollout.

Demo steps

# Demo — apply a policy change with Inforcer

1. Open the Inforcer console and show the tenant list with baseline version per tenant.
2. Open the current Conditional Access baseline template and highlight one policy (for example, MFA required for all users).
3. Make a controlled edit to the template (for example, add a named location exclusion) and save it as a new version.
4. Show the diff between the previous and the new version of the baseline.
5. Deploy the new version to a single pilot tenant, not the whole estate.
6. Show the deployment status view confirming the pilot tenant is on the new version.
7. Run a drift report on a second tenant to show how out-of-band portal changes are surfaced.
8. Roll the pilot tenant back to the previous version to demonstrate safe rollback.

## Pre-demo checklist

- Pilot tenant confirmed as safe to change during the session.
- Break-glass account exclusions verified in every Conditional Access policy shown.
- Screen sharing hides client-identifiable tenant names where the audience is external.

Claims policy

# Claims — Inforcer

## Allowed claims

- Inforcer centralises M365 policy deployment across multiple tenants from one console.
- Baselines are versioned and deployments are tracked per tenant.
- Drift between a tenant and its baseline can be detected and reported.
- Changes can be rolled back to a previous baseline version.
- Central management reduces the manual effort of per-tenant portal administration.

## Forbidden / needs-human-review claims

- Any specific pricing, licensing tiers, or discount figures.
- Any guaranteed time savings percentage or ROI figure.
- Claims that Inforcer covers a specific M365 workload unless verified against the current product docs.
- Comparisons naming competing products.
- Any claim about compliance certification (for example "makes you Cyber Essentials compliant") — standardisation supports compliance, it does not grant it.