What Essential Eight regular backups ML1 asks for
An assessor or customer who asks for Essential Eight regular backups at Maturity Level One wants evidence that the organization can restore its business after data loss or ransomware, and that unprivileged users cannot damage the copies. Meeting ML1 means six controls from ASD's Information Security Manual are in place: ISM-1511 requires backups of data, applications and settings to be performed and retained according to business criticality and continuity needs; ISM-1810 requires backups to be synchronised so they can be restored to a common point in time; ISM-1811 requires them to be retained in a secure and resilient way; ISM-1812 and ISM-1814 stop unprivileged accounts from reading other users' backups or changing and deleting them; and ISM-1515 requires restoration to a common point in time to be tested in disaster recovery exercises. Together they address the most common failure in ransomware recovery, where backups exist but are encrypted, incomplete or never proven to work.
Teams usually find three parts hard. The first is inventory: a criticality ranking for each system has to exist before retention periods and backup frequencies can be justified, and many organizations hold the data but cannot say which applications depend on it. The second is synchronisation: a database, its file store and its configuration may be backed up at different times, so a restore produces a mix of states that does not match any single moment. The third is testing: a backup job reporting success proves little, and a full restore of a representative system is the only evidence that ISM-1515 accepts. Confirm with your backup product whether it can record job success, verification results and restore history in a form an assessor can sample.
Start by asking the business owner of each critical system to confirm its recovery time and recovery point expectations, then compare those with the actual backup schedules. Record who approved each decision. For the restore test, pick a system, restore it to an isolated environment, and document the time taken and the state of the data. Open-source options such as Bareos can schedule jobs and keep a catalog of backed-up files, and restic can verify that stored pack files are unmodified. Whether either tool fits your environment depends on your platforms and your assessor's expectations, so confirm both before you commit.
Which systems, data and teams the backup requirement covers
Maturity Level One applies to the data, applications and settings you decide are in scope, so the first job is an inventory built with the people who own those assets. The cards below cover the decisions that change the size of the work and the sign-offs needed before any backup job is configured.
Data stores and applications in scope
Start with an inventory of every data store and application that holds business records, including file shares, databases, email archives and line-of-business systems. For each one, record the owner, the data classification and whether it can be rebuilt from another source. Anything left off the list is a gap an assessor will find when they compare the backup scope with the asset register. Ask the asset owner to confirm the list in writing.
Configuration and network device settings
Backups of data, applications and settings are all in scope at this level, so configuration is not optional. Firewall rules, switch configurations, hypervisor settings, directory service configuration and application settings files each need a defined backup method and a restore owner. Confirm with the infrastructure team which devices export configuration and how often that export runs, since a data backup alone may not restore a working network.
Retention set by criticality and continuity
Retention periods follow from business criticality and business continuity requirements, not from the storage that happens to be free. The business continuity plan and the recovery objectives agreed by the business owner should state how far back restoration must reach. Document each retention decision by system so the backup configuration can be traced to a stated requirement. Ask the business continuity lead to approve the figures.
Cloud and SaaS data sources
Data held in cloud accounts and SaaS platforms counts toward the requirement even when the provider runs the infrastructure. Mailboxes, collaboration sites, cloud-hosted databases and object storage often sit outside the on-premises backup tool. Confirm what the provider backs up by default, what it does not, and whether restoration to a common point in time is possible across services. Where a provider feature is used, record the setting and who controls it.
Sign-off from backup, infrastructure and business owners
The backup administrator configures jobs, the infrastructure team owns the platforms being protected, and the business owner decides how much data loss is tolerable. Each group should sign the scope and retention schedule, because a gap between them is where backups quietly miss a system. Keep the signed schedule with the disaster recovery plan so the restore tests in the next step can be checked against it.
How an assessor tests regular backups at ML1
This table compares each ML1 backup control with how an assessor tests it, the evidence they usually request and the findings that appear most often. Read each row as a question the assessor will ask, then check whether your own backup records answer it before the assessment starts.
| Control | How an assessor tests it | Evidence requested | Common findings |
|---|---|---|---|
| ISM-1511: Backups by business criticality | Interview the backup owner, then compare the backup scope against the business impact analysis and the list of critical systems | Asset register, backup policy, business impact analysis, backup schedule and retention settings per system | Critical systems missing from backup scope or backed up on the same schedule as low-value systems |
| ISM-1810: Common point in time | Inspect how backups of databases, applications and settings are timed and sequenced, then ask how a restore would reach one consistent state | Backup job definitions, database snapshot or quiesce settings, and a sample restore report showing matched timestamps | Databases and applications backed up at different times with no documented method to restore them to one consistent point |
| ISM-1811: Secure and resilient retention | Inspect where backup copies are stored and how they are encrypted and separated from production | Storage location records, encryption configuration, access reviews for the backup store and copies held off-site or off-platform | Backup copies stored on the same network or credential domain as production with no separate protection |
| ISM-1812: Unprivileged access to other users' backups | Review access control lists on the backup server and repository, then test whether a standard user account can list or read another user's backup | Role assignments, access control list exports and a record of the access test performed | Standard users able to browse or restore backup sets belonging to other users or systems |
| ISM-1814: Unprivileged modification or deletion | Attempt, or observe a test attempt, to modify or delete backup sets using an unprivileged account, and review deletion permissions | Permission exports, test records showing denied deletion, and retention job logs | Unprivileged accounts can delete or overwrite backup sets, or nobody has checked the permissions since setup |
| ISM-1515: Restore tested in disaster recovery exercises | Ask for the most recent disaster recovery exercise report, then sample a restore and check that it reached a common point in time | Exercise plan, dated test results, restore logs, and the corrective actions raised from each test | Restore tests never run, run only for single files, or run without checking that data, applications and settings align |
How to implement ML1 backups in sequence
The sequence moves from knowing which systems matter, to setting how often they are backed up and how long copies are kept, to producing synchronised copies, locking out unprivileged access, and proving the restore works. Each step ends with a record that an assessor can check.
Classify systems by business criticality
Start by listing the data, applications and settings the organization relies on, then rank each by business criticality with input from the system owners and the business continuity lead. Record the owner, the dependencies between systems, and the recovery expectations agreed for each. The step is complete when the register is approved and every in-scope system has a criticality rating that the backup design can reference. Assessors will look for this register first, because ISM-1511 ties backup scope and retention to criticality and business continuity requirements.
Set backup frequency and retention periods
For each criticality tier, document how often backups run and how long each copy is kept. Base these values on the business continuity requirements from the previous step, not on the default settings of a tool. Confirm the agreed values with the business owners and record who approved them. The output is a backup schedule and retention table that maps each system to its tier. Ask your auditor which evidence they expect for the approval, since the requirement is about the organization's own decision.
Configure synchronised backups to a common point in time
Build backup jobs so that related data, applications and settings can be restored to the same point in time. For open-source tooling, a backup director such as Bareos can schedule and supervise backup, restore, verify and archive jobs and keep a SQL catalog of backed-up files. Where restic is used, it writes deduplicated snapshots to a repository. Test that jobs for dependent systems finish inside a shared window or can be paired by timestamp. The step is done when a job log and catalog entry show a consistent set of backups for a defined point in time. This addresses ISM-1810 and ISM-1811.
Store backups securely and verify their integrity
Place backup copies in a secure and resilient location, separate from the production systems they protect, and encrypt them in transit and at rest according to your own standards. Run integrity checks on a schedule. For restic, the check command verifies the structure of snapshots, trees and pack files, and the --read-data or --read-data-subset options read pack files back to confirm the stored data is unmodified. Keep the check logs. The step is complete when storage locations are documented and recent integrity check results show no errors. This supports ISM-1811.
Restrict access for unprivileged accounts
Review who can read, modify or delete backup data and catalogs. Unprivileged accounts must not access other users' backups, and they must not be able to change or remove backups. Use separate backup administration accounts, remove standing rights for general users, and confirm that storage permissions match the access matrix. Record the review with the approver and the date. The output is an access matrix plus evidence, such as permission exports, showing that unprivileged accounts are blocked. This addresses ISM-1812 and ISM-1814.
Schedule and run a disaster recovery restore test
Include restoration of data, applications and settings to a common point in time within a disaster recovery exercise. Define the scenario, the systems in scope, the expected recovery outcome, and who runs the test. Perform the restore from the backup repository rather than from the live system, and compare the result with the expected state. Use Bareos restore selection by date and time, or restic restore of a chosen snapshot, depending on the platform. The output is a test plan, a restore log and a record of any gaps. This addresses ISM-1515.
Record findings and schedule the next test
Document the results of the restore test, assign actions for any failed or partial restores, and track those actions to closure. Update the criticality register, schedules and access matrix if the test exposed gaps. Schedule the next disaster recovery exercise and store the plan and results where an assessor can retrieve them. The step is complete when the actions are closed or accepted by an owner, and the next exercise is on the calendar. Keeping this record current is what turns a one-time setup into evidence that the mitigation still works.
Why a common point in time is the hardest part
A backup is only useful at Maturity Level One if the database, its application and its settings can be restored to the same moment. ISM-1810 asks for backups synchronised so that restoration happens to a common point in time. A database restored from 02:00 alongside an application configuration captured at 06:00 can produce an environment that starts but behaves incorrectly, with references, schema versions or stored settings that no longer agree. Assessors will ask whether the team can describe that consistency point, not just whether jobs succeeded.
Mismatch usually comes from scheduling rather than from the backup tool. A database dump job, a file system job for the application server and a job that exports configuration files may each run at different times, or against live systems that keep changing while they run. Each job reports success, yet no single restore point exists. Before claiming the control is met, the team should confirm which systems share a backup window, whether the database is quiesced or captured through a consistent snapshot, and whether the application and its settings are captured in the same job or in jobs with a documented, acceptable gap. If the platform uses Bareos, the Director's job definitions and schedules show this directly. If it uses restic, the snapshot tags and the backup command ordering show which data was captured together.
Confirm this in a disaster recovery exercise rather than on paper, because ISM-1515 expects restoration to a common point in time to be tested. Ask the implementation partner or internal team to restore a chosen point, bring up the application, and check that database records, configuration and application version agree. Record the timestamps of each source so the mismatch window is known and can be accepted or closed. The auditor will look for that record. An illustrative outcome might be a finding that the configuration export runs ninety minutes after the database dump, which the team then fixes by moving it into the same job.
Evidence that passes a regular backups ML1 assessment
An assessor testing Regular backups at Maturity Level One looks for records that show backups exist, match business criticality, restore to a common point in time, and have been test-restored. The cards below cover the artifacts that carry that proof and how to keep each one current between assessments.
Backup policy with criticality classification
The backup policy states which data, applications and settings are in scope, how each system is classified by business criticality, and the retention and recovery requirements that follow from that classification. It ties backup frequency and retention to the business continuity requirements the organization has agreed. Refresh it whenever a system is added, reclassified or retired, and at least when business continuity plans change. Check that the classifications match the asset register the assessor will sample.
Job schedules and success logs
Schedule exports and job success or failure logs show that backups of each in-scope system ran as the policy requires. An assessor will sample a few systems and compare their logged jobs against the schedule. Keep logs for the retention period the policy sets, and review failed jobs with a documented follow-up so that a gap is visible rather than silently absorbed. Export a dated copy of the schedule at each assessment.
Backup catalogue or inventory
A catalogue lists each backed-up system, its backup set, the last successful job and the restore points held. With a tool such as Bareos, the SQL catalog of backed-up files can serve as the underlying record. The catalogue shows that data, applications and settings are covered together and that restore points share a common point in time. Reconcile it against the asset inventory each quarter so that new systems do not run outside backup coverage.
Access control lists for backup storage
Access control lists for backup repositories and storage show that unprivileged accounts cannot read other users' backups or modify and delete them. Export the permissions for each repository, list the accounts with rights, and confirm that regular users hold none. Review these lists when staff change roles and at each assessment. Note any service accounts that can delete backups, because an assessor will ask whether those rights are justified.
Dated disaster recovery restore test reports
A restore test report records which systems were restored, to which common point in time, who ran the exercise, when it happened, and whether the restored data, applications and settings worked. Restore tests are required as part of disaster recovery exercises, so a report should exist for each exercise. Include failures and the corrective actions taken. Schedule a fresh exercise before each assessment so the newest report is recent and shows the current environment.
Self-hosted open-source backup tools for ML1
Bareos fits organizations that want a central scheduler and catalogue for many systems. The Bareos Director schedules and supervises backup, restore, verify and archive jobs, and it keeps a SQL catalog of backed-up files. That catalogue lets operators restore files selected from the current backup or from a backup taken before a given date and time, which maps directly to the ML1 expectation of restoring to a common point in time.
- Job records as evidence: Scheduled job logs and status reports show what was backed up, when, and whether it succeeded. Assessors often ask for these records across a sample period.
- Catalogue as evidence: The SQL catalog shows which files and systems are covered, which supports the business criticality mapping an assessor will check.
- Restore testing: Restore and verify jobs produce records you can attach to disaster recovery exercise results, which ISM-1515 requires you to test.
- Licensing caveat: Bareos is licensed under AGPL-3.0-only. Legal review is needed before modifying and distributing it, or offering it as a network service to others.
- Operational cost: The catalog database, storage targets and director host need sizing, patching and backup of their own.
Confirm with your team that Bareos supports your platforms, storage targets and retention rules before committing to it.
restic suits teams that want encrypted, deduplicated backups written to a repository they control, with fewer central services to run. 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 to confirm the stored backup data is unmodified, which gives you integrity evidence beyond a successful write.
- Consistency check output: Scheduled
restic checkruns and their logs show that repository structure is intact and, when read-data options are used, that stored data reads back correctly. - Snapshot listings: Snapshot metadata records what was backed up and when, which supports point-in-time restoration claims.
- Restore evidence: Test restores to a separate location, with recorded results, support the disaster recovery testing requirement.
- Licensing caveat: restic is licensed under BSD-2-Clause, which is permissive. Check your own packaging and any bundled dependencies against your legal requirements.
- Scale limits: Full read-data checks take time and I/O on large repositories, so decide how much data to verify and how often, and document that choice.
Confirm that restic's repository model, scheduling and access controls meet your ML1 access restriction requirements for unprivileged users.
The choice depends on how your estate is run, not on which tool is more secure. A director-driven design centralizes scheduling, catalogue and retention in one place, which helps when many servers and databases need consistent records. A repository-driven design keeps each backup set self-describing and verifiable, which helps when teams manage their own sources. Many organizations use both, so confirm that your evidence scheme covers each tool.
- Estate size: Large, heterogeneous estates often benefit from a central catalogue. Small, well-defined sets may not need one.
- Evidence location: Decide where job logs, catalogue exports and check results will be stored, and for how long.
- Access model: Both tools need separate credentials for backup operators, so ML1 separation from unprivileged users must be designed in, not assumed.
- Skills: Your team must be able to run restores under pressure, so pick the tool your operators already understand.
- Cost: Software licenses are not the main cost. Design, hosting, storage, monitoring and testing time usually drive the total.
Ask an implementation partner to write down the trade-offs for your environment in a fixed-scope design document before build work starts.
What meeting regular backups ML1 costs
This table breaks the cost of meeting regular backups at Maturity Level One into its components, showing who is paid, whether each cost is one-time or recurring, and what moves it up or down. No figures are given because none were supplied, so use the drivers to build a written scope and ask each bidder to price every row separately.
| Cost component | One-time or recurring | What drives it up or down | Who is paid or who bears it |
|---|---|---|---|
| Backup storage capacity | Recurring | Volume of data in scope, retention periods set by business criticality, and how many restore points are kept. Tiering older copies to cheaper storage lowers it. | Storage provider or the organization's own infrastructure team |
| Backup software licences | Recurring if commercial, none for open source | Number of protected hosts, agents and data sources. Self-hosted open-source tools such as Bareos (AGPL-3.0-only) and restic (BSD-2-Clause) remove licence spend, though support contracts may still apply. | Software vendor, or no licence fee for open-source components |
| Engineering time to configure backups and synchronisation | One-time | Number of systems, application complexity and whether databases need consistent snapshots to reach a common point in time. Standard templates for similar systems reduce it. | Internal engineers or an implementation partner under a fixed-scope agreement |
| Business criticality and recovery scoping | One-time, revisited on change | Number of systems classified as critical and whether business continuity owners are available to confirm requirements. Clear, signed classifications reduce rework. | Organization's business owners, with advisory support from a consultant if needed |
| Access control for backup repositories | One-time setup, recurring review | Number of accounts that touch backups and how well unprivileged access is already separated. Fewer shared credentials mean less effort to demonstrate restriction. | Internal identity and security teams |
| Disaster recovery restore testing | Recurring | Frequency of exercises, number of systems restored in each, and whether restores are run in a private test environment. Scheduled, scripted restores reduce staff hours per exercise. | Internal operations staff, with optional support from a testing partner |
| Evidence upkeep | Recurring | Number of backup jobs, restore test records and access reviews to retain. Automated job reports and a central log of exercise results reduce manual collation. | Internal compliance or security staff |
| Assessor sampling and fieldwork | Recurring per assessment cycle | Number of backup systems the assessor samples and how complete the evidence package is at the start. Well-indexed evidence shortens sampling time. | Independent assessor or certification body, which issues any report. The organization pays and prepares evidence. |
Where ML1 backup programs usually fall short
Most Maturity Level One backup programs fail at the edges: the inventory of what gets backed up, the synchronisation between related systems, and the proof that restores work. The cards below cover five gaps an assessor is likely to test, and how to close each one before the assessment begins.
Incomplete system inventory
ML1 asks for backups of data, applications and settings chosen by business criticality, so the scope starts with a register of systems and their recovery needs. Teams often back up file servers and miss SaaS exports, configuration files, certificates and small departmental applications. Check the inventory against cloud accounts, virtual machine lists and the business continuity plan, and record the criticality tier and the backup job that covers each item.
Backups that were never restored
A successful backup job proves little until a restore has been completed. ML1 requires restoration to a common point in time to be tested as part of disaster recovery exercises. Programs often run jobs for years without a timed restore of a full application. Schedule restore tests for each critical system, record the time taken, the data checked and any failures, and feed those results back into the recovery plan.
Unsynchronised application and database backups
A database backed up at 01:00 and a file share backed up at 03:00 can produce a restore that is internally inconsistent. ML1 requires backups to be synchronised so that everything restores to one common point in time. Check the backup schedule for dependent systems, use application-consistent dump or snapshot methods where they exist, and confirm the restore test recovers the whole service rather than its parts.
Repositories writable by ordinary administrators
Backup repositories often sit on file shares or storage that general server administrators can delete from. ML1 requires protection from unprivileged users, and the control on preventing modification or deletion of backups sets the baseline for later levels. List who holds write, delete and key-management rights on each backup target, separate the backup administrator role where possible, and test that a standard administrator account cannot remove existing backups.
Unclear retention and secure storage
Retention periods that exist only in someone's memory make it hard to show backups are kept according to business requirements. Storage may also be unencrypted or located where it shares the failure domain of the production systems. Write down retention periods per criticality tier, confirm backups are encrypted at rest and in transit, and place at least one copy outside the failure domain of the source, so a single incident cannot take out both.
Who owns the backup control and who prepares evidence
Your organization owns the regular backups control. Under the Essential Eight, the mitigation is yours to run, and that ownership does not transfer to a consultant or software vendor. Someone in your business must decide what counts as business critical, how long each data set is retained, and what recovery point and recovery time the business can accept. Those decisions drive every ML1 requirement, from backup scope to restore testing.
- Criticality and retention decisions: Name the owner who classifies data, applications and settings by business criticality and approves retention periods.
- Access rules: Decide which accounts may read, restore or change backup jobs, and document why unprivileged users are kept away from others' backups.
- Disaster recovery exercises: Schedule and sponsor the restoration tests that show data, applications and settings can be brought back to a common point in time.
- Operational records: Keep job logs, exception approvals and remediation tickets in a system your assessor can access.
- Final accountability: Sign the risk acceptance for any gap, since no partner can accept risk on your behalf.
Before engaging anyone, confirm which of these decisions your team can make and who signs off on each.
An implementation partner prepares the systems and evidence that support the control. DeployOpen, for example, plans, builds, hardens, backs up, documents and supports self-hosted open-source platforms in your own cloud accounts, data centers or air-gapped networks. For backups, that can include configuring a backup director and catalog, setting job schedules and retention, and separating backup storage from ordinary user access. A partner does not decide what your business considers critical and does not certify the result.
- Configuration: Build backup jobs and catalogs with tools such as Bareos, and configure integrity checks with tools such as restic
check. - Restore test design: Draft test plans, scenarios and success criteria for disaster recovery exercises, which you approve and run.
- Evidence packs: Export job reports, configuration baselines, access listings and restore test records into an organized package.
- Documentation: Write runbooks and a control narrative that explains how each ML1 requirement is met.
- Gap reporting: Identify where a requirement is not yet met and quote remediation work separately.
Ask for the written scope, the named deliverables and who on your side must approve each one before work begins.
The independent assessor tests whether the control works and states the conclusion. An assessor can be an accredited or qualified firm you engage for an assessment, or an internal assurance function that is independent of the team running the control. Either way, the assessor samples backup jobs, reviews restore test records, checks who can reach backup repositories and reaches its own view. Essential Eight is a set of mitigations rather than a certification scheme, so there is no ASD certificate to obtain.
- Independent testing: The assessor re-performs samples rather than relying on documents the implementation partner wrote.
- Sole authority for conclusions: Only the auditor or assessor issues the assessment conclusion, and no implementation partner can issue it.
- Evidence review: The assessor checks that evidence is complete, dated and traceable to the requirement.
- Scope confirmation: Agree with the assessor which systems, locations and data sets fall within the assessment.
- Reporting: The assessor's report, not the partner's evidence pack, is what you give to customers or regulators.
Confirm the assessor's qualifications, independence and reporting format before you commit to a timeline.
Regular backups ML1 questions buyers ask
How much effort does Essential Eight regular backups at ML1 take?
Effort depends mostly on how many systems are in scope, how many distinct business criticality tiers you define, and how much of the backup estate already runs on a tool that schedules and reports on jobs. ML1 asks for backups of data, applications and settings sized to business criticality and continuity needs, synchronised to a common point in time, retained securely, and test-restored in disaster recovery exercises. The one-time work is mapping systems to criticality, designing schedules and retention, and building the first restore test. The recurring work is monitoring job results, reviewing retention, and running restore tests on a cycle your continuity plan sets. No effort figure is supplied for this page, so ask any provider to break its estimate into these components before comparing offers.
How long does it take to set up a restore test cycle for ML1?
The duration depends on whether you already have a documented disaster recovery plan, a current inventory of systems, and a backup platform that records what it has protected. Setting up the cycle means agreeing which systems are restored, to what common point in time, who runs the exercise, and what success looks like, then recording the results as evidence. Where those inputs exist, setup is mostly coordination and scripting; where they do not, the inventory and continuity work comes first and takes longer. No duration is supplied for this page, so ask for a timeline tied to the written scope and to the dependencies that must be settled before the first test.
Can our team implement ML1 regular backups in-house?
Often yes, if you have engineers who already operate backup infrastructure and an owner for continuity planning. Open-source options such as Bareos, which runs a Director that schedules backup, restore and verify jobs and keeps a SQL catalog of backed-up files, and restic, which verifies snapshot structure and can read pack files back to confirm stored data is unmodified, can be deployed inside your own environment. The harder part is usually not the software but the evidence: documented criticality tiers, job records, retention settings and dated restore test results that an assessor can trace. Teams without that discipline in-house often bring in an implementation partner for the design and first test, then keep the cycle themselves.
What skills and staff time does ML1 backup work need?
You need people who understand your systems and their dependencies, people who can operate the backup platform, and a business owner who can decide criticality and acceptable recovery positions. Systems staff need time to document what each application and its settings depend on, so a restore test restores a working service rather than isolated files. Security or compliance staff need time to confirm that unprivileged accounts cannot reach other users' backups or modify them, and to file the results. Time requirements vary with estate size and are not supplied here, so ask a provider to name the roles and days it expects from your staff in its written scope.
Do backups alone satisfy Essential Eight ML2 or ML3?
No. Backups are one of eight mitigation strategies, and ML1 backup requirements are a subset of the requirements at higher levels, so meeting ML1 for backups does not establish ML2 or ML3 for this strategy. ML2 adds controls such as privileged accounts other than backup administrators being unable to access or modify other users' backups, and ML3 narrows access further, including limits on backup administrators during the retention period. Those levels also depend on the other seven strategies, which are assessed separately. Check the ISM Essential Eight profiles and the maturity model before planning, since the level you target is set across all eight strategies.
What should we ask a partner for in a fixed-scope quote for ML1 backups?
Ask for the written scope to list the systems in scope, the criticality tiers and the basis for assigning them, the backup platform and where it will run, the retention and synchronisation design, the restore test plan with the systems and common point in time it covers, and the evidence produced. Ask which deliverables are one-time and which recur, what the provider does and what your staff must do, and what changes the scope. Ask who owns the controls and who issues any assessment report, since an implementation partner prepares systems and evidence while an independent assessor issues conclusions. DeployOpen does not publish a price list, and a quote follows from the written scope.
Where can I confirm the ML1 backup requirements myself?
Start with the ASD Essential Eight Maturity Model on cyber.gov.au, then check the ISM Essential Eight ML1 profile in the ASD OSCAL repository, where the ML1 backup controls are tagged. Confirm the current release date and version when you read them, because the model and the ISM are updated. Use those sources to check your own interpretation, and confirm any open question about applicability with your assessor or with ASD guidance before you rely on it.
How DeployOpen scopes and prepares backup evidence
DeployOpen plans, implements and documents self-hosted backup platforms inside your own infrastructure, whether that is your cloud accounts, data centers or air-gapped networks. Before work starts, the written scope should name which data sets, applications and system settings are in the backup estate, which business criticality tier each one sits in, and which retention periods apply. Those decisions drive the ML1 controls directly, because ISM-1511 expects backups to follow business criticality and continuity requirements. Confirm the criticality classification with your business continuity owner first, since an implementation partner can configure schedules but cannot decide what the business considers critical.
The restore test and evidence pack are prepared under a fixed scope agreed in writing. For a Maturity Level One engagement, that typically means a documented backup schedule, a catalog or inventory of protected sets, evidence that a common point in time can be restored, records of access restrictions for unprivileged accounts, and the output of a disaster recovery restore exercise tied to ISM-1515. Ask the partner to state which artifacts they will produce, who runs each test, and what happens if a restore fails during the exercise. Run a small restore yourself before the formal test so your team knows how the tooling behaves.
DeployOpen does not issue assessment reports, attestations or certifications. Your own assessor or the organization's internal audit function performs the assessment and forms the conclusion. The Essential Eight is a set of mitigation strategies, not a certification scheme, so there is no ASD certificate to obtain. Maturity is shown through assessment of how each strategy is implemented and how well it works against the maturity model, which is published on the ASD Essential Eight maturity model page. Any claim that a vendor or consultant has certified your backups as Essential Eight compliant should be treated as a red flag.
