Essential Eight regular backups: the technical controls at each maturity level

About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not a lab validation of the procedures. Check the stated versions and your own recovery requirements before making changes.

The regular backups strategy has the same four backup controls at every maturity level, and two access controls (ISM-1812 and ISM-1814) also stay unchanged. What rises between levels is the access limit: each level removes rights from another class of account, until at Maturity Level Three even the backup administrator cannot change or delete a backup during its retention period. A backup design therefore reaches a level through its permission model, its storage locks and a tested restore, not through how often the job runs.

The commands below were not run in a lab. They are reference material, not a ready-to-run procedure, until a qualified engineer has checked them on a test system. Server, group, role, bucket and file names are examples.

Recommendations and interpretations are editorial unless attributed; source research is not lab validation.

Why it matters

The Australian Signals Directorate (ASD) says a ransomware process running with an unprivileged user's rights should be blocked from overwriting or deleting backups, and that a compromised account with excessive backup rights lets an attacker easily encrypt or delete all backups.

ASD says organisations should reach the same level across all eight strategies before moving higher.

How it works

The controls by level

The table condenses the control text (for example, "accounts" for "user accounts") from the maturity model and the mappings printed against each control in the Information security manual (ISM) system management guidelines, September 2026 edition. ML1 to ML3 mean Maturity Levels One to Three.

The ISM uses "unprivileged" for accounts that cannot modify system configurations, account privileges, event logs or security configurations. Its "privileged" definition also covers accounts with limited privileges that can still bypass some security controls. That second half matters for backups, as the Windows section below shows.

Who can do what

This view is our reading of the controls and the assessment guide. A break glass account is a separately held account kept for emergencies (our wording; the ISM terminology page opened does not define it).

ASD adds design guidance at Maturity Level Two: backup administrator accounts should go to a small group of trusted administrators, and a separate group should be set up for restoring backups.

At Maturity Level Three, ASD says only a subset of privileged accounts, the backup administrators, should be able to access backups. A self-service portal where staff browse their own backups conflicts with that. So does letting a server administrator open a backup of a server they run. In both cases restores would need to be carried out by a backup administrator account.

Terms the model does not define

"Common point in time." ASD's guide explains it by the failure it prevents: data backed up out of sync with its applications and settings hampers restoration, and data may be lost. The pages opened set no tolerance in seconds. We read it as a recovery point at which the parts of one system are compatible with each other, not one timestamp across the whole organisation.

Mechanisms exist for this, each with limits:

• SQL Server transaction marks let related databases be restored to the same named point. You can recover them only to a mark, not to an arbitrary time, any later committed transaction is lost, and the mark does not spread to another server by itself. Microsoft says marking is suitable only when testing related databases or when you are willing to lose recently committed transactions, so weigh that before using it for production.
• Where no such mechanism applies, record which backup sets belong together and prove the set in the restore test.

"Secure and resilient." The assessment guide gives two examples of what to check: whether backups are encrypted, and how quickly they can be used to recover from IT equipment failures. A defensible design has an encrypted copy, a copy outside the failure domain of production, and keys that survive the loss of the production environment.

"Disaster recovery exercise." The guide's context says at least annually. It also says business-as-usual recovery of user files is not sufficient: the intent is restoring a significant component of a system in a scheduled exercise. The control text states no frequency.

Immutability sits beside the Essential Eight

The September 2026 ISM has two controls that the Essential Eight does not map: ISM-2151 and ISM-2152, both marked "Essential 8: N/A".

• ISM-2151: backups are stored using a technically enforced immutability mechanism for the duration of their retention period.
• ISM-2152: backup infrastructure, including servers, repositories and management consoles, is segregated from production and uses a separate authentication mechanism for administrative access.

The ISM's reason is that malicious actors routinely seek backup infrastructure using credentials harvested from production. A backup server that signs in against the production directory shares that directory's authentication, so we read it as not meeting ISM-2152.

ISM-1708 can be met by whatever stops a backup administrator. ISM-2151 asks specifically for a technical mechanism. In practice a storage-level lock is the straightforward way to satisfy both.

What to choose and why

Windows and SMB repositories: count the hidden rights

The assessment guide asks for a demonstration that an unprivileged account cannot reach other users' backups, cannot modify or delete its own, and cannot take ownership of content to change permissions. Folder permissions alone do not settle this:

• An owner can always change an object's permissions, even when denied all access. The Take ownership right gives that power over any object.
• The Back up files and directories right bypasses permissions for read through the backup API, and the Restore right bypasses them for write.
• Backup Operators members can back up and restore all files regardless of the permissions protecting them.

Those accounts can bypass security controls, so we read them as privileged under the ISM definition, whatever their group name suggests. Administrators count too. By default, Administrators and Backup Operators hold the backup and restore rights on standalone servers, and Administrators hold Take ownership. Policy can also assign each right to any list of accounts. Microsoft's pages for these rights are Windows 10 content dating from 2017, so confirm them on your Windows Server version.

List the holders on the server that holds the repository. The Active Directory Backup Operators group covers domain controllers, while a member server has its own local groups. From an elevated session there:

Get-LocalGroupMember -Name "Administrators"
Get-LocalGroupMember -Name "Backup Operators"
secedit /export /mergedpolicy /areas user_rights /cfg C:\Temp\rights.inf

Get-LocalGroupMember lists each local group. secedit /export writes the assigned rights to a file, and /mergedpolicy merges domain and local policy. Read the SeBackupPrivilege, SeRestorePrivilege and SeTakeOwnershipPrivilege lines.

Expand any domain group those commands return, including nesting. ASD names Active Directory queries and tools such as BloodHound for this.

Get-ADGroupMember -Identity "Repo-Admins" -Recursive

-Recursive includes indirect members. Then read the folder's access list on the server:

icacls D:\Backups

In the output, F is full access, M modify, DE delete, WDAC change permissions and WO take ownership. icacls does not show user rights, so it cannot prove the control alone.

The stronger evidence is an attempt, but a refusal alone proves little. The backup right is effective only through the NTFS backup interface, and taking ownership is a separate action. An account holding those rights can be refused an ordinary delete and still get through. So test each route, as a test account in each class being tested. The first command runs over the share. The others run on the repository server, where the rights apply:

Use a controlled canary exercise designed from the account-and-maturity matrix above. For each account class, record the operation, required expected result, exact disposable object, approving owner and evidence to retain. Reading, overwriting, deleting and taking ownership are separate tests; whether each must fail depends on the maturity level and account type.

Run the procedure only in an isolated test repository with no production backup paths reachable. An operation may succeed when the control is absent, so the design must tolerate deletion or ownership change without harming real data. Recreate the canary between independent attempts, record effective privileges and capture both successful and refused operations. The article supplies no executable destructive test commands because that procedure has not been validated here.

Pair every refusal with the list of who holds the rights.

Object storage: Amazon S3 Object Lock

Object Lock works only with versioning enabled and applies per object version. Two modes matter:

• Compliance mode: no user can overwrite or delete the version, including the account root user. The mode cannot be changed and the period cannot be shortened.
• Governance mode: anyone holding s3:BypassGovernanceRetention can override it by sending the bypass header. The S3 console includes that header by default.

Check the configuration, then a sample version:

aws s3api get-object-lock-configuration --bucket example-backup
aws s3api get-object-retention --bucket example-backup \
  --key canary/canary.dat --version-id EXAMPLEVERSIONID

The output shows ObjectLockEnabled and the default retention, then Mode and RetainUntilDate. A lock test needs a deliberately created canary version and a known account context. Plan ordinary version deletion and, for governance mode, the separate bypass-capable case. A refused request can mean either that retention blocked deletion or that the identity had no deletion permission in the first place, so document the effective permissions alongside the result.

Review identity policies, resource policies, permissions boundaries, organisation controls, session restrictions and relevant condition keys. Also examine who can alter those controls or obtain more privileged credentials. A short IAM simulator request does not model every relevant policy and context and cannot by itself prove that a role lacks bypass or self-escalation rights.

The test record should include the bucket, key, version identifier, retention mode and date, principal, request context and expected outcome. Use a short, deliberate test retention where supported, account for cleanup, and keep the procedure away from production backups. A compliance-mode canary may remain until expiry even when the exercise is complete.

Leave out --version-id and the request adds a delete marker instead. Locks do not prevent delete markers, so that call succeeding proves nothing, and neither does the object disappearing from a default listing.

Warning: compliance mode is deliberately irreversible. A wrong retention period on real data cannot be shortened. Test the design in governance mode first, as AWS suggests.

Which mode meets Maturity Level Three? Compliance mode stops a backup administrator only if that person does not control the AWS account, because deleting the account is the one early deletion route. Keeping account administration separate also fits ISM-2152. For governance mode, an assessor must evaluate whether ISM-1708 is met, including whether s3:BypassGovernanceRetention is held by a break glass account alone and no backup administrator can grant it through IAM or bucket policy. AWS says of that mode that you can still grant some users permission to delete the objects.

Whether governance mode satisfies ISM-2151 is unsettled. The control asks for a technically enforced mechanism that prevents modification or deletion for the retention period, and governance mode can be overridden by design. The pages opened do not decide this, so put it to your assessor.

Compliance mode has a cost of its own: ASD accepts that backup contents may need deleting for privacy or legal reasons, through break glass accounts at Maturity Level Three, and compliance mode leaves no such route. We recommend compliance mode where in-retention deletion is not a realistic obligation. Where it is, use governance mode with the bypass held only by a monitored break glass role, and accept the ISM-2151 question. The model requires such credentials to be long, unique, unpredictable and managed; long means at least 30 characters. Take legal advice on the deletion obligation; this article is not legal advice.

Object storage: Azure Blob

Microsoft's time-based retention has one trap for this control. A policy begins unlocked, and an unlocked policy can be shortened or deleted. A locked policy cannot be deleted or decreased, and Microsoft recommends locking typically within 24 hours. An unlocked policy does not stop an administrator who can change it, so we read it as not meeting ML3. A locked policy has the same cost as compliance mode: we read it as leaving no route for in-retention deletion. Microsoft also recommends enabling soft delete for extra protection before any immutability policies are applied.

Service accounts

The ISM defines a user as a human or non-human actor, and service accounts as user accounts used by non-human users. Only computer accounts fall outside user accounts. ASD's guide says that at Maturity Level Three all user accounts except break glass accounts should not be able to modify and delete backups. A backup job running as a service account is therefore in scope, and one that can delete within retention appears to fail the level.

Write without delete or bypass is closer to a requirement than a preference. A job that prunes expired restore points does need delete rights once retention has passed, so a storage lock is the normal way to reconcile the two: the job may issue the delete, and the lock refuses it until retention ends. Count the job's identity with the backup administrators when reviewing access.

The evidence an assessor can use

ASD ranks evidence in four levels:

Two documents the guide names directly are the business continuity plan showing frequency and retention, and, ideally, an after-action review or post-exercise report showing what was exercised and the lessons learnt. Assessors also ask when the last exercise ran and whether restoration was partial or full.

In the exercise record, name the system, the recovery point, the data, application and settings components restored, how you confirmed they worked together, the time taken and the lessons.

Risks and limits

• One ineffective control sinks the level. A strategy counts as implemented only if all its controls are assessed "effective" or "alternate control". A single "ineffective" stops the claim for that level. The guide also lists “no visibility”, “not implemented” and “not applicable”. On the all-controls wording, the first two block the claim as well. The guide does not say how "not applicable" is counted, so ask.
• Risk acceptance cannot replace a whole strategy. Assessors should not accept risk acceptance as a reason for skipping an entire strategy. Exceptions need compensating controls, approval through a process and regular review. Compensating controls need to provide equivalent protection. ASD adds that appropriate use of exceptions should not preclude an organisation from being assessed as meeting a level.
• Sampling. Assessors should test a representative sample and record limits. A locked repository for one system says nothing about the other backup targets.
• Retention versus lock length. Where a backup format depends on earlier restore points, a lock shorter than the chain leaves part of the chain unprotected. Check your product's documentation.
• Version. ASD updates these documents, so re-check control text and ISM mappings before an assessment.

Sources

Opened 2026-11-10.

• Essential Eight maturity model, ASD
• Essential Eight assessment process guide, ASD
• Essential Eight maturity model FAQ, ASD
• ISM guidelines for system management, ASD
• ISM cyber security terminology, ASD
• Take ownership of files or other objects, Microsoft
• Back up files and directories, Microsoft
• Restore files and directories, Microsoft
• Active Directory security groups, Microsoft
• Get-ADGroupMember, Microsoft
• icacls, Microsoft
• Get-LocalGroupMember, Microsoft
• secedit /export, Microsoft
• robocopy, Microsoft
• takeown, Microsoft
• Use marked transactions to recover related databases consistently, Microsoft
• S3 Object Lock, AWS
• delete-object, AWS CLI
• get-object-lock-configuration, AWS CLI
• get-object-retention, AWS CLI
• simulate-principal-policy, AWS CLI
• Immutable storage for Azure Blob Storage, Microsoft

This article was originally published on 10 November 2026.