SC.L2-3.13.16 Data at rest: requirements and evidence

What SC.L2-3.13.16 data at rest requires in plain terms

If your organization handles controlled unclassified information, CUI is probably sitting on more places than your architecture diagram shows: file servers, laptops, USB drives, backup sets, mobile phones and archived email. SC.L2-3.13.16 asks that the confidentiality of CUI at rest is protected, and an assessor will work through each of those copies and ask what protects it. The single assessment objective in NIST SP 800-171A for this requirement is written at that level of generality, so the test is whether you can show a protection for every stored location, not whether you encrypted a particular disk. Encryption is the approach most organizations pick, but the CMMC Assessment Guide Level 2 states that it is not mandatory. Physical security or other technical protections can satisfy the objective. Where you do use cryptography, however, SC.L2-3.13.11 applies and the modules must be FIPS-validated, so a strong algorithm alone does not close the gap.

The weight of this requirement is low. Under 32 CFR 170.24 it is worth 1 point out of 110 total requirements. Because it is a 1-point requirement that is not on the exclusion list in 32 CFR 170.21, it can go on a plan of action and milestones if your score is at least 88 of 110 (0.8), with closeout due within 180 days. Do not read that as a shortcut. A POA&M item still has to be closed on time, and an assessor will expect the closeout evidence to exist. The check to run now is whether you have a written list of every location where CUI rests, along with the protection applied to each. Confirm the current POA&M rules with your contracting officer and the eCFR text before relying on them, because the CMMC timeline changed after the rule took effect.

The hard part is almost never the encryption setting. It is the inventory. CUI migrates into shadow copies, exports, email attachments, cloud sync folders, developer workstations and backup catalogs that nobody listed when the system security plan was written. Start by tracing the data flows from your CUI boundary outward, then list each storage type: server volumes, databases, endpoint disks, removable media, mobile devices, cloud storage and backup repositories. For each one, record the protection (full disk encryption, server-side encryption, physical control or a documented exception) and the key or access custody behind it. Open-source tools such as Nextcloud server-side encryption and the Bareos and restic backup tools can produce part of this evidence, but they only cover what you point them at, and an assessor will test the inventory itself.

Which systems, media and third parties fall under data at rest

Data at rest is assessed wherever CUI is stored, not only in the primary system. The cards below cover the storage locations that most often hold CUI, and each one names a scoping decision that changes how much work the assessment requires.

Servers and file shares

Start with the systems that hold CUI as their main job: application databases, document repositories and shared folders on file servers. Confirm which volumes and directories contain CUI, and record the storage layer that protects each one, such as full-disk encryption, database encryption or server-side encryption in a self-hosted file platform. Where encryption is used, the cryptographic module must be FIPS-validated, so check the module certificate for each component rather than the algorithm name alone. Note which folders are excluded from encryption and why.

Endpoints and laptops

Laptops and workstations often hold local copies of CUI in downloads, sync clients and email caches, even when the primary store is in the cloud. Decide whether those endpoints are inside the assessed boundary, and whether the organization will allow CUI to sit locally at all. If local copies are permitted, the endpoint encryption and device management settings become part of the evidence. Ask the endpoint team to produce a report of enabled disk encryption across the fleet, and treat any unmanaged device that touches CUI as a scoping question.

Mobile devices

Phones and tablets that open CUI through mail or file sync create storage that is easy to forget. Determine whether CUI is cached on the device or only viewed through a managed container, because the answer decides whether device-level encryption and remote wipe are part of the at-rest evidence. Confirm that device management enforces encryption, that the policy applies to every enrolled device, and that personal devices enrolled under a bring-your-own model are either excluded from CUI access or brought into scope.

Removable and shared media

USB drives, external disks, optical media and shared network media are the storage most likely to leave the building. Decide whether portable storage may hold CUI at all. Where it may, require encryption for the media itself and keep a register of which devices hold CUI and who is responsible for them. Media that is retired, reused or sent for repair needs a sanitization step, and that step should appear in the same evidence trail as the encryption record.

Backup repositories and archives

Backups are the most common scoping surprise. A backup set that contains CUI is CUI at rest, so it needs the same protection as the source system, even when no one browses it day to day. Decide whether backups fall inside the assessed boundary, then confirm that the backup repository is encrypted with keys that are managed and rotated under the key management process. Tools such as Bareos and restic can produce job records and integrity checks that serve as evidence, but the organization must confirm the encryption setting and key custody itself.

Cloud storage operated by providers

When CUI sits in storage run by a cloud or SaaS provider, the first question is whether that service is inside the assessed boundary and whether the provider's environment meets the requirements that apply to it. Confirm where the data is stored, who holds the encryption keys, and what the provider's own assessment evidence covers. Customer-managed keys and provider-managed keys lead to different evidence and different responsibilities, so the contract and the configuration both need review before the scope is fixed.

How an assessor tests data at rest protection

This table walks through how an assessor tests the single SP 800-171A objective for SC.L2-3.13.16, row by row, from document review to interviews and configuration testing. Read it as a checklist: each row names what the assessor examines, what you should have ready, and where findings usually appear.

Test activity	What the assessor examines	Evidence to have ready	Common finding
Examine procedures	Written procedures for protecting CUI at rest, checked for scope, approval and whether they describe current practice	Final, approved procedures with version history and an owner; dated approval records	Drafts or unsigned procedures presented as final, so the requirement is not met
Examine the CUI location list	Whether the list of information at rest that needs confidentiality protection covers every store that holds CUI	A current inventory of CUI repositories, including servers, laptops, removable media, backups and cloud storage	Outdated CUI location list that omits new file shares, laptops or backup targets
Examine cryptographic mechanisms	Which mechanisms protect data at rest, and whether their configuration documentation matches the deployed settings	Configuration documentation for disk, database and file encryption, including algorithms, key storage and enablement scope	Documentation describes encryption that is not enabled on every system in scope
Examine physical and other safeguards	Where encryption is not used, whether physical or other technical protections are documented and effective	Written rationale and controls for each unencrypted location, such as locked storage or access logs	Physical safeguards claimed without records showing they are applied
Interview administrators	Whether system administrators can explain how CUI at rest is protected and where keys are held	Named administrators available for interview; a short walkthrough of the encryption setup for each system type	Administrators unaware of encryption settings on endpoints or unsure which systems hold CUI
Test configurations on sampled systems	Encryption status on a sample of servers, workstations, laptops, mobile devices and removable media	Screenshots or command output showing encryption status, plus the sampling list the assessor selected	Encryption enabled on servers but not on laptops or mobile devices
Verify cryptographic module validation	Whether any encryption used to protect CUI at rest relies on a FIPS-validated module, as SC.L2-3.13.11 requires	Module certificate numbers and the configuration that enables FIPS mode; confirm current validation status with the vendor	Approved algorithm in use without a validated module, which the assessor may treat as not met
Review backup and media protection	Whether backup repositories and archived media holding CUI are protected at rest	Backup encryption settings, repository configuration and records of media handling	Backups stored unencrypted on network shares or offsite media

Implementing data at rest protection step by step

This sequence turns SC.L2-3.13.16 from a policy statement into a documented, verified state: every location holding CUI is known, each one has a chosen safeguard, cryptography is validated, and evidence exists for an assessor to test.

Inventory every location where CUI rests
Start by listing each drive, server volume, database, backup set, removable medium, laptop, phone and cloud storage bucket that holds CUI at rest, including copies made by sync clients and collaboration tools. The organization owns this list, and the system owner signs off on it. Done means a CUI storage register exists with each location, its owner, the data types it holds and the system boundary it falls within. An assessor will compare this register against what they find on the systems, so gaps here surface later.
Choose the safeguard for each location
For each entry in the register, decide whether the protection will be cryptography, physical control, or a combination. Encryption is one approach to protecting CUI at rest, not a mandatory one, so the decision should be recorded with its reasoning, for example that a sealed data center rack is protected physically while a laptop that leaves the building needs full-disk encryption. Output: a decision table mapping each location to its safeguard, the accountable owner and any compensating controls. Ask your consultant or internal team to confirm that each physical safeguard can be demonstrated, not only described.
Configure cryptography and validate it against SC.L2-3.13.11
Where encryption is chosen, configure it on each platform and confirm that the cryptographic modules are FIPS-validated, not merely that the algorithm is approved. Record the module name, validation status and the configuration keys used. Platform documentation, such as the Nextcloud encryption configuration guide, explains what server-side encryption protects and what it leaves exposed, including file names and folder structure, so those gaps must be addressed by another safeguard or documented as accepted risk. Output: a configuration baseline for each encrypted location with validated module references.
Document key handling with SC.L2-3.13.10 in mind
Encryption is only as strong as its key management. Document who generates, stores, rotates, backs up and retires each key, and where the keys live relative to the data they protect. Where a secrets management service is used, such as OpenBao's transit secrets engine with versioned keys and rotation, record the key versions in use, the rotation procedure and access restrictions. Output: a key management procedure and a key inventory that an assessor can trace from each encrypted location back to its key owner. Confirm with the vendor how the platform behaves when keys are lost, since that determines recovery planning.
Protect backups and removable media
CUI frequently persists in backups and portable media after it has left its primary location, so these copies must appear in the register and receive the same safeguard decision. For backup tooling such as Bareos, confirm that the catalog and stored volumes are encrypted or physically protected, and that restores are tested. For restic repositories, the check command with read-data options can confirm that stored pack files are unmodified. Output: a backup protection record listing each backup target, its encryption or physical control, and the date of the most recent verification run.
Verify settings on each system and record results
Test each location against its configuration baseline. Check that encryption is active on the volume or application, that the module reported in the baseline is the one running, that key access is limited to the documented roles and that physical safeguards are in place. Capture the output, such as configuration exports, command results and dated screenshots, and keep the record in final form, since an assessor will not accept drafts as evidence. Output: a verification record per system with the tester, date and any deviations raised as findings.
Maintain the baseline and re-verify after change
Data at rest protection degrades when systems are added, migrated or upgraded without updating the register. Tie the storage register and configuration baseline to change control, so each new storage location or key change triggers a documented verification. Schedule periodic re-verification with a named owner, and feed deviations into the system security plan and any plan of action. Output: a change-linked update log and a current verification record, which together show the protection is maintained between assessments.

Evidence that satisfies data at rest and how to keep it current

An assessor testing SC.L2-3.13.16 will ask to see where CUI lives at rest and how that storage is protected. The cards below cover each artifact that answers those questions, and how to refresh it so it still matches the environment when the assessor arrives.

CUI storage location list

This is the starting point for the assessment objective. List every drive, volume, database, backup target, removable medium and mobile device that holds CUI, and tie each entry to the system boundary and the owner. Assessors compare this list against scans, asset inventories and the system security plan, so gaps show quickly. Refresh it when a system is added, a cloud bucket is created, or a device is retired, and record the date of each review. Confirm the list covers copies made by backups, logs and analytics exports, since these are commonly missed.

Protection procedures in final form

Assessors look for written procedures that say how information at rest is protected, who runs each step and how exceptions are handled. Drafts do not count toward a MET finding, so the approved version and its approval record must be the ones assessors see. Each procedure should name the protection method for each storage type, whether encryption, physical safeguards or both. Review the document after any change to storage platforms and keep prior versions to show history.

Encryption configuration exports

Where encryption is used, the assessor expects configuration evidence showing that it is turned on for the CUI stores in scope. Export the relevant settings from each platform, such as server-side encryption options, volume encryption status and storage bucket policies, and time-stamp them. For example, a Nextcloud instance using server-side encryption should show the encryption module enabled, with a note that file names and folder structure are not encrypted. Re-export after upgrades or migrations, because defaults change between releases.

FIPS validation records

SC.L2-3.13.16 requires FIPS-validated cryptography wherever encryption protects CUI at rest. Keep the certificate number, module name, version and validation status for each cryptographic module in use, and map each one to the storage system that calls it. An approved algorithm alone is not enough. Check the validation status before each assessment, because validation certificates change status over time, and record the configuration that makes the module run in its validated mode.

Device encryption and sanitization reports

Laptops, phones, tablets and removable media that hold CUI need evidence of full-disk or media encryption, usually a report from the endpoint management tool showing encryption status per device. Pair that with sanitization or disposal records for media retired, reused or returned, showing the method used and the person who witnessed it. Reconcile the device report against the asset inventory each refresh cycle, and flag any device that reports unencrypted or is missing from the inventory.

Backup encryption settings and restore tests

Backups are copies of CUI at rest, so the assessor will ask how they are encrypted and who holds the keys. Export the backup job settings showing encryption is enabled, and record where the keys are stored and who can access them. OpenBao's transit engine can supply versioned keys with rotation for application data, and restic checks with --read-data can confirm stored data is unmodified. Keep a restore test record with the date, scope and result, and repeat it after key rotation or backup platform changes.

What meeting data at rest protection costs

This table breaks down the cost components of meeting SC.L2-3.13.16 by who is paid, whether the cost is one-time or recurring, and what drives it up or down. No fee figures are supplied for this requirement, so use the rows to structure your quote requests and to see where open-source tooling removes license spend but not labor.

Cost component	Who is paid	One-time or recurring	What drives it
Encryption tooling and licenses	Software vendors, or no license fee for self-hosted open-source platforms	Often one-time setup, with recurring support or subscription fees where a vendor is used	Number of storage locations and whether a commercial product or open-source platform is chosen
FIPS-validated module selection	Internal staff or an implementation partner for research and confirmation	One-time, with re-checks when versions or modules change	Whether the platform's cryptographic module holds a current FIPS validation that matches the deployed version
Inventory and configuration engineering	Internal engineers or an implementation partner	One-time for the initial inventory and configuration, then recurring for changes	Number of data stores, endpoints, mobile devices, backup repositories and cloud buckets holding CUI
Key management and rotation setup	Internal engineers or an implementation partner	One-time build, recurring rotation and access reviews	Cloud versus on-premises hosting, and whether keys sit in a hardware or software-backed store
Evidence upkeep	Internal compliance staff or an implementation partner	Recurring, tied to each change in scope	Frequency of configuration changes, system re-verification cycles and the number of systems in the CUI boundary
External review	Consultants or independent reviewers, if engaged	Usually one-time readiness review, with optional repeats before assessment	Scope complexity and how many systems must be re-verified after changes
Assessor time	The C3PAO or assessor performing the assessment, where a certification assessment applies	One-time per assessment cycle	Number of storage locations and devices to sample, and whether evidence is in final form
Self-hosted open-source platform labor	Internal staff or implementation partner, not the software author	Mostly one-time build, with recurring operations and patching	Open-source licenses remove license spend, but hardening, backup and monitoring labor remains

Open-source tools that produce data at rest evidence

Four open-source tools cover different parts of protecting CUI at rest: file-level encryption, key handling, backup catalogs and backup integrity. Each one produces some evidence an assessor can examine, but none of them makes a system compliant by itself. The organization still decides what CUI is stored, which safeguards apply and how the configuration is documented.

Nextcloud server-side encryption

Nextcloud's server-side encryption protects file contents on local and external storage, with keys kept on the server. It does not encrypt file names or folder structure, so CUI-bearing names and paths remain visible to anyone with direct access to the storage backend. Record which encryption module is enabled, where keys are stored and how the storage is mounted. Confirm with the vendor whether the cryptographic module has FIPS validation, because the operator must establish that status for the specific build and configuration in use. Metadata stays readable unless other safeguards cover it.

OpenBao transit secrets engine

OpenBao's transit secrets engine encrypts and decrypts application data without storing that data, and it supports versioned encryption keys with key rotation. This lets a system keep data encryption outside the application and record who used which key version and when. Assessors will look for documented key life cycle procedures, rotation records and access policies. Confirm that the cryptographic primitives in use are backed by a FIPS-validated module, and document the operator's position on that point. Licensing is MPL-2.0, which carries file-level copyleft obligations to review with counsel.

Bareos backup jobs and catalog

Bareos's Director schedules and supervises backup, restore, verify and archive jobs, and keeps a SQL catalog of backed-up files. The catalog gives an assessor a record of what was backed up, when and from which client, and it supports restores from the current backup or from a point before a given date and time. Confirm that backup volumes are encrypted and that the catalog database and storage media are protected. Bareos is licensed under AGPL-3.0-only, so confirm how its network-facing components are used and whether your obligations change if you modify the software.

restic check with read-data options

The restic check command verifies the structural consistency of snapshots, trees and pack files. Adding --read-data or --read-data-subset reads pack files back to confirm that the stored backup data is unmodified. Run these checks on a schedule and keep the output, since the logs show that the stored CUI backups were tested for integrity and not only written. Note that restic is BSD-2-Clause licensed, which carries few restrictions. Confirm where repository encryption keys are held and who can access them, because a backup that cannot be decrypted provides no recovery path.

Who does what for data at rest: your team, a partner and the assessor

Your organization owns the requirement. It must know where CUI sits at rest, decide how each location is protected, and approve the procedures that govern that protection. No partner or assessor can make those decisions for you, and the assessment objective for SC.L2-3.13.16 asks whether the confidentiality of CUI at rest is actually protected.

CUI inventory: Maintain a current list of drives, databases, backup sets, removable media and mobile devices that hold CUI, and name an owner for each.
Protection decisions: Choose encryption, physical safeguards or a combination for each location, and record why. Encryption is not mandatory under the Level 2 assessment guide, so the rationale matters.
Final procedures: Write and approve the procedures for protecting information at rest, and make sure staff follow them.
Cryptographic ownership: Where cryptography is used, you own the module choice and its FIPS-validated status under SC.L2-3.13.11.
Evidence in final form: Keep signed, dated versions of the inventory and procedures, since drafts do not satisfy an objective.

Check that someone inside the company can answer, without notes, where CUI at rest lives and who approved its protection.

Common gaps in data at rest protection and how to close them

Most failed or weak SC.L2-3.13.16 findings come from a few predictable places: CUI that nobody inventoried, encryption that does not meet the FIPS bar, keys sitting next to the data, and paperwork that never left draft. Each card names the gap, the fix, and the evidence an assessor will ask to see.

CUI missing from the inventory

The assessment objective asks whether the organization knows where CUI at rest lives. Laptops used for contract work, personal devices, old file shares, email archives and forgotten backups are the usual omissions. Start from data flows: trace where CUI is created, received, processed and stored, then walk each location against the system boundary. The evidence is a current, dated list of CUI storage locations with an owner for each, reconciled against the system security plan. Ask whether anyone has checked endpoints outside the managed fleet.

Encryption without FIPS-validated modules

Turning on encryption does not by itself satisfy the requirement when cryptography is used. The cryptographic module must be FIPS-validated, not just implement an approved algorithm, and the configuration must be documented. Check which library or module actually performs the encryption, whether it is operating in its validated mode, and whether the validation certificate covers the version in production. Evidence includes the module name and certificate reference, the enabled configuration, and a test showing encrypted data on disk. Confirm details with the vendor and the NIST validation listing.

Keys stored beside the data

Encrypted data protected by a key kept on the same disk, in the same image or in the same configuration file offers little protection if the medium is lost or copied. Separate key custody from the data store, restrict who can read keys, and record rotation. A central secrets service with versioned keys and rotation, such as OpenBao's transit engine, can hold keys outside the application host. The evidence is a key inventory, access records for key material, and rotation history that ties back to the key management requirement.

Removable media left unprotected

USB drives, external disks, optical media and portable devices that hold CUI are a frequent blind spot because they leave the building. Define which media may hold CUI, require encryption or physical safeguards for each, and block or log use of unapproved devices. The assessor will look for a written procedure, a register of media that carry CUI, and proof that a sample device is encrypted. Where encryption is not used, document the physical safeguard instead and show how it is enforced.

Backup repositories outside scope

Backups copy CUI into a second location, often managed by a different team with weaker controls. If the backup server, catalog or offsite copy is excluded from the boundary, the CUI at rest protection claim does not cover it. Bring backup storage into scope, confirm that backup data is encrypted, and keep the catalog under the same access controls. Tools such as Bareos keep a catalog of backed-up files, and restic can verify that stored pack files are unmodified with its read-data checks. Evidence includes backup job records, encryption settings and a restore test.

Procedures still in draft

Assessors score a requirement as MET only when evidence is in final form. A protection procedure marked draft, an unsigned encryption standard or a configuration document that describes a system from last year will not carry the objective. Finalize the procedure, record the approval and date, assign an owner, and set a review cycle. Match the documented configuration to what is running, because a mismatch is a finding even when the policy itself is approved. Confirm the final-form expectations with your assessor before fieldwork.

Data at rest questions buyers ask before hiring help

What does data at rest protection cost, and what drives the price?

The cost depends on how many systems, drives, backup media and mobile devices hold CUI, and on whether those stores already support encryption. No fixed price applies to this requirement, and DeployOpen does not publish a price list. Costs fall into three groups: the implementation work (configuring encryption, key storage and device policies), the evidence work (documenting which stores hold CUI and how each is protected), and any hardware or licensing changes. Ask for a written scope that lists each store, the protection method for each, and the evidence deliverables. Cost rises with the number of stores and with legacy systems that need replacement. It falls when CUI is confined to a small set of well-documented repositories. Assessment fees are paid to the independent assessor, not to the implementation partner, so ask for them as a separate line.

How long does it take to protect CUI at rest?

The timeline depends on the number of CUI stores, how much of the environment already encrypts data, and how quickly the organization can approve configuration changes. Most of the elapsed time usually comes from inventory and change approval, not from the technical configuration itself. Before work starts, the team should confirm the list of information at rest that requires confidentiality protection, because later discoveries of unlisted stores extend the schedule. Ask any partner for a timeline in the written scope, with milestones for the inventory, the configuration changes, the testing of restores and the evidence package. Under the CMMC rule, a 1-point requirement like this one can close on a POA&M within the window described in the FAQ on that topic, so plan against that window rather than an open-ended schedule.

What does the work need from our own staff?

The work needs named owners from IT operations, security, and the business units that hold CUI. Their input is required because only the organization knows where CUI actually resides. Expect requests for access to storage platforms, backup systems, mobile device management consoles and key management processes. Staff should also be available to approve changes that may affect user workflows, such as enforced encryption on laptops or new key custody rules. Ask the partner to name the decisions they need from your team, the approval path for each, and the dates by which the decisions are needed. Clear ownership of the system security plan entries for this requirement prevents delays later in the assessment.

Can our internal team implement SC.L2-3.13.16 without outside help?

Yes, an internal team can implement this requirement if it has staff who understand storage encryption, key management, backup verification and the assessment objectives in NIST SP 800-171A. The requirement is narrow, but the evidence burden is real. The team must show a documented inventory of CUI at rest, the protection applied to each store, and proof that cryptography, where used, is FIPS-validated under SC.L2-3.13.11. Teams without assessment experience often struggle with that evidence step. Outside help can be limited to a readiness review or evidence packaging, which keeps the organization in control of its controls. The organization owns the controls and the assessor issues any findings. Confirm internal capability against the assessment objectives before deciding.

Is encryption mandatory for CUI at rest under CMMC Level 2?

Encryption is not mandatory for this requirement. The CMMC Assessment Guide for Level 2 describes encryption as one approach to protecting CUI at rest, and physical security or other technical protections may be used instead. The assessor checks whether CUI at rest is protected, so the organization must be able to explain its chosen method and show it works. If the organization does use cryptography, that cryptography must meet SC.L2-3.13.11, which requires FIPS-validated modules, not just approved algorithms. Many organizations choose full-disk or volume encryption on endpoints and server-side encryption on file platforms because these are easier to document. Confirm your chosen approach with your assessor early.

How does a POA&M apply to this 1-point requirement?

SC.L2-3.13.16 is worth 1 point and is not on the exclusion list, so it may be placed on a plan of action and milestones if the organization qualifies for Conditional Level 2 status. Under the scoring rules, the overall score must be at least 88 of 110, which equals 0.8, and closeout is due within 180 days. Note that the Department of War suspended CMMC Phase II in July 2026 and said Phase I self-assessments, SPRS postings and DFARS 252.204-7012 obligations remain in place, so confirm the current rules with your contracting officer before relying on a POA&M. A POA&M does not excuse the requirement. Track the open item, document interim protections and close it with evidence. Verify the current status of the rules on the DoW CIO About CMMC page.

What evidence does the assessor need to see for data at rest?

The assessor works from the three assessment objects in NIST SP 800-171A: the procedures for protecting information at rest, the list of information at rest that needs confidentiality protection, and the cryptographic mechanisms with their configuration documentation. A requirement is met only when the objective is satisfied with evidence in final form, not drafts. Typical evidence includes the CUI storage inventory, the system security plan entry, encryption configuration exports, key custody records, device policy settings, FIPS validation certificates for the modules in use, and a sample of restore tests from encrypted backups. Ask your assessor which artifacts they expect before you build the package, because format and scope vary by assessment.

How DeployOpen scopes and evidences data at rest protection

DeployOpen plans, implements and documents the technical safeguards that protect CUI at rest on the self-hosted open-source platforms it deploys inside your own infrastructure. Your organization owns the requirement, and an independent C3PAO or assessor, where one applies, makes the assessment decision.

How we scope

Written scope lists every storage location, drive, backup target and removable medium that holds CUI, agreed before work starts.
We map each location to the safeguard that protects it: encryption, physical control or a documented combination of both.
Where cryptography is chosen, the scope names the FIPS-validated module and the cryptographic mechanisms in use.

How we build

We configure server-side encryption for file storage, such as Nextcloud, and confirm which metadata remains unencrypted.
We deploy key management services, such as OpenBao, with versioned keys and a documented rotation procedure.
We test that stored data cannot be read in plaintext from the storage layer and record the results for review.

How we hand over

Deliverables include configuration documentation, the inventory of CUI at rest and the cryptographic mechanism settings.
Test records show backups and restores work, using restore tests and restic check with read-data options where used.
Your organization receives final-form evidence and a runbook, and you confirm the assessment objectives with your assessor.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Retainers can cover re-verification of encryption settings after platform upgrades and changes to storage locations.
Ask your assessor which evidence format and retention period they expect before the engagement begins.