03.08.09 System backup: cryptographic protection guide

What 03.08.09 requires for CUI in backups and why it is easy to miss

03.08.09 asks you to protect the confidentiality of backup information and to apply cryptographic mechanisms that prevent unauthorized disclosure of CUI at every backup storage location. If a backup holds CUI, the copy is subject to the same confidentiality expectations as the production system, even though its purpose is recovery. The requirement sits in Rev. 3's media protection family, and it applies whether the backup lives on tape, in an on-premises repository, with a managed service or in a cloud bucket. The confidentiality risk is simple to describe and easy to overlook. A backup is a complete, portable copy of data that may have been protected by access controls and network boundaries in production, yet the copy often sits in a storage location with looser administration, a separate vendor or a different retention schedule. Rev. 3 keeps this requirement even though it leaves the contingency planning family out. NIST's reasoning, as shown in the source controls CP-9 and CP-9(8) from SP 800-53 Rev. 5, is that the family concerns availability, while this single control protects confidentiality. The Rev. 3 discussion points you to 03.13.11 (Cryptographic protection) for the mechanism itself, so the two requirements should be reviewed together.

The difficulty in practice is scope. Backup copies frequently fall outside the system boundary documented in the system security plan, which means an assessor may find encrypted-at-rest production storage alongside an unencrypted replication target that nobody listed. Start by inventorying every backup destination, including offsite copies, vendor-hosted repositories and removable media, and record for each one whether CUI reaches it and which cryptographic mechanism protects it. Confirm the exact determination statements and assessment objects in SP 800-171A Rev. 3 before you build the evidence list, since the assessment uses examine, interview and test methods, and the test method expects you to show the cryptographic mechanism working on the backup storage itself. Ask your backup vendor or open-source platform team to document where keys are generated, who holds them and how they rotate.

Which backup systems, storage locations and third parties fall under 03.08.09

Scope for 03.08.09 follows the copies of CUI, not the systems that create them. Each card below is a place where a backup copy of CUI may sit, or a party that may touch it, and each one needs a documented decision about whether it holds CUI and how it is protected.

Backup servers and media servers

The backup server runs the jobs that read production data and write it elsewhere, so it handles CUI in transit and at rest even when no one logs in to it. Treat it as in scope if any job it runs touches a system that holds CUI. Check whether the backup software can encrypt backup data before it leaves the server, and whether the encryption keys are stored on the same host that holds the backups.

Backup catalogs and job databases

A backup catalog lists file names, paths, sizes and dates. Those records can reveal CUI even when the file contents are encrypted, so a catalog that indexes CUI is itself in scope. Confirm whether the catalog database is encrypted, who can query it, and whether it is backed up with the data it describes.

Offsite, cloud and object storage

Offsite and cloud backup targets are the locations most often missed in scoping, because they sit outside the organization's data center. Each target that receives CUI must enforce cryptographic protection, and the organization must decide whether the provider's default encryption meets the requirement or whether client-side encryption is needed. Ask the provider where keys are held and who can access them.

Tape and removable media used for backups

Tapes, external drives and rotated disks that hold backup sets are system media containing CUI, so they fall under the media protection requirements as well as 03.08.09. Track which cartridges or drives hold CUI, confirm they are encrypted before they leave a controlled area, and make sure the keys needed to read them are stored separately from the media.

Backup administrator accounts

Administrators who can restore or export backups can read CUI without touching production systems, so their accounts and the keys they can reach belong in the scope. Confirm which roles can restore data, decrypt backups or change encryption settings, and whether those actions are logged and reviewed. Separate duties where one person should not hold both restore rights and key access.

Third-party backup providers

When a managed backup provider or colocation partner stores or processes CUI backups, the organization still owns the decision of what is protected and how. Put the cryptographic requirements, key custody and incident notification duties into the contract, and ask the provider for evidence of how backups are encrypted. Note that NIST places responsibility for SP 800-171 implementation and compliance on the federal agency that holds the contract.

How to implement cryptographic protection for CUI backups, step by step

This sequence takes a team from knowing which backups hold CUI to proving that those backups stay confidential at rest, with keys held apart from the data and restores tested under encryption. Each step produces a record an assessor can examine.

Confirm which backups fall in scope
Before choosing any tool, the organization confirms which backup jobs, snapshots and replicas hold CUI or copies of systems that do. Ask the federal contracting office or your system security plan owner to confirm the CUI boundary, then trace every backup job, target and offsite copy back to the systems inside it. Output: a scoped list of backup jobs and storage locations, signed off by the system owner. Do not start tool selection until this list is agreed, because it determines which locations need encryption.
Inventory backup storage locations and their controls
For each in-scope job, record where the backup lands: on-premises disks, tape, a network share, a cloud bucket, a secondary data center or a third-party backup service. Note the access paths, administrators with access, retention periods and whether copies leave your control. Output: a location register that lists each store, its owner, the data it holds and any existing encryption. This register is what an assessor will compare against your backup configuration.
Set cryptographic expectations for each location
Write down what cryptographic protection means for each backup location, and link it to the requirement for cryptographic protection of CUI (03.13.11), which the Rev. 3 discussion of 03.08.09 points to. Define the approved algorithms and modules, the encryption scope (full backup data, catalogs and metadata) and who may decrypt. Confirm with your compliance lead which FIPS-validated mechanisms your contract requires. Output: a short cryptographic standard referenced from the backup procedure.
Select encryption at each backup location
Choose the encryption layer that fits each location: encryption in the backup software, encryption in the backup repository, or encryption at the storage layer. Bareos can run backup, restore and catalog jobs under its own control, restic encrypts its repositories and offers verification, and Nextcloud server-side encryption protects file contents at rest but does not encrypt file names or folder structure, so it cannot be the only control for metadata. Confirm each tool's encryption and FIPS status with the vendor or project before relying on it. Output: a selected mechanism per location and a configuration record.
Separate encryption keys from backup data
Keep decryption keys in a system that is separate from the backup media and its repository, so that stealing or restoring backup data alone does not expose CUI. OpenBao's transit secrets engine can hold and rotate versioned keys without storing the protected data, which supports a separation pattern when your chosen backup tool can use external key material. Define who can approve key creation, rotation and retirement, and how old key versions are kept available for restores. Output: a key management record showing key owners, rotation procedure and location of key custody.
Configure and run encrypted backup jobs
Apply the chosen settings to each in-scope job and run it on the production schedule. Check the configuration files, job definitions and repository settings against the cryptographic standard from step three, and capture screenshots or exported configuration as evidence. For restic, confirm the repository was initialized with encryption and run integrity checks, including data reads with --read-data or --read-data-subset, so the stored backup data is confirmed unmodified. Output: configuration exports and check logs for each job.
Test encrypted restores and record the results
Restore representative files and full systems from encrypted backups into an isolated environment. Confirm the restored data is readable, matches the source, and that the restore worked with the key versions currently in custody and with older versions still in retention. Include a restore from the offsite or secondary location. Output: dated restore test records with the operator, scope, result and any defects, which feed the contingency plan and assessment evidence.
Document the contingency plan and backup procedures
Write the contingency planning procedures that describe the backup jobs, locations, encryption settings, key custody and restore tests. Link them to the system security plan and the incident response plan so that a lost key or compromised repository has a defined response. Assign owners for each procedure and set the review cycle with the system owner. Output: approved procedures and a plan that an independent assessor can examine against the two determination statements in SP 800-171A Rev. 3 for 03.08.09.

How an assessor tests 03.08.09 under SP 800-171A Rev. 3

This table shows how an assessor applies the two determination statements for 03.08.09 under SP 800-171A Rev. 3, row by row across examine, interview and test objects. Read each row as evidence the assessor will ask for, and the common findings column as the gap that most often causes the requirement to fail.

Assessment object	Method and what the assessor checks	Evidence to have ready	Common finding
Contingency planning policy and procedures	Examine: whether the organization-defined policy covers protecting backup confidentiality and the cryptographic controls applied to backups	Approved contingency planning policy with a named owner, review date and backup encryption scope	Policy is silent on backup encryption, so encryption depends on individual administrators
Procedures for system backup	Examine: whether backup procedures require encryption before data reaches backup storage and define key handling	Written backup runbooks showing the encryption step, job schedules and restore steps	Runbooks describe the backup job but never mention encryption or the storage location
Contingency plan	Examine: whether the plan identifies backup systems and storage locations that hold CUI and how they are protected	Contingency plan listing each backup target, its location and its encryption method	Offsite or cloud backup copies appear in the plan's inventory but not in the encryption section
System design documentation	Examine: whether the design shows where cryptographic protection is applied to backup information and where keys are held	Architecture diagrams with backup flows, encryption points and key custody boundaries	Diagram shows the backup server but not the encrypted copy sent to secondary storage
System configuration settings	Examine: whether backup software, storage and key settings enable cryptographic protection as documented	Exported backup job configurations, repository encryption settings and key management settings	Configuration shows encryption enabled on the primary repository but not on the replica
Personnel with system backup responsibilities	Interview: whether operators can explain how backups are encrypted, where keys live and how a restore is authorized	Named operator list, training records and a walkthrough of one backup and restore	Operators cannot say whether the backup target is encrypted and defer to a vendor default they have not verified
Personnel with information security responsibilities	Interview: whether security staff monitor backup encryption and respond when a backup target is unencrypted	Monitoring or review records showing backup encryption checks and exception handling	Security staff assume backups are covered by full-disk encryption on the backup host, which may not protect copies in transit or in cloud storage
Mechanisms for cryptographic protection of backup information	Test: whether the encryption mechanism protects backup data at storage locations and prevents unauthorized disclosure	Test results showing an encrypted backup can be read only with the authorized key, plus a sample of stored backup files confirmed as encrypted	Keys stored beside backups on the same volume, so anyone with backup media can decrypt them

Which evidence shows that CUI backups are encrypted and recoverable

An assessor testing 03.08.09 wants proof on two fronts: that backup copies of CUI are protected cryptographically at every storage location, and that those copies can actually be restored. The artifacts below cover both, and each one goes stale unless it is refreshed on a schedule between assessments.

Backup policy and contingency plan sections

The written policy should state which systems back up CUI, where the copies go, which encryption applies at each storage location, and who holds the keys. The contingency plan should reference the same backup procedures and restore objectives. Assessors compare these documents against the running configuration, so any mismatch between the paper and the system becomes a finding. Review both documents at least once a year and after any change to backup storage.

System design diagrams of backup flows

A current diagram should show every path CUI takes into backup, including the backup server, catalog database, offsite or cloud repositories and any replication links. Mark where encryption is applied on each hop and where keys are held. Assessors use the diagram to decide which storage locations to test, so an unlabeled copy outside the diagram is a common gap. Regenerate the diagram whenever a storage target is added or moved.

Configuration exports showing encryption settings

Export the backup and storage configuration on a fixed schedule and keep the dated files. For example, a repository setting or a server-side encryption flag should appear in the export with its value and the date it was captured. Compare each export with the previous one to show that encryption was never silently disabled. Store the exports in a location that backup administrators cannot edit.

Key management records

Keep records showing who created, stored, rotated and retired each encryption key used for backups, and where each key is held. Versioned keys with a rotation history give an assessor a clear trail, while keys stored beside the data they protect raise a question about the cryptographic protection. Confirm the key management approach with your assessor and check that records match the keys the systems are actually using. Link this card to the key management requirement in 03.13.

Restore test records

Encryption proves little unless encrypted backups restore. Record each test with its date, the backup set used, the storage location, the person who ran it, and the result, including whether decryption succeeded. Use a sample that includes each storage location, not only the most convenient one. Run tests on a schedule that your own contingency plan sets, and keep the failed tests along with the fixes.

Access records for backup administrators

Maintain a current list of accounts that can administer backups, restore data or read encryption keys, along with the approval for each grant and logs of their use. Assessors check that key access is limited to the people who need it and that changes to backup roles are traceable. Review the list at each access review cycle and remove accounts for people who changed roles or left. Logs from the backup server should flow into the central audit trail.

Why 03.08.09 changed from Rev. 2 requirement 3.8.9 and what CMMC scores it

NIST's change analysis traces 03.08.09 back to Rev. 2 requirement 3.8.9 and classifies the change as significant, meaning the Rev. 3 wording adds more detail and foundational tasks rather than simply renumbering the old text. The practical consequence is that a backup encryption design which satisfied 3.8.9 in an earlier assessment may not answer every element of the Rev. 3 statement. Before you rely on an existing backup design, compare its documented scope, key handling and verification steps against the two determination statements in SP 800-171A Rev. 3 for 03.08.09, and confirm with your contracting officer which revision your contract cites. The change analysis workbook is the place to see the mapping line by line.

The scoring side is still anchored to Rev. 2. CMMC Level 2 assesses 3.8.9 as MP.L2-3.8.9, and under the scoring methodology in 32 CFR 170.24 that practice is worth 1 point. A single point is small, but an assessor who finds backup media or a backup repository holding CUI without cryptographic protection will record a gap against that practice, and the same gap can affect how the system security plan describes your backup architecture. Confirm the current scoring rules with the eCFR text for 32 CFR 170.24 before you plan remediation, since the weight of a practice is the number a sponsor will read first.

Because the DoW class deviation names Revision 2 explicitly, DoD contractors are currently assessed against the 110 Rev. 2 requirements, and the 3.8.9 wording in the contract governs what you must demonstrate. Read the Rev. 3 text as a guide to the depth of evidence an assessor may expect, not as a substitute for the Rev. 2 requirement the contract cites. A practical approach is to document one backup encryption design that answers both the Rev. 2 requirement and the Rev. 3 determination statements, so that a future move to Rev. 3 under the proposed FAR rule does not force a second rewrite. Ask your contracting officer or sponsor in writing which revision and which ODP values apply to your contract.

Which open-source backup and encryption tools can produce the evidence

Bareos is a backup system licensed under AGPL-3.0-only. Its Director schedules and supervises backup, restore, verify and archive jobs, and keeps a SQL catalog of the files it has backed up. That catalog is useful evidence for an assessor because it records what was backed up and when, and it allows restores of files selected from the current backup or from a backup taken before a given date and time. For 03.08.09, the question is not only whether backups run but whether the backup data is protected. Bareos job and storage configuration determines where encryption is applied, so the configuration itself is part of the evidence.

Job records: The catalog shows which jobs ran, their schedules and their outcomes, which supports the examine method.
Restore testing: Restores of selected files from a dated backup can be recorded as test evidence.
Catalog protection: The SQL catalog holds metadata about CUI backups and needs the same access controls and protection as the backups.
Storage encryption settings: Confirm whether encryption is configured on the storage daemon or the destination media and document the setting.
Configuration evidence: Keep Director and storage configuration files under change control as system configuration settings.

Confirm with the Bareos documentation and your own configuration whether the encryption options you rely on meet your cryptographic module requirements before you describe them in a system security plan.

restic is a backup tool licensed under BSD-2-Clause. Its repositories store backup data in encrypted form, and its check command verifies the structural consistency of snapshots, trees and pack files. With the --read-data or --read-data-subset options, check reads pack files back to confirm that the stored backup data is unmodified. This gives an assessor a repeatable test that goes beyond confirming that a backup job finished, which is the kind of evidence the test method for 03.08.09 looks for.

Encrypted repository: Repository encryption is the core control for backup confidentiality at the storage location, so record the repository settings and the key handling procedure.
Scheduled integrity checks: Run restic check --read-data-subset on a schedule and retain the output as evidence.
Full read verification: Use --read-data at defined intervals to read all pack files and retain the results.
Password and key custody: Document where repository passwords or keys are stored, who can access them and how they are rotated.
Restore evidence: Keep records of test restores that show the encrypted repository is usable.

Confirm with the restic documentation whether its encryption design and any cryptographic primitives meet the cryptographic module requirements that apply to your contract, because a tool's design does not by itself establish validated module status.

What meeting 03.08.09 costs in money and effort

This table breaks down the cost components of encrypting backups for 03.08.09, who is paid for each, whether it is one-time or recurring, and what drives it up or down. Use it to structure a written quote so that each line item can be compared across suppliers. No prices or durations are given because none were supplied for this requirement.

Cost component	Who is paid or who bears it	One-time or recurring	What drives it and what to ask for in a quote
Backup platform licenses	Software vendor, if a commercial product is chosen; none for the open-source tools named here	Recurring if a commercial product or support contract is used	Confirm whether any support contract applies to Bareos, restic or the key management component. Ask the quote to state which tools carry license or support fees.
Engineering time for encryption and key management	Internal staff or implementation partner, under a fixed-scope agreement	One-time, with later changes	Driven by the key management approach (server-held keys, transit encryption, or externally managed keys) and the number of backup tools. Ask for the design, configuration steps and acceptance tests in the scope.
Storage for encrypted copies	Cloud provider, data center or hardware owner	Recurring	Driven by data volume, retention period and the number of storage locations. Ask the quote to show assumed volume, retention and copies per location.
Restore testing time	Internal backup or operations staff, or a partner	Recurring	Driven by how often encrypted backups are restored and verified and how much data each test covers. Ask for the test schedule and what each restore test must prove.
Evidence upkeep	Internal compliance or security staff	Recurring	Driven by how many records the assessor samples, such as key rotation logs, backup job reports and configuration exports. Ask how evidence is collected and retained.
External testing or review	Independent assessor or security testing provider	Periodic	Driven by whether the review covers only the encryption design or also restore and key handling. Ask for the review scope and what is delivered.
Auditor sampling and assessment	Independent assessor or DoD assessment body, as applicable	Periodic	Driven by the assessment type and the number of backup locations in scope. Confirm the assessor's fees and sampling approach directly with them, as these are outside the implementation quote.

Where organizations fall short on backup encryption and how to close each gap

Backup encryption usually fails at the edges: the plan that never mentions backups, the key sitting next to the data it protects, and the copy that leaves the building unencrypted. The cards below pair each gap with the check that closes it, so the evidence an assessor asks for exists before the assessment begins.

Backups missing from the system security plan

Many organizations encrypt the production systems carefully but never describe the backup platform, its storage targets or its data flows in the system security plan. Under 03.08.09, an assessor will compare the backup architecture with the documented boundary and ask where CUI is copied. Closing action: list every backup server, catalog, repository and offsite target in the system security plan, with the encryption method used at each location.

Encryption keys stored with the backup

A backup encrypted with a key kept on the same server or inside the same repository protects very little, because anyone who copies the backup can often copy the key too. Assessors look at where key material lives and who can reach it. Closing action: store backup keys in a separate key management system or a sealed vault, restrict read access to named roles, and document the recovery path for the keys.

Unencrypted offsite and tape copies

Organizations often encrypt the primary backup repository and then replicate it to a cloud bucket, a secondary site or tape without confirming that the copy is encrypted too. Each copy is a storage location holding CUI and falls within the requirement. Closing action: inventory every replica, rotation and tape set, confirm encryption on each one, and record the result in the configuration evidence.

Restores that have never been tested

Encryption that has never been used to restore data may hide a broken key, a missing passphrase or a repository that cannot be read. Assessors commonly ask for evidence that restores work, not only that backups run. Closing action: run a scheduled restore of an encrypted sample set into an isolated environment, verify the content, and keep the job log and the result as evidence.

Backup administrators without documented access

Backup software typically gives its operators read access to every protected system, which makes them a high-value group. If their access is not documented, the organization cannot show who could decrypt CUI from a backup. Closing action: name the backup administrators and key custodians in writing, tie their access to individual accounts with multi-factor authentication, and review that list on a set schedule.

Procedures that disagree with configuration

A backup procedure may say that all repositories are encrypted while the configuration file shows an exception for a legacy job or a test system. Assessors compare written procedures with the settings they can inspect, so any mismatch becomes a finding. Closing action: reconcile the backup procedure with the exported configuration, test the settings on a sample of jobs, and assign an owner to review both documents together after each change.

Who owns 03.08.09: your team, an implementation partner and the auditor

Your organization owns the control. Under the federal contract or agreement, the contracting agency holds the responsibility for how SP 800-171 is applied and for any compliance issues, so the decisions that define the control sit with you. Your team decides which backup sets contain CUI, where they are stored, who may restore them, and how long they are retained. It also holds the encryption keys or controls the key custody arrangement, because a backup encrypted with keys the backup provider controls does not give you the confidentiality the requirement asks for. Your system security plan must describe the backup design and name the owners of each step.

Backup scope: Identify every system, database and file share whose backups include CUI, and record that scope in the system security plan.
Key custody: Decide who generates, stores, rotates and recovers backup encryption keys, and document the break-glass process.
Procedures and policy: Approve the contingency planning and backup procedures that an assessor will examine.
Restore testing: Run and record restore tests, since the team that depends on the backups must be able to show they work.
Vendor and cloud decisions: If a cloud provider or external service hosts backups, your team remains responsible for what that provider can read.

Before any outside party touches the design, confirm with your contracting officer which backup responsibilities the agreement assigns to you.

Questions buyers ask about 03.08.09 cost, effort and outside help

How much effort does encrypting CUI backups take?

The effort depends on how many backup systems hold CUI, how many storage locations receive those backups, and whether the encryption keys are already managed centrally. No supplied figure sets a duration, so ask for a scope-based estimate rather than a generic number. Work usually falls into three parts: identifying every place CUI is backed up, choosing and configuring cryptographic protection for each backup target, and producing configuration and key-handling records an assessor can examine. Teams with few backup platforms and an existing key management service generally have less to do than teams with many backup stores and no central keys. Ask any provider to break its quote into those parts.

Can an open-source backup stack meet 03.08.09 on its own?

Open-source tools can provide the cryptographic protection, but they do not meet the requirement by themselves. The organization must still define the backup policy, scope which backups contain CUI, document the contingency plan, and show that encryption is enabled and working at every backup storage location. For example, Bareos schedules and supervises backup jobs and keeps a catalog of backed-up files, while restic uses encrypted repositories and its check command can read pack files back to confirm stored data is unmodified. Confirm each tool's encryption behavior, key handling and version against its current documentation in your own environment before relying on it.

What does the internal team need to contribute?

The internal team owns the controls, so it must supply decisions and knowledge that an outside partner cannot make for it. That includes naming which systems and data sets contain CUI, approving the backup policy and retention periods, deciding who holds key custody, and confirming who is responsible for backup and information security. Staff also need to be available to answer interview questions, since the assessment procedure for 03.08.09 includes interviews with people who run system backups and people with information security responsibilities. An implementation partner can prepare configurations and evidence, but these decisions remain with the organization.

How long does a fixed-scope implementation take to agree in writing?

DeployOpen agrees scope, deliverables and timelines in writing before work starts, and most engagements are fixed-scope. No duration is given here because the timeline follows from the systems, storage locations and evidence in scope. To get a usable schedule, ask for a written scope that lists each backup platform, each storage target, the key management approach, the evidence to be produced, and the points where the internal team must provide input. A written timeline should tie back to those items so changes to scope can be priced and dated.

Does 03.08.09 depend on the Rev. 2 or Rev. 3 contract clause?

The requirement sits in both revisions, but the contract clause that applies depends on the agreement and the current DoD guidance, not on the requirement text itself. In Rev. 3, 03.08.09 is an exception drawn from the contingency planning family to protect backup confidentiality. Under Rev. 2, the same concern appears as requirement 3.8.9, and CMMC Level 2 still uses Rev. 2 and scores it as one point under the 32 CFR 170.24 methodology. A DoW class deviation dated 3 September 2026 names Rev. 2 explicitly, while a FAR proposed rule would point to Rev. 3. Ask the contracting officer which revision governs your contract before scoping work.

Who issues the assessment result for 03.08.09?

Only an independent assessor or the relevant government body issues an assessment result. DeployOpen prepares systems, configurations and evidence for assessment, but it does not issue reports, attestations or certifications. For DoD contracts, the result is typically a Basic Assessment that the organization self-scores and submits to SPRS, or a DCMA DIBCAC assessment, depending on the contract. Confirm with the contracting officer which assessment applies, and ask any partner to state clearly what it prepares and what it does not sign.

What should be included in a quote for this work?

A useful quote separates one-time work from recurring costs and states what each item covers. Ask for the written scope, the list of backup systems and storage locations in scope, the cryptographic approach for each, the key management design, the evidence package, and the handover to the internal team. Also ask which items are fixed and which depend on information the organization has not yet provided, and whether ongoing support or upgrades are priced separately as a retainer. Ask who performs interviews, testing and document review, since those activities feed the assessment. DeployOpen does not publish a price list, so a quote follows from the written scope.

How DeployOpen scopes and prepares 03.08.09 evidence

DeployOpen works on 03.08.09 System backup: cryptographic protection as an implementation and readiness partner inside your own infrastructure. We help you define the backup systems that hold CUI, put cryptographic protection in place on those backups, and assemble the evidence an assessor will examine, while your organization owns the control and an independent assessor reaches the findings.

How we scope

Identify every backup system, repository and storage location that holds CUI, including off-site and cloud copies.
Confirm which backup tools, key stores and encryption mechanisms are in use and how they are configured today.
Agree the written scope, deliverables and timeline with you before any work begins, since engagements are fixed-scope.

How we build

Configure backup platforms such as Bareos or restic so that backup data is encrypted before it reaches storage locations holding CUI.
Integrate key management, for example with OpenBao transit or Nextcloud server-side encryption where those fit your design, and document key ownership and rotation.
Test restores and integrity checks, such as restic check with read-data options, to confirm encrypted backups can be recovered and verified.

How we hand over

Deliver configuration records, backup policy and procedures, and the contingency plan sections that describe CUI backup handling.
Document system design and configuration settings that an assessor will examine for the two determination statements in 03.08.09.
Walk your backup, security and compliance staff through the evidence so they can answer interview questions about the control.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after handover, if you want help keeping the backup configuration current.
Re-verify encryption and restore testing after platform upgrades or changes to backup storage locations.
Confirm with your assessor and your contracting officer which assessment method and requirement version apply to your engagement before final evidence is packaged.