Essential Eight backups for Microsoft 365, what applies

Do Essential Eight backups for Microsoft 365 need a separate backup?

Your organization always keeps responsibility for its Microsoft 365 data under the shared responsibility model, so a customer, contract or ASD-aligned assessment that asks for Essential Eight backup evidence will expect you to show how that data is protected. In-place retention policies and labels are one way to do it, but they are not a backup by default. Evaluate them against the backup requirements in ISM-1511, ISM-1810 and ISM-1811 (business criticality, synchronized restoration to a common point in time, and secure, resilient retention) rather than assuming they satisfy those controls. Microsoft's own Essential Eight backup guidance makes the same point: retention policies and labels should be assessed both as a backup stand-in and for their wider governance effects.

Whether you need a separate backup depends on three things: the target maturity level, the criticality of the data, and whether you can demonstrate restoration to a common point in time. Ask whether retention can restore Exchange, SharePoint, OneDrive and Teams data to the same point in time, and whether that restore has been tested as part of a disaster recovery exercise (ISM-1515). Then check who can alter or delete retained content. Under ISM-1812, ISM-1814 and the stricter ML3 requirements in ISM-1705, ISM-1707 and ISM-1708, unprivileged and privileged accounts must not be able to modify or remove backups, and backup administrators must not be able to change them during the retention period. Confirm these restrictions in your own tenant with the vendor documentation and your own test restores, because retention settings alone may not show them.

Where retention policies cannot meet these tests, a separate backup is the practical route, and it is usually the part a partner builds and tests. The organization still owns the decisions: the recovery objectives, the retention periods and who may access or delete backups. Ask any provider to state in writing which Microsoft 365 workloads are covered, how restores to a common point in time are proven, and where backup evidence is stored. Server system state and domain information can be covered with the Microsoft Azure Recovery Services (MARS) agent, which is a separate scope item from Microsoft 365 mailboxes and sites.

Retention policies and labels versus a separate backup

Microsoft's guidance allows in-place retention policies and labels to serve as one way of protecting Microsoft 365 data, because content held under retention is preserved even if a user deletes it. They are configured in Microsoft Purview and apply across Exchange, SharePoint, OneDrive and Teams content. The mechanism keeps data in place rather than copying it elsewhere, so the question is whether the retained copy meets the restoration and protection expectations of your backup strategy.

What it protects: Content that falls under a retention rule or label is kept for the configured period, including content a user has deleted from view.
What it does not protect: Retention does not provide a separate copy that is isolated from tenant administrators, so a tenant-level change or a misconfigured policy can affect the data it is meant to preserve.
Restore to a common point in time: Retention does not by itself synchronise data, applications and settings to a single restoration point, which the Essential Eight regular backups strategy expects.
Governance effects: Retention also determines how long data must be kept and when it must be deleted, so it can conflict with privacy or records obligations if applied without review.
Coverage gaps: Confirm with Microsoft which workloads and item types each policy covers, because retention scope differs between services.

Before relying on retention as a backup stand-in, check the Microsoft documentation for each workload and confirm with your legal and records teams how retention interacts with your governance obligations.

Covering server system state and domain information

Microsoft 365 backups rarely stand alone. The servers, identity infrastructure and settings beside them often fall under the same Essential Eight regular backups expectations, and they need their own scope decisions. The cards below cover the items that commonly sit at the edge of this scope.

Server system state

System state holds the operating system configuration, registry, boot files and, on domain controllers, the Active Directory database. Microsoft's guidance says server system state can be backed up with the Microsoft Azure Recovery Services (MARS) agent. Confirm the agent's support for each server version you run before you rely on it. Then check whether each server's restore procedure has been tested against the common point in time that ISM-1810 requires.

Domain information

Domain information, including directory objects and domain controller state, is what lets identity recover after an incident. Microsoft's guidance notes that domain information can also be backed up with the MARS agent. Record which domains, domain controllers and directory components are in scope, and whether restoring them would also restore the accounts and privileges that ISM-1705 and ISM-1707 restrict.

Criticality inventory for ISM-1511

ISM-1511 requires backups to be performed and retained according to business criticality and business continuity requirements. Build one inventory that lists each server, domain service and settings store, its owner, its recovery time expectation and its retention period. Without this list, teams cannot show which systems were in scope for backups and why others were excluded.

Settings and configuration stores

Device configuration, group policy objects, certificate authority data and infrastructure-as-code repositories often hold settings that are hard to rebuild by hand. Decide for each store whether it is backed up as a separate item, recovered from source control, or documented as rebuildable. Each choice should appear in the criticality inventory, with the reason recorded.

Synchronized restore testing

ISM-1515 requires restoration to a common point in time to be tested during disaster recovery exercises. Server system state and domain information must be restored together with Microsoft 365 data and settings, so the exercise shows whether identity, mail and files return to a consistent state. Ask your assessor which artifacts will show that the test covered these items.

Confirm agent support and access

Before you commit to the MARS agent, confirm its support for your server versions, your network path to the recovery vault, and how backup administrator access is separated. ISM-1708 requires backup administrator accounts to be prevented from modifying and deleting backups during retention, so the agent's administrator model belongs in your review. Keep the confirmation with your evidence.

How the backup evidence is built and tested

The sequence moves from deciding which Microsoft 365 workloads matter most, through configuring protection and access controls, to proving that a restore to a common point in time works. Each phase hands a named record to the next, so the final test can be traced back to the scope decision that justified it.

Scope Microsoft 365 workloads by business criticality
The organization's business continuity owner and data owners list the Microsoft 365 workloads in use, including Exchange Online mailboxes, SharePoint Online sites, OneDrive accounts, Teams data and Entra ID configuration where it matters for recovery. Each workload is rated by business criticality and by the recovery needs the business has agreed, which is the basis ISM-1511 expects for how backups are performed and retained. The output is a signed scope register that names each workload, its owner, its criticality rating and its retention requirement. Confirm that the register is approved before any retention or backup setting is changed.
Configure retention and backup synchronization
The Microsoft 365 administrators decide how each workload is protected. Microsoft's guidance describes in-place retention policies and labels as one option, but they should be evaluated both as a backup stand-in and for their wider governance effects. Where a separate backup product is used, including the Microsoft Azure Recovery Services (MARS) agent for server system state and domain information, its schedules are set so that all in-scope data is captured to a common point in time under ISM-1810. The output is a configuration record showing each policy, schedule and retention period, mapped to the scope register. Ask the platform team to confirm in writing which workloads a retention policy covers and which need a separate backup, because retention and backup do not always cover the same data.
Secure and retain backups resiliently
The team stores backup copies in a location that is separate from the production tenant's administrative plane and protected against loss, meeting the secure and resilient retention expectation in ISM-1811. Encryption, storage redundancy and the location of backup copies are documented against the retention periods in the scope register. The output is a storage and resilience record that names where each backup copy lives, how it is encrypted, and who can reach the storage. Review this record whenever the tenant, storage account or backup vendor changes, since the protection of the copies depends on those details.
Restrict access and deletion rights
The security team applies the access model that the Essential Eight requires for the target maturity level. Unprivileged accounts must not reach other users' backups or be able to change or delete them (ISM-1812, ISM-1814). Privileged accounts, other than backup administrators, must not access backups belonging to other accounts and must not modify or delete them (ISM-1705, ISM-1707). Backup administrator accounts must be unable to modify or delete backups during the retention period (ISM-1708). The output is an access matrix listing each role, its permitted actions and the group that holds it, along with exported role assignment reports taken from the admin consoles. Confirm the matrix with an access review before the restore test begins, because a restore test run by an account that could also delete the backup proves less than it appears to.
Test restoration within disaster recovery exercises
The business continuity team runs a disaster recovery exercise that restores in-scope Microsoft 365 data, applications and settings to a common point in time, which is the test ISM-1515 requires. The test should start from a defined recovery point, cover each workload in the scope register, and record the time taken and any gaps found. The output is a test report with the recovery point used, the workloads restored, the outcome for each, and the corrective actions raised. Keep the report with the scope register and access matrix, since an assessor will expect to trace a passed restore back to the decisions that made it possible. Confirm with your assessor or auditor which evidence format and sample they expect before the exercise.

What to have in place before an assessment

An assessor testing backups for Microsoft 365 will look for proof that the backup and retention design matches business need, that the people who can change it are known, and that restores have actually worked. The five items below connect those three questions, and each one has a named owner inside your organization.

Documented criticality register

A register that lists each Microsoft 365 workload (Exchange mailboxes, SharePoint sites, OneDrive, Teams) with its business criticality, recovery expectations and the retention period that follows from them. Backup scope under ISM-1511 comes from this document, so an assessor will ask how each retention setting traces back to it. Check that every workload appears and that the owner signed off the latest version. The business continuity lead typically owns it, with input from data owners.

Retention and backup configuration exports

Exports of retention policies, retention labels and any third-party backup job settings, taken from the Microsoft Purview portal or your backup platform. Confirm the export shows which locations each policy covers, whether retention is in-place, and how labels interact with policies. Review them against the criticality register to find gaps. The Microsoft 365 administrator who manages compliance settings owns these exports, and each export should carry a date.

Backup administrator role assignments

A current list of every account holding backup administrator rights, separate from global and compliance administrator roles where your tenant allows it. ISM-1708 requires backup administrators to be unable to modify or delete backups during retention, so check whether any of these accounts can also change retention settings. Export the Microsoft Entra role assignments and compare them against the approved list. The identity or security team owns this record, and the backup owner approves changes.

Deletion and access logs

Audit log evidence showing who deleted, purged or restored content, and who accessed backups belonging to other accounts. ISM-1812 and ISM-1814 require that unprivileged accounts cannot reach other users' backups or change them, so the logs should show attempts as well as successes. Confirm that audit logging is enabled, that retention on the logs themselves covers your review cycle, and that someone reviews them. The security operations team typically owns the review, and the Microsoft 365 administrator owns the log settings.

Dated restore test record

A record of each restore test showing the workloads restored, the point in time used, the people involved, the time taken and whether the restored data matched the source. ISM-1515 expects restoration to a common point in time to be tested within disaster recovery exercises, and ISM-1810 expects backups to be synchronised so that point in time is achievable. Keep the record with the test scope and any failures or fixes. The business continuity lead runs the exercise, and the backup owner signs off on the result.

Who owns the controls, who prepares evidence, who assesses

Your organization owns the controls. Microsoft's guidance is explicit that customers keep responsibility for their information under the shared responsibility model, so the business decisions behind Microsoft 365 backups cannot be delegated to a vendor. Those decisions determine what the configuration must achieve, and an assessor will ask who made them and when.

Criticality and continuity: Decide which Microsoft 365 data, such as mailboxes, OneDrive, SharePoint and Teams, is business critical, and set retention and recovery expectations that reflect business continuity requirements (ISM-1511).
Retention rules: Approve in-place retention policies, labels or separate backup retention, and document whether they serve as a backup stand-in, a governance control, or both.
Access approvals: Name the backup administrators and approve who may restore, view or change backups, consistent with the privileged access restrictions in ISM-1705, ISM-1707 and ISM-1708.
Restore sign-off: Accept the outcome of common point in time restore tests run as part of disaster recovery exercises (ISM-1515).
Ongoing records: Keep approvals, review minutes and exception decisions in a form the assessor can read.

Confirm with your assessor which of these decisions they expect to see signed by a named role.

Questions buyers ask about Essential Eight backups for Microsoft 365

Are Microsoft 365 retention policies enough to meet the Essential Eight backup strategy?

Retention policies and labels can be one way to keep Microsoft 365 data recoverable, but they are not automatically a complete backup. Microsoft's own Essential Eight guidance says customers keep responsibility for their data under the shared responsibility model, and that retention policies and labels should be evaluated both as a backup stand-in and for their wider governance effects. The deciding factors are whether they meet your restoration point, your business continuity requirements and the access and deletion restrictions your target maturity level demands. Ask your Microsoft account team and your assessor to confirm how the controls you rely on behave for each workload, including what a user or administrator can delete and how restoration to a common point in time works.

Does each maturity level require a separate backup product?

The Essential Eight does not name a product. It sets requirements for how backups are performed, synchronised, retained and protected, and those requirements tighten as you move up the levels. Whether a separate backup platform is needed depends on whether your existing Microsoft 365 features can meet those requirements at your target level, particularly the restrictions on who can modify or delete backups. Many organizations find that the access and immutability requirements at the higher levels drive the decision. Confirm the exact requirements for your target level in the ISM Essential Eight profile, then test each candidate against them.

How do server system state and domain information fit into Microsoft 365 backups?

Microsoft 365 backup covers cloud data, but Essential Eight backup scope also includes the systems and settings your organization depends on. Microsoft's guidance notes that server system state and domain information can be backed up with the Microsoft Azure Recovery Services (MARS) agent. Your engineers should list every system, configuration and identity source needed for recovery, then confirm each one has a backup that can be restored to the same point in time as the rest of the environment. Restoration to a common point in time must also be tested during disaster recovery exercises, so system state backups belong in the same test plan.

What does the work need from internal staff?

Internal staff must own decisions that no outside party can make for you. These include setting the backup criticality tiers and recovery objectives tied to business continuity, approving who may hold backup administrator or privileged roles, and deciding retention periods. Staff also need to run restoration tests, review backup logs and keep records that an assessor can inspect. Engineering time goes into configuring retention, immutability and access controls, and into maintaining them when Microsoft 365 licensing or administrative roles change. Plan for these people to participate in the work, not only approve it at the end.

Can we implement and evidence Essential Eight backups in-house?

Many organizations with capable Microsoft 365 administrators can do this in-house, especially at the lower maturity levels where the work is mostly configuration and documentation. The harder parts are restoration testing against a common point in time, separating backup administrator roles from everyday administration, and producing evidence in a form an independent assessor can verify. Ask whether your team has the time to build and maintain the test cycle, and whether it can produce the logs and records that show the controls operate over time. If you bring in an implementation partner, the partner prepares systems and evidence, while your organization still owns the controls and the independent assessor provides any assessment outcome.

What drives the cost and effort of Microsoft 365 backups?

Cost depends on the size and number of Microsoft 365 workloads in scope, the target maturity level, the retention periods you set, and how many systems outside Microsoft 365 need backing up. Licensing for any backup platform recurs, while design, configuration and restoration testing are largely one-time efforts that are repeated when the environment changes. Higher maturity levels add immutability and stricter access controls, which usually add engineering and review work. When requesting a quote, ask the provider to itemize scope by workload, identify which tasks are one-time and which recur, state the testing cadence, and list what they expect your staff to provide.

How do we confirm a backup capability with a vendor before buying?

Ask the vendor for written answers to specific questions rather than relying on marketing summaries. Confirm whether the feature covers each workload you need, whether backups can be restored to a common point in time, whether unprivileged and privileged accounts can modify or delete them, and whether backup administrators can be blocked from changing backups during the retention period. Request documentation, a demonstration in a test tenant and the logs the product produces. The Microsoft Learn Essential Eight regular backups page is a useful starting point for Microsoft's own position, and your assessor should review the results against the ISM controls for your target level.

How DeployOpen prepares Microsoft 365 backup evidence

DeployOpen plans, implements and documents backup systems for Microsoft 365 data inside your own infrastructure, so the evidence you show an assessor reflects how your environment actually behaves. We prepare systems and records for your assessment; the organization owns its controls, and an independent assessor forms the conclusion.

How we scope

Engagements are fixed-scope, with the written scope agreed before any work starts.
Scope records which Microsoft 365 workloads, retention settings and backup targets are covered by the backup strategy.
We confirm the target Essential Eight maturity level with you and map each backup control to the systems it governs.

How we build

We configure retention policies and labels, then document whether they replace or supplement a separate backup.
We set up separate backup storage where the design requires it, with access limited so unprivileged accounts cannot change or delete backups.
We test restoration of data to a common point in time and record the results for your disaster recovery exercises.

How we hand over

You receive configuration records, access role assignments and restoration test results written for your assessor.
Documentation explains the backup schedule, retention periods, deletion restrictions and the owner of each control.
We walk your team through the evidence so your staff can produce it again during future assessments.

How we support

Ongoing support, upgrades and recurring restoration testing are available as a retainer after handover.
Retainers can cover reviews of retention settings when Microsoft 365 licensing or administrator roles change.
Your organization keeps ownership of the controls, and any independent assessment remains with your chosen assessor.

Essential Eight backups for Microsoft 365