03.13.08 Transmission and storage confidentiality: evidence

What NIST SP 800-171 03.13.08 requires for CUI in transit and at rest

Requirement 03.13.08 asks you to use cryptography so that CUI cannot be disclosed without authorization while it moves across a network and while it sits on disks, databases or object storage. A contract or a DFARS clause that cites NIST SP 800-171 will expect you to show that every path carrying CUI is protected and that the protection is applied to stored copies too. The disclosure risk is straightforward: a copy of CUI intercepted in transit or read from a stolen or reused drive is a disclosure, whether or not anyone opened it. Turning on encryption is the easy part. Proving it holds across every connection, every key, every replica and every backup is the hard part, because a single unencrypted sync job, an export to a laptop or a backup target outside the encrypted scope can defeat the control on paper while the design says otherwise.

Rev. 3 consolidates several Rev. 2 requirements here. It absorbs Rev. 2's 3.8.6, which covered encrypting CUI on portable media in transport, and Rev. 2's 3.13.16, which covered CUI at rest. NIST also states that withdrawn requirement 03.01.13, the Rev. 2 remote sessions requirement, is addressed by 03.13.08. The Rev. 3 discussion points to 03.13.11 for the choice of cryptography. The practical consequence is that one requirement now carries the evidence for three older concerns, so your assessor will expect one coherent encryption design rather than separate media and transport answers. Note also that DoD contract assessments and CMMC currently use Rev. 2, where the counterpart is 3.13.8, and that the DoW class deviation and the proposed FAR overhaul rule determine which revision your contract cites. Confirm the revision named in your contract before you scope evidence.

Which CUI systems, transfers and media 03.13.08 covers

Requirement 03.13.08 applies wherever CUI travels or rests, so scoping starts by listing those places. The cards below group the decisions an assessor will expect you to have made, and each one should trace back to the system security plan boundary.

CUI-bearing systems and data stores

Start with every system that creates, processes or stores CUI, including applications, databases, file shares, collaboration tools and endpoints. For each one, record where CUI is written to disk and which encryption mechanism protects it at rest. Confirm that the system security plan lists these components, because an assessor will compare the plan against what is actually deployed. Note that file names and folder structures may remain visible even when file contents are encrypted, so check whether that metadata is itself CUI.

Network paths carrying CUI

Map every path that carries CUI: user sessions to web applications, service-to-service calls inside the enclave, administrative connections and replication traffic. Each path needs a defined protection mechanism, and the choice should be documented per path rather than assumed for the whole network. Confirm that internal paths are covered, not only the connection from the internet to the perimeter.

External transfers and third-party exchanges

List every point where CUI leaves your boundary, such as file transfers to a prime contractor, email to a subcontractor, or data exchanged with a government portal. Each external transfer should use a documented protection mechanism, and the agreement covering the exchange should be recorded in the plan. Ask each recipient how they protect CUI on their side, since your protections end at the boundary you control.

Removable and transported media

Portable drives, laptops, backup tapes and other media that leave a controlled space are a common gap in scoping. Identify which media may hold CUI, who may transport it, and how encryption is applied before it leaves the facility. The requirement that Rev. 2 called 3.8.6, encrypting CUI on media in transport, is now part of 03.13.08, so media decisions belong in this scope as well as in the media protection family.

Backups, replicas and cloud providers

Backups, disaster recovery replicas and logs that copy CUI are in scope even when they are rarely accessed. Cloud providers and managed service vendors that host or transmit CUI also need to be listed, along with the cryptographic keys they hold. Ask each provider which encryption features apply, who controls the keys, and what evidence they can supply. Keep these decisions aligned with the system security plan boundary so that every copy of CUI has a named owner and a defined mechanism.

Assigning mechanisms to each path

Within the boundary, the organization decides which cryptographic mechanism applies to which data path, store or media type. The requirement does not fix a single product or method for the whole environment. Record each decision with its owner, its scope and its review date, and confirm that the cryptography used for each path is the type your organization has defined under related requirement 03.13.11. Keep the list current as systems change, so the scope matches the plan at assessment time.

How an assessor tests NIST SP 800-171 03.13.08

This table walks through how an assessor applies the examine, interview and test methods from SP 800-171A Rev. 3 to 03.13.08, row by row for each object type. Read it as a checklist of what to have ready before an assessment, and note the CMMC scoring and POA&M point at the end, which affects how a gap on this requirement is handled.

Assessment object	What the assessor does	Evidence requested
Examine: system and communications protection policy and procedures	Reads the policy to confirm it addresses cryptographic protection of CUI in transit and at rest, and checks that procedures name owners and review cycles.	Approved policy, procedure documents with version history, and evidence of the last review.
Examine: procedures for transmission confidentiality	Traces how CUI is protected on each transmission path, such as web, email, API, VPN and file transfer, and checks that the procedure matches the configured systems.	Transmission procedures, data flow diagrams marking CUI paths, and the list of approved protocols.
Examine: procedures for protection of information at rest	Checks that stored CUI, including backups and removable media, has a documented encryption method, key custody model and exception process.	At-rest encryption procedure, storage inventory listing CUI locations, and backup encryption settings.
Examine: system design documentation	Compares the design against the diagrams and confirms encryption points, key stores and cryptographic modules appear in the architecture.	Current architecture diagrams, system security plan sections on CUI protection, and the cryptographic module inventory.
Interview: personnel with information security responsibilities	Asks how encryption is enforced in daily operations, who approves exceptions and how a failed or disabled encryption setting is detected.	Named role holders, responsibility matrix and examples of exception approvals or monitoring alerts.
Interview: system developers	Asks how applications encrypt CUI in transit and at rest, which libraries they use and how keys are handed to the code.	Developer documentation, dependency list and secure coding standard references for encryption.
Test: mechanisms supporting transmission confidentiality	Checks TLS or VPN configurations on live endpoints for enforced encryption, disabled weak protocols and no plaintext fallback.	Configuration exports, scan results or screenshots from the systems in scope, and test records dated within the assessment window.
Test: cryptographic mechanisms for at-rest and transit protection	Confirms that encryption is active on storage volumes, databases and backups and that the cryptographic modules in use match the documented inventory.	Encryption status reports, key management records and module validation details where the organization claims them.
CMMC scoring and POA&M	Under CMMC Level 2, SC.L2-3.13.8 carries 3 points in the 32 CFR 170.24 methodology, and 32 CFR 170.21 does not allow it on a POA&M for Conditional status.	Confirm the current CMMC scoring and POA&M rules with your assessor or the eCFR text before planning remediation.

Which evidence passes 03.13.08 and how to keep it current

An assessor testing 03.13.08 looks for proof that CUI is encrypted on every path and store, and that the proof still matches the running system. The cards below cover six artifacts, each with a routine for refreshing it between assessments so the System Security Plan and the evidence stay aligned.

CUI data path and store inventory

This is a documented map of every place CUI travels or rests: application servers, databases, object storage, backups, file shares, email gateways and endpoints, with the mechanism protecting each one. Assessors use it to confirm that no path was left out of the encryption review. Keep it current by reconciling it against the asset inventory and data flow diagrams at each change window, and by recording who approved each new store before CUI is written to it. Missing stores are the most common gap and usually appear after a cloud project adds a bucket or replica.

Transport and storage encryption configuration exports

Configuration exports show that encryption is enabled in the running system, not only in policy. For a self-hosted file platform, this can include the server-side encryption settings of Nextcloud, TLS settings on load balancers and the database encryption parameters. Schedule exports to a versioned evidence repository, compare each export to the approved baseline, and open a change record for any drift. Ask your integrator to confirm which settings are read-only for administrators so that exports cannot be quietly edited.

Key lifecycle records

Key lifecycle records document how cryptographic keys were generated, where they are stored, when they were rotated and when they were retired or destroyed. For 03.13.08 they show that the keys protecting CUI are managed, not left as static values in configuration files. OpenBao's transit engine supports versioned keys and rotation, and those version histories can serve as records. Review the log monthly, confirm rotation followed the approved schedule, and record each rotation in the System Security Plan if the procedure changes.

Certificate inventory and renewal logs

A certificate inventory lists every TLS certificate that protects CUI in transit, its issuer, its expiry date and the workload it serves. Renewal logs show that certificates were replaced before expiry and that the replacement used an approved issuer. In Kubernetes or OpenShift, cert-manager stores issued certificates in Kubernetes Secrets and renews them automatically, so export its certificate resources on a schedule. Assessors will ask who receives expiry alerts and what happens when a renewal fails, so document both.

Media transport and backup encryption records

These records show that CUI moved on removable media or stored in backups was encrypted before it left a controlled location. They include backup job configurations, encryption verification results, transport logs with chain of custody and records of any restore test. Because 03.13.08 absorbed the Rev. 2 requirement for encrypting CUI on media in transport, a backup job that runs unencrypted is a finding even if the production system is compliant. Verify encryption at the job level each cycle, not only at the platform level.

Blocked unencrypted path test results

Test results show that an unencrypted path is refused, not merely discouraged. Examples include a plain HTTP request to a CUI portal that receives no content, an attempt to mount a share over an unencrypted protocol that fails and a database connection without TLS that is rejected. Run these checks as part of the regular security assessment, keep the command output and timestamps, and rerun them after any change to the gateway or service configuration. Illustrative example: a monthly script that attempts a plaintext connection to each CUI endpoint and stores the refusal messages in the evidence repository.

How to implement 03.13.08 in the order that keeps rework low

This sequence works from knowing where CUI moves and rests toward the evidence an assessor will ask for, so cryptographic choices are settled before configuration is built and tested. Each step produces an artifact that the next step depends on.

Map CUI data paths and stores
The organization owns this step and its system owners do the work, with DeployOpen or another implementation partner able to help trace flows across the environment. List every path CUI takes, including user browsers, email, file sync, APIs, database replication, administrative access, and transfers to subcontractors or cloud services. Then list every place it rests, including primary storage, caches, logs, backups, snapshots, removable media and endpoints. The closing artifact is a path and store inventory tied to the system security plan boundary. If a path is missing here, no later step will protect it, so confirm the inventory with the people who operate each system rather than relying only on architecture diagrams.
Set cryptographic choices and contract parameters
Decide which cryptographic mechanisms apply to each path and store, and record the organization-defined choices that 03.13.08 depends on. The discussion of 03.13.08 refers to 03.13.11 (Cryptographic protection), so the algorithms, key lengths and validated modules chosen here should be the same ones used to satisfy that requirement. Check the contract, the agreement or the federal agency's instructions for any ODP values that have been specified, and ask the contracting officer to confirm any that have not. Where no value is supplied, the organization must assign one. The output is a cryptographic standard for the environment that names approved protocols, algorithms, modules and the exceptions process.
Protect transmission on every path
System engineers configure encryption for each path in the inventory, covering external connections, internal service-to-service traffic, administrative sessions and file transfers. Enforce current TLS versions and disable fallback to plaintext protocols at the server, proxy and client levels. Apply the same rule to remote sessions, which 03.13.08 treats as addressed by its transmission protection, so remote access should not depend on a separate unencrypted route. The closing artifact is a configuration baseline per path that shows the protocol, cipher policy and certificate source, reviewed by the security team before go-live.
Protect data at rest and in backups
Apply encryption to every store in the inventory, including the storage that holds backups and snapshots, since 03.13.08 incorporates the Rev. 2 requirement for CUI at rest and the media-transport requirement. Server-side encryption in a platform such as Nextcloud protects file contents on local and external storage with keys kept on the server, but it does not encrypt file names or folder structure, so the team must document that gap and decide whether it is acceptable for the CUI involved. Confirm the same for databases, object storage, logs and removable media. The output is a store-by-store encryption record that states the mechanism, the key location and any metadata that remains visible.
Set key and certificate management
Key generation, distribution, storage, rotation and destruction are governed by 03.13.10 (Cryptographic key establishment and management), so this step connects the two requirements in one design. Choose where keys live and who can use them. OpenBao's transit secrets engine can encrypt and decrypt application data without storing it, sign and verify data, and rotate versioned keys, which supports application-level encryption under central control. FreeIPA's integrated Dogtag certificate authority can issue and manage internal certificates, and cert-manager can create and renew TLS certificates for Kubernetes or OpenShift workloads from issuers such as a CA key pair or HashiCorp Vault. Confirm that each issuer and key store is covered in the system security plan. The output is a key and certificate register with owners, rotation records and issuer configuration.
Capture evidence and test for unencrypted fallback
Assemble the evidence an assessor will examine, interview and test against for 03.13.08. SP 800-171A Rev. 3 looks for policy and procedures for transmission confidentiality and for protection of information at rest, system design documentation, configuration records, and the cryptographic mechanisms themselves. Run scans and controlled tests that attempt connections over plaintext ports, downgraded protocols and unencrypted storage mounts, and record the results. Any finding should be fixed and retested before the evidence package is final. Schedule repeat tests after certificate renewals, key rotations and configuration changes so the evidence stays current. The closing artifact is a test report and evidence index mapped to the two determination statements for 03.13.08, ready for the independent assessment.

Which self-hosted tools produce encryption and key evidence

Four self-hosted open-source components cover different parts of transmission and storage confidentiality: file encryption at rest, application-level encryption, internal certificate issuance and workload TLS. None of them makes a system compliant on its own, and the organization still owns the scoping, key policy and assessor-facing evidence. Confirm FIPS validation status of any cryptographic module with the vendor before citing it in a system security plan.

Nextcloud server-side encryption

Nextcloud's server-side encryption protects file contents on local and external storage, with keys held on the server. That supports the at-rest half of 03.13.08 for CUI stored in file shares, but file names and folder structure stay unencrypted, so CUI in names is still exposed. Check whether the enabled encryption module is FIPS-validated, confirm key recovery procedures, and document where metadata containing CUI is kept. The AGPL-3.0-only license also matters if you modify the server code and offer it to users.

OpenBao transit encryption

The OpenBao transit secrets engine encrypts and decrypts application data without storing the data itself, so applications send plaintext in and receive ciphertext back. It also supports versioned encryption keys and key rotation, which gives assessors a visible record of how keys change over time. The gap is that OpenBao does not, by itself, prove transmission protection or secure application code paths. Confirm the FIPS validation status of the build you deploy and define who may create, rotate and disable keys.

FreeIPA certificate authority

FreeIPA includes an integrated certificate authority based on Dogtag, which issues and manages certificates for hosts, services and users inside your identity domain. Those certificates support TLS for internal services and give you an audit trail of issuance and revocation. Evidence for 03.13.08 still needs a documented certificate policy, a defined list of protected services, and proof that unmanaged certificates are not used for CUI paths. Confirm the cryptographic module status with the vendor before relying on it for assessment.

cert-manager workload TLS

cert-manager creates TLS certificates for workloads in Kubernetes or OpenShift from issuers such as ACME, a CA key pair, HashiCorp Vault, CyberArk or a self-signed issuer. It stores certificates in Kubernetes Secrets and renews them before they expire, which reduces lapsed certificates on CUI-bearing service paths. Evidence includes issuer configuration, certificate inventory and renewal events. Choose the issuer deliberately: public ACME issuers may be unsuitable for internal CUI services, and the organization must confirm which issuer and cryptographic module it uses.

What NIST SP 800-171 03.13.08 costs in money and effort

This table breaks down the cost of meeting 03.13.08 into its components, showing who is paid for each, whether it is one-time or recurring, what moves it up or down, and what to request in a quote. Use it to compare an implementation proposal against the work the requirement actually creates. No figures are given because none were supplied for this requirement, so the quote questions carry the weight.

Cost component	One-time or recurring	What drives it up or down	What to ask for in a quote
Encryption and key tooling	Mostly one-time setup, then recurring support if a vendor subscription is chosen	Open-source tools such as OpenBao, Nextcloud and FreeIPA remove license fees, but integration, hardening and testing still cost engineering time. Count of platforms needing separate key handling raises it.	Itemized list of licensed versus open-source components, and the engineering hours assumed for integration and hardening
Engineering time for transport encryption	One-time, with periodic rework when services change	Number of CUI data paths, legacy protocols that need retiring, and whether internal service-to-service traffic is included	A path inventory showing each CUI flow and the encryption method assigned to it
Engineering time for storage encryption	One-time, with rework on storage migrations	Number of storage locations, whether file names and folder metadata must also be protected, and whether backups and media are in scope	Confirmation of what is encrypted at rest, what is not, and how the gap is documented
FIPS-validated module requirements	One-time validation effort, recurring if modules are revalidated or replaced	Whether the organization or the federal agency requires FIPS-validated cryptography, and whether cloud-managed services can satisfy it	Written statement of the required validation status for each module and proof of current validation
Certificate and key operations	Recurring	Number of certificates, use of automated renewal, cloud versus on-premises issuance, and key rotation frequency set by the organization	Description of issuance, renewal, rotation and revocation procedures, with who performs each step
Evidence upkeep	Recurring	Frequency of configuration changes, number of owners who must produce records, and how often the system security plan is updated	Evidence schedule listing what is collected, how often, and where it is stored
External testing or review	Recurring or per engagement	Scope of cryptographic testing, number of endpoints, and whether testing covers configuration review only or active testing	Written scope, test methods and deliverables agreed before work starts
Assessor time	Per assessment, set by the independent assessor	Number of CUI paths the assessor must examine and interview on, and the quality of the documentation provided beforehand	Written fee basis and assumed hours from the assessor, requested before engagement

Your team, an implementation partner and the auditor for 03.13.08

Your organization remains accountable for 03.13.08. Under NIST's guidance, the federal agency that holds the contract is responsible for how SP 800-171 is applied and for any compliance issues, so the decisions that define the requirement cannot be delegated away. Your team sets the policy and makes the calls that a partner or auditor will later test against.

CUI path inventory: List every place CUI travels or rests, including file shares, collaboration tools, backups, endpoints, removable media and cloud services, and record the protection applied to each path.
Key policy: Decide who may generate, rotate, escrow and destroy cryptographic keys, and which algorithms and modules are approved for CUI.
Organization-defined parameters: Assign the values for any parameters in the requirement that no federal agency has specified, and document the rationale.
System security plan entries: Describe how 03.13.08 is implemented, who operates it and where the evidence lives, in language an assessor can trace.
Accountability for exceptions: Approve and track any deviation, and confirm that it is reflected in the plan of action and milestones where applicable.

Check that each decision has a named owner and a date, because those records are what an assessor will ask for first.

Where 03.13.08 findings usually come from and how to close them

Most 03.13.08 findings trace back to a small set of gaps: the organization does not know every place CUI travels or rests, or it protects one path while leaving others open. The cards below pair each common gap with the action that closes it and the evidence an assessor will ask to see, so the system security plan and the actual configuration describe the same system.

Incomplete CUI path inventory

Teams often document the main application and its database but miss the paths CUI takes after that: exports, sync clients, email attachments, ticketing systems, log pipelines and support tooling. Close this by tracing CUI from every ingress point to every store and exit, then recording each hop as a flow in the system design documentation. Check that each hop appears in the system security plan. Evidence: a current data flow diagram, a CUI asset list tied to it, and a dated review record.

Encryption at the edge only

Organizations often terminate TLS at the load balancer and then send CUI in plaintext between services, to message queues or to databases on the internal network. The assessor will test whether transmission confidentiality holds across internal hops, not just the front door. Close this by enforcing TLS or an equivalent protected channel on each service-to-service connection, including database connections. Evidence: captured configuration for each hop and a test showing a plaintext connection is refused.

Unencrypted backups and transported media

Backup sets, replicas, laptops and removable drives that leave the controlled environment often hold CUI without encryption, and teams forget that these copies are in scope for 03.13.08 because Rev. 3 folded the Rev. 2 media-in-transport and CUI-at-rest requirements into it. Close this by encrypting every backup target and portable device before data is written, and by documenting who holds the keys. Evidence: backup job configuration showing encryption settings, device encryption reports and a transport log.

Missing key rotation records

Keys may be generated and used correctly, yet the organization cannot show when they were rotated, who approved the change or which version protected which data. An assessor reviewing cryptographic protection will ask for this history. Close this by using a key manager that versions keys and supports rotation, then retaining the rotation policy and its logs. Evidence: key inventory with versions, rotation schedule records, and audit entries for each rotation event.

File metadata exposed at rest

Server-side encryption can protect file contents while file names and folder structure remain readable on the storage backend. In a CUI repository, a project name or folder label can disclose the nature of the work even when the documents are encrypted. Close this by naming the metadata exposure in the risk assessment, restricting what is placed in names and paths, and documenting the residual risk for the authorizing official. Evidence: the encryption configuration, a risk entry covering metadata, and the naming standard for CUI folders.

System security plan drift

The system security plan describes an encrypted boundary, but the running configuration has exceptions, test systems with real CUI or a service that was added after the last review. A mismatch between the plan and the system is one of the most common reasons an assessor cannot credit a requirement. Close this by reconciling the plan against configuration exports and scanner output before each assessment, and by logging every change that affects cryptographic protection. Evidence: a dated plan revision, configuration snapshots and change tickets that match the plan.

Questions buyers ask about 03.13.08 cost, effort and scope

How much effort does 03.13.08 take, and what drives it?

The effort depends mainly on how many systems hold or transmit CUI and how much of their encryption is already in place. 03.13.08 asks for cryptographic mechanisms that prevent unauthorized disclosure of CUI in transit and at rest, so the work splits into two parts: finding every path where CUI moves or rests, and proving each path is encrypted with mechanisms you can document. Drivers include the number of data stores, the number of external connections, whether keys are managed centrally, and how much legacy software needs changes. Ask any provider for a written scope listing the systems and data flows covered before accepting an effort estimate. Assessors will test the mechanisms directly, so budget time for evidence collection as well as configuration. The NIST SP 800-171 Rev. 3 publication gives the requirement text and related controls.

Can our team meet 03.13.08 without an implementation partner?

Yes, an internal team can meet 03.13.08 if it has people who understand cryptography, network design and the system's data flows. The organization owns its controls and makes the final decisions. A partner is most useful when the work needs parallel effort across several platforms, when staff lack experience with key management, or when the team needs help producing evidence an assessor can follow. Be clear about roles: an implementation partner prepares systems and evidence, while only an independent assessor or auditor reaches a formal conclusion. Whatever route you choose, the Rev. 3 assessment procedure for 03.13.08 expects examination of policy, procedures and system design documents, interviews with staff, and testing of the mechanisms themselves.

What does the work need from our staff?

The work needs named owners from several groups, not only security. Typically this includes people who know where CUI is created, stored, moved and deleted; system administrators who can configure encryption on storage and transport paths; a person who owns key generation, rotation and storage; and developers who maintain any application that handles CUI. Someone must also write and maintain the procedures that the assessment examines, and staff must be able to explain them during interviews. Plan for these people to spend time on reviews and testing across the project. Ask a provider to name the roles it expects from your side in the written scope, because gaps in staff availability are a common reason evidence arrives late.

How long does 03.13.08 take to implement?

The duration depends on scope and is set by the written plan, not by a general rule. A narrow scope covering one platform with existing encryption will move faster than a program that must cover file shares, databases, backups, remote access and external transfers. Timing also depends on change windows, procurement of any new key management components, and how quickly your teams can test changes without disrupting users. Ask for a schedule that lists milestones, dependencies and the evidence each milestone produces. DeployOpen plans most engagements as fixed-scope work, with scope, deliverables and timelines agreed in writing before work starts.

Does Rev. 2 or Rev. 3 apply to our contract?

Your contract decides it, and the answer is not the same for every buyer. NIST withdrew Rev. 2 on 14 May 2024, but the CMMC Level 2 rule in 32 CFR Part 170 makes its requirements identical to Rev. 2, so DoD contractors are assessed against the 110 Rev. 2 requirements. For 03.13.08, the Rev. 2 counterparts are 3.8.6, 3.13.8 and 3.13.16, which Rev. 3 folded into one requirement. A DoD class deviation signed 3 September 2026 names Rev. 2 explicitly, while a proposed FAR rule would move civilian contracts to Rev. 3 with values set by the DoW CIO. Confirm the revision, the assessment method and the deadline in your contract, and check the current status of each rule with your contracting officer, since these documents change.

Is FIPS-validated encryption required for 03.13.08?

03.13.08 asks for cryptographic mechanisms that prevent unauthorized disclosure of CUI, and it does not itself name FIPS validation. The companion requirement 03.13.11 covers the types of cryptography, and NIST's discussion there recommends FIPS-validated cryptography. The Rev. 2 counterpart 3.13.11 carries partial credit in DoD and CMMC scoring, so check how your scoring method treats it before you choose modules. Ask your contracting officer and assessor which validation they expect, and confirm the certificate status of each module in the NIST validation list for your deployment. Also verify the cryptographic modules your platforms actually load, since a product can be validated while the configuration you run is not.

How DeployOpen prepares 03.13.08 encryption systems and evidence

DeployOpen helps organizations prepare the encryption systems and evidence that 03.13.08 Transmission and storage confidentiality asks for, inside the organization's own infrastructure. The organization owns its controls and its decisions on what to protect, and only an independent assessor can issue an assessment result.

How we scope

Engagements are fixed-scope, with the systems, CUI flows and encryption points agreed in writing before work starts.
The written scope lists which transmission paths and storage locations holding CUI are in and out of the 03.13.08 work.
Scope also records which key management, certificate and backup components the organization already operates.

How we build

We plan and deploy self-hosted services such as server-side file encryption, a transit encryption service and an internal certificate authority inside the client's environment.
We configure TLS for internal and external transmission paths and confirm that cryptographic mechanisms are the ones the organization has chosen and documented.
We test encrypted transmission and stored data during build to confirm that unencrypted fallback paths are closed or documented.

How we hand over

We deliver configuration records, architecture diagrams and key lifecycle procedures that map to the examine and interview objects in SP 800-171A Rev. 3.
Handover includes test records showing encrypted transmission and storage, along with a list of open items the organization must resolve.
The organization's own staff receive documented runbooks so they can operate and evidence the controls after handover.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, covering changes to encryption configuration over time.
We can rerun encryption verification after upgrades, certificate renewals or changes to CUI flows, and update the evidence set.
Assessment decisions, reports and any certification remain with the organization and its independent assessor or certification body.