What immutable backups for Essential Eight Maturity Level 3 require
Your contract, customer or regulator now expects Essential Eight Maturity Level 3 backups, and the core demand is specific: backup administrator accounts must be prevented from modifying and deleting backups during their retention period (ISM-1708). The organization owns this control and the evidence that proves it. An implementation partner can prepare the systems, configuration and evidence, but only an independent assessor issues the assessment conclusion. Start by confirming in writing which backup administrator accounts exist today, because any account that can alter retention settings or purge a repository will fail this test regardless of how the backup product is labeled.
Mapping that requirement to a design means separating three roles in your backup estate: unprivileged users, privileged administrators and backup administrators. Under the Essential Eight baselines, unprivileged accounts and privileged accounts other than backup administrators must not access their own backups (ISM-1813, ISM-1706), and privileged accounts must not reach backups belonging to other accounts (ISM-1705). In a self-hosted design, this usually means a separate backup server identity, repository credentials held outside the production estate, and a retention lock enforced by the storage or tool rather than by an operator's good intentions. In Bareos, retention periods for jobs, files and volumes determine how long records stay in the catalog and how long a volume is guaranteed not to be reused. In restic, restic check with --read-data-subset can confirm that stored data has not been modified, which supports the integrity evidence an assessor will ask for.
Cost and effort depend on the size of the estate, data volumes, retention periods, the number of systems in scope and how much existing tooling you can reuse. One-time costs usually include design, separation of roles, immutable storage configuration and the first restore test; recurring costs include monitoring, periodic restore exercises, storage growth and support. Ask any partner for a written scope that names the systems in scope, the retention policy, the restore test plan and the evidence deliverables, and ask which parts they expect your team to perform. Restoration of data, applications and settings to a common point in time must be tested as part of disaster recovery exercises (ISM-1515), so budget for that test as a recurring activity, not a one-off.
Who is paid for what in an immutable backup project
This table compares each cost component of an immutable backup project for Essential Eight Maturity Level 3, showing who is paid, whether the cost is one-time or recurring, and what drives it. Read it when preparing a quote request, because the largest recurring costs often sit with the organization rather than the implementation partner. No prices or durations are stated, so ask each party to price its share against the written scope.
| Cost component | Who is paid or who carries it | One-time or recurring | What drives the cost |
|---|---|---|---|
| Internal backup and security staff | The organization's own staff, who own the backup policy, approve retention and hold the backup administrator role | Recurring | Number of backup administrators, separation of duties, time spent on retention reviews and access recertification |
| Storage and infrastructure | The organization, in its own cloud accounts, data centers or air-gapped network | Recurring, with a one-time setup | Data volume, retention period, growth rate, replication to a second location and the immutable storage design chosen |
| Backup software licences | Open-source tools such as Bareos or restic carry no licence fee, so the cost is hosting and operation | One-time setup, then recurring operation | Hosting platform, patching of the backup server, monitoring and the staff time needed to run it |
| Implementation partner scoping and build | The implementation partner, under a written, fixed-scope agreement | One-time | Number of systems in scope, number of backup sources, integration with existing identity and storage, and documentation depth |
| Integrity checks and restore testing | Shared: staff run the tests, and the partner may design the procedures | Recurring | Frequency of checks, amount of data read back, and how often a common point in time restore must be tested under ISM-1515 |
| Retention and access audits | The organization, with its internal audit or compliance team | Recurring | Number of accounts that can reach backups, number of retention policies, and how often access rights are reviewed |
| Independent assessor | The independent auditor or assessor, who reviews the evidence. DeployOpen does not issue assessment reports | Usually one-time per assessment, repeated on reassessment | Scope of evidence, number of backup systems tested, and whether the assessor needs to observe a restore in person |
| Growth and ongoing support | The organization, or a support retainer with the partner if one is agreed | Recurring | Storage growth, new systems added to backup scope, upgrades of backup tools, and changes to retention rules |
What makes ML3 backup work cost more or take longer
Immutable backups at Maturity Level 3 are shaped less by the backup software than by how many systems, retention periods, administrator identities and restore tests the organization must carry. Each driver below changes the design, the recurring effort and the evidence an assessor will ask for, so scope them in writing before choosing tools.
Systems and data classes in scope
Every system whose data must be recoverable adds a backup job, a catalog entry, a restore path and a retention rule. Group systems by data class and recovery requirement rather than by server, so that the number of distinct policies stays manageable. Ask the implementation partner to list each system, its data classification and its owner before pricing begins. Confirm which systems are cloud-hosted SaaS, since those often need a separate export or vendor-native retention feature. A longer inventory means more jobs to build, more restore tests to run and more evidence to collect each cycle.
Retention periods and storage volume
Retention determines how long backups must remain unmodifiable, which in turn sets storage growth and the size of the immutable window. A longer period multiplies stored data across full and incremental copies. In Bareos, job, file and volume retention periods control how long catalog records remain and how long a volume is guaranteed not to be reused, so these values must be set deliberately for each data class. Ask for a written retention schedule, a storage growth estimate under that schedule and a plan for when retention expires and media is recycled.
Backup administrator accounts and separation
The ML3 rule that backup administrator accounts cannot modify or delete backups during retention is the most design-sensitive requirement. Each backup administrator account is a separate identity with its own controls, and the number of such accounts drives the work of provisioning, reviewing and monitoring them. Keep backup administrators apart from production identities and from the domain administrators who manage the systems being backed up. Ask whether the backup platform can enforce retention independently of the administrator who holds the keys, since a shared administrator model usually needs extra compensating work.
Existing backup tooling and immutability features
Costs fall sharply when existing tools already support write-once storage, object lock or enforced retention, and rise when they do not. Before procurement, document each current backup product, its version, its storage targets and whether retention can be changed by an administrator. Confirm these features with the vendor and in a test environment, not from marketing material. Open-source options such as restic can write to repositories that are then placed behind storage-level protection, but the storage layer must still enforce the immutability that the design depends on. Migrating from an incompatible tool adds a parallel run and a longer evidence period.
Offsite and air-gapped copies
A copy held offsite or in an air-gapped location protects against a compromise that reaches the primary backup environment, but it duplicates storage, transfer and access controls. Each additional location needs its own encryption keys, network path, retention settings and restore test. Decide early whether the offsite copy is a second immutable repository, a tape or disconnected medium, or a cloud bucket in a separate account. Ask the partner to show how the offsite copy is synchronized, how failed transfers are detected and who can reach it. Every extra location also adds a line to the evidence pack.
Existing restore evidence
Assessors look for proof that data, applications and settings can be restored to a common point in time as part of disaster recovery exercises, as the requirement in ISM-1515 expects. Organizations that already run documented restore tests with recorded timings, results and corrective actions need less preparation than those that have only backup job logs. Where no restore history exists, plan for a first full exercise, a written test plan and a remediation cycle before the assessment window. Ask for the last restore test report, the scope it covered and the open findings from it.
Which self-hosted tools can meet the retention and integrity rules
Bareos is an open-source backup system licensed under AGPL-3.0-only. Its retention settings are the main tool-level control over how long backup records and data stay in place. Job, file and volume retention periods work on different objects. Job retention controls how long the job record stays in the catalog, file retention controls how long file entries stay in the catalog, and volume retention controls how long a volume is guaranteed not to be reused after its last write. Those settings govern when Bareos may recycle media. They do not, by themselves, stop an administrator from editing the catalog, deleting volumes or changing the configuration.
- Catalog records: Job and file retention determine how long Bareos keeps records of what was backed up, which affects restore planning and audit trails.
- Volume guarantee: Volume retention sets the period in which Bareos will not overwrite a volume, but it is a scheduling rule rather than a write lock.
- Admin separation: Backup administrator accounts can still change retention settings or remove volumes unless the organization restricts them outside Bareos.
- Storage write protection: Immutability has to come from the storage layer, such as object lock or write-once media, configured and verified by the organization.
- Restore testing: Retention settings do not prove that backups can be restored to a common point in time, so restore exercises remain a separate task.
Confirm with the Bareos project and your own storage platform which features prevent modification and deletion during retention, and document how those features are enforced for backup administrator accounts.
restic is an open-source backup tool licensed under BSD-2-Clause. It encrypts every repository by default, which protects confidentiality, and its check command helps show that stored data has not been altered. All data restic writes to a repository is encrypted with AES-256 in counter mode and authenticated with a Poly1305-AES message authentication code. The check command verifies the structural consistency of snapshots, trees and pack files. Adding --read-data or --read-data-subset makes it read pack files back and confirm the stored data is unmodified, which gives evidence for the integrity side of the requirement.
- Encryption: AES-256 in counter mode protects the confidentiality of stored backup data.
- Authentication: Poly1305-AES authentication allows restic to detect modification of encrypted content.
- Structural checks: The default check run verifies snapshots, trees and pack files without reading all data.
- Data verification: --read-data reads every pack file, and --read-data-subset reads a defined portion, which lets you choose the depth and schedule of verification.
- Access limits: restic does not prevent a user with repository write access from deleting snapshots, so access controls and storage-level immutability remain necessary.
Confirm with the restic documentation how your chosen version and storage backend handle deletion, and test whether a backup administrator can remove snapshots before retention expires.
Neither Bareos nor restic alone satisfies the access rules at ML3. The rules require that unprivileged accounts and most privileged accounts cannot reach their own backups, that backup administrators cannot modify or delete backups during retention, and that privileged accounts cannot touch other accounts' backups. Those are access and enforcement decisions made in the identity model, the storage platform and the operating procedures. An encryption and verification tool does not make a backup unchangeable for a user who holds the keys or write rights.
- Separated identities: Backup administrators need accounts that are distinct from daily administration, with access logged and reviewed.
- Storage immutability: Object lock, write-once media or an equivalent control must block deletion for the retention period, including for administrators.
- Key custody: Encryption keys and repository passwords must be held so that a single administrator cannot both change backups and erase evidence of the change.
- Scheduled verification: Integrity checks need a defined schedule, retained output and an owner who acts on failures.
- Restore evidence: Records from disaster recovery exercises that restore data, applications and settings to a common point in time support the ISM-1515 requirement.
Before relying on either tool, ask the vendor or project which immutability features they provide and confirm them in a test environment that reflects your own storage and identity setup.
Organizations usually pick a tool by workload, then add the controls the tool does not provide. Bareos suits environments that need central scheduling and catalog-based management across many clients. restic suits teams that want encrypted, deduplicated repositories with a simple command set and strong verification commands. Both can sit on storage that supports immutability, and both can be run in self-hosted environments inside the organization's own infrastructure. The choice affects how much of the evidence the team must build by hand.
- Workload fit: Bareos fits scheduled, catalog-driven backup of many systems, and restic fits repository-based backup where the team controls scripts and storage.
- Evidence output: Catalog reports and retention settings support Bareos evidence, while check output and logs support restic evidence.
- Operational ownership: Each tool needs patching, storage capacity planning, key management and backup of its own configuration.
- Licensing review: AGPL-3.0-only and BSD-2-Clause carry different obligations, so legal teams should review them against the intended use.
- Independent review: Only an independent assessor can confirm that the design meets the ML3 rules.
Check whether your chosen combination produces records that show who accessed each backup, when retention was enforced and when verification ran.
How an ML3 backup design moves from scope to assessor evidence
This sequence turns the Essential Eight regular backups strategy into a backup design that an assessor can test, starting from what data exists and ending with restore results and retained records. Each phase produces a written artifact that the next phase depends on, so gaps surface early rather than during the assessment.
Scope systems and data classes
The organization owns this step and its internal asset owners do most of the work, with an implementation partner helping to map systems, backup sources and data flows. List every system that holds data the organization must be able to recover, including Microsoft 365 or other SaaS data where it applies. Group the data into classes by business impact and retention need. The step is done when every in-scope system is assigned to a class and the owner has signed off the inventory.
Define retention periods per data class
The organization sets retention periods for each data class, and its risk, legal and records owners approve them. Retention drives how long a backup is protected from modification or deletion, so each period must be written down with the reason behind it. Confirm the retention rules in your backup tool match the approved periods, using the tool's documentation on job, file and volume retention. The output is a retention schedule that the backup configuration can be checked against.
Separate backup administrator identities
Create dedicated backup administrator accounts that are distinct from daily administrator accounts and from unprivileged user accounts. Restrict which accounts can read, write or delete backups, so that no ordinary privileged account can reach another account's backups. The identity team and the security team review the access matrix and confirm that backup administrator accounts are themselves protected by strong authentication. The output is an approved access matrix that names every account allowed to touch backup data.
Configure write protection and retention enforcement
Configure the backup repository so that backup administrators cannot modify or delete backups during their retention period. This is usually done through the tool's volume or repository controls, object-lock style features on the storage layer, or a separate storage account with its own deletion rules. Test the control by attempting a deletion with a backup administrator account before retention expires, and record the result. The output is a tested configuration with the failed deletion attempt documented.
Set up encryption and integrity checks
Enable encryption for backup data at rest and in transit, and store key material separately from the backup repository. Schedule integrity checks that verify repository structure and, on a regular cycle, read stored data back to confirm it has not changed. Confirm with the tool's documentation which checks are structural and which read data, because only the data-reading checks confirm the stored content. The output is an encryption configuration, a key custody record and a schedule of integrity check runs with their logs.
Schedule restore tests within disaster recovery exercises
Plan restore tests as part of disaster recovery exercises, so that data, applications and settings are restored to a common point in time. The recovery team runs the exercise, and the system owners confirm that restored systems behave correctly against the expected point in time. Record the recovery point used, the time taken and any gaps found. The output is a dated exercise report with the restore results and the actions raised from them.
Collect evidence for the assessor
Assemble the artifacts from each earlier phase into one evidence pack that maps to the ISM controls for backups at the target maturity level. The pack should include the scope inventory, retention schedule, access matrix, enforcement test results, integrity logs and exercise reports. Ask the independent assessor which samples they will select and confirm the pack covers them. The step is done when the assessor has accepted the evidence list, and only the assessor can state whether the design meets the level.
What must be in place before an assessor reviews the backups
An assessor testing regular backups at Maturity Level 3 looks for evidence that each control operates, not only that it is configured. The six items below are the records most likely to be requested, and each one can be checked internally before the assessor arrives.
Documented retention schedule
Write down which data sets are backed up, how long each backup set is kept, and when a volume or snapshot may be expired. An assessor compares this schedule with the configured retention settings, so any mismatch becomes a finding. Check that the schedule names an owner, a review date and the backup tool that enforces each period. For Bareos, the job, file and volume retention values should each match the document. Keep the schedule under change control so the version in force on the test date is clear.
Backup administrator account separation
Produce an account inventory that lists every account able to reach the backup platform, its role and its privilege level. The ML3 rules separate backup administrators from other privileged accounts and from unprivileged users, and the assessor will check that no one account holds more than its role allows. Confirm that backup administrators cannot change or delete backups during retention, and that other privileged accounts cannot read another account's backups. Review the inventory against the directory each quarter and record who approved each entry.
Evidence of retention enforcement
A configured retention period is not enough on its own. The assessor will ask for evidence that the platform blocks a deletion attempt before the period ends, such as a test where a backup administrator tries to remove a protected backup and the attempt is refused and logged. Store the result of that test with the date, the account used and the platform version. Repeat the test after upgrades, since a change to the backup software can alter how locks behave.
Integrity check logs
Keep dated logs from integrity checks run on the repository. 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. Record the command used, the scope of the read (full or subset), the result and who reviewed any error. An assessor expects a regular cadence, so show the schedule and the logs that fulfill it, including any failed run and how it was resolved.
Encryption configuration
Document where encryption keys are created, who holds them, and where recovery copies are stored. For restic, all repository data is encrypted with AES-256 in counter mode and authenticated with a Poly1305-AES message authentication code, so the assessor will focus on key handling rather than the algorithm. Confirm that keys are not stored only on the backup server, that the key holders are separate from backup administrators where practical, and that a key recovery test has been run and recorded.
Recent restore test with a common point in time
ISM-1515 requires restoration of data, applications and settings to a common point in time to be tested as part of disaster recovery exercises. Prepare a dated record showing that the restore used one recovery point for all systems in scope, the time taken, the systems involved and the checks that confirmed the restored data was usable. Note any gap between the common point and the last good backup. Confirm the test was performed by someone other than the backup administrator who set up the job.
Who owns the controls and who prepares the evidence
The organization owns its backup controls, its retention decisions and its restore capability. Under the Essential Eight, the mitigation strategy is implemented and operated by the organization, so no outside party can accept responsibility for whether backups are immutable during retention. Internal staff also decide who holds backup administrator accounts and how those accounts are separated from everyday administration.
- Retention decisions: Business and legal owners set how long each data set is kept and approve any change that shortens or extends retention.
- Access design: The security team decides which accounts are unprivileged, privileged and backup administrator, and confirms that no account can both write and delete its own backups.
- Restore exercises: Operations staff schedule and run restore tests, including the common point in time restoration tested in disaster recovery exercises (ISM-1515).
- Evidence ownership: The organization keeps the configuration exports, job logs, access reviews and restore test records that an assessor will request.
- Sign-off: A named executive accepts residual risk where a control cannot be met as written.
Before engaging anyone, confirm internally who holds each of these decisions and who will sign the restore test records.
An implementation partner such as DeployOpen plans, configures, hardens, documents and prepares evidence for the backup system. Work is performed inside the client's own cloud accounts, data centers or air-gapped networks, and the client keeps ownership of the backup data, keys and repositories. The partner does not decide retention periods or accept risk on the organization's behalf, and it does not issue assessments or certificates.
- Design: Plans the repository layout, retention settings and separation of administrator roles against the ISM controls.
- Configuration: Sets up tools such as Bareos or restic, including volume retention, encryption and access restrictions.
- Hardening: Applies the controls the tool offers for protecting backup storage from modification and deletion, and documents where a platform cannot enforce a requirement alone.
- Documentation: Writes runbooks, configuration baselines and restore procedures the organization can maintain.
- Evidence preparation: Collects configuration exports, check outputs and restore logs in a form an assessor can review.
Ask any partner to state in writing which items it will prepare and which remain with your team.
The independent assessor tests whether the backup controls work as described and records its conclusion. The assessor is independent of both the organization and the implementation partner, and it is the only party that issues a report or conclusion. The Essential Eight is a set of mitigations rather than a certification scheme, so the assessor evaluates implementation and effectiveness against the maturity model rather than handing over a certificate.
- Scope confirmation: Agrees which backup systems, accounts and data sets fall within the assessment.
- Testing: Inspects administrator permissions, attempts modification or deletion of retained backups where the method allows, and reviews integrity check results.
- Restore observation: Reviews restore tests and the records that prove them.
- Evidence review: Checks that the documentation matches what the systems actually do.
- Conclusion: Records findings and any maturity conclusion in its own report.
Confirm the assessor's independence and the form of its deliverable before work starts, and do not accept preparation work from the assessor as a substitute for its own testing.
Where backups are held by a cloud or software-as-a-service provider, responsibility is shared. Microsoft's Essential Eight backup guidance states that customers always retain responsibility for their information under the shared responsibility model and still need to protect Microsoft 365 data, with in-place retention policies and labels as one way to do it. The provider supplies storage features, but the organization must still configure and prove them.
- Provider features: Retention policies, labels and storage immutability settings are controls the organization must enable and verify.
- Customer duties: The organization remains accountable for data classification, retention and access, whatever the provider offers.
- Gaps: Any feature the provider does not expose must be covered by a documented compensating control.
- Contract terms: Confirm which backup and restore evidence the provider will supply during an assessment.
- Tool limits: Confirm with each vendor whether a specific immutability or retention feature meets the ISM wording in your environment.
Request the provider's current documentation and confirm each feature in your own tenant before relying on it.
Evidence moves through three hands: the partner produces it, the organization owns and retains it, and the assessor reviews it. Clear handoffs prevent gaps where a control was configured but no one can show the configuration, or where records were produced but cannot be traced to a specific system. The handoff should be agreed before implementation, not during the assessment.
- Named artifacts: List each expected item, such as retention settings, access lists, integrity check output and restore test reports.
- Ownership: Record who stores each artifact and where it is kept.
- Dates and versions: Keep configuration and tool versions alongside each record so the assessor can match evidence to the system state.
- Access to assessor: Decide how the assessor receives evidence, and whether it can test systems directly.
- Retention of records: Keep evidence for as long as the assessment cycle requires, which should be confirmed with the assessor.
Before the assessment begins, ask the assessor to review a sample evidence pack and confirm it meets its expectations.
Questions buyers ask about Essential Eight ML3 backups
Can an open-source backup tool alone meet Essential Eight ML3 for backups?
No tool alone meets a maturity level, because the Essential Eight is a set of mitigations that the organization implements and evidences, not a certification a product can earn. Open-source tools such as Bareos and restic can supply retention controls, encryption, integrity checks and restore logs, but the organization still has to configure account separation, storage access rules and restore exercises so that backup administrators cannot modify or delete backups during retention. Confirm each ISM control in the ML3 profile against the design, then have an independent assessor test it.
What does the work need from our internal staff?
Internal staff remain responsible for the decisions that assessors will ask about: which systems are in backup scope, how long each data set must be kept, who holds backup administrator rights, and who approves a restore. Your team also needs to provide access to identity systems, storage accounts and change records so the implementation can be verified. An implementation partner can prepare the configuration and documentation, but the organization owns the retention policy and its operation after handover.
How do we evidence that restore testing actually works?
Evidence is a dated record of a restore to a common point in time, covering data, applications and settings, performed as part of a disaster recovery exercise. ISM-1515 asks for this restoration to be tested, so keep the exercise plan, the job logs, the restored system's validation results and the signed-off outcome. Ask your auditor which records they will sample, and store them where backup administrators cannot alter them.
Can DeployOpen run an ML3 backup project under a fixed scope?
Yes, most DeployOpen engagements are fixed-scope, with the scope, deliverables and timelines agreed in writing before work starts. A typical written scope for this work would name the systems in backup, the self-hosted tools deployed in your environment, the account and storage design, the restore test plan and the evidence pack. DeployOpen prepares systems and evidence for your assessment, but it does not issue audit reports or certifications, and it does not publish a price list. A quote follows from the written scope.
What changes for Microsoft 365 data under the shared responsibility model?
Microsoft 365 data remains your responsibility, even though the service is hosted by Microsoft. Microsoft's Essential Eight backup guidance states that customers always retain responsibility for their information and still need to protect it, with in-place retention policies and labels as one way to do so. Your design must decide whether those retention features, a separate self-hosted backup, or both will meet the ML3 access rules, and you must show that backup administrators cannot delete held data.
How do we confirm which ML3 requirements apply to our backups?
Start from ASD's machine-readable profiles, which list the ISM controls for Essential Eight ML1, ML2 and ML3 in OSCAL form. Download the ISM OSCAL release and open the ML3 baseline, then filter the regular backup controls, including ISM-1813, ISM-1706, ISM-1708, ISM-1705, ISM-1707 and ISM-1515. Read each control's text in the catalog, map it to a configuration or procedure you own, and record the gap. Confirm the release version your assessor uses, because profiles are updated.
Which backup rules are hardest to satisfy with self-hosted tools?
The hardest rule is preventing backup administrators from modifying or deleting backups during retention, because the same people who run the tool often hold the credentials that can remove data. Self-hosted designs usually rely on separate storage accounts, write-once or object-lock features where the storage platform offers them, and retention settings enforced outside the administrator's direct control. Confirm that your chosen storage backend supports these features before selecting the tool, and test that a privileged deletion attempt fails.
How DeployOpen scopes and prepares ML3 backup evidence
DeployOpen plans, builds and documents self-hosted backup platforms inside your own infrastructure, so the access controls, retention settings and restore records that Maturity Level 3 asks about are in place before an assessor arrives. The organization owns its controls, and an independent assessor reaches the conclusion about maturity.
How we scope
- We agree a written, fixed scope listing the backup tools, storage targets and systems covered for Immutable backups for Essential Eight Maturity Level 3.
- The scope names which account types exist, including backup administrator accounts, and which accounts must be denied access to backups.
- Scope documents the retention periods, restore test cadence and evidence owners that the written scope commits to delivering.
How we build
- We configure backup software so retention periods stop modification and deletion of backups by backup administrator accounts during retention.
- We set up integrity checks and encryption, then document how each check runs and where its output is stored for review.
- We build and document restore tests for a common point in time, so disaster recovery exercises produce evidence an assessor can follow.
How we hand over
- You receive configuration records, access role mappings and retention settings mapped to the relevant ISM controls for your assessor.
- Handover includes runbooks for restore testing and a log of past test results, with the named owner for each recurring task.
- We walk your team through the evidence set so your staff can reproduce checks and explain them to an independent assessor.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover, covering backup software updates and repeated restore tests.
- A retainer can keep retention settings, access reviews and integrity check outputs current as your environment changes.
- Confirm with us in the quote which post-handover tasks sit inside the retainer and which remain with your internal team.
