Microsoft does back up tenant configuration, so the honest answer to "is our configuration protected" is yes, within a defined scope and a short horizon. Microsoft Entra Backup and Recovery takes automatic daily backups of supported directory objects, including Conditional Access policies and named locations, and retains up to seven days of backup history. The Tenant Configuration Management APIs in Microsoft Graph let you snapshot current settings as a baseline and monitor for drift against it, with each snapshot retained for a maximum of seven days. Microsoft 365 Backup separately protects SharePoint, OneDrive and Exchange data with a one-year retention. The design question for a UK SMB or an MSP is therefore not absence. It is horizon and scope: a seven-day recovery window underneath an audit cycle measured in months.
Data backup and configuration backup are different problems
Microsoft 365 Backup is a strong product and deserves an accurate description. It backs up all or selected SharePoint sites, OneDrive accounts and Exchange mailboxes, with a one-year retention period across all three and recovery points at ten-minute intervals for the recent window. A full site or OneDrive account restores to its exact prior state, Exchange restores can be full mailbox or granular items found by search, and backups sit on append-only storage inside the Microsoft 365 data trust boundary so they cannot be overwritten by a service or malware action.
What it protects is content. It does not protect the settings that decide who reaches that content: the Conditional Access policy, the sharing configuration, the transport rule, the role assignment. Losing a file and losing the rule that guarded ten thousand files are different incidents with different recovery paths, and conflating them is how teams assume a gap is covered.
What Microsoft's shared responsibility model says
Microsoft publishes the division openly, and the table is worth reading rather than paraphrasing. In the responsibility matrix on Microsoft Learn, the row "Configurations and settings" is the customer's responsibility in every column: on-premises, IaaS, PaaS and SaaS. So are "Customer data" and "Identities and users". The article states that for all cloud deployment types you own your data and identities, and lists data, endpoints, accounts and access management as responsibilities you always retain.
That is not a gap in the platform. It is the contract, stated plainly, and it means "who owns our Conditional Access policy set" has a documented answer. Deciding what good looks like, and proving what it looked like last quarter, sits on your side of the line.
Data and configuration follow separate paths, with separate retention, and only one of them stretches to a year.
What Microsoft now provides for configuration
Two capabilities do most of the work, and plenty of runbooks have not caught up with either.
Microsoft Entra Backup and Recovery recovers critical directory objects to a previously known good state after accidental changes or compromise. Supported objects include users, groups, apps, service principals, Conditional Access policies, named locations, the authentication method policy and the authorization policy for selected properties. Backups run automatically once a day and retain up to seven days of history. Nobody can switch them off: Microsoft states that no signed-in user or application, even with the highest admin privileges, can turn off, delete or modify backups in the tenant. It needs a workforce tenant with Microsoft Entra ID P1 or P2, and access runs through two roles, Backup Reader and Backup Administrator. The feature most people underuse is the difference report: before recovering anything, compare the current tenant state against a backup and review exactly which attributes and links changed. Microsoft keeps expanding the supported list, so recheck it rather than trusting a note from last year.
The Tenant Configuration Management APIs in Microsoft Graph approach the same problem from the settings side, across workloads rather than only the directory. Snapshot APIs extract current configuration as a baseline representing the desired state, and monitoring APIs compare against that baseline and raise drifts, which you resolve in the relevant admin centre. The published limits tell you how to design around it: each monitor runs at a fixed interval of six hours, you can create up to thirty monitors per tenant, and you can monitor up to eight hundred configuration resources per day per tenant across all of them. Setting it up means adding the Tenant Configuration Management service principal to the tenant and granting it permissions first.
The seven-day horizon, against an annual cycle
Entra Backup and Recovery retains up to seven days of backup history. A Tenant Configuration Management snapshot is retained for a maximum of seven days, then automatically deleted. Both are sized for incident recovery, which is what they are for, and they are good at it: something broke this morning, compare, restore, move on.
An audit cycle is not shaped like that. Certification visits come round annually, client reviews quarterly, and questions arrive with a lag. If a Conditional Access exclusion was added in March and an assessor asks in November what the policy looked like beforehand, a seven-day window cannot answer, and by default neither can the change record, since Microsoft Entra audit logs are retained for seven days on Entra ID Free and thirty days on P1 and P2. That half of the problem gets its own treatment in how long your Microsoft 365 security evidence actually lasts.
So the state ages out in a week and the change record in a month. Anything you need to evidence beyond that has to be captured by you, before the window closes.
What is on the supported list, and what is not
Read the supported object list as an inclusion list, not a summary. Entra Backup and Recovery does not support the recovery or re-creation of hard-deleted objects. Soft-deleted users, Microsoft 365 Groups, cloud security groups, application registrations and service principals can be restored for thirty days, and the service complements that behaviour rather than replacing it. Objects mastered in Active Directory Domain Services need an alternative approach, although you can create difference reports for synchronised objects, and for some types such as groups you can move the source of authority to the cloud.
On the Tenant Configuration Management side the constraint is the quota rather than a fixed list. Eight hundred monitored resources a day sounds generous until you count every policy, rule and setting you would like to watch. Microsoft's worked example uses twenty transport rules and thirty Conditional Access policies in one monitor's baseline, which gives a sense of the intended granularity.
The useful exercise is a one-page inventory: for each configuration area carrying real risk, note which mechanism covers it, what the retention is, and who would notice if it changed. Most teams find two or three areas with nothing in the third column.
Deletion is loud, modification is silent
A deleted Conditional Access policy announces itself. Access breaks, the service desk lights up, somebody investigates within the hour, and seven days is ample.
A modified policy announces nothing. Add one group to an exclusion list, relax a session control, widen a named location, and everything keeps working. That is the point of the change, whether it was made in a hurry for a genuine reason or by somebody who should not have been able to make it. Nothing breaks, so nothing prompts an investigation, and the state that would have shown the before picture quietly expires.
This is why detection matters more than restore day to day. Difference reports and drift monitoring both answer "what changed" rather than "put it back", and the six-hour interval gives up to four comparisons a day against your baseline. One caveat belongs in your runbook: when an administrator updates the baseline of an existing monitor, all previously generated monitoring results and detected drifts for that monitor are automatically deleted. Re-baselining is legitimate after an approved change, and it is also an erasure, so record when and why you did it.
What proportionate looks like
For a small or mid-sized organisation, or an MSP running many tenants, this need not become a programme. Confirm the entitlement first, since Entra Backup and Recovery needs P1 or P2. Baseline the settings that carry risk rather than everything, keeping the list inside the daily quota. Export that configuration on a schedule to somewhere you control, dated, so the record outlives the seven-day horizon. Point drift monitoring at the policies where a silent change would matter most, typically Conditional Access, external sharing and privileged role assignment. Route audit logs to storage or analytics with a retention matching your audit cycle. Finally, write down who may change what, and treat every re-baseline as a change in its own right.
The controls an assessor asks about are the ones worth monitoring, and the mapping in Microsoft 365 settings against Cyber Essentials and ISO 27001 is a sensible place to choose which settings earn a monitor. The Cyber Essentials v3.3 checklist covers where scope statements sink an assessment, and the same "prove the number, not the screenshot" discipline applies to endpoints, as in why your Intune device count is wrong.
Where EtherInsights fits
The work above is straightforward once and tedious every month, which is where tooling earns its keep. EtherInsights keeps a dated view of tenant configuration alongside the cost, licence and endpoint picture, so a policy change shows up as an event with a before and after rather than as something you discover during an audit. Across a multi-tenant estate it gives the same baseline and drift view per customer.
Configuration assurance sits inside the control story covered by Microsoft 365 security and conformity, and the operational half, who changed what and whether it was approved, belongs with IT operations and compliance. Both lean on one idea: keep a baseline, watch for drift, and hold the evidence longer than the platform is designed to hold it.
Microsoft covers more of this than it did two years ago, and covers it well. Build for the horizon and the scope, not for an absence that no longer exists.
Explore Microsoft 365 security and conformity to see how baseline, drift and evidence fit together across one tenant or many.