03.16.03 External system services: requirements and evidence

03.16.03 external system services: what the requirement asks for

The organization must set security requirements for every external provider that processes, stores or transmits CUI, document who is responsible for what, and keep checking that the provider meets those requirements. Picture a team that has just moved CUI into a SaaS collaboration tool or outsourced hosting. Under 03.16.03, the move is not finished when the service goes live. The team has to define the security requirements the provider must satisfy, record which controls the organization keeps and which the provider runs, including responsibilities shared between them, and monitor provider compliance on an ongoing basis. The organization-defined parameter is the list of security requirements the provider must meet, so the organization must write those values itself unless the federal agency it contracts with has already specified them.

This is a new Rev. 3 requirement. NIST's change analysis lists 03.16.03 as one of 19 requirements new in Rev. 3, and it maps to no Rev. 2 requirement. Its source control, SA-9 in SP 800-53 Rev. 5, had been tailored out of Rev. 2 as a control expected to be implemented without being specified. CMMC Level 2 assesses the 110 Rev. 2 requirements, so it has no matching requirement ID. A contractor who only prepares for CMMC may not notice the gap until a contracting officer or assessor asks about provider oversight. The risk is concrete: CUI can leave the organization's boundary through a provider's staff, subcontractors and infrastructure, and the organization remains accountable for it. The provider's own certifications do not transfer that accountability on their own.

Several things make this hard in practice. Contracts with existing providers often predate the requirement and contain no security terms, no breach notice obligations and no right to evidence. Some providers will not share audit reports or configuration details beyond a marketing summary. And the parameter values are often left undefined, so the monitoring has nothing to measure against. Confirm with your contracting officer whether a value has been specified for this parameter, and where it has not, write the security requirements down before you negotiate with providers. Ask each provider for the evidence it can produce and the cadence at which it will produce it.

Which external providers and services fall under external system services

Whether 03.16.03 applies to a provider depends on one question: does the service process, store or transmit CUI. The cards below sort the common provider types by that test and by where they sit relative to the CUI boundary, so the organization can decide which providers must meet its security requirements.

Providers that handle CUI

Any external provider that processes, stores or transmits CUI is in scope. This includes cloud hosting for systems holding CUI, managed email or file sharing used to send CUI, and offsite backup services that hold CUI copies. Start with the system security plan and data flow diagrams, then list every provider that touches those flows. Confirm the list with the people who own each data path, because shadow SaaS tools often appear only in those interviews.

Hosting and managed services at the boundary

Colocation, managed Kubernetes, managed databases and MSP administration often sit on the edge of the CUI boundary. A provider that administers infrastructure with access to CUI systems may be in scope even when it never reads the data. Check whether the provider has administrative access, can reach encryption keys or can change configurations. Those capabilities usually decide the question more than where the data physically resides.

Providers outside the boundary

Some providers handle only metadata, billing records, marketing data or general corporate information that contains no CUI. Their services are generally outside 03.16.03 if the organization can document that CUI never reaches them. Record that determination with its reasoning, because assessors test the scoping decision as well as the requirement. Revisit it when a provider adds features that change what data it receives.

Support tickets and troubleshooting access

Support channels are a common gap. A help desk, a vendor engineer who joins a session or a log file attached to a ticket can expose CUI even when the service is not meant to receive it. Define a rule for what staff may share with support, and check whether the provider's remote access sessions are recorded. Tell the provider in the agreement which data types must never appear in tickets.

Links to 03.01.20 use of external systems

03.01.20 covers the organization's own use of external systems, meaning the terms and controls that govern when staff can connect to or store CUI on systems it does not own. 03.16.03 addresses the provider side. The two requirements meet where an external service is used for CUI: the access rules set under 03.01.20 are the place to record which providers are approved, and 03.16.03 sets what those providers must meet.

Security requirements the organization sets

03.16.03 has one organization-defined parameter: the security requirements providers must satisfy. NIST does not supply those values, so the organization must write them. Decide which controls, certifications or contract clauses apply to each provider type, and document the values in the system security plan. Assessors will check that the parameter is defined and that the requirements match the providers in scope.

How an assessor tests external system services under SP 800-171A

This table breaks down how an assessor tests 03.16.03 under SP 800-171A Rev. 3, row by row across the examine, interview and test methods, with the objects requested and the findings that usually fail. Read it as a checklist of the evidence to have ready before an assessment starts.

Assessment element	What the assessor requests or checks	What passes and common findings
Determination statements (three)	Assessor confirms the organization defines and documents the security requirements that external providers must meet, documents user and provider responsibilities, and monitors provider compliance on an ongoing basis.	Passes when each of the three statements has a documented, current answer. Common finding: requirements exist only in a contract clause with no internal record of how they are monitored.
ODP determination statement	Assessor checks that the organization-defined parameter, the security requirements external providers must satisfy, has a defined value.	Passes when the value is written into policy or the system security plan. Common finding: the ODP is left blank because no federal agency specified it, so the requirement is not complete.
Examine method	Acquisition and system and services acquisition policy and procedures, procedures for monitoring provider compliance, and acquisition documentation such as contracts and service agreements.	Passes when documents name the providers in scope, the security requirements, and the roles for each party. Common finding: contracts that are silent on CUI handling or on audit rights.
Interview method	Personnel with acquisition responsibilities and the external providers of system services, asked how requirements are set, communicated and checked.	Passes when staff describe the same process the documents show. Common finding: procurement staff are unaware that a provider touches CUI, so no one triggers the monitoring step.
Test method	Organizational processes for monitoring provider compliance on an ongoing basis, tested by observing or reviewing how the monitoring actually runs.	Passes when monitoring records show reviews over time, such as renewed attestations or reviewed provider reports. Common finding: a one-time review at onboarding with no later evidence of monitoring.
Shared responsibility records	Documented split of duties between the organization and each provider for CUI-related controls.	Passes when each control has a named owner on each side. Common finding: responsibilities described only in general terms, leaving gaps in logging or incident notification.
Scoping check (illustrative)	Inventory of every external service that processes, stores or transmits CUI, compared against the provider list used in the assessment.	Passes when the list matches the systems in the system security plan. Common finding: SaaS tools adopted by business teams that never entered the inventory.

How to implement external system services in order

This sequence turns 03.16.03 into working governance: you find every provider that touches CUI, set the security bar they must meet, write it into contracts, document who does what, and keep checking that providers still meet it.

Inventory every external service that touches CUI
List each external system service that processes, stores or transmits CUI, including cloud platforms, managed security services, SaaS collaboration tools, payroll or HR processors, offsite backup and support or maintenance providers. Record the service, the provider, the CUI categories involved, the connection method and the internal owner. Confirm the list with system owners and procurement, since shadow SaaS is a common gap. The step closes when the inventory is approved and linked to the system boundary in your system security plan.
Define and assign the ODP security requirements
03.16.03 has one organization-defined parameter: the security requirements that external providers must satisfy. NIST does not assign this value, so if your federal customer or contract does not specify it, your organization must. Write a short requirements set for providers, such as the controls from your own system security plan, encryption expectations, incident notification and access review. Ask the contracting officer or customer whether they have published a value. The step closes with an approved requirements document that names the parameter value and the owner who approved it.
Update contracts and flow-down terms
Using the approved requirements, amend each provider agreement or add a security addendum that obligates the provider to meet them, to report security incidents affecting CUI, to support assessments or evidence requests and to flow the same obligations to its own subcontractors where CUI is involved. Legal and procurement own this work, and counsel should review terms against any applicable clause. Where a provider will not accept terms, record the gap and the compensating decision. The step closes when each in-scope agreement is signed or a documented exception is approved.
Document roles and shared responsibilities per service
For each external service, write a responsibility matrix that states what the provider operates, what your organization configures and manages, and which user roles hold which duties, such as account provisioning, key management, log review and incident response. Map these responsibilities to the relevant requirements in your system security plan so no requirement falls between parties. Ask providers for their shared responsibility documentation and compare it with your own. The step closes when every in-scope service has a signed-off matrix stored with its contract.
Set up ongoing monitoring and a recurring review cadence
Assign an owner to monitor each provider's compliance with the agreed requirements on an ongoing basis. Collect evidence such as current attestation reports, certifications, penetration test summaries, incident notices and subprocessor changes, and check them against the requirements from step two. Set a review cadence for each provider based on its risk and record findings in your plan of action and milestones where gaps appear. The step closes when the first monitoring cycle is complete, evidence is filed and any gaps are tracked to closure.

Evidence that shows external system services is met and stays current

An assessor testing 03.16.03 looks for a chain of records: the security requirements the organization set for providers, the contract terms that bind providers to them, and dated proof that someone checked compliance afterward. The cards below cover the artifacts that form that chain and the triggers that keep each one current between assessments.

Defined provider security requirements

This is the organization-defined parameter for 03.16.03: the security requirements external service providers must satisfy when they handle CUI. Because NIST does not assign values to ODPs, the organization must write them down, typically as a baseline that covers access control, encryption, incident notification, data location and sanitization at exit. Check that the document names the systems and CUI types it applies to and carries an owner and an approval date. Confirm the requirements align with the system security plan so the two do not contradict each other.

Executed contract clauses

Requirements on paper do not bind a provider until the signed contract or order form contains them. Assessors typically sample contracts for clauses on CUI handling, incident notification timing, audit or evidence access, subcontractor flow-down and termination data return. Record which clause maps to which defined requirement so the link is visible. Ask providers that operate on standard terms to provide the signed addendum, not only a web policy.

Shared responsibility matrix

03.16.03 requires roles and responsibilities for external services to be defined and documented, including those shared with the provider. A matrix lists each control area, such as identity administration, encryption key custody, logging, patching and backup, and states whether the organization, the provider or both own it. Gaps usually appear where both parties assume the other is responsible. Review the matrix whenever the provider changes its service tier or architecture, and confirm the provider has signed off on its column.

Provider due diligence records

Before and during the relationship, the organization gathers evidence that the provider meets the defined requirements. This may include independent attestation reports, certifications with stated scope, questionnaire responses and results of the organization's own review. The record should show what was reviewed, who reviewed it, what gaps were accepted and when the next review is due. Note that an attestation covers only the scope it names, so confirm that scope includes the services that touch CUI. Only the independent auditor that issued a provider's report can vouch for that report.

Dated monitoring records and owners

The requirement to monitor provider compliance on an ongoing basis is tested by dated records, not by policy wording. Keep a register listing each provider, the monitoring activity, the person responsible, the date performed and the outcome, along with follow-up tickets for findings. Assessors will look for entries across the review period, so a single annual review with no interim activity is a visible gap. Set calendar reminders tied to the owner's name so the register does not go stale between assessments.

Acquisition procedure and review triggers

The acquisition procedure is the written process that brings a new provider into scope: it requires the security requirements to be checked before signature, the responsibility matrix to be completed and the provider to be added to the monitoring register. Keep it current by attaching review triggers, including contract renewal, a change in the provider's subprocessors or hosting location, a reported incident at the provider and any change to the CUI the provider handles. Confirm the procedure is the one staff actually follow by sampling recent onboardings.

What meeting external system services costs in money and effort

This table breaks down the cost components of meeting 03.16.03 by who is paid, whether the cost is one-time or recurring, and what pushes it up. Use it to structure a quote request so each component is priced separately and can be compared across bidders. No figures are stated because none were supplied; ask each party to price the components in writing.

Cost component	Who is paid or who spends effort	One-time or recurring	What drives it up and what to ask for in a quote
Provider contract changes	Legal and procurement staff, and sometimes the provider's counsel	One-time per contract, with recurring review at renewal	Drives up: number of CUI providers and contracts that predate the requirement. Ask: whether the quote covers amending each contract to add security requirements and roles, and how many contracts are in scope.
Defining requirements and mapping responsibilities	Internal GRC or engineering staff, or the implementation partner	One-time, then updated when services or data flows change	Drives up: the number of services that process, store or transmit CUI and how many shared responsibilities need documenting. Ask: whether the scope includes a responsibility matrix per provider and who signs it off.
Monitoring provider compliance	Internal GRC staff or a retained third party	Recurring, typically per provider and per review cycle	Drives up: the number of providers and how often evidence is refreshed. Ask: the review frequency assumed, what evidence is requested from each provider, and who does the follow-up.
Tooling and platform labor	Internal staff or implementation partner for setup, data entry and workflow	Mostly one-time setup, with recurring maintenance	Self-hosted open-source tools remove license spend but not labor to install, configure and maintain them. Ask: whether the quote prices setup, hosting, upgrades and support separately.
External review of provider evidence	Independent reviewer or security consultant	Recurring for high-risk providers, otherwise occasional	Drives up: weak or outdated provider evidence and high-impact CUI processing. Ask: what review depth is included and what happens when a provider cannot supply current evidence.
Auditor or assessor sampling time	Independent assessor, billed by the assessment firm	Recurring with each assessment cycle	Drives up: more providers sampled and poorly organized evidence. Ask the assessor to confirm the sample size approach and which provider records they expect in advance. DeployOpen does not issue assessment results.
Internal interview and coordination time	Acquisition, security and system owners	Recurring during assessments and contract renewals	Drives up: unclear ownership of providers. Ask: whether a named owner per provider is assigned before work begins.

Open-source tools that can hold provider evidence for this requirement

03.16.03 asks for three things to be provable: the security requirements placed on providers, the division of responsibilities, and ongoing monitoring of provider compliance. The three tools below cover different parts of that evidence trail, and none of them replaces the organization's own judgment or an independent assessor's work.

Assessment tracking with CISO Assistant

CISO Assistant (AGPL-3.0-only) is a self-hosted governance platform that ships with NIST SP 800-171 among more than 200 frameworks. It can record assessments against the requirements and keep the audit work in one place, so a provider's answers to your security requirements can be tied to the requirement they satisfy. Check whether the bundled NIST SP 800-171 framework version matches the revision your contract names, and confirm how it models external providers before you rely on it as a provider register.

Version history for responsibility matrices

XWiki (LGPL-2.1-or-later) keeps every change to a page under version control, recording what changed, when and by whom. For 03.16.03, this matters for the roles and shared responsibilities documents, because you can show an assessor how a provider's responsibilities were defined at a given date and who approved each change. Confirm that your deployment keeps the history for the pages you need and that your retention rules meet your own records policy.

Role-based control of acquisition procedures

BookStack (MIT) assigns abilities through roles and lets you override permissions per role at the shelf, book, chapter or page level. You can keep provider acquisition procedures editable only by the acquisition team and readable by security staff, which supports the documented roles that 03.16.03 expects. Test the permission model with a sample user from each role before you rely on it, and confirm whether provider-facing content needs a separate instance.

Confirm fit and license obligations

Each tool covers part of the evidence, and none of them holds a provider's own certifications or reports. Before adoption, confirm that each tool fits your provider register, your monitoring cadence and your data handling rules, and that it supports the evidence an assessor will request. Also confirm your license obligations: AGPL-3.0-only can carry source disclosure duties if you modify and offer the software over a network, and LGPL and MIT terms differ. Your legal team should review these with the deployment design.

Who does what for external system services: your team, a partner and the auditor

Your organization owns 03.16.03. NIST places responsibility for applying SP 800-171 and resolving compliance issues with the federal agency that holds the contract or agreement with you, so your leadership must be able to show that the decisions behind each external provider relationship were made by people who are accountable for them. Your team sets the security requirements that providers must meet, decides which providers may handle CUI, signs the contract terms, accepts residual risk when a provider cannot meet a requirement, and runs ongoing monitoring of provider compliance.

Provider requirements: Define the security requirements that providers handling CUI must satisfy, filling in the organization-defined parameter for this requirement.
Contract decisions: Negotiate terms that carry the requirements, incident notice duties and data handling rules into each agreement.
Risk acceptance: Record who approved any gap, what compensating control applies and when the decision is reviewed.
Ongoing monitoring: Review provider evidence on a schedule you set and act on changes in a provider's posture.
Roles and shared responsibility: Confirm which duties sit with your staff and which sit with each provider.

Before accepting any provider's evidence, check that a named owner on your side signed off on the requirement it supports.

Where organizations fall short on external service providers and how to close it

Most gaps under 03.16.03 come from the same root problem: the organization has not written down which external providers touch CUI, what they must do, and who does what. Each card below names one gap, why it matters for the assessment, and the fix an assessor will look for.

No inventory of providers touching CUI

Many organizations cannot say which SaaS tools, managed service providers, hosting platforms or support vendors process, store or transmit CUI. Without that list, the organization cannot define security requirements for providers or monitor them. Build the inventory from the system security plan data flows, then check it against accounts payable, single sign-on application lists and cloud billing. Ask each business owner to confirm whether their tools receive CUI, including support tickets and email attachments.

Undefined security requirements parameter

03.16.03 has one organization-defined parameter: the security requirements that external providers must satisfy. NIST does not assign values to it, and a nonfederal organization that leaves it blank has no measurable standard to hold providers to. Define a short, versioned set of requirements, such as encryption of CUI at rest and in transit, incident notification timing, and U.S. data location where the contract requires it. Confirm with the contracting agency whether it has already specified values for this parameter.

Contracts without security clauses

A provider contract that covers price and uptime but says nothing about CUI handling leaves the organization unable to enforce anything. Add clauses that mirror the defined security requirements, grant the right to request evidence such as independent assessment reports, require notice of security incidents, and state what happens to CUI at contract end. Procurement and legal should review the clauses before renewal, and existing contracts should be amended where the provider agrees.

Shared responsibilities left implicit

Teams often assume the provider handles encryption, logging or access reviews, while the provider assumes the customer does. A responsibility matrix for each provider settles this. List each control area, state whether the organization, the provider or both are responsible, and name the person who owns the organization's side. Keep the matrix with the system security plan so an assessor can trace each responsibility to a named owner and a contract term.

Monitoring only at onboarding

Some organizations review a provider's security documentation once, file it, and never look again. Clause 03.16.03 calls for ongoing monitoring of provider compliance. Set a review calendar tied to risk, collect updated assessment reports and security attestations, track provider incidents and changes to subprocessors, and record each review with its outcome. Assessors look for the procedure, the cadence and dated records that show the procedure ran.

Questions buyers ask about external system services and provider monitoring

How much effort does 03.16.03 take for a small contractor?

For a small contractor, the effort is mostly an inventory and paperwork exercise, but it recurs. Start by listing every external service that processes, stores or transmits CUI, including email, file sharing, collaboration tools, backup providers and managed IT. For each one, record the security requirements you expect the provider to meet, the responsibilities you keep and the responsibilities the provider keeps, and how you will check their compliance over time. NIST does not publish a time estimate for this requirement in the sources available to us, so the effort depends on how many providers you use and how much evidence each one already gives you. Ask your assessor and your prime contractor which providers they expect to see documented before you size the work.

Does a SaaS provider's SOC report or FedRAMP status satisfy 03.16.03?

Neither one satisfies 03.16.03 automatically. A SOC report or FedRAMP authorization is evidence to review, and it can support the requirement if it covers the controls you rely on for CUI. You still need to define the security requirements you expect the provider to meet, document which responsibilities belong to you and which belong to the provider, and show that you monitor compliance on an ongoing basis. Check the report's scope, period and carve-outs, and confirm that the services you use are inside the authorized or audited boundary. The assessor will look at your documented expectations and your monitoring process, not only the provider's certificate.

What does the work need from the internal team?

The internal team owns the requirement, so it needs people who can make decisions about providers and who can keep records current. Typically that means someone from acquisition or procurement, someone from IT or security who understands where CUI flows, and a person who can approve or reject provider risk. The assessment procedure for 03.16.03 examines the acquisition policy, procedures for monitoring provider compliance and acquisition documentation, and it interviews the people with acquisition responsibilities and the providers themselves. Plan for those people to produce the documents, answer interview questions and review monitoring results on a regular schedule.

Can an organization meet 03.16.03 without outside help?

Yes, an organization can do this alone if it has the skills to write the policy, maintain the provider inventory and review provider evidence. The work is documentation and monitoring rather than new technology, so many organizations handle it in house. Outside help is most useful when the team lacks experience with assessment procedures, when many providers handle CUI, or when the system security plan needs to reflect shared responsibilities accurately. An implementation partner can prepare the documents, the monitoring workflow and the evidence trail, but the organization still owns its controls and an independent assessor still judges them.

How long does it take to get evidence from external providers?

The time depends on the provider, not on a figure NIST publishes. Some providers keep current audit reports and security documentation that they can share quickly under a nondisclosure agreement. Others need contract changes, a review of their CUI handling or a new report, which can take longer. Start by asking each provider which evidence they hold, how current it is and who on their side can answer security questions. Ask for the scope of any report, the date of its most recent review and the process for notifying you of material changes. Build those requests into your acquisition timeline before your assessment window opens.

What does a fixed-scope engagement with DeployOpen cover for this requirement?

A fixed-scope engagement covers the deliverables agreed in writing before work starts. For 03.16.03, that can include a review of your provider inventory, drafts of acquisition and monitoring procedures, a shared responsibility model for each in-scope service, and a monitoring workflow for ongoing provider checks. DeployOpen prepares systems, controls and evidence for the assessment, but it does not issue assessment reports or certifications, and an independent assessor makes the determination. The exact scope, deliverables and timeline come from the written statement of work. Ask for it to name each provider and document that will be produced, and state which parts remain with your team. Ongoing monitoring and periodic reviews can be handled through a retainer if you want continued support.

What should I confirm with my assessor about provider monitoring?

Confirm early how your assessor will test the monitoring part of the requirement. The assessment method for 03.16.03 looks at whether you have a defined process for monitoring provider compliance and whether that process actually runs. Ask which records they expect to see, how often they expect monitoring to happen and whether they want to interview your provider contacts. Also confirm how they treat providers that hold evidence under a different framework, since a SOC report or FedRAMP package may need to be mapped to your own requirement set. Get those answers in writing so the evidence you prepare matches what the assessor will test.

How DeployOpen prepares external system services evidence

DeployOpen helps organizations prepare the systems, documents and monitoring records that show how external service providers handling CUI are held to defined security requirements. The organization still owns its controls and supplier decisions, and an independent assessor reaches the conclusion on compliance.

How we scope

Inventory every external system service that processes, stores or transmits CUI in the environment in scope
Agree with the client which organization-defined security requirements providers must satisfy for 03.16.03
Set out in the written scope which documents, tools and monitoring processes are included, with fixed deliverables and timelines

How we build

Configure the platform records that hold the provider register, role assignments and shared responsibility matrix
Set up a recurring review workflow so provider compliance evidence is collected and tracked on an ongoing basis
Integrate the provider records with the system security plan and related 03.15 and 03.17 documentation where the client uses them

How we hand over

Deliver the shared responsibility documentation, provider roles and monitoring procedures in an editable, version-controlled form
Map each evidence item to the examine, interview and test objects that SP 800-171A Rev. 3 lists for 03.16.03
Train the client's acquisition, security and compliance staff to run the monitoring process and keep records current

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after handover, if the client wants it
Review the monitoring records at agreed intervals and update them when providers, services or CUI flows change
Confirm with the client's assessor which evidence format and depth they expect before the assessment begins