NIST SP 800-171 Rev. 3 is final — what your file-transfer stack has to prove

NIST SP 800-171 Revision 3 reached final status in May 2024, and the defense contractor community has been working through its implications ever since. If you’re a defense contractor or subcontractor handling Controlled Unclassified Information (CUI), Rev. 3 is not a distant regulatory concern — it’s the framework your next CMMC 2.0 Level 2 assessment will be measured against. And several of the changes in Rev. 3 have direct, specific implications for how you configure and document your file-transfer stack.

This post focuses narrowly on file transfer: what changed in Rev. 3 that affects file-transfer controls, which control families your assessor will probe, and what evidence you need to have ready.

What changed in Rev. 3

The most significant structural change in Rev. 3 is the alignment with NIST SP 800-53 Rev. 5 control numbering and organization. If your organization has maintained System Security Plan (SSP) documentation against Rev. 2, the control identifiers have changed. The substance of many controls is similar, but the mapping work to update your SSP is non-trivial and needs to happen before an assessment.

Several substantive changes are relevant to file-transfer workflows specifically.

New organization-defined parameters (ODPs). Rev. 3 introduces organization-defined parameters for many controls, replacing some prescriptive requirements with requirements that the organization define the specific parameter value and document it. This sounds like flexibility, but it’s actually a documentation obligation: where Rev. 2 might have said “encrypt CUI in transit,” Rev. 3 says “encrypt CUI in transit using [ODP: encryption standard]” — and your SSP must specify what that standard is, why you selected it, and how it’s enforced. For file-transfer controls, this means your SSP needs explicit statements about TLS version floors, cipher suite selection, and key length requirements.

Supply chain risk management controls. Rev. 3 added supply chain risk management (SCRM) requirements that weren’t present in Rev. 2. SRMA control SR-02 requires organizations to establish and maintain a supply chain risk management plan. For file-transfer workflows that depend on third-party software, SaaS platforms, or protocol libraries, this creates a documentation requirement: your SCRM plan must address how you assess and monitor the supply-chain risk of your file-transfer tooling.

Enhanced audit and accountability requirements. Rev. 3 strengthened the specificity requirements for audit logging. The logging requirements now more explicitly require that audit records be sufficient to reconstruct events — not just capture that an event occurred, but capture enough context to reconstruct what happened to what data in what context. For file-transfer operations, this raises the bar on what “adequate audit logging” means.

Cryptographic protection controls. The cryptographic protection controls in Rev. 3 align with the updated NIST recommendations on approved cryptographic algorithms, reflecting the post-quantum landscape. While the Rev. 3 controls don’t mandate specific post-quantum algorithms yet, the framework positions organizations to incorporate those requirements as they’re finalized.

Control families that touch file transfer

Three control families generate the most assessor activity for file-transfer stacks.

3.1 Access Control (AC). Access control requirements for CUI handling include limits on who can access CUI, enforcement of separation of duties where appropriate, and controls on information flow. For file-transfer workflows, the relevant controls include:

• AC-02: Account management — every account with access to CUI transfer workflows must be documented, with business justification, and reviewed on a defined schedule. Shared service accounts are a recurring finding; they make it impossible to produce the per-individual audit trail AC-02 requires.
• AC-03: Access enforcement — CUI files must only be accessible to authorized users. Access control at the file level, not just the folder level, may be required depending on how your workflows are structured.
• AC-17: Remote access — if file transfers involve remote access paths (which they almost always do), remote access must be controlled with MFA and documented in your SSP.
• AC-20: Use of external systems — if you’re using a SaaS file-transfer platform, the use of that external system for handling CUI must be documented in your SSP with an assessment of the system’s security posture.

3.3 Audit and Accountability (AU). This family is where assessors spend the most time with file-transfer systems because the audit log is the primary evidence artifact for CUI access.

• AU-02 / AU-12: Audit event generation — the system must generate audit records for file-access events, upload and download events, authentication events, and administrative actions. The audit events must include: who (authenticated identity), what (specific file, specific operation), when (timestamp), and from where (source IP or session context) at minimum.
• AU-09: Protection of audit information — audit logs must themselves be protected from modification and unauthorized access. An assessor will ask whether your file-transfer audit logs can be modified by an administrator with access to the file-transfer system, and whether logs are exported to a SIEM or log management system outside the control of the file-transfer platform admin.
• AU-11: Audit record retention — CUI-related audit records must be retained for a defined period specified in your SSP. The period must be consistent with your incident response requirements — if your IR plan specifies that you may need to investigate events up to 12 months old, your audit logs need to be retained for at least 12 months.

3.13 System and Communications Protection (SC). This family covers the cryptographic controls most directly relevant to file transfer.

• SC-08: Transmission confidentiality and integrity — CUI in transit must be protected using approved cryptographic mechanisms. For file-transfer platforms, this means TLS for web-based transfers and SFTP (not plain FTP) for protocol-based transfers. Your SSP must specify the TLS version floor (NIST recommends TLS 1.2 minimum with TLS 1.3 preferred) and must document how you enforce it.
• SC-12: Cryptographic key management — if your organization manages cryptographic keys for CUI encryption (including customer-managed keys), the key management procedures must be documented, including how keys are generated, stored, distributed, and destroyed.
• SC-28: Protection of information at rest — CUI must be encrypted at rest with approved algorithms. AES-256-GCM is the standard; the ODP in your SSP must specify the algorithm and document how at-rest encryption is verified.

Evidence your CMMC assessor will request

Based on the control families above, here’s what to have ready before a Level 2 assessment involving your file-transfer stack.

System Security Plan section for file transfer. A dedicated section of your SSP that describes your file-transfer system, how it handles CUI, which controls are implemented within the platform versus by organizational policy, and the ODPs for all controls with defined parameters. This section should reference your file-transfer vendor’s technical documentation as supporting evidence.

Account and access control documentation. A current list of all accounts with access to CUI through the file-transfer system, with business justifications, review dates, and authorization records. For service accounts, functional purpose documentation. Evidence that MFA is enforced for all accounts.

Audit log samples. Sample audit log output showing that the system generates required event records (access, upload, download, admin actions) with the required fields (identity, timestamp, file ID, operation). Assessors frequently request a demonstration that the audit log can be queried and exported.

Log retention evidence. Documentation of where audit logs are retained, for how long, and how they’re protected from modification. If logs are exported to a SIEM, show the export configuration and the SIEM retention policy.

Encryption configuration documentation. Vendor documentation or configuration screenshots showing the TLS version floor, cipher suite configuration, and at-rest encryption specification. For customer-managed keys, key management policy documentation.

BAA or CUI handling agreement with vendor. If you’re using a SaaS file-transfer platform, the agreement with the vendor that covers CUI handling obligations. This includes, at minimum, the vendor’s representation that they meet the applicable requirements and ideally their own CMMC or NIST 800-171 attestation documentation.

Incident response plan reference. The section of your IR plan that covers file-transfer-related incidents and specifies the audit log retention period that supports IR investigations.

How SEND-SECURELY.COM maps

Our trust portal includes a NIST 800-171 Rev. 3 control mapping document that covers every Rev. 3 control and specifies, for each, whether the control is implemented by the SEND-SECURELY.COM platform, by customer configuration, or by the customer’s organizational processes outside the platform.

For CMMC 2.0 Level 2 customers, we provide: a pre-filled SSP section template for SEND-SECURELY.COM deployments, sample audit log output for AU-02/AU-12 evidence packages, encryption configuration documentation meeting SC-08 and SC-28 ODPs, and our SOC 2 readiness package and ISO 27001-aligned security documentation for vendor assessment evidence under AC-20.

If you’re in the DIBCAC assessment pipeline and need specific evidence artifacts, contact your account representative. We’ve worked with assessors across many CMMC assessments and know what documentation they ask for.