What Essential Eight regular backups ML2 asks of privileged accounts
At Maturity Level Two, the question is no longer whether backups exist or are tested, but whether privileged accounts can misuse them. Privileged accounts other than backup administrators must not be able to access backups that belong to other accounts, and they must be prevented from modifying or deleting backups. ML2 adds these two requirements, ISM-1705 and ISM-1707, on top of the ML1 backup controls, and those ML1 controls carry forward unchanged, including the expectation that restoration is tested in disaster recovery exercises. An organization that already runs ML1 backups should treat ML2 as a change to who can reach the backup data, not as a change to how backups are made.
The risk is specific. During an intrusion, an attacker who obtains an administrator's credentials will often look for backups first, either to read sensitive data from them or to destroy the recovery copies before encrypting production systems. If privileged accounts can browse or delete other users' backups, a single compromised account can undo the organization's recovery position. The difficulty is that access to backups is spread across many places: the backup software's own console and roles, the storage target, hypervisor snapshot features, and cloud provider consoles and storage permissions. A control that restricts the backup tool but leaves a hypervisor administrator free to delete snapshots does not meet the requirement.
The practical starting point is an access inventory. List every account and group that can reach backup jobs, catalogs, repositories, storage buckets, snapshot management and cloud backup vaults, then record which of those accounts are privileged and whether each one is a backup administrator. Confirm the exact wording and scope of ISM-1705 and ISM-1707 in the ISM OSCAL catalog (ISM OSCAL catalog) with your assessor before you design the change, because interpretation of backup administrator scope affects which roles you may keep. Evidence will typically be role definitions, access test results and deletion attempts logged under non-backup administrator accounts.
Which systems, accounts and teams the ML2 backup access rule covers
The Maturity Level Two rule on backup access applies to every backup your organization holds, so the first job is to decide which data sources, accounts, roles, repositories and third parties fall inside it. Each card below is a scoping decision that changes the work, with the people who must confirm it.
Backed-up data sources
List every workload that produces backups: on-premises servers, endpoints, SaaS tenants and cloud workloads. The access rule applies to backups of all of them, so a SaaS export kept outside the main backup platform is still in scope. Check whether each source has a backup owner, a retention setting and a restore path. Ask the system owners and the infrastructure lead to confirm the list, because a source missing from the inventory is a source where privileged users may retain unrestricted access.
Domain and directory administrators
Domain admins, directory global administrators and similar accounts often hold rights over backup servers, storage and credentials by inheritance. Under the ML2 rule these accounts must not read other accounts' backups or change and delete them. Confirm which groups grant these rights through nested membership, service accounts or delegated permissions. The identity team should confirm this, since group nesting is where unintended access usually hides.
Hypervisor and virtualization administrators
Hypervisor administrators can often snapshot, mount or copy virtual machine disks, which may expose backup data without touching the backup product. Review who can clone virtual machines, export disks or access datastores that hold backup files. The virtualization team should confirm these permissions, and the scope should cover the hosts and management consoles where backup repositories are attached.
Cloud owners and application administrators
Cloud account owners, subscription administrators and application administrators can often reach storage buckets, snapshots and database exports holding backups. Map each cloud account and application that stores backup data, then identify the roles able to read, copy or delete those objects. The cloud platform owner and each application owner should confirm the list, since application admins frequently manage their own exports outside central backup tooling.
Backup administrator role
The backup administrator role is the one account type excluded from the ML2 restriction, so its definition controls the whole rule. Document who holds the role, how it is granted and whether it is shared. Keep the role small and separate from other privileged duties. Ask the security lead and the internal audit function to confirm the membership, because an overbroad backup administrator role removes the protection the rule is meant to provide.
Repositories, catalogs and third parties
Backup repositories, job catalogs and metadata databases reveal what is backed up and can allow restores, so they fall within the access rule. Confirm who can read or change repository storage and catalog databases. Where a managed backup provider runs the platform, its staff and tooling become part of the scope. Ask the provider for its privileged access list and its contract terms on backup access, and confirm both with your own security team.
How an assessor tests regular backups at ML2
This table sets out the test steps an assessor typically takes for the two backup controls added at Maturity Level Two, with the evidence each step asks for and the findings that tend to appear. Read each row as a test the organization should be able to pass before the assessor arrives. Assessors sample accounts and observe attempts, so the ML1 restoration testing controls, which also remain in scope, should be ready alongside these rows.
| Test area | Evidence requested | Common findings |
|---|---|---|
| Privileged account population | Complete list of privileged accounts with roles, plus the list of backup administrator accounts kept separate from them | Privileged accounts missing from the list, or backup administrator accounts not identified as a distinct group |
| Repository and catalog permissions (ISM-1705) | Access control settings on backup repositories and the backup catalog, with a sample showing that non-backup-admin privileged accounts cannot open other accounts' backups | Broad group memberships that let general administrators browse or restore other users' backups |
| Modification and deletion attempts by non-backup-admin privileged users (ISM-1707) | Observed attempts by sampled privileged accounts to modify or delete backups, with the denial logged | Permissions allowing deletion through a secondary console, script or retention override |
| Separation between backup administrators and other administrators | Role definitions, approval records for changes to backup roles, and logs showing who holds backup administrator rights | Backup administrator rights granted to the general server team without a documented need |
| Protection of backup logs and job records | Samples of backup job logs and catalog change records, showing they cannot be altered by the accounts under test | Job records stored where privileged users can edit or purge them |
| Restoration testing in disaster recovery exercises (ML1 controls still in scope) | Dated restore test records, scope of each test, results and remediation actions | Restore tests that only confirm a job completed, without checking the restored data |
| Sampling approach | Assessor-selected sample of accounts and backup sets, with the organization ready to produce each on request | Organization unable to produce evidence for an account the assessor selects during fieldwork |
How to implement ML2 backup access separation in sequence
This sequence separates backup access from ordinary privileged use so that accounts other than backup administrators cannot read other users' backups or change and delete them. Each step produces a record that an assessor can check, and the order matters because later steps depend on the roles and permissions defined earlier. The exact configuration depends on the backup platform in use and should be confirmed against that vendor's documentation.
Inventory privileged accounts and backup-related roles
List every account and group that holds administrative or elevated rights over the backup platform, its storage, its hosts and the hypervisors or databases it protects. Include service accounts, cloud roles, break-glass accounts and vendor or managed-service access. The owner of this step is the organization's identity or infrastructure team, with the backup administrator confirming which accounts exist in practice. The output is a role register that names each account, its holder, its purpose and the systems it can reach. The step is complete when a reviewer can trace every privileged path to a backup repository or catalog without finding an unlisted account.
Define a dedicated backup administrator role
Create one role whose only purpose is operating the backup platform, and assign it to a small, named set of people or service identities. Remove backup administration rights from general domain, virtualization and cloud administrators unless they have a documented need. Record the approval for each assignment. The output is a role definition with its scope, members and approver. The step is complete when the role is the only path that can manage backup jobs, retention and restore policy, and the organization can name every member and explain why each needs it.
Restrict repository, catalog and storage credentials
Limit who can read backup repositories, the backup catalog and the storage credentials used to reach backup media. Separate the credentials the backup software uses from the credentials administrators use to log in, and store them in a managed secrets location with restricted read access. Confirm that the catalog cannot be browsed to retrieve another account's data by people outside the backup administrator role. The output is a configuration export showing access controls on repositories and catalog, and a credential inventory. The step is complete when a non-backup administrator attempting to open another user's backup is refused.
Prevent modification and deletion by other privileged accounts
Set the platform so that privileged accounts outside the backup administrator role cannot change, overwrite, expire or delete backup sets, jobs, volumes or retention settings. Where the platform supports it, restrict deletion rights to the backup administrator role and confirm that storage-level permissions do not allow deletion through a different path, such as a hypervisor snapshot console or object storage administration. The output is a permission matrix mapping each privileged role against read, modify and delete rights on each backup object type. The step is complete when the matrix matches what the platform enforces.
Verify with negative tests
Test the controls by attempting actions that should fail. Using accounts from each privileged role outside backup administration, try to browse another account's backups, restore data to an unauthorized location, alter a job, change retention and delete a backup. Record the account used, the action attempted, the expected result and the actual result. Include one test per path identified in the role register, and repeat tests after any change to roles or platform versions. The output is a set of test records with dated results and the name of the tester. The step is complete when every expected denial is observed and any unexpected success has a logged remediation and retest.
Document the configuration and runbook
Write down the final design and the procedures that keep it in place. Include the role register, permission matrix, configuration exports, the approval process for adding members to the backup administrator role, the periodic review cadence set by the organization, and the steps for handling a request to access another user's backup. Link each control to the test record that shows it works. The output is a runbook and a controlled document set that an assessor can read without help from the implementer. The step is complete when an operator who did not build the design can follow the runbook to make a permitted change and to refuse a prohibited one.
How Bareos and restic support the ML2 backup evidence
Bareos is an open-source backup system whose Director schedules and supervises backup, restore, verify and archive jobs. The Director keeps an SQL catalog of the files it has backed up and can restore files selected from the current backup or from a backup taken before a given date and time. For an ML2 assessment, this catalog and the job records are useful evidence because they show which jobs ran, when, and which files were restored and by whom. Assessors can use them to test that backups happen on schedule and that restoration is possible.
- Job records as evidence: Schedules, run history and restore requests give a traceable record that can be sampled during an assessment.
- Catalog as an inventory: The SQL catalog shows which systems and file sets are covered, which supports the scope claim for backups.
- Restore audit trail: Restore operations are recorded in the Director, so restoration activity by privileged users can be reviewed.
- Verify and archive jobs: Verify jobs give a second check of stored data, and archive jobs support longer retention where the organization requires it.
- Separation still required: Access to the Director console and the catalog database must be restricted to backup administrators and tested. Confirm the permission model in the Bareos documentation before relying on it.
Before claiming ISM-1705 or ISM-1707 coverage, confirm that unprivileged accounts cannot reach other users' backups through the Director or the catalog, and test that they cannot modify or delete them.
restic is an open-source backup tool that stores encrypted, deduplicated snapshots in a repository. Its check command verifies the structural consistency of snapshots, trees and pack files. With the --read-data or --read-data-subset options, it reads pack files back and confirms that the stored backup data is unmodified. This gives an organization a concrete integrity test that it can run on a schedule and keep as evidence. restic does not, by itself, decide who may delete a repository, so access control for the repository location is a separate design decision.
- Structural checks: A standard check confirms that snapshots, trees and pack files are consistent with each other.
- Full data reads: The --read-data option reads all pack files, and --read-data-subset tests a portion, which lets teams balance thoroughness against the time and load involved.
- Schedulable output: Check results can be logged and retained as dated evidence of integrity testing.
- Repository access is external: Who can delete the repository depends on the storage backend and its credentials, so object lock, separate credentials or storage-level retention must be configured outside restic.
- Confirm the model: Check the restic documentation for the current permission and repository behavior, and test it in your own environment.
Before relying on restic for ISM-1707, confirm that the storage backend, not only the restic command, prevents privileged accounts from deleting or altering backup data.
Both tools are open source, but their licenses differ in ways that affect how an organization deploys and modifies them. Bareos is licensed under AGPL-3.0-only, and restic is licensed under BSD-2-Clause. Procurement and legal teams should review these licenses against their own obligations before deployment, particularly if the tools are modified or offered to third parties over a network.
- Bareos license: AGPL-3.0-only is a copyleft license. Network-facing modifications may carry source disclosure obligations, so legal review is advisable.
- restic license: BSD-2-Clause is a permissive license with a short notice requirement.
- Support model: Open-source licensing does not include vendor support, so confirm who will maintain, patch and test each tool.
- Evidence ownership: The organization owns its job records, catalog data and check outputs, whatever the license.
- Version tracking: Record the exact versions in use, since evidence is tied to the configuration that produced it.
Ask your legal and procurement teams to confirm the license obligations for your intended deployment before the tools are placed in service.
Which evidence passes an ML2 backup access assessment
At Maturity Level Two, an assessor needs proof that privileged accounts outside the backup administrator role cannot reach other accounts' backups or change them. The cards below cover the records that show who holds that access, how it is enforced, how it was tested, and how it changed over time. Each artifact should be exported on a schedule and signed off so it is still current when the assessor arrives.
Privileged account and backup administrator register
This register lists every privileged account, every backup administrator account and the role each one holds across backup servers, repositories and catalogs. It establishes the boundary the assessment tests: only backup administrators sit outside the restriction in ISM-1705 and ISM-1707. Export it from the directory or identity system on a fixed schedule, and require the backup owner to sign off each review. Check that dormant or shared admin accounts do not appear without an owner.
Access control exports for backup systems
Export the permission settings from the backup director, storage repositories and catalog database, showing which accounts can read, restore, modify or delete job data. The assessor compares these exports against the register to confirm no privileged user outside the administrator role holds access to another account's backups. Confirm that deletion and modification rights are separated from restore rights. Retain exports in a location the backup team cannot edit.
Negative test records for privileged users
Negative tests show that a privileged user who is not a backup administrator was refused when attempting to restore, read, modify or delete another account's backup. Record the test account, the action attempted, the target backup, the refusal message and the date. Run these tests after each permission change and at a regular interval, not only before an audit. A test that was never refused is evidence of a gap, so record it and the remediation.
Job and restore logs with protected retention
Backup job logs, restore logs and catalog access logs show who ran what and when, and they should show that no unauthorized account touched protected backups. ISM-1815 requires event logs to be protected from unauthorized modification and deletion, so store these logs on a separate system with restricted write access. Set a retention period that covers the audit window, and sample logs for denied attempts as well as successful jobs.
Change records for permission updates
Every change to a backup role, group membership or repository permission should have a ticket, an approver and a before and after record. The assessor uses these to confirm that privileged access was not widened without review. Compare change tickets against the access exports to find changes made outside the process. Keep change records linked to the register so each update to privileged access can be traced to a decision.
What meeting ML2 backup access controls costs
This table lists the cost components of meeting the Maturity Level Two backup access controls, who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Read it to see where spend moves when backup software is open source, since removing license fees does not remove configuration, testing or evidence work.
| Cost component | Who is paid or who does the work | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Backup software licenses or open-source adoption effort | Vendor for commercial licenses; internal staff or implementation partner for open-source adoption | Licenses recur annually; open-source adoption is one-time, with some ongoing upkeep | Number of platforms and repositories in scope; existing backup tooling that can be extended rather than replaced |
| Engineering time for role design and permission hardening | Internal platform or backup engineers, often with an implementation partner | One-time for initial role design; recurring when staff or systems change | Number of privileged accounts; how many backup administrator roles must be separated from other privileged roles |
| Negative testing time | Internal security or QA staff, or an external tester | Recurring, typically at each change and before each assessment | Number of access paths to backup repositories, including consoles, APIs and restore tools |
| Evidence upkeep | Internal compliance or operations staff | Recurring for as long as the control is in scope | Repository model and how much logging and access history the platform produces without custom work |
| External testing or review | Independent testers, reviewers or implementation partner, under written scope | Typically one-time per cycle, with recurring retests | Scope of testing, number of platforms and whether internal testing already covers the access checks |
| Auditor sampling | Independent auditor, paid under their engagement terms | Recurring at each assessment cycle | Number of backup systems sampled, quality of the evidence pack and how many exceptions are raised |
| Quote inputs to request | Implementation partner or vendor preparing the quote | Both | Ask for each line above to be priced separately, with the assumed platform count, account count and repository model stated |
Where organizations fall short on ML2 backup access
Most ML2 backup failures are not missing tools. They are overlapping accounts, broad admin rights and access reviews that skip the backup platform. The cards below cover the gaps assessors most often find and the fix for each.
Backup admins share domain admin credentials
When backup administrators log in with the same credentials as domain administrators, the backup platform inherits every domain privilege, and privileged users outside the backup role can reach other accounts' backups. Separate backup administrator identities, store their credentials apart from domain admin credentials, and check that no general privileged group can reset their passwords or add itself to their role.
Hypervisor owners can delete snapshots
Virtualization and cloud owners often hold rights to delete snapshots and volume copies. A snapshot removed by a platform owner is a backup removed for ML2 purposes, even if the backup software never touched it. Restrict snapshot deletion to the backup role, and test whether a general cloud or hypervisor administrator can delete a recovery point from their own console.
Catalogs and repositories writable by general admins
The backup catalog and the repository hold the data that matters for restore. If general system administrators can write to repository paths, edit the catalog database or change retention settings, unprivileged users can modify or delete backups. Review file system permissions on repository storage and database rights on the catalog, and confirm that the Director or repository owner account is the only writer.
No negative test evidence
Assessors look for proof that restricted access is enforced, not only that it is documented. Teams often hold role definitions and screenshots but no record of an attempt by an unprivileged account to read, modify or delete another account's backup, and no record of the denial. Run that test with a standard user and a general admin, and keep the denied attempt, the logged event and the date as evidence.
SaaS and endpoint backups outside the role model
Backups of Microsoft 365 mailboxes, laptops or SaaS tenants are often configured by the application owner or the user, outside the central backup role. Those copies can be deleted by the person whose data they hold, which fails the ML2 requirement that privileged accounts other than backup administrators cannot modify or delete backups. Bring every backup source under the same administrator model, or document and justify each exception with the owner who accepts it.
Access reviews that skip backup platforms
Quarterly access reviews usually cover directory groups and business applications, but not the backup console, the catalog or the storage repository. An account that left a backup role two years ago can still hold delete rights. Add the backup platform, its catalog, its repositories and its snapshot consoles to the review scope, and record who approved each privileged backup account.
Who does what for ML2 backup access: your team, a partner and the auditor
Your organization owns the Essential Eight implementation and the regular backups control at Maturity Level Two. Only you can decide who is a backup administrator, which privileged roles may touch backup data, how exceptions are approved and how long backups are retained. These decisions create the access model that the auditor will test, so they must be written down, approved by an accountable owner and kept current when staff change roles.
- Role decisions: Name the backup administrator group and confirm that every other privileged account is excluded from reading, modifying and deleting backups of other accounts.
- Approvals: Record who signs off on changes to backup access, retention settings and restore authority, and keep those approvals as evidence.
- Day-to-day operations: Run scheduled backups, monitor job results, review access lists and respond to failed jobs or restore tests.
- Policy and ownership: Maintain the backup policy, the restoration testing schedule and the disaster recovery exercise records that ISM-1811 and related controls expect.
- Incident handling: Route backup-related security events into your incident response process, including the reporting steps covered by ISM-0123 and ISM-1819.
Before you engage anyone, confirm that a named internal owner can answer for each of these items during the assessment.
An implementation partner such as DeployOpen can plan, build and configure the backup platform inside your own infrastructure, then prepare the evidence your team and the auditor will need. The partner works on your systems under a written scope, but it does not decide your control design and it does not issue any report or certificate. Its work product is configuration, testing results and documentation that your organization adopts and owns.
- Access configuration: Set up backup roles so that privileged accounts other than backup administrators cannot access, modify or delete backups belonging to other accounts, as ISM-1705 and ISM-1707 describe.
- Negative testing: Attempt the prohibited actions from non-administrator privileged accounts and record that they fail, along with the logs that show the attempts.
- Evidence assembly: Export access lists, job logs, restore test records and configuration baselines in a form that maps to the control IDs.
- Tool setup: Deploy open-source options such as Bareos for scheduling and catalog management, or restic for repository checks, and document how each is configured.
- Handover: Train your staff to run and review the controls, and agree in writing what support continues after the engagement.
Before you sign, confirm in the statement of work that the partner will not author your policies as its own opinion, will not sign attestations, and will hand over all evidence to you.
An independent auditor or assessor tests whether the control operates as designed and reports on what it finds. The Essential Eight is a set of mitigations, not a certification scheme, so there is no ASD certificate. Maturity is shown through an assessment of implementation and effectiveness against the maturity model, and the assessor's conclusions carry weight only because the assessor is independent of the work it reviews.
- Sampling and testing: The assessor selects accounts, reviews access rights, inspects logs and may request a live restore or a demonstration of the negative tests.
- Reporting: Only the assessor issues the findings or assurance conclusion. Your organization decides how to act on them.
- Independence limits: If the same firm designed the controls or ran the negative tests, the assessor may need to disclose that relationship or use a separate team for the testing.
- Scope agreement: The assessor will confirm which systems, backup platforms and privileged roles are in scope before fieldwork begins.
- Evidence requests: Expect requests for policies, approvals, configuration exports and restore test records, and check that each item exists before fieldwork.
Before you engage an assessor, ask how it handles conflicts with any partner that has built the environment.
Many organizations outsource the technical build and the evidence preparation, while keeping the decisions and the operation in-house. The cost and effort of each part depend on the size of the backup estate, the number of privileged roles and how much of the environment already exists. Quotes should separate fixed deliverables from ongoing operation, because backup access is reviewed repeatedly over time.
- Usually outsourced: Platform installation, role configuration, scripting of access checks, negative test execution and evidence packaging.
- Usually kept in-house: Access approvals, role definitions, incident decisions, restore authority and the ongoing review cycle.
- Recurring work: Periodic access reviews, log checks, restore tests and updates to documentation after changes in staff or systems.
- Cost drivers to ask about: Number of backup targets, number of privileged account types, whether the environment is on premises or in a cloud account, and whether air-gapped networks are involved.
- Quote request: Ask for a written scope that names the systems, the deliverables, who performs each test and what happens to the evidence at the end.
Before you sign any statement of work, confirm which items your team must perform itself to keep the assessment independent and credible.
Questions buyers ask about ML2 backup access before hiring help
How much extra effort does Maturity Level Two add on top of Level One backups?
ML2 adds a narrower set of controls rather than a new backup program. The ML1 backup controls, including restoration testing in disaster recovery exercises, still apply. The new work is the access model: privileged accounts other than backup administrators must not access other accounts' backups (ISM-1705), and they must be prevented from modifying or deleting backups (ISM-1707). Effort depends on how many privileged accounts currently touch backup repositories, how many backup platforms exist, and whether access is granted through shared accounts or individual roles. Ask any provider to inventory those three things before quoting, since they determine most of the change.
Can an in-house team implement ML2 backup access controls without outside help?
Often yes, if the team already runs its backup platform and has someone who owns identity and privileged access. The work is mostly configuration: separating backup administrator roles from general administrator roles, removing standing rights to read or change other accounts' backups, and confirming that deletion is blocked for non-backup-admin accounts. Teams that struggle usually lack a clear list of who holds privileged rights, or they discover that old service accounts can reach backup storage. Outside help is most useful for the independent review of those findings and for documenting evidence an assessor will accept. Confirm your internal capacity against the ISM Essential Eight profile before deciding.
How long does ML2 backup access work take, and what drives the duration?
No duration is stated in the supplied facts, so confirm any timeline with the provider against your environment. The main drivers are the number of backup repositories and clients, the number of privileged accounts and groups with backup rights, the state of existing role design, and whether change windows are needed for restores or job changes. Retention settings and the choice of storage platform also affect how much testing is needed. A fixed-scope written plan, agreed before work starts, is the usual way to pin the timeline down.
What does the work need from our own team?
The work needs named owners on three sides: the backup platform, identity and privileged access, and the security team that will review evidence. Backup platform owners provide job, catalog and repository details. Identity owners provide the list of privileged accounts, groups and service accounts with backup rights. Security owners confirm which access reviews already exist and who signs off on exceptions. Plan time for each owner to validate changes, since a backup administrator who is also an operator will need to show that their own rights are limited to backup duties.
Can open-source tools produce the evidence for ML2 backup access?
Open-source backup tools can help, but they do not decide compliance on their own. Bareos has a Director that schedules and supervises backup, restore, verify and archive jobs and keeps a SQL catalog of backed-up files, which gives you job and catalog records to show who ran what. restic's check command verifies structural consistency and, with --read-data or --read-data-subset, reads pack files back to confirm stored data is unmodified, which supports integrity evidence. Neither tool, by itself, proves that privileged accounts are blocked from other accounts' backups. That proof comes from role configuration, access reviews and logs, so confirm how your chosen platform enforces role separation before relying on it.
What will an assessor sample when checking ML2 backup access?
Assessors typically sample the current role and permission configuration, a set of privileged accounts, and evidence that those accounts cannot read or change other accounts' backups. Expect requests for access review records, change records showing when backup rights were granted or removed, and logs covering attempted or actual deletions. They may also check whether backup administrator accounts are separate from ordinary privileged accounts. Assessment procedures come from ASD's guidance and the assessor's own methodology, so confirm the sampling approach with your assessor before collection starts.
Does ASD issue a certificate for Essential Eight Maturity Level Two?
No. The Essential Eight is a set of mitigation strategies, not a certification scheme, and ASD does not issue a certificate for any maturity level. Maturity is shown through assessment of each strategy's implementation and effectiveness against the maturity model. Any document claiming an ASD certificate should be treated with caution. Ask your independent assessor or internal audit to state in writing how they will report on ML2 backup access, and request that the report describes the evidence reviewed rather than a certificate.
How should we scope a quote for ML2 backup access work?
Ask for a written scope that lists the backup platforms and repositories in scope, the privileged account groups and service accounts reviewed, the deliverables (configuration changes, evidence pack, and written findings), and what the provider will not do. A good quote separates implementation work from independent assessment, since an implementation partner prepares systems and evidence, while only an independent assessor reports on maturity. Ask what is one-time (role redesign, evidence capture) and what recurs (periodic access reviews, restore testing, configuration drift checks). DeployOpen works on fixed-scope engagements agreed in writing before work starts, and does not publish a price list.
How DeployOpen scopes and prepares ML2 backup evidence
DeployOpen plans, implements and documents self-hosted backup platforms inside your own infrastructure, so the privileged access restrictions for Regular backups maturity level 2 are built into the system and recorded as evidence. The organization owns its controls, and an independent assessor decides whether they meet the level.
How we scope
- Engagements are fixed-scope, with the backup estate, privileged account groups and target maturity level agreed in writing before work starts.
- The written scope names which backup administrator accounts are excluded from the access and modification restrictions for ISM-1705 and ISM-1707.
- Scope also records which ML1 backup controls, including restoration testing, are in place and how the ML2 logging obligations will be met.
How we build
- Configure the backup director and storage so privileged accounts outside the backup administrator group cannot read other users' backup sets.
- Restrict modify and delete rights on backup catalogs and volumes, then test that unprivileged privileged accounts are actually refused.
- Protect event logs from unauthorised modification and deletion, and route backup job and access events to central logging for review.
How we hand over
- Deliver a control-by-control record mapping each ML2 backup requirement to the configuration, owner and test that shows it operating.
- Provide sample evidence exports such as access test results, job reports, restore test logs and log protection settings for the assessor.
- Document recurring tasks, such as access reviews and restoration tests, so the organization can keep the level after handover.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover, covering changes to the backup platform.
- Support can include re-running access tests after privilege changes or platform upgrades, with results added to the evidence file.
- Ask the auditor or assessor early which evidence format they need, since DeployOpen prepares evidence but does not issue assessment conclusions.
