External System Services is the requirement that governs the cloud providers, managed service providers, and subcontractors who touch your Controlled Unclassified Information (CUI). It is part of the System and Services Acquisition (03.16) family, and for most contractors it is one of the highest stakes requirements in the publication, since so much CUI now lives in somebody else's environment. External System Services (03.16.03) has three (3) parts: require external system service providers to comply with defined security requirements, define and document user roles and responsibilities including shared responsibilities with those providers, and implement processes to monitor provider compliance on an ongoing basis. Per the NIST discussion, the responsibility for managing risks from the use of external system services remains with the organization charged with protecting CUI.
A common difficulty with this requirement is signing a cloud contract and assuming the provider's compliance is now the provider's problem. It is not. The NIST discussion is explicit that the risk stays with you, and R3 adds an ongoing monitoring obligation that is the net-new piece of this requirement. Teams also skip the shared responsibility documentation, which is exactly where control gaps hide: both sides assume the other one handles a given control, and nobody does.
Where things stand for companies facing the transition from NIST 800-171 R2 to R3:
The following is reproduced verbatim from NIST 800-171 R3, requirement 03.16.03 External System Services. Only the formatting has been adjusted for readability. This requirement has three (3) lettered parts:
The source control is SA-09 from NIST 800-53. The bracketed assignment in part a is the Organization-Defined Parameter (ODP): the security requirements providers must satisfy. Per the NIST discussion, organizations establish relationships with external service providers in a variety of ways, including business partnerships, contracts, interagency agreements, lines of business arrangements, licensing agreements, joint ventures, and supply chain exchanges, and service-level agreements define expectations of performance, describe measurable outcomes, and identify remedies, mitigations, and response requirements for instances of noncompliance. The NIST discussion also notes that this requirement is related to Use of External Systems (03.01.20). You can read the requirement directly at NIST 800-171 R3, 03.16.03 (p. 71).
One (1) value sits inside this requirement. Depending on your contract, your organization may be permitted to define it. Organizations in the DIB subject to CMMC are not, because the DoD has defined it as policy.
The value below comes from Attachment A of the DoD Chief Information Officer (CIO) memorandum dated 10 April 2025 (signed David W. McKeown). The memo identifies each parameter by requirement sub-part, while NIST 800-171A R3 identifies the same parameter by ODP number. Both identifiers appear below so you can match your System Security Plan (SSP) language to either document.
The assigned value for 03.16.03.a, quoted from the memo:
The memo states that its values "will be updated as necessary," so confirm against the current version before writing them into policy.
NIST 800-171A R3 breaks 03.16.03 into four (4) assessment objectives: one (1) Organization-Defined Parameter (ODP) and three (3) determination statements. These AOs are:
Note that A.03.16.03.a is not satisfied merely by requiring compliance in a contract: the objective states that the providers comply. If you are a DoD contractor, the ODP is specified. Per the DoD-specified ODP value in ComplianceForge's NIST 800-171 R3 Transition Guide, the security requirements (ODP[01]) are that cloud service providers be Federal Risk and Authorization Management Program (FedRAMP) Authorized at the FedRAMP Moderate (or higher) baseline in accordance with the FedRAMP Marketplace, or meet security requirements established by the government equivalent to the FedRAMP Moderate (or higher) baseline, and that all other external service providers must meet NIST 800-171 R2. The full guidance on assessment methods and objects, is in NIST 800-171A R3, 03.16.03 (p. 93).
Examine: system and services acquisition policy and procedures; procedures for monitoring security requirement compliance by external service providers; acquisition documentation; contracts; service-level agreements; interagency agreements; licensing agreements; list of security requirements for external provider services; assessment results or reports from external service providers; SCRM plan; system security plan.
Interview: personnel with acquisition responsibilities; external providers of system services; personnel with SCRM responsibilities; personnel with information security responsibilities.
Test: organizational processes for monitoring security and privacy control compliance by external service providers on an ongoing basis; mechanisms for monitoring security and privacy control compliance by external service providers on an ongoing basis.
03.16.03 maps from elements of NIST 800-171 R2 requirement 3.1.20 (verify and control or limit connections to and use of external systems):
Mapped against the four (4) AOs, three (3) are indirect (moderate effort) and one (1) is net new (significant effort), with none direct and none unmapped. R2 handled external systems primarily as an access control question about connections. R3 reframes it as an acquisition and provider-management question, splitting the concern across Use of External Systems (03.01.20) for the connection side and this requirement for the provider side. The genuinely new obligation is ongoing monitoring of provider compliance, which turns a point-in-time contract check into a continuous activity.
Source Control in NIST 800-53 R5:
Secure Controls Framework (SCF) Crosswalk
Organizations running a single control set across multiple frameworks can satisfy 03.16.03 through the following SCF controls:
The crosswalks from NIST 800-171 R3 and NIST 800-171A R3 to the SCF are available at no cost through the SCF Set Theory Relationship Mapping (STRM): https://securecontrolsframework.com/start-here/set-theory-relationship-mapping-strm. The STRM also carries the relationship type for each mapping (Equal, Subset Of, Intersects With), which tells you whether an SCF control fully satisfies the requirement or only part of it. Mapping above taken from SCF 2026.3.
The following are issues teams may encounter rather than certainties. They are about ongoing monitoring and shared responsibility, each of which needs documented evidence of due diligence and due care such as policies, standards, procedures, and configuration screenshots:
Reasonable objective evidence for an assessment is often subjective. The following examples of evidence to address NIST 800-171 R3 03.16.03 are sourced from the SCF Evidence Request List (ERL), available at https://securecontrolsframework.com/free-content/scf-download. These ERL artifacts are mapped to NIST 800-171 R3 03.16.03 through SCF controls. They establish a starting point for discussions on what an organization needs to have for evidence of due diligence and due care to withstand external scrutiny by an assessor or regulator.
Alongside these, keep the System Security Plan (SSP) narrative for 03.16.03 recording the ODP values you adopted.
With three (3) AOs mapping indirectly and one net new, 03.16.03 is a significant lift, largely because it depends on other organizations moving at their pace rather than yours. A realistic sequence:
What value does the DoD require for the organization-defined parameter in NIST 800-171 R3 03.16.03? R3 leaves the value to the organization. For the DIB, the DoD set it in the 10 April 2025 memorandum under ODP identifier 03.16.03.a: 1. For cloud service providers: (i) FedRAMP Authorized at the FedRAMP Moderate (or higher) baseline in accordance with the FedRAMP Marketplace; or (ii) meets security requirements established by the government equivalent to the FedRAMP Moderate (or higher) baseline. 2. All other external service providers must meet NIST SP 800-171 R2.
How many assessment objectives does NIST 800-171 R3 03.16.03 have? NIST 800-171A R3 breaks 03.16.03 into four (4) assessment objectives: one (1) Organization-Defined Parameters (ODPs) and three (3) determination statements. An assessor works through each one separately, so each needs its own evidence.
Which NIST 800-53 R5 control does NIST 800-171 R3 03.16.03 come from? SA-09.
Where does NIST 800-171 R3 03.16.03 sit in the NIST 800-171 R3 Kill Chain? Phase 3e, Establish The Compliance Scope for parts b; Phase 4c, Risk Management Practices for parts a; Phase 4e, Risk Management Practices for parts c. The Kill Chain is a phased model for sequencing R3 implementation, and it assigns this requirement to that phase.
03.16.03 External System Services requires your external providers to meet defined security requirements, documents who is responsible for what including shared responsibilities, and monitors provider compliance on an ongoing basis. It maps indirectly from elements of R2 3.1.20, with ongoing monitoring as the net-new obligation. The recurring problem is treating a signed contract as the finish line. Inventory the providers touching your CUI, hold cloud services to FedRAMP Moderate and others to NIST 800-171 R2 for DoD work, map the shared responsibilities so nothing falls between you and the provider, and keep checking rather than checking once.
Authoritative sources:
Authoritative sources:
This guide reproduces U.S. Government text from NIST 800-171 R3 and NIST 800-171A R3 and references the DoD ODP memorandum of 10 April 2025. It is educational, not legal or assessment advice. Last reviewed: 2026-09-22.
