03.13.11 Cryptographic protection: requirement and evidence

What NIST SP 800-171 03.13.11 cryptographic protection requires in practice

If you are the compliance lead on a contract that flows down NIST SP 800-171, 03.13.11 asks two things of your organization: it must implement the types of cryptography it has defined to protect the confidentiality of CUI, and it should use FIPS-validated cryptography for that purpose, which is the recommendation in NIST's discussion of the requirement. The types are an organization-defined parameter (ODP). NIST does not pick them for you. Rev. 3 lists the ODP as the one value you must set for this requirement, so the first deliverable is a written statement of which algorithms, modules and key lengths protect CUI, where each applies (email, file shares, databases, backups, remote sessions), and why that choice follows the laws, regulations and standards that bind your contracts. Assessors check that this definition exists, that it is current, and that it matches what the systems actually do.

Assessors test 03.13.11 mainly through documents and configuration, not through a single control they can sample. They will look for the cryptographic protection procedures, system design documentation that shows where CUI is encrypted, configuration settings on servers, endpoints, gateways and applications, and the validation certificates for each cryptographic module. Confirm the exact validation status of every module you rely on against the current NIST validation lists before you write it into the system security plan, because a certificate that is historical, unlisted or covers a different version of the module will not carry the credit you expect. Pair each module with the configuration that actually enables it, and keep dated screenshots or exported settings so the evidence reflects the state at assessment time.

The practical stakes come from scoring. CMMC Level 2 still assesses the Rev. 2 counterpart, 3.13.11 (SC.L2-3.13.11), and under the 32 CFR 170.24 methodology it is worth 5 points, dropping to 3 points when encryption is used but is not FIPS-validated. Under 32 CFR 170.21, a non-validated implementation can be carried on a plan of action and milestones, but that route has its own conditions, so confirm them in the rule text before you rely on it. Because the Rev. 2 and Rev. 3 requirements differ in detail, map your evidence to both numbering schemes now. Also confirm which version your contracting officer names, since current DoD guidance on the revision in force is still moving.

Which systems, data and third parties fall under 03.13.11 cryptographic protection

Scope for 03.13.11 starts with where CUI is stored or transmitted, then follows the cryptographic modules, the teams that run keys and configuration, and the external providers that touch that data. Each of the four areas below changes what an assessor will ask for and how much evidence the organization must produce.

Systems that store or transmit CUI

Start with the data flows, not the org chart. List every system where CUI is created, stored, processed or sent, including file sharing, email gateways, backups, databases, logs that capture CUI and developer environments. Each one needs a stated encryption method, because 03.13.11 asks the organization to define the types of cryptography that protect CUI confidentiality. A system that holds CUI without a defined method is an immediate gap. Confirm the list against the system security plan and the data flow diagrams before scoping encryption.

Cryptographic modules and services

The modules that perform encryption, such as operating system libraries, TLS stacks, hardware security modules, key stores and the transit encryption services that applications call, form the core of the scope. For each one, record the module name and version and whether it holds a FIPS validation certificate. NIST's discussion recommends FIPS-validated cryptography for protecting CUI, and assessors will ask for the validation certificate. Where a product offers encryption without validation, the organization must document that choice and understand how CMMC scoring treats it.

Teams that own keys and configuration

Assessors interview the people who run cryptography. Identify who sets the approved algorithms, who issues and rotates keys, who changes system configuration settings that enable or disable encryption, and who approves exceptions. These roles often sit across security, platform engineering, application teams and an outsourced hosting provider. Write them down with named responsibilities, because SP 800-171A Rev. 3 lists personnel with cryptographic responsibilities and system developers as interview objects for this requirement.

External cloud and hosted providers

A cloud platform, managed database or SaaS tool that stores CUI belongs in the assessment whenever the organization relies on it for encryption. The key decision is whether the provider's encryption is inside the organization's boundary. If the organization holds the keys, configures the service and can show the settings, the encryption is generally its evidence to produce. If the provider controls the keys and the organization cannot see the configuration, the gap must be documented and handled through contract terms and provider evidence. Ask each provider which FIPS-validated modules it uses and for the certificate numbers.

Scoping decision: non-validated encryption

Whether any encryption in scope is not FIPS-validated changes the score and the work. Under the CMMC scoring methodology, the 3.13.11 requirement carries a different point value when encryption is used but not FIPS-validated, and a plan of action and milestones is allowed only in that case. Inventory each encryption instance, record its validation status and decide early whether to replace it. Confirm the current scoring rules with your assessor, since the Rev. 2 and Rev. 3 rules are changing.

How an assessor tests 03.13.11 cryptographic protection

This table maps the SP 800-171A Rev. 3 assessment approach for 03.13.11 to the methods, objects, evidence and common findings an assessor works through. Use it to prepare the documents and interviews before an assessment, since the single determination statement is tested through several methods at once.

Method and assessment element	Objects the assessor examines or interviews	Evidence to have ready	Common findings
Examine: policy and procedures	System and communications protection policy, procedures for cryptographic protection	Approved policy naming the types of cryptography used to protect CUI confidentiality, with dated approval	Policy is generic and names no cryptography type, or procedures were never updated after system changes
Examine: ODP value defined	Organization-defined parameter for cryptography types, recorded in the system security plan or policy	Written statement of the approved cryptography types and where each applies, such as TLS versions and at-rest algorithms	Parameter left blank or described only as encryption in general, so the check that the value is defined fails
Examine: system design documentation	Architecture diagrams and data flow records showing where CUI is encrypted	Diagrams marking encrypted paths for CUI in transit and storage, including backups and remote access	Design shows encryption on the web tier but not on internal database or backup paths
Examine: system configuration settings	Cryptographic settings on servers, load balancers, databases, endpoints and key stores	Configuration exports or screenshots showing enabled protocols, approved ciphers and key lengths	Legacy protocols or weak ciphers still enabled, or settings differ from the documented approach
Examine: cryptographic module validation certificates	FIPS validation certificates for each module used to protect CUI	Certificate numbers matched to the exact module version and mode deployed, with validation status checked	Certificate covers a different version, the module runs in a non-validated mode, or the certificate was not verified
Examine: procedures for cryptographic protection	Operating procedures for enabling, rotating and verifying cryptography	Runbooks and change records showing how cryptographic settings are applied and reviewed	Procedures describe intent but no steps an administrator can repeat
Interview: personnel with cryptographic responsibilities	Staff who own encryption, certificates and key stores	Consistent explanation of the approved types and the process for exceptions	Staff cannot name the approved types or describe how a new service is brought into scope
Interview: system developers and information security personnel	Developers building services that handle CUI and security staff who review them	Evidence that developers use the approved libraries and modules	Developers choose their own libraries, so non-validated cryptography reaches production
Test: mechanisms implementing cryptographic protection	Encryption mechanisms in place on sampled systems, such as TLS endpoints and storage encryption	Test results or observed behavior showing CUI is protected with the documented types	Mechanism is installed but not enabled for CUI workloads, or a sampled system falls outside the documented design

Implementing 03.13.11 cryptographic protection in order

This sequence turns the 03.13.11 requirement into a defined cryptography standard, a verified inventory of where CUI is protected, and configuration evidence an assessor can examine and test. Each step names the record it produces so the next step has something concrete to build on.

Define the cryptography types for CUI
The organization sets the value of the single organization-defined parameter for 03.13.11: the types of cryptography it will use to protect the confidentiality of CUI. The owner is usually the CISO or security architect, with input from system owners and the compliance lead, because the value must match the system security plan. Confirm the value is written down and approved, since an assessor checks that the parameter is defined as well as that it is followed. The output is a cryptography standard that names approved algorithms, key lengths and modes, and states that FIPS-validated cryptography is the expected choice for CUI.
Inventory where CUI is encrypted
Map every system, storage location, backup, transfer path and application that handles CUI, then record whether cryptography protects it in transit or at rest and which mechanism does so. System owners and the architecture team usually produce this with the data flow diagrams from the system security plan. Include file shares, collaboration tools, databases, endpoints, removable media and cloud services, because gaps often sit in systems that were not in the original design. The output is a cryptographic inventory that lists each CUI location, its protection mechanism, and the owner responsible for it.
Confirm FIPS-validated modules and certificates
For each cryptographic mechanism in the inventory, confirm that the module is FIPS-validated and record its validation certificate number from the NIST Cryptographic Module Validation Program listing. Check the exact module version and operating mode, because a product can be listed while the deployed build or configuration falls outside the validated boundary. Where a mechanism is not validated, record it as a gap and decide whether to replace it or document it under the CMMC scoring and plan of action rules, which treat unvalidated encryption differently from no encryption. The output is a validation register with one row per module, certificate number, version and status.
Configure systems to approved algorithms only
Configure each system to use only the algorithms, protocols and key lengths named in the cryptography standard, and disable weaker options such as legacy protocol versions and obsolete ciphers. Platform engineers apply the settings through configuration management so the baseline is repeatable and changes go through change control. For open-source components, confirm the configuration keys that enable the validated modules, for example through the platform's FIPS mode or the crypto library it uses, and test that the setting survives upgrades. The output is hardened configuration baselines and exported configuration settings for each in-scope system.
Document key handling with 03.13.10
Work with the owners of 03.13.10 to document how keys for the approved cryptography are generated, stored, distributed, accessed, rotated and destroyed. Key management is the point where encryption most often fails in practice, so the 03.13.11 record should point to the key procedures rather than repeat them. Where an open-source key service such as a transit secrets engine, an internal certificate authority or a certificate manager is used, document which system holds each key class and who can administer it. The output is a cross-reference table that links each cryptographic mechanism to its key store, key owner and key procedure.
Test the configuration and encryption
Verify that encryption is active where the inventory says it is, using test evidence rather than configuration intent alone. Testers check that CUI in transit uses the approved protocols, that data at rest is encrypted, and that weak options are refused when attempted, and they record the commands, scan results or screenshots used. This aligns with the test method SP 800-171A Rev. 3 applies to 03.13.11, so the test results should be captured in a form an assessor can reproduce. The output is a test report that names each check, the system tested, the expected and observed result, and the tester.
Record outputs and schedule review
Assemble the outputs of the previous steps into the evidence package for 03.13.11: the cryptography standard, the inventory, the validation register, the configuration baselines, the key cross-reference and the test report. The control owner signs off on the package, and the system security plan is updated to reflect the parameter value and current architecture. Set a review cycle and a trigger list, such as new CUI locations, module changes, certificate expirations or algorithm retirements, that reopens the inventory and testing. The output is a versioned evidence set and an updated system security plan entry that an independent assessor can examine.

Evidence that passes 03.13.11 and how to keep it current

An assessor testing 03.13.11 will look for a defined cryptography decision, proof that the chosen modules are validated, and configuration that matches the documents. Each artifact below has its own owner and its own triggers for review, so keeping them current between assessments is a set of recurring tasks rather than a single annual refresh.

Defined cryptography types document

This is the organization-defined parameter that 03.13.11 requires you to set: which cryptographic types protect CUI confidentiality, such as the algorithms, key sizes and modes permitted for data in transit, at rest and for signing. Name an owner, usually the security architect, and approve the document through your change process. Review it when a protocol is deprecated, when a platform upgrade changes defaults, or when a new data store enters the CUI boundary. Confirm that the ODP is defined, since assessors check it separately.

Cryptographic module validation certificates

Keep the current FIPS validation certificate for every module that performs encryption of CUI, and record the exact module version deployed. NIST recommends FIPS-validated cryptography, and CMMC scoring depends on whether encryption is FIPS-validated. Track certificate status with the vendor or the validation program, since certificates can be retired. Note that a component can be a validated module in one mode and not in another, so record the mode in use. If a module is not validated, that gap belongs on a POA&M only under the conditions in 32 CFR 170.21.

System design and data flow documents

Show where CUI is encrypted, which components terminate each encrypted session, and where keys are generated and stored. Diagrams should match the system security plan and the current network and service inventory. Update them on each architecture change, on new integrations with external services, and when a key management service or certificate issuer is added or replaced. An assessor will compare the diagram against live configuration, so a diagram that omits a proxy or a backup path is a common finding.

Configuration exports and screenshots

Capture the settings that enforce the defined cryptography, such as TLS minimum versions, cipher suites, server-side encryption status and key rotation intervals. Prefer exported configuration files or command output with timestamps over manual screenshots, because exports can be diffed between reviews. Store them under version control or in an evidence repository with the system name and date. Refresh them after each patch cycle or configuration change, and check for drift against the approved cryptography document.

Procedures for cryptographic protection

Written procedures describe how cryptography is selected, deployed, verified and changed, including who approves a new algorithm and how exceptions are recorded. Assign an owner in security operations and tie review to the policy cycle and to incidents that exposed a weak setting. Interview objects for 03.13.11 include personnel responsible for cryptographic protection and system developers, so staff must be able to explain the procedure consistently. Update the document whenever tooling changes, such as a move to a new secrets or certificate platform.

Test results and verification records

Testing shows that encryption works as designed, not only that it is configured. Keep records of TLS scans, encryption-at-rest checks, key rotation tests and certificate renewal runs, each with date, tool, scope and result. Assign ownership to the team that runs the tests and schedule them after significant changes and on a recurring basis. Retain failed tests along with remediation records, because assessors look for how gaps were closed. Confirm that the scanning tool and its configuration are themselves documented.

What meeting 03.13.11 cryptographic protection costs

This table breaks down the cost components of meeting 03.13.11 by who is paid, whether each cost is one-time or recurring, what moves it up or down, and how to contain it. Use it to frame written quotes, since no prices are published here and every figure depends on your system scope. The main takeaway is that the largest avoidable cost is usually the choice of cryptographic modules, and the recurring cost is evidence upkeep.

Cost component	Who is paid	One-time or recurring	What drives it up or down	How to keep it down
Validated cryptographic modules	Module vendor or licensing body, or none for open-source modules	Often recurring (license or support); open-source options may carry none	Number of platforms needing FIPS-validated modules and whether the vendor holds a current validation	Confirm each module's validation certificate and status before selecting it; ask vendors to state that in writing
Engineering to configure and document encryption	Internal staff or an implementation partner, under a written scope	One-time, with later changes	Count of CUI data flows, key stores and services that need encryption configured	Scope the enclave tightly so fewer systems carry CUI; reuse one documented crypto standard across systems
Key management and certificate tooling	Internal staff, partner or open-source community maintainers	Mostly one-time setup, then recurring operation	Number of keys, certificates and rotation policies; whether an existing PKI is reused	Reuse an existing internal CA where it meets the standard; self-hosted open-source tools can remove license spend, though operating them still costs staff time
Evidence upkeep	Internal compliance and engineering staff	Recurring	Frequency of configuration changes, certificate renewals and module updates that must be recorded	Automate configuration exports and key inventory reports; keep one owner for the crypto evidence set
External testing or review of cryptographic configuration	Independent testing firm or assessor, under written scope	Periodic	Number of in-scope systems, custom cryptography used and depth of test method requested	Ask for a fixed scope listing systems and test methods; avoid custom cryptography that needs extra review
Assessor sampling and review	Independent assessor or certification body	Periodic, per assessment cycle	How many systems and configuration records the assessor samples and how well evidence is organized	Prepare a clean evidence package with system design documents and validation certificates ready before the assessment
Scoring consequence of non-validated encryption	Not a payment; affects contract standing	Applies at each assessment	Under 32 CFR 170.24, 5 points for 3.13.11 versus 3 points when encryption is used but not FIPS-validated; 32 CFR 170.21 allows a POA&M only in the non-validated case	Confirm validation status early; ask the assessor how the scoring applies to your configuration in writing

Self-hosted open-source tools that produce cryptographic protection evidence

Open-source platforms can produce much of the evidence an assessor examines for 03.13.11, including encryption settings, key lifecycle records and certificate inventories. Each tool covers only part of the cryptographic picture, so the organization still has to document which cryptography protects CUI and prove that the underlying module is FIPS-validated.

Nextcloud server-side encryption

Nextcloud's server-side encryption protects file contents at rest on local and external storage, with keys held on the server. The configuration and key settings give an assessor something concrete to examine for the types of cryptography the organization has defined for CUI. The gap is metadata: file names and folder structure are not encrypted, so a CUI-bearing folder name may still disclose information. Confirm whether the PHP OpenSSL build and any external storage paths use FIPS-validated modules in your environment, and document the key recovery arrangement.

OpenBao transit secrets engine

The OpenBao transit engine encrypts and decrypts application data without storing that data, and it supports versioned encryption keys with rotation. Its audit-logged operations and key version history produce evidence that cryptographic keys are managed under defined rules. The gap is that OpenBao does not decide which algorithms the organization must use, and applications still need correct integration. Confirm that the cryptographic module behind OpenBao carries FIPS validation in your build, and record the rotation policy the engine enforces.

FreeIPA with Dogtag certificate authority

FreeIPA includes an integrated certificate authority based on Dogtag for issuing and managing certificates across internal systems. The issuance logs, certificate profiles and revocation records show how the organization controls the certificates protecting CUI in transit. The gap is scope: FreeIPA covers the certificates it issues, so systems enrolled outside it need separate inventory. Confirm the FIPS mode of the host OS and the cryptographic libraries Dogtag uses, and keep a current list of issued certificates for the assessor.

cert-manager for Kubernetes and OpenShift

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 CA. It stores certificates in Kubernetes Secrets and renews them before they expire, which produces a traceable record of issuer, certificate and renewal. The gap is that the choice of issuer determines the cryptography, and a self-signed or public ACME issuer may not meet the organization's defined requirements for CUI. Confirm which issuer and key algorithms your cluster uses, and whether the cryptographic modules involved are FIPS-validated.

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

Your organization owns the requirement. Under 03.13.11, the types of cryptography that protect the confidentiality of CUI are an organization-defined parameter, so only you can name them in your policy and system security plan. Your security leadership also decides how keys are governed, who may approve exceptions and how long they last. A partner can recommend options, but the decisions and the accountability stay with your management.

Defining the cryptography: Choose the approved algorithms, key lengths and modules, and state whether they must be FIPS-validated.
Owning policy and procedures: Write the cryptographic protection policy and the procedures staff follow, and keep them current.
Governing keys: Assign key custodians and decide who may generate, rotate, access and destroy keys.
Approving exceptions: Record any encryption that is not FIPS-validated, with a business justification and a plan of action and milestones where needed.
Interviewing and answering: Personnel with cryptographic and security responsibilities must explain the controls to an assessor.

Before engaging anyone, confirm internally which decisions you have already made and which are still open.

Where organizations fall short on 03.13.11 and how to close each gap

The gaps below cluster around one question: can the organization show which cryptography protects CUI, which modules perform it, and who controls the keys? Each card names a common shortfall, the fix, and the evidence an assessor would expect to see. Ownership of the controls stays with the organization, and an independent assessor judges the result.

Encryption without FIPS validation

Teams often turn on encryption in a product and assume the requirement is met. NIST's discussion recommends FIPS-validated cryptography for protecting CUI, and CMMC scoring gives less credit when encryption is used but is not FIPS-validated. Check each component that touches CUI, record the validated module and its certificate number, and confirm the product is running in the validated mode rather than only shipping a validated library. Evidence: the module validation certificates and configuration exports showing the mode in use.

Undefined cryptography types

The organization must define the types of cryptography it uses to protect CUI confidentiality, and that definition is an organization-defined parameter with no value supplied by NIST. An assessor checks that the value exists and matches what the systems run. Write a short standard that names approved algorithms, key lengths and protocol versions for data in transit and at rest, approve it through the system security plan, and reconcile it against actual configurations. Evidence: the approved cryptography standard and a configuration scan that matches it.

Certificates outside the system boundary

TLS certificates issued for internal services often live in tools nobody inventories, so expiring or weak certificates protect CUI paths the security plan never describes. Maintain a register of every certificate that secures a CUI path, tag each with the system boundary it serves, and automate issuance and renewal where possible. cert-manager can create and renew certificates for Kubernetes or OpenShift workloads and store them in Kubernetes Secrets, but the register itself must still be maintained. Evidence: the certificate inventory and renewal logs.

Unclear key ownership with 03.13.10

03.13.11 asks what cryptography is used, while 03.13.10 covers how keys are generated, distributed, stored and destroyed. Teams often assign both to the same person without writing down the split, and an assessor may find a key with no named owner. Write a responsibility matrix that assigns each requirement to a role, name the system of record for keys, and cross-reference the two requirements in the system security plan so neither is left implicit. Evidence: the responsibility matrix and key custodian records.

No configuration history over time

A correct setting on the day of an assessment does not show that cryptography stayed in place across upgrades, redeployments and emergency changes. Keep versioned configuration for every CUI-handling component, route changes through change control, and retain the diffs. Infrastructure-as-code repositories and configuration management baselines usually provide this trail. Compare the current state against the approved standard on a schedule and record the results. Evidence: change tickets, commit history and periodic configuration scan reports.

Metadata left unencrypted in file stores

Nextcloud server-side encryption protects file contents at rest, with keys kept on the server, but it does not encrypt file names or folder structure. A CUI file name can reveal the content, so the gap is real even when the file body is protected. Decide whether file names are CUI for the purpose of the boundary, restrict where sensitive names are used, and document the residual risk in the security plan. Confirm the current behavior with the vendor and your own tests before relying on it. Evidence: the encryption configuration, test results on stored metadata and the documented risk decision.

What buyers ask about 03.13.11 cost, effort and outside help

How much effort does 03.13.11 cryptographic protection take to meet?

The requirement itself is short, but the effort sits in the work around it: deciding which cryptography types protect CUI, documenting that choice, and proving that every system carrying CUI uses it. Effort rises with the number of systems, data stores, transfer paths and third-party services that touch CUI, and with how much of the environment has no inventory. Under Rev. 3 the organization must define the cryptography types itself, because the requirement has one organization-defined parameter that NIST does not fill in. Ask any quote to break the effort into discovery of CUI flows, cryptographic design and configuration, validation evidence gathering, and a documented review cycle, and to state which of these recur each year.

Can a self-hosted open-source stack meet 03.13.11?

A self-hosted stack can support the requirement, but the platform does not meet it on its own. The organization still has to choose cryptography types, configure them consistently and show evidence. Open-source components can help with that evidence. Nextcloud's server-side encryption protects file contents at rest, though it does not encrypt file names or folder structure, so that gap must be documented or addressed elsewhere. OpenBao's transit engine handles application-level encryption with key rotation, and cert-manager automates TLS certificates in Kubernetes or OpenShift. Confirm with each vendor whether a given module holds FIPS validation for your use, because the assessment looks for validation certificates, not just the presence of encryption.

What does 03.13.11 need from our own staff?

Your staff must own the decisions an outside partner cannot make for you. That includes the organization-defined choice of cryptography types, the risk acceptance for any non-validated encryption, and the policy and procedures for cryptographic protection that the assessment examines. Engineers who run the systems need to explain how the design works during interviews, since the assessment interviews personnel with cryptographic and information security responsibilities and system developers. Expect a named owner, access to design documentation and configuration records, and time from the people who operate key management. Ask a provider to list these internal roles in writing before work starts.

How long does 03.13.11 work take?

No researched duration for this requirement is available, so confirm the timeline in the written scope rather than relying on a general estimate. The schedule depends on how many CUI systems are in scope, whether cryptographic modules already hold validation certificates, how complete the current documentation is, and how quickly your team can answer interview questions. A fixed-scope engagement sets deliverables and dates in writing before work starts, so ask for milestones tied to inventory, configuration, evidence and review. Also confirm whether any follow-on support or retesting is included or billed separately.

Will an assessor accept evidence prepared by a partner?

Yes, partner-prepared evidence can be used, but the assessor makes the judgment. DeployOpen prepares systems, controls and evidence for compliance assessments, and it does not issue audit reports, attestations or certifications. Independent assessors and certification bodies issue those results. Evidence for 03.13.11 typically includes the cryptography policy and procedures, system design documentation, configuration settings and cryptographic module validation certificates. Those artifacts should reflect the organization's own operating environment, and the organization remains responsible for its controls. Confirm with the assessor, before evidence is collected, which formats and sampling they expect.

Can we skip FIPS validation for 03.13.11 under Rev. 3?

Rev. 3 does not remove the FIPS question, since the discussion for 03.13.11 recommends FIPS-validated cryptography for protecting CUI. The organization may define other cryptography types through the organization-defined parameter, but that choice must be justified and tested, and the assessment examines validation certificates. For contracts, the answer also depends on which revision the contract names. The DoD's Class Deviation 2026-O0025, Revision 3 names Rev. 2 explicitly, and Rev. 2 scores 3.13.11 at 5 points when FIPS-validated encryption is used, or 3 points when encryption is used without validation, with the latter allowed only on a plan of action and milestones. Confirm the applicable revision and scoring rules with your contracting officer before deciding.

How DeployOpen scopes and prepares 03.13.11 evidence

DeployOpen works on 03.13.11 Cryptographic protection by first agreeing in writing which systems, data flows and cryptographic types the organization has defined for CUI confidentiality. We then prepare the systems, configuration and documentation that an independent assessor will examine, interview and test. The organization owns its controls, and only the assessor issues any assessment result.

How we scope

The written scope lists each system, data flow and encryption use that carries CUI confidentiality under 03.13.11.
We record the organization-defined cryptography types so the required parameter value is documented and approved by the organization.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.

How we build

We configure self-hosted platforms in the client's own infrastructure to use the agreed cryptographic types and approved key handling.
We deploy key management and certificate services, such as OpenBao, FreeIPA and cert-manager, where the scope calls for them.
We test that encryption is enforced in each in-scope path and record the configuration settings that show it.

How we hand over

We deliver configuration records, architecture diagrams and procedures that map to the examine objects for 03.13.11.
We confirm with the client which FIPS-validated modules and validation certificates apply to each in-scope component.
We document open items and gaps so the organization can decide remediation or a plan of action and milestones with its assessor.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
We help the client keep configurations and cryptographic settings current when platforms are upgraded or new systems join scope.
Assessment decisions, scores and certifications remain with the organization and its independent assessor, not with DeployOpen.