What MP.L2-3.8.9 protect backups requires for CUI
MP.L2-3.8.9 requires that the confidentiality of backup CUI be protected at every storage location where backups reside. It is the CMMC Level 2 version of NIST SP 800-171 Rev. 2 requirement 3.8.9, and the assessment objective is narrow: a backup copy of CUI must be protected wherever it sits. For a compliance lead, the practical consequence is that the backup estate is in scope just as the live system is. A forgotten tape in a drawer, an unencrypted external drive in an engineer's bag, or a NAS share with broad read access exposes the same CUI as the production server it was copied from, even though nobody thinks of it as a system.
This requirement is easy to miss because backups are copies that sit outside the controls built around the main system. They often live in separate tools, on separate hardware, under separate administrators, and they are rarely listed in the system security plan. The hard parts are usually three. First, the inventory: many organizations cannot list every location where backup data lands, including offsite rotations, cloud buckets and vendor-managed copies. Second, older media: tapes and drives written years ago may not be encrypted, and re-encrypting or retiring them requires a decision about what happens to data already stored. Third, access rules: backup consoles and repositories are often administered by a small group with rights that differ from production, and those rights are seldom reviewed with the same rigor.
Which backup locations and teams fall in scope
Any copy of CUI that can be restored is a backup, and MP.L2-3.8.9 applies wherever those copies sit. The cards below cover the places CUI backups usually live, the teams that run them, and the scoping questions that decide what the requirement covers. Your System Security Plan must record each decision.
USB drives and removable backup media
External drives used for manual or rotating backups are the most common gap, because they leave the building in a bag or a drawer. Each drive that has ever held CUI needs an owner, an encryption method, and a storage location with controlled access. Check whether anyone copies CUI to a personal or unmanaged drive, since those copies fall under the requirement even when no one counts them as backups.
Tape and offline media
Tape cartridges and offline disks often sit in off-site vaults or rotation boxes that are managed by a separate vendor or a facilities team. Confirm who holds the keys to those containers, how cartridges are logged in and out, and whether the tapes are encrypted before they leave the data center. Retired or damaged cartridges must also follow your sanitization process, not simply go into a bin.
NAS and backup servers
Network-attached storage and dedicated backup appliances hold full copies of file shares and databases, often with broad administrative access. Scope them as systems that store CUI backups, then confirm encryption at rest, administrator accounts limited to named people, and physical security for the device. A NAS that is shared with other departments is a common place where CUI backups are overlooked.
Backup software and catalogs
The backup server and its catalog store file names, paths, job histories and sometimes restore points, which can reveal CUI even when the data is encrypted. Identify where the catalog database lives, who can query it, and whether restores can be run by people outside the backup administrators. Restore access is the path an attacker or insider would use, so it belongs in the scope review.
Offsite and cloud backup providers
Backups replicated to a cloud bucket, a colocation facility or a provider's managed service are stored outside your direct control. Treat each provider as holding CUI if backups from in-scope systems land there, and confirm the encryption keys, administrator access and physical controls the provider applies. Ask for the provider's security documentation and record the responsibility split in your System Security Plan.
Scoping decisions and owners
Whether a backup is in scope depends on whether it contains CUI, and that is a fact about the data, not the storage medium. Tokenized, masked or excluded data can change the work, but only if the decision is documented and tested. Backup administrators, the system owner, and the compliance lead should agree on these calls and confirm them in your own System Security Plan before an assessor reviews them.
How an assessor tests backup confidentiality
This table compares what an assessor does, the evidence they request and the findings they commonly raise for the single assessment objective of MP.L2-3.8.9. Read each row as a step in the test: the requirement is MET only when the confidentiality of backup CUI is shown at every storage location, and only with evidence in final form, not drafts.
| Test area | Evidence requested | Common findings |
|---|---|---|
| Backup procedures and mechanisms | Written backup procedure, system backup configuration, and a demonstration of a backup job running from start to finish | Procedure describes backups but does not say how backup data is protected, or the procedure is an unapproved draft |
| Backup storage locations | Inventory of every location holding backup CUI, including tapes, external drives, NAS, servers, offsite and cloud backup | Locations missing from the inventory, such as a laptop-attached drive or a vendor-held replica |
| Backup logs and records | Backup job logs, retention records and restore test records for the sampled period | Logs show backups completed but do not show which location received them or whether encryption was enabled |
| Encryption at each location | Encryption settings or configuration exports for each backup target, with key custody details | Encryption enabled on the primary repository but not on the offsite copy or on external media |
| Access control at each location | Account lists and permission settings for each backup repository, plus approval records for administrator access | Shared administrator accounts, or backup administrators with broader access than the people who need it |
| Physical security of backup media | Storage location descriptions, access records for locked storage, and custody records for media moved offsite | Tapes or drives left unlocked in shared areas, or no record of who handled removable backup media |
| Sampling and walkthrough | Assessor selects sample locations and asks the operator to show encryption and access settings live | Operators describe controls from memory and cannot show the settings or the logs that support them |
| Evidence finality | Final, approved versions of policies, configurations and records dated within the assessment period | Draft procedures, unsigned plans or screenshots without dates are not accepted as final evidence |
How to implement backup confidentiality step by step
This sequence takes an organization from an unknown set of backup copies to a documented, tested state in which every copy of CUI held in backup is protected against unauthorized access wherever it is stored. The organization owns each control, while an implementation partner can prepare systems, configurations and evidence along the way.
Inventory every backup copy holding CUI
Start by listing every place a backup of a CUI-bearing system is written, including tapes, external drives, NAS devices, backup servers, replicated sites and cloud backup buckets or vaults. Include backups made by endpoints, databases and virtual machine snapshots, since teams often forget these. The owner of each system confirms which backups contain CUI. The output is a backup register that names each copy, its storage location, its backup tool, its retention period and the data owner, and that the system owner has signed off on.
Classify each location and its access path
For each entry in the register, record who and what can reach the storage: administrators, backup service accounts, cloud identities, network paths, and any vendor or managed service with access. Classify the location by its exposure, such as on-premises and inside the boundary, offsite, or in a shared cloud account. Mark locations that sit outside the system security plan boundary for further review. The output is a classified access map showing each backup location, its access paths and its owner.
Define encryption and key management for each backup type
Decide how each backup type is protected at rest, using encryption that suits the storage and the tool in use, and confirm that the cryptographic modules meet the FIPS-validated cryptography expectations for CUI in the related requirements. Define where keys are generated, who can use them, how they are stored outside the backup they protect, and how they are rotated and recovered. Confirm with your tool vendors and assessor what their encryption and key features actually do, rather than assuming. The output is a written encryption and key management standard, with a configuration record for each backup type.
Restrict access to jobs, catalogs and restore rights
Limit who can create, change or delete backup jobs, who can read backup catalogs and logs, and who can perform restores. Separate backup administration from system administration where practical, use named accounts with multifactor authentication for privileged access, and remove standing rights that are no longer needed. Restore rights often expose more CUI than backup rights, so review them first. The output is a role matrix for backup operations and a review record showing that each privileged account was approved by its owner and is logged.
Secure physical media and offsite copies
For removable media, tape, and any backup hardware kept outside a secured room, define storage, check-out and transport controls, including locked storage, tamper-evident packaging and a custody record for each movement. For offsite and cloud copies, confirm the physical and provider-side controls in writing, and confirm the provider's data residency and access logging. The output is a physical handling procedure and a current media or location log that a reviewer can compare against the backup register.
Test restores and backup integrity
Run restore tests from each backup type, including encrypted copies, and confirm that the data comes back readable only by authorized staff using the controls documented in earlier steps. Where the tool supports it, run integrity checks that read stored backup data back and confirm it has not been modified. Record the date, the scope, the person who ran the test and the result, including failures and the corrective action. The output is a dated test record for each backup type, with any defects tracked to closure.
Document the procedure in the System Security Plan
Write the backup procedure into the system security plan, covering the backup register, the storage locations, encryption and key management, access roles, physical handling, test schedule and the responsible owners for each. Link each section to the evidence that supports it, such as backup logs, configuration exports and test records. Ask your assessor which evidence they expect, and confirm that drafts are replaced with final versions before assessment. The output is an approved system security plan section for backup confidentiality with a cross-reference to each supporting artifact.
Evidence that passes for backup confidentiality
An assessor testing MP.L2-3.8.9 looks for a connected set of records: the procedures that create backups, the places they land, how each location is encrypted, who can reach them, and how the physical media are kept. The cards below cover each artifact and the upkeep that keeps them accurate between assessments.
System backup procedures
Written procedures showing what is backed up, how often, by which tool, and where each job writes. Assessors use these to trace from the stated process to the running jobs. Check that the procedures name every system holding CUI, including file servers, databases and endpoints, and that they reflect the current backup product, not a retired one. A procedure that describes a job nobody still runs will fail the trace.
Security plan entries for backup
The system security plan should describe how backups fit the CUI boundary, which components store backup copies, and how their confidentiality is protected. Assessors compare this description against the actual architecture. Confirm that the plan lists off-site and cloud backup targets as in scope, and that the entries match the procedures and the storage register word for word on locations and protections.
Register of backup storage locations
A maintained inventory of every place a backup copy exists: tape, external drives, NAS units, backup servers, replication targets and cloud buckets. The register is the anchor for every other artifact, because an unlisted copy is an unprotected copy. Date each review and record who approved it. Gaps usually appear around laptops, administrator workstations and retired devices that still hold older snapshots.
Backup logs and job records
Logs from the backup platform showing that jobs ran, which data they covered, and where the output was written. Restore and verify job records show that stored data is readable and intact. Keep these with timestamps, so an assessor can match a job to a location in the register. Bareos keeps a SQL catalog of backed-up files, which can serve as a primary record when its retention settings are documented.
Encryption configuration for each location
For every entry in the storage register, record how confidentiality is achieved: encryption at rest on the backup repository, encryption applied before data leaves the source, or full-disk encryption on removable media. Record the key custody model, who can unwrap keys, and how keys rotate. Restic encrypts repository contents by design, and Nextcloud server-side encryption does not hide file names or folder structure, so a configuration record should state what each location does and does not conceal.
Access lists and restore rights
Current lists of accounts that can read, modify, delete or restore from each backup system, with the approving owner and the date of the last review. Restore rights deserve separate lines because restoring a backup copies CUI to a new place. Remove departed staff and service accounts promptly, and confirm that backup administrators cannot silently alter retention or deletion settings without an audit trail.
Physical storage control records
Records showing how tape, external drives and backup appliances are locked, logged in and out, and moved between sites. Assessors check custody logs, locked cabinet inventories and transport records for media that leave a controlled area. Pair these with the data center or site access logs that cover the room holding the backup hardware, and note any media that was destroyed or returned after sanitization.
What meeting MP.L2-3.8.9 costs in money and effort
This table compares the main cost components of protecting backup CUI, who is paid for each, whether it is one-time or recurring, and what moves it up or down. Read it as a checklist for a written quote, since no figures are published for this requirement. The main takeaway is that most of the cost comes from people and evidence upkeep rather than software licenses.
| Cost component | One-time or recurring | What drives it | How to keep it down |
|---|---|---|---|
| Tooling and licenses | Recurring if commercial, one-time setup | Number of backup platforms, storage targets and key management systems in scope | Self-hosted open-source backup and encryption tools such as Bareos, restic, Nextcloud and OpenBao can remove license spend, but confirm support and hosting costs |
| Engineering time for encryption and access control | One-time, with periodic review | Number of backup sets, encryption design, key rotation design and separation of backup administrator roles | Standardize one encryption and access pattern across all backup targets, and document it once in the system security plan |
| Inventory and backup evidence upkeep | Recurring | Number of backup locations, job frequency, retention periods and log volume kept as evidence | Automate job logs and catalog exports, and keep a single register of backup storage locations that is reviewed on a fixed schedule |
| Physical security for backup media | One-time for locks and storage, recurring for custody and access checks | Number of tapes, external drives and off-site copies that leave controlled areas | Limit removable backup media to what is needed, record custody, and favor encrypted, access-controlled storage |
| External review or testing | Recurring or per engagement | Whether a third party tests restores, key handling and access to backup repositories, and how many systems are covered | Agree the scope in writing before work starts, and reuse prior test results where the configuration has not changed |
| Assessor time | Per assessment | Number and quality of evidence items, and whether evidence is in final form at assessment | Prepare evidence in final form before the assessment, since drafts do not satisfy the objective |
| Plan of action and milestone closeout | One-time, if used | 3.8.9 is a 1-point requirement under 32 CFR 170.24. A POA&M for Conditional Level 2 status is allowed only if the score is at least 88 of 110, with closeout due within 180 days | Fix the requirement before assessment where possible, and confirm current POA&M rules with the contracting officer given the 13 July 2026 Phase II suspension |
Open-source tools that produce backup evidence
MP.L2-3.8.9 asks whether backup CUI stays confidential wherever backups live, so the assessor will look for backup procedures, storage locations, logs and proof that the protections work. The tools below can generate parts of that evidence, but each one covers only a slice of the requirement, and the organization still owns the configuration, key handling and sign-off that make the evidence credible.
Bareos backup scheduling and catalog
Bareos is a backup system whose Director schedules and supervises backup, restore, verify and archive jobs and keeps a SQL catalog of backed-up files. For MP.L2-3.8.9, the job definitions, schedules and catalog entries show where backup CUI is written and how long copies persist, which supports the backup procedures and backup logs an assessor will request. Confirm that the storage daemon writes to locations covered by your encryption and access control, and that the catalog database is itself protected. Bareos is licensed AGPL-3.0-only, so confirm that this license fits how you distribute or modify it.
Restore testing by point in time
Bareos can restore files selected from the current backup or from a backup taken before a given date and time. Recorded restore tests show that protected backups are recoverable, and they produce the dated records that show the backup process operates as documented. Test restores into a controlled location, and confirm that restored CUI inherits the same access restrictions as the source. Keep restore job logs with the security plan, since an assessor will compare them against the documented backup procedure.
restic integrity checks
restic is a backup tool whose check command verifies the structural consistency of snapshots, trees and pack files. With the --read-data or --read-data-subset option, it reads pack files back to confirm that stored backup data is unmodified. Saved check output is evidence that stored backups have not been altered, which is relevant to the confidentiality and integrity expectations around backup CUI. Note that check confirms structure and content integrity; it does not by itself prove that the repository is encrypted or access controlled, so confirm those settings separately. restic is licensed BSD-2-Clause.
Nextcloud encryption at rest
Nextcloud server-side encryption protects file contents at rest on local and external storage, with keys kept on the server. It is relevant when backup CUI is held in Nextcloud storage or on external mounts that could be removed or lost. The encryption does not cover file names or folder structure, so sensitive names may remain visible to anyone with storage access. Confirm which storage mounts are included, how the keys are backed up and who can reach them, and document the residual metadata exposure in the system security plan. Nextcloud is licensed AGPL-3.0-only.
OpenBao transit encryption and key rotation
The OpenBao transit secrets engine encrypts and decrypts application data without storing it, and supports versioned encryption keys with rotation. Teams can use it to encrypt backup data or backup keys before they leave a controlled boundary, with key access logged and limited by policy. Evidence includes key version history, rotation records and access policies. The team still has to decide what data is encrypted, confirm that FIPS-validated cryptography is used where the requirement needs it, and protect the OpenBao unseal material and its own storage. OpenBao is licensed MPL-2.0.
Who owns backup confidentiality, who builds it, and who assesses it
Your organization owns MP.L2-3.8.9. The requirement asks that the confidentiality of backup CUI be protected wherever backups are stored, and that obligation stays with the contractor even when a partner builds the technical controls. Your team decides what counts as backup CUI, approves who may access backup repositories, and holds custody of the physical media and keys that protect them.
- Backup policy: Define which systems back up CUI, where copies go (tape, external drive, NAS, server or cloud), how long they are kept and who approves exceptions.
- Access approvals: Name the individuals who may restore or read backups, and review that list on a schedule you can show to an assessor.
- Physical custody: Keep tapes, drives and NAS units in controlled locations, and record check-out and return of removable backup media.
- Key ownership: Decide who holds encryption keys and passphrases, and who can rotate or revoke them.
- Evidence ownership: Retain backup procedures, the system security plan entries, storage location records and backup logs in final form.
Before engaging anyone, confirm that your team can name every location where CUI backups exist, including copies held by a managed service provider or cloud account.
An implementation partner prepares the systems and paperwork that let your team meet MP.L2-3.8.9. Under a written, fixed scope, a partner such as DeployOpen can configure encryption for backup repositories, design backup architecture on self-hosted platforms inside your environment, and assemble evidence packages and documentation. The partner does not decide whether your controls pass.
- Encryption configuration: Set up encryption for backup stores, such as repository encryption in Bareos or restic and server-side encryption for Nextcloud-held backup data, with keys managed under your policy.
- Backup architecture: Document backup jobs, retention, storage locations and restore testing so that the design matches the security plan.
- Verification tests: Run and record integrity checks and test restores, so you can show that backup processes work as described.
- Evidence packages: Collect procedures, configuration exports, logs and location records in the form an assessor will examine.
- Documentation handover: Deliver runbooks and the scope in writing so your staff can operate the controls after the engagement ends.
Ask the partner to state in writing what it will not do, including that it will not sign or issue any assessment result or represent itself as an assessor.
The assessor decides whether MP.L2-3.8.9 is met. For Level 2 certification assessments, a C3PAO authorized or accredited by the CMMC Accreditation Body, currently The Cyber AB, performs the assessment. Where a Level 2 self-assessment is permitted under the current rules, your organization performs it and reports the result as the rules require. Confirm the current assessment phase requirements for your contracts before you plan, because the Department of War suspended Phase II in July 2026.
- Assessment objective: The single NIST SP 800-171A objective for 3.8.9 asks whether backup CUI is protected at storage locations, and the assessor tests this against final evidence.
- Independence: The assessor cannot have helped design the controls it tests in a way that compromises its impartiality, so the implementation partner must stay out of the assessment decision.
- Testing method: Expect interviews, examination of procedures and configurations, and testing of backup mechanisms, with records checked against actual storage locations.
- Scoring effect: MP.L2-3.8.9 is a 1-point requirement, so a partial result may be handled through a POA&M only where the scoring rules allow it.
- Contract and SPRS: Self-assessment results are posted through SPRS, and the Affirming Official signs them.
Ask prospective assessors how they handle evidence that is still in draft and how they will test restores.
Where backup confidentiality usually fails an assessment
Assessors testing MP.L2-3.8.9 look for one thing: whether backup CUI stays confidential wherever a copy lives. The gaps below cluster around backups nobody inventoried, copies that leave controlled storage unprotected, and paperwork that cannot prove the controls worked. Each card names the gap and the step that closes it.
Backups outside the inventory
Ad hoc scripts, cron jobs and staff laptops often hold copies of CUI that never appear in the system inventory or the system security plan. An assessor who finds one copy you did not list will question every other backup claim. Close the gap by scanning for backup jobs on servers, workstations and endpoints, then recording each storage location, owner and data class in the inventory. Ask whether any backup runs from a personal device or a tool nobody administers.
Unencrypted drives and tapes sent offsite
External drives, tapes and removable disks that leave the facility are a common failure because they often ship in plain form. Check whether each physical backup is encrypted with FIPS-validated cryptography, whether keys are held separately from the media, and whether custody records exist for every shipment. Physical safeguards alone rarely satisfy the objective for media that moves, so confirm encryption before the next courier pickup.
Cloud backup buckets without review
Cloud backup storage is frequently configured for convenience, with default encryption settings unverified and bucket access granted to broad service roles. Confirm that data is encrypted at rest with keys you control, that public access is blocked, and that the identities allowed to read or delete backups are reviewed on a schedule. Pull the bucket policy and access logs as evidence, because the console view alone will not show who can read the data.
Broad rights to catalogs and restores
The backup catalog lists every file that was backed up, and restore rights let someone pull those files back out, so both are confidentiality-sensitive even when the backup itself is encrypted. Limit the Director or backup administrator role to named people, separate restore approval from backup operation where practical, and log restore requests. A Bareos-style catalog or restic repository password held by many administrators is a finding waiting to happen.
Restore tests never documented
Assessors test the processes and mechanisms for conducting backups, and a backup that has never been restored tells them little about whether protection holds during recovery. Run restore tests on a schedule, record the date, scope, operator and result, and keep the restored data under the same access controls as production. Verification commands such as restic check with --read-data are useful here, but the written record of the test is what the assessor will request.
Draft or undated evidence
An assessment objective is met only when evidence is in final form, so a backup procedure marked draft, an unsigned security plan section or a log without dates will not count. Assign an owner to each backup document, version it under change control, and date every backup log and test record. Before the assessment, check that the backup storage locations listed in the plan match the locations in your logs and inventory.
Questions buyers ask about MP.L2-3.8.9
How much effort does protecting backups for CMMC take?
The effort depends on how many places hold backup copies of CUI and how many of those places already use encryption and access control. MP.L2-3.8.9 is a single assessment objective: the confidentiality of backup CUI must be protected at storage locations. In practice, the work is to find every backup location, encrypt the backup data at each one, restrict who can read or restore it, and secure the physical media. Tapes, external drives and removable disks need the most handling, because they leave the building and are easy to lose. Cloud backup and NAS devices usually need configuration work and access review rather than new hardware. The Assessment Guide lists encryption, access management and physical security as the ways to meet this, so each location needs at least one of them in place and documented.
How long does it take to secure backups for CMMC?
No fixed duration applies to every environment, and no published figure is used here. The timeline is driven mainly by the number of backup locations, the state of the existing backup design, and how quickly approvals and change windows move in your organization. A single backup server with one encrypted repository is a small job. A mix of tape rotation, office NAS units, laptop backups and several cloud accounts takes longer because each location needs its own encryption setting, key handling, access list and evidence. Ask any implementation partner for a written schedule tied to a defined list of locations, and ask what happens if the inventory turns up locations nobody expected.
What does an implementation need from our team?
The work needs four things from your side: read access to the asset and backup inventory, administrators who can change backup and storage settings, a named owner who can approve the approach, and a sign-off on how the backup controls are described in the System Security Plan. Without an accurate list of backup targets, the work cannot start, because an unlisted cloud bucket or a forgotten external drive will fail the assessment objective. Administrators need time to change encryption settings and access groups, often with a rollback plan and a maintenance window. The SSP owner must confirm that the written description matches what the systems actually do, since an assessor will compare the two.
Can our in-house team protect backups without outside help?
Yes, an in-house team can do this if it has staff who understand the backup platform, the storage devices and the encryption options, and if someone owns the evidence. The requirement does not call for specialist tools or outside staff. What outside help adds is an independent check of coverage, a second view on the inventory, and experience with how assessors read evidence. Many teams find that the hard part is not the encryption itself but finding every backup copy and keeping the list current as systems change. A partner can prepare the configuration and evidence, but your organization still owns the controls and the final documentation.
Is our backup software enough evidence for MP.L2-3.8.9?
No. A backup tool can produce useful evidence, but it cannot prove the requirement alone. SP 800-171A lists system backup procedures, the security plan, backup storage locations and backup logs or records as potential evidence, and it also calls for tests of the backup processes and mechanisms. A backup catalog or job log shows that jobs ran, not that the stored data is encrypted or that only authorized people can read it. Tools such as Bareos keep a catalog of backed-up files and restore on request, and restic's check command with read-data options can confirm that stored pack files are unmodified. Those outputs support the case, but you still need the encryption settings, access lists, storage location records and physical security records. Confirm with your assessor which artifacts they expect for each location.
Can a partner issue the CMMC assessment result for our backups?
No. A partner such as DeployOpen can plan the work, configure systems, collect evidence and prepare documentation, but it cannot issue an assessment result, report or certificate. For a Level 2 certification assessment, that role belongs to a C3PAO authorized or accredited by The Cyber AB. Self-assessments are performed by the organization itself. Your organization owns the controls and the statement of how they are met, and the independent assessor decides whether each objective is satisfied. Ask any partner to state this division in writing before work begins, and confirm current assessment timing with the Department of War, since the program schedule has changed in 2026.
How DeployOpen scopes and prepares backup evidence
DeployOpen plans and implements the backup platform for MP.L2-3.8.9 inside your own infrastructure, then prepares the encryption, access control and physical safeguards and the records an assessor will review. Your organization owns the control and the final evidence, and only an independent assessor can judge whether the requirement is met.
How we scope
- Written scope lists every backup location holding CUI, including tapes, external drives, NAS, servers and cloud backup.
- Scope records which backup jobs, catalogs and restore points contain CUI and who owns each one.
- Fixed-scope engagements agree deliverables and timelines in writing before any work starts, with ongoing support available as a retainer.
How we build
- Configure backup software such as Bareos to run documented backup, restore and verify jobs against the in-scope systems.
- Enable encryption for every backup repository, with keys held in a managed key store and access limited to named roles.
- Restrict physical and logical access to backup media and storage, and test restores and integrity checks before handover.
How we hand over
- Documented backup procedures, storage location inventory, and configuration baselines mapped to the single 3.8.9 assessment objective.
- Backup logs, restore test records and access review records kept in the form an assessor expects to see them.
- Handover walkthrough so your staff can run, verify and audit backups without depending on DeployOpen.
How we support
- Retainer options cover backup monitoring, upgrades to the backup platform, and periodic restore testing.
- Re-review of the backup scope whenever systems holding CUI change or a new storage location is added.
- Your organization decides which findings to remediate and keeps the assessment evidence current for the independent assessor.
