Regular backups maturity level 3: requirements and evidence

What Essential Eight regular backups at ML3 requires

An assessor or customer asking for ML3 backup evidence is asking about more than who can read backups. At Maturity Level Three, the restrictions reach backup administrators, not only ordinary users. Under the ISM Essential Eight baseline, ISM-1813 and ISM-1706 bar unprivileged accounts, and privileged accounts other than backup administrator accounts, from accessing their own backups, while ISM-1708 requires that backup administrators be prevented from modifying or deleting backups during their retention period. These three ML3 backup controls replace the ML2 control set in the ISM Essential Eight profile, so ML2 evidence alone will not satisfy ML3. The ML1 and ML2 duties still apply, including backups of data, applications and settings, synchronised point-in-time copies, secure retention and test restores.

The risk this addresses is ransomware or a malicious insider who holds administrative credentials and uses them to encrypt or delete the backup set before anyone notices. If the same account that runs backups can also erase them, a stolen administrator credential defeats the recovery plan. Immutability and separation of duties are usually the hard parts. Immutability requires storage that refuses changes or deletion until the retention period ends, and the organization must confirm that the chosen backup software and storage backend enforce this rather than relying on policy. Separation of duties requires that the people or accounts who run backups cannot override the retention lock, which often means changing who holds root or cloud owner rights on the backup storage.

Action items for the reader: write down which accounts can reach each backup repository and confirm no user or non-backup privileged account is on that list; document how backup administrator actions are restricted during retention; and test that a deletion attempt under a backup administrator account is refused. Bareos keeps a catalog of backed-up files and manages retention through its Director, and restic's check command with --read-data can confirm stored data is unmodified, but neither product proves immutability on its own. Ask your implementation partner and independent assessor to confirm how the retention lock is enforced in your environment, and retain the configuration and test records as evidence.

Which backup systems, accounts and third parties fall in scope at ML3

Maturity Level Three for regular backups reaches every system that stores, moves or restores backup data, not only the backup server. The cards below cover the components an assessor will ask about and the scoping choices that change how much work the level requires.

Backup servers and catalogs

The backup server schedules jobs and holds the catalog that records which files sit in which backup. At ML3, the people and accounts that can change the catalog or the job schedule are part of the protected set. Bareos, for example, keeps its catalog in SQL, so the database server, its credentials and its own administrators fall in scope. Check where the Director and catalog run, who can log in to them, and whether catalog backups are themselves protected from deletion.

On-premises backup storage targets

Disk repositories, network-attached storage and backup appliances are where most ML3 immutability questions get decided. Confirm whether the storage supports write-once retention enforced below the administrator layer, or whether the only protection is an access policy that a backup administrator can change. Ask the vendor how retention locks are applied and whether they can be removed before the retention period ends.

Cloud object storage and offline media

Cloud buckets, tape libraries and removable media often hold the copies that make a backup set recoverable after an attack. Each location needs its own answer on immutability, object lock or write-once settings, and on who holds the root or account-owner credentials. Offline or air-gapped copies still count if they hold backup data and can be reached by a backup administrator. List every copy destination and its retention control in the scope document.

Backup administrator and operator accounts

Backup administrator accounts carry the ML3 requirement that they cannot modify or delete backups during retention, so they need their own scope line. Check whether these accounts are shared with domain administration. If they are, a compromised domain administrator can reach the backup platform, and the separation the level expects is not in place. Operator accounts that only run jobs and view status need a separate review of their rights.

Restore accounts and restore paths

Restore accounts can read backup data, which makes them a route to the content that ML3 protects. An unprivileged user or a non-backup privileged account must not reach their own backups, so restore rights are a scope item in their own right. Document who can start a restore, which systems a restore can write to, and whether restored data lands on production networks where it can be reached again.

Managed backup providers and network reach

A managed backup provider holds backup data and admin access on the organization's behalf, so its staff, tooling and support channels fall in scope. Ask whether the provider can delete or alter backups in the retention period and how that control is evidenced. Also check whether backup storage is reachable from production administrative networks, since that path changes which accounts and hosts an assessor must test.

How backup access is separated at ML3

At Maturity Level Three, the access model for backups rests on one split: ordinary users and most privileged accounts cannot read backup data at all, and even backup administrators cannot change or delete backups while they are inside their retention period. The Essential Eight baseline ties this to ISM-1813 and ISM-1706, which state that unprivileged accounts, and privileged accounts other than backup administrator accounts, must not access their own backups. ISM-1708 then requires that backup administrator accounts be prevented from modifying and deleting backups during retention. Read together, these controls define three roles: people who consume backups for restores, the backup administrators who run the platform, and everyone else. Each role needs a different permission set, and the access review for each should be documented separately.

The reason for separating backup administrators from other privileged accounts is that a backup is only evidence of recovery if it cannot be altered by the same actor whose compromise it is meant to survive. An attacker who gains domain administrator rights can often reach backup servers, and a backup administrator who can also delete the repository lets that attacker erase the recovery path in one step. For that reason, the retention decision should not sit with the same identity that runs the jobs. In practice, the organization should confirm that retention periods are set and enforced by a control that a backup administrator cannot override, such as immutability or object lock on the storage, and that deletion before expiry requires a separate approval outside the backup platform. Ask your platform team to demonstrate this with a test deletion attempt under a backup administrator account, and record the result.

For open-source platforms, the mechanics differ by tool. Bareos separates the Director, which schedules and supervises jobs and keeps the catalog, from the storage and client components, so the organization must decide which accounts can run restores, change pool retention and purge volumes. restic repositories are encrypted and accessed through a password or key, so key custody is an access decision in its own right. Whatever tool is used, the organization owns the access policy and the evidence that it holds, while an implementation partner can configure storage immutability and role separation and an independent assessor tests whether it works. Confirm with your platform vendor which retention and deletion protections are native and which depend on the underlying storage.

How an assessor tests ML3 backup immutability

This table sets out, for each of the three ML3 backup controls, how an assessor tests access and deletion rights, what evidence they request, and where organizations commonly fail. Read each row as a test the assessor will run against your configuration, not as a design choice. The main takeaway is that backup administrators must be unable to delete or shorten retention, and that policy statements alone will not pass.

Control	Assessor test approach	Evidence requested	Common findings
ISM-1813 (unprivileged and non-backup privileged access)	Review the access control configuration on the backup server, catalog and storage repository. Attempt access to a backup set as an ordinary user and as a privileged account that is not a backup administrator.	Role and group membership exports, access control lists for backup repositories, and logs of denied access attempts from test accounts.	Domain administrators or server administrators can browse or restore other users' backup sets through inherited rights.
ISM-1706 (privileged accounts other than backup administrators)	Confirm that privileged accounts outside the backup administrator group cannot read, restore or export backup data. Test restore and file browse functions with those accounts.	Documented list of privileged accounts with their assigned backup roles, and test results showing blocked restore or browse attempts.	Standing restore rights granted to local administrators on backup clients, so any server admin can recover another system's data.
ISM-1708 (backup administrators cannot modify or delete during retention)	Attempt to delete, overwrite or shorten retention on a live backup as a backup administrator inside the retention period. Review whether immutability or object lock is enforced at the storage layer, not only in the backup application.	Retention policy settings, immutability or object lock configuration, and a dated record of a rejected deletion attempt by a backup administrator account.	Backup administrators hold standing deletion rights, or the same account can shorten retention, so the control depends on trust rather than enforcement.
Retention and immutability settings	Review the configured retention period for each backup pool and confirm it cannot be reduced by the account that performs routine backup operations.	Configuration exports showing retention periods, the change control record for any retention change, and the identity that approved it.	Retention values are editable through the same console used for daily operations, with no second approval step.
Separation of duties	Check that the account that creates backups, the account that manages retention, and the account that manages storage credentials are not the same identity.	Role matrix showing each identity and its permitted actions, plus evidence of periodic access reviews.	One break-glass account holds every backup right and is used for routine work, so separation exists on paper only.
Key and credential control	Confirm that backup encryption keys and storage credentials cannot be used by a backup administrator to bypass immutability at the repository level.	Key custody records, storage credential inventory, and a description of who can rotate or revoke credentials.	Backup administrators hold the storage administrator credential, which allows deletion outside the backup application.
Event logging for backup changes	Trigger a retention change and a deletion attempt, then confirm the events are recorded, timestamped and retained outside the backup administrator's reach.	Log samples showing backup job, retention and access events, and confirmation of where logs are sent.	Backup logs are stored only on the backup server, which a backup administrator can alter or clear.

Sequence to implement ML3 backup controls

This sequence moves an organization from its existing backups to a configuration where no ordinary user or non-backup administrator can read backups, and where backup administrators cannot change or delete backups during retention. Each step ends with an artifact that an assessor can inspect. The exact configuration depends on the backup platform, so confirm each setting against the vendor documentation before relying on it.

Inventory backup scope and accounts
Start by listing every system, dataset, application and configuration set that is backed up, along with the backup jobs, storage targets and retention periods that cover them. Then list every account that can touch those backups, including service accounts, human administrators, and any account that holds privileges on the backup server or storage. The owner of this step is usually the backup or platform team, with the security team reviewing it. The output is a backup register and an account register that name each account's role. You know this step is done when every backup job maps to a named target and every account with backup access has a documented reason for it.
Separate backup administrator roles from other privileges
Create a distinct backup administrator role and assign it only to accounts whose job is to run, configure or restore backups. Remove backup rights from general system administrators, application owners and standard users where they are not needed, and make sure no one retains backup access through inherited group membership. Backup administrator accounts should be separate from everyday accounts so that their use is traceable. The output is a role assignment list and a revised privilege model showing that backup administration is isolated from other privileged work. Confirm how your platform represents these roles, since the names and granularity differ between products.
Enforce write-once or immutable retention on the backup target
Configure the backup storage so that written backups cannot be altered or deleted before their retention period expires. This may be object lock or a write-once setting on the storage platform, or a repository design that keeps retained data append-only. The configuration should hold even when a backup administrator attempts to delete or shorten retention. Record the retention settings, the lock mode and the storage location in the configuration baseline. Ask the vendor whether the lock can be overridden by the same account that created it, because that answer decides whether this step meets the requirement. The output is a screenshot or exported configuration showing the immutability setting applied to each backup target.
Restrict read access for unprivileged and non-backup accounts
Limit access to backup data so that unprivileged accounts, and privileged accounts other than backup administrators, cannot read their own backups or anyone else's. Check file system permissions, backup client policies, restore portals and any web interfaces that expose backup catalogs. Pay particular attention to users who restore their own files, because that feature can grant read access to backup content unless it is controlled. The output is an access test record showing that each account class is denied access to backup stores, catalogs and restore functions outside its role.
Test that backup administrators cannot alter retention or delete
Run a controlled test in which a backup administrator attempts to delete a backup, shorten its retention, disable the lock or change the storage policy during the retention period. The attempts should fail at the storage or platform layer, not only because the administrator chooses not to act. Repeat the test after any platform upgrade or configuration change. Record the test steps, the accounts used, the time of each attempt and the error or refusal returned. The output is a signed test report that an independent assessor can rerun. Where a test succeeds, treat the result as a defect and fix the configuration before closing the step.
Document and retain configuration evidence
Write down the backup design, role model, immutability settings, access controls and test results in a configuration baseline. Store copies of the exported configuration, logs of backup and restore jobs, and the test reports in a location that backup administrators cannot modify. Set a review schedule that rechecks the configuration and re-runs the deletion test. The owner is the control owner, with the platform team supplying the evidence. The output is an evidence pack organized by control, with each artifact dated and linked to the system it covers. Confirm with your assessor which artifacts they expect, since evidence requirements vary by assessment approach.

Evidence that proves ML3 backup controls work

Maturity Level Three backup controls are only as credible as the records behind them. The cards below cover the artifacts an assessor is likely to ask for, and the routine that keeps each one current between assessments. Your organization owns these controls, while an independent assessor decides whether the evidence supports the maturity level claimed.

Backup access control configuration exports

Export the access control settings from the backup server, the backup storage and any cloud backup console, then store dated copies with change history. Assessors check that unprivileged accounts and non-backup privileged accounts have no route to read, restore or browse backup sets. Confirm that the export shows effective permissions, not only role names, because inherited permissions often widen access. Repeat the export after every platform upgrade.

Backup administrator role and account listings

Produce a listing of every account that can administer backups, with its role, owner, approval record and last sign-in. Compare it against the directory of privileged accounts so each backup administrator is a separate, named identity that is not used for daily work. The listing shows the separation required by ISM-1813 and ISM-1706 in a form an assessor can sample. Review it on a fixed schedule and record the reviewer's sign-off.

Immutability and retention lock configuration

Capture the retention lock or object lock settings for each backup repository, including the retention period, the lock mode and who can change it. The key question is whether backup administrators themselves can shorten or remove a locked backup during retention, which ISM-1708 prohibits. Test this on a non-production repository so the evidence shows the lock behaves as configured, not only as documented. Record the configuration hash or snapshot of the settings.

Logs of blocked deletion and modification attempts

Retain logs showing that attempts to modify or delete backups during retention were refused, along with the account, time and source of each attempt. Forward these events to a central log store that backup administrators cannot edit. ML3 extends timely event log analysis to non-internet-facing servers and workstations under ISM-1907 and ISM-0109, so confirm that alerts on these events reach a responder. Keep a record of how each alert was triaged.

Restore test records

Keep a dated record for each restore test, showing the backup set selected, the target system, the person who ran the test and whether the restored data matched the source. For self-hosted tools, verification commands such as restic check with read-data options produce output that can be filed with these records. Restore tests should cover backups that are still under immutable retention, because that is where a failure would matter most. Record any failed test and the corrective action taken.

Retention change records and periodic reviews

Log every change to retention periods, lock settings and backup administrator membership with a ticket, an approver and the reason. Keep a configuration snapshot at each review, so the assessor can compare the setting in force at a given date against the approved change. Schedule an access review of backup roles, then file the outcome with the configuration exports. Ask your assessor which review interval they expect to see for your environment before you set one.

Why ML3 logging on backup systems matters for assessment

At Maturity Level Three, the ISM Essential Eight baseline extends timely event log analysis from internet-facing servers to non-internet-facing servers and workstations (ISM-1907, ISM-0109). For backups, this means the backup server, the storage target and the admin workstations used to manage them fall inside the logging review, not only the systems that face the internet. An assessor will expect you to show that backup platform events reach a central log store and are reviewed in time to matter. Confirm with your assessor which review cadence they will accept as timely for your environment, because the baseline sets the expectation but leaves the interval to the organization.

The events that matter most for this control are the denied ones. Under ISM-1813, ISM-1706 and ISM-1708, an unprivileged user or a non-backup-administrator privileged account that tries to read another account's backup should be refused, and a backup administrator that tries to modify or delete a backup inside its retention period should be refused too. If your Bareos Director or restic repository stores audit records of those refusals, forward them to the central store and alert on them. Ask your team to produce a sample of denied access and deletion attempts from a test run, because an assessor will often ask to see that the log entries exist, not just that logging is turned on.

Before the assessment, confirm three decisions in writing: which backup components write logs, where those logs are held, and who can alter or clear them. A backup administrator who can edit the log store can also hide a failed deletion, so log retention and write access should sit outside the backup administrator role. Ask your implementation partner to document the log sources, the forwarding path and the alert owner, and ask your auditor which evidence they will sample. Whether an assessor accepts your log review as meeting the baseline is their determination, not the implementation partner's.

What meeting ML3 backup controls costs

This table lists the cost components of meeting Maturity Level Three backup controls, marking each as one-time or recurring and naming what moves it up or down. No figures are given because none are supplied for this topic, so use the table to structure a quote request and ask each supplier to price every row separately. Self-hosted open source removes license spend, but the infrastructure and staff time rows remain.

Cost component	One-time or recurring	Who is paid, and what drives it
Immutable or write-once storage	One-time setup, recurring storage	Storage vendor or your own infrastructure team. Driven by retention length, data volume and whether object lock or equivalent is available in your environment. Ask whether immutability is enforced at the storage layer.
Backup platform licenses or self-hosted effort	Recurring	Commercial licenses are billed per capacity, client or module. Self-hosted tools such as Bareos (AGPL-3.0-only) carry no license fee, but you pay for hosting, patching and staff time to run the Director, catalog and storage daemons.
Engineering time to separate roles and configure retention	One-time	Internal staff or an implementation partner. Driven by the number of account types, existing directory design and how many systems need backup administrator separation. Ask for the role model and retention settings in writing.
Dedicated backup administrator accounts and access controls	One-time setup, recurring administration	Identity and access work to keep unprivileged and privileged accounts out of backups, and to keep backup administrators from altering retained data. Driven by directory complexity and the number of administrative paths into the backup server.
Restore and integrity testing	Recurring	Internal staff or external testers. Tools such as restic check with read-data options add compute and time per run. Driven by data volume and how often you test. Ask what is tested and how results are recorded.
Evidence upkeep	Recurring	Internal GRC or security staff. Covers job logs, retention configurations, access reviews and restore test records. Driven by how many systems are in scope and how often evidence is collected.
External testing or review	Recurring or per engagement	Independent reviewers or testers. Scope depends on whether you want a readiness review of role separation and immutability before an assessment. Ask for a fixed scope in writing.
Auditor sampling and assessment	Per assessment	The independent assessor, not DeployOpen or any other implementation partner. Driven by how many backup jobs, retention sets and administrator accounts the assessor samples. Ask your assessor what evidence they will request.

Self-hosted open-source options for ML3 backups

Bareos is an open-source backup system licensed under AGPL-3.0-only. Its Director is the central component that schedules and supervises backup, restore, verify and archive jobs, and it keeps a SQL catalog of the files it has backed up. That catalog is what lets an operator restore files selected from the current backup or from the backup that existed before a given date and time, which supports the point-in-time recovery expected at higher maturity levels. For ML3, the ISM controls that matter most are ISM-1813, ISM-1706 and ISM-1708, which separate backup administrators from other accounts and stop administrators from changing backups during retention. Bareos can express role separation in its configuration, but the organization must still confirm that the administrator accounts are the only ones with access to the catalog and storage, and that no ordinary user or privileged account outside the backup team can reach the backup data.

Director scheduling: Confirm that the schedules, retention settings and job definitions are stored under version control and reviewed by someone other than the person who changed them.
Catalog protection: Confirm who can read and alter the SQL catalog, since catalog changes can hide or misrepresent backup history.
Restore testing: Confirm that restores are run from both the current backup and an earlier point, and that results are recorded.
Storage immutability: Confirm that retention and immutability are enforced on the storage target itself, such as object lock or write-once media, because the Director's settings alone do not prevent deletion by someone with storage credentials.
Licensing: Confirm with counsel how AGPL-3.0-only terms apply if you modify Bareos and offer it to users over a network.

Check each item against your own environment and the current ISM Essential Eight profile before relying on Bareos for ML3 evidence.

Where ML3 backup implementations usually fall short

Most Maturity Level Three backup designs fail in the same few places: an administrator can still reach deletion rights through another role, or the controls exist on paper but were never exercised. The cards below cover six gaps an assessor is likely to probe, each with a closing step the organization can check before the assessment.

Domain and hypervisor admin deletion rights

A backup administrator may be blocked from the backup console but still hold domain administrator or hypervisor administrator rights that let them delete backup repositories, snapshots or the storage volumes underneath them. ISM-1708 expects backup administrators to be prevented from modifying and deleting backups during retention, so that prevention has to hold across every role they can reach. Close it by listing every account that can touch the backup storage, including hypervisor and storage consoles, and removing delete rights from each path.

Retention settings editable by the same account

A retention period that the backup administrator can shorten, or a lock that the same administrator can remove, provides no protection against that administrator. Immutability has to be set by a control that the backup administrator cannot override during the retention period. Close it by testing whether the account that runs backups can change the retention value, extend it, or disable the lock, and by confirming that any such change requires a separate approval path.

Backup catalogs reachable by ordinary users

The backup catalog records which files were backed up and when, and it can expose file names and paths even when the file contents are protected. ISM-1813 and ISM-1706 require that unprivileged accounts, and privileged accounts other than backup administrators, cannot access their own backups. Close it by checking catalog and restore interfaces with a standard user account and a non-backup privileged account, then confirming both are refused.

No evidence of attempted deletions

An assessor will look for proof that deletion attempts were blocked, not only a configuration that should block them. Without logs of refused delete or modify requests, the organization cannot show that its controls were exercised or that an attempt would be noticed. ML3 also extends timely event log analysis to non-internet-facing servers and workstations under ISM-1907 and ISM-0109. Close it by confirming that backup platform and storage audit logs capture refused deletions and that someone reviews them on a defined schedule.

Immutability never tested

A backup set can be marked immutable and still be deletable if the storage layer, a snapshot policy or a failover target was configured differently. Many organizations only discover this during an incident. Close it by running a controlled deletion test against a non-production backup set in the retention period, recording the result, and repeating the test after any change to storage, hypervisor or backup software. Keep the test records as evidence.

Shared administrator accounts

When several people share one backup administrator login, the logs cannot show which person performed a change or deletion attempt, and the separation of duties that ML3 depends on collapses. Close it by assigning each backup administrator a named account, removing shared credentials from the backup platform and storage consoles, and checking that the audit trail records the individual user for every action.

Questions buyers ask about ML3 backup costs, effort and assessment

How much more effort do ML3 backups take compared with ML2?

ML3 usually adds work in access separation and retention enforcement rather than in backup volume. At ML2, privileged accounts other than backup administrators must not reach or change backups, so the main change is that access must be designed and tested. At ML3, backup administrators are also barred from modifying or deleting backups during the retention period, which normally means immutable or write-once storage, retention locks enforced outside the administrators' control, and separate credentials for the storage layer. The effort drivers are the number of backup systems in scope, how many storage locations need immutability, whether retention periods are already defined, and how much evidence the assessor will ask to see. Ask any partner to split its quote into design, configuration, testing and evidence collection so you can see where the ML3 increment sits.

Does a self-hosted backup tool remove license spend?

A self-hosted open-source tool can remove per-seat or per-terabyte licence fees for the backup software itself, but it does not remove the cost of running it. Bareos is licensed under AGPL-3.0-only and restic under BSD-2-Clause, so the software can be used without a commercial licence, subject to the terms of each licence. The recurring costs that remain include the storage capacity you buy or operate, the hardware or cloud accounts that host the Director and catalog, monitoring, patching, and staff time for restore testing. Immutability often depends on the storage target rather than the backup application, so confirm what object lock, WORM or retention features your chosen storage provides. Ask for a total cost comparison that lists licence, infrastructure, storage and support lines separately.

What does the internal team need to contribute to ML3 backups?

Your internal team owns the controls, approves the access model and keeps the evidence, so it needs named owners rather than a large workload. Typical contributions include identifying which systems and data are in scope, confirming retention requirements with business and legal owners, approving who holds backup administrator roles, and reviewing restore test results. Engineers need enough time to maintain the backup environment, apply patches, and respond when a job or restore fails. Where skills are thin, the gap is usually in storage immutability and in documenting how deletion is blocked during retention. Before committing, confirm which of these tasks your staff can absorb and which need outside support.

Can an implementation partner set up ML3 backups for us?

Yes, an implementation partner can plan, configure, harden and document the backup environment and prepare the evidence, but it cannot decide that your organization meets ML3 or issue any certificate. DeployOpen plans, implements, hardens, backs up, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks, and it prepares systems and evidence for compliance assessments. The Essential Eight is a set of mitigations rather than a certification scheme, so maturity is assessed against the ASD maturity model by your own assessor or internal review, and you own the outcome. Ask any partner to show which deliverables it produces and which decisions remain with your staff.

How long does a fixed-scope ML3 backup engagement take to agree in writing?

The time to agree a fixed-scope engagement depends on how quickly scope, systems and deliverables can be defined, not on a standard duration. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Delays usually come from unclear system inventories, undecided retention periods, unresolved storage choices or slow approvals for administrator roles. To speed this up, prepare a list of backup sources, current retention rules, storage locations and the roles that touch backups. No duration is set here, so ask for the agreed timeline and its dependencies in the written scope before signing.

Can we self-assess our ML3 backup controls without outside help?

Yes, an organization can self-assess its backup controls, and many do so as a first pass, but a self-assessment cannot replace an independent assessment or produce an external certificate. Start from ASD's Essential Eight Maturity Model and its ISM Essential Eight profiles, which list the ML3 backup controls, including ISM-1813, ISM-1706 and ISM-1708, and check each against your configuration and evidence. For a useful self-assessment, test access by each account type, attempt to delete a backup as a backup administrator during retention, and run restore tests with recorded results. Where the results are not clear, bring in an assessor. Confirm with your governance or audit function what internal assurance is required.

What evidence will an assessor ask for on ML3 backup immutability?

An assessor will typically ask to see the configuration showing that backups cannot be changed or deleted during retention, and proof that a backup administrator cannot override it. Useful evidence includes access control lists showing which accounts can reach backups, storage settings showing retention locks, logs of denied deletion attempts, and restore test records. Using a tool such as restic, you can run check with the read-data options to confirm stored data is unmodified, and Bareos keeps a catalog that records what was backed up and restored. Confirm the exact evidence format with your assessor before the engagement starts.

How DeployOpen prepares ML3 backup controls and evidence

DeployOpen works on Regular backups maturity level 3 by planning, building and documenting self-hosted backup systems inside the client's own infrastructure. The organization keeps ownership of its controls, and DeployOpen prepares the systems and evidence that an independent assessor reviews.

How we scope

Engagements are fixed-scope, with the backup estate, retention periods and administrator roles agreed in writing before work starts.
The written scope lists which systems, data sets and backup administrator accounts must be restricted from access and deletion.
Scope documents which environments, including air-gapped networks, are covered and which are excluded from the ML3 backup work.

How we build

We configure a self-hosted backup director and catalog to schedule, verify and restore jobs inside the client's infrastructure.
We set up immutable retention so that backup administrators cannot modify or delete backups during the retention period.
We separate backup administrator accounts from unprivileged and other privileged accounts so that none of them can reach backups they do not own.

How we hand over

We document the access model, retention configuration and restore procedures so the client's team can operate them without us.
We record test restores and integrity checks as dated evidence the client can present to its independent assessor.
We confirm with the client which evidence its assessor expects, since the assessor, not DeployOpen, decides whether controls are met.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Retainer work can cover periodic restore tests, access reviews of backup accounts and updates to the backup platform.
Clients should ask for the support scope, response arrangements and evidence refresh cycle in writing before signing.