SA-9: External System Services

To meet the sa-9: external system services requirement, you must ensure every third party providing system services to your environment contractually agrees to your security and privacy requirements, and you verify they operate required controls throughout the relationship. Operationally, this is a defined intake, contracting, oversight, and evidence-retention workflow tied to each external service and the data/system boundary it touches. ¹

Key takeaways:

• SA-9 is a “provider must comply” control: contract terms plus ongoing oversight, not a one-time questionnaire. ¹
• Scope is broader than “vendors”; it includes any external system service connected to your system or handling your data. ¹
• Auditors will ask for proof by service: who owns it, what requirements apply, and recurring evidence that the provider meets them. ¹

SA-9 sits at the exact point where your internal controls stop and a third party’s controls begin. If a cloud provider hosts your application, a managed service provider administers endpoints, or a SaaS platform processes regulated data, your risk posture depends on security and privacy commitments you do not directly operate. SA-9 addresses that gap by requiring you to (1) specify your security and privacy requirements for external system services and (2) require providers to comply and employ the controls you identify. ¹

For a CCO, Compliance Officer, or GRC lead, the fastest path to operationalizing SA-9 is to treat it as a repeatable lifecycle control: intake and classification of external services, contract clauses that bind providers to your requirements, defined oversight routines (including evidence collection), and clean traceability from each service to the controls it must meet. This page gives you a requirement-level implementation approach: who owns what, what artifacts to keep, how to prepare for exams, and how to avoid the common failure mode of “we asked once at onboarding, then never looked again.” ¹

SA-9: External system services requirement (plain English)

SA-9 requires you to make external system service providers follow your organization’s security and privacy requirements and to ensure they operate specified controls. Put differently: if you rely on a third party to run, host, manage, monitor, or process anything that affects your system’s confidentiality, integrity, or availability, you must (a) set requirements, (b) bind the provider to them, and (c) maintain oversight evidence that the provider meets them. ¹

The practical outcome an assessor expects: you can pick any in-scope external service and show the security/privacy requirements that apply, the contract terms that require them, and the current evidence that the provider is meeting them.

Regulatory text

“Require that providers of external system services comply with organizational security and privacy requirements and employ the following controls: {{ insert: param, sa-09_odp.01 }};” ²

What the operator must do with this text

• Define “organizational security and privacy requirements” for external services in a way that is specific enough to contract and test (for example, incident reporting, access control, encryption, audit logging, vulnerability management, subcontractor controls).
• Identify which controls external providers must “employ” for the type of service and system boundary involved.
• Make the requirement enforceable through procurement gating and contract language (MSA/SOW/DPA/SLAs).
• Prove ongoing compliance by collecting and reviewing evidence on a recurring basis, not only at onboarding. ¹

Who SA-9 applies to

Entity scope

• Federal information systems implementing NIST SP 800-53 controls. ¹
• Contractor systems handling federal data where NIST SP 800-53 is a contractual or program requirement. ¹

Operational scope (what counts as an “external system service”)

Treat SA-9 as applying when a third party:

• Hosts workloads or data (IaaS/PaaS/SaaS).
• Administers infrastructure (managed service providers, SOC, NOC).
• Provides identity, monitoring, logging, ticketing, CI/CD, or backup platforms that connect to your environment.
• Processes your data in a way that affects privacy obligations (customer support platforms, analytics, communications tooling).

A clean test: if the third party’s failure becomes your incident, it belongs in SA-9 scope.

What you actually need to do (step-by-step)

1) Build and maintain an external system services inventory

Create a single inventory list with, at minimum:

• Service name, provider legal entity, service owner (internal), and business purpose
• Data types processed/stored/transmitted
• Connectivity/integration type (API, agent, SSO, network peering)
• System boundary mapping (what system(s) it supports)
• Criticality tier (high/medium/low) based on impact if the service fails

Exam tip: auditors often fail SA-9 implementations because the organization cannot enumerate external system services consistently across IT, Security, Procurement, and business units. ¹

2) Define a “SA-9 requirements profile” by service tier

Write a requirements matrix that translates “organizational security and privacy requirements” into checkable obligations, such as:

• Security governance: policies, background checks for privileged staff where relevant
• Access control: SSO/MFA support, least privilege, privileged access management expectations
• Data protection: encryption requirements, key management expectations, data retention/deletion
• Logging and monitoring: audit logs availability, retention, and access for investigations
• Vulnerability management: patching expectations, penetration testing posture, disclosure timelines
• Incident response: notification expectations, cooperation, evidence preservation
• Subcontractors: flow-down requirements, approval rights for critical subprocessors

Keep it short enough to contract and measure. If your matrix is a narrative document, it will not survive procurement pressure.

3) Add procurement gating (no contract, no connection)

Operationalize a hard gate:

• No production integration, credentials, network access, or data sharing until the provider has accepted your SA-9 requirements and you have documented evidence review commensurate with risk.

If you need a “break glass” path for urgent business, document the exception with compensating controls and a deadline to remediate.

4) Contractually bind the provider to requirements

Your contracts should clearly include:

• Security and privacy requirements reference (attachment or incorporated policy)
• Right to receive evidence (e.g., SOC 2 report, ISO certificate, pen test summary) as applicable to your program
• Incident notification and cooperation terms aligned to your internal incident process
• Subprocessor/subcontractor flow-down requirements
• Audit/assessment rights appropriate to your risk and negotiation posture
• Termination and data return/destruction requirements

Common hangup: teams rely on a standard DPA only. SA-9 is broader than privacy; it covers security and operational controls too. ¹

5) Implement ongoing oversight and evidence collection

Create an oversight cadence tied to tier:

• Track the provider’s evidence receipt dates and review outcomes.
• Document review notes: what changed, identified gaps, and whether you accepted risk.
• Monitor for material changes: new subprocessors, platform architecture changes, major outages, breach disclosures.

Daydream can help here by mapping SA-9 to a named control owner, a documented procedure, and a recurring evidence checklist so oversight doesn’t depend on tribal knowledge. ¹

6) Tie each external service back to your internal control environment

For each critical external service, record:

• Which internal controls depend on the provider
• Which controls are “inherited” versus “customer responsibility” (shared responsibility model)
• Where evidence is stored and who reviewed it

Assessors want traceability. If you cannot show how provider controls support your system’s control implementation, SA-9 will feel “papered.”

Required evidence and artifacts to retain

Keep artifacts at two levels: program-level (how you run SA-9) and service-level (proof for each provider).

Program-level artifacts

• SA-9 control narrative: scope statement, roles, procedure, and oversight cadence ¹
• External system services inventory template and current inventory export
• Requirements matrix (security + privacy) by tier and service type
• Procurement gating workflow (ticketing or intake form) with approval steps
• Exception process and risk acceptance template

Service-level artifacts ²

• Contract package: MSA/SOW/DPA and security exhibit
• Evidence received (as applicable to your program): attestation reports, certifications, pen test summaries, vulnerability disclosure posture, incident response commitments
• Completed review record: reviewer name, date, findings, remediation requests, acceptance rationale
• Access/integration approval record: who approved connectivity and under what conditions
• Ongoing monitoring notes (material changes, renewals, known incidents)

Common exam/audit questions and hangups

Expect questions like:

• “Show me your full list of external system services connected to System X.”
• “Pick one high-impact provider. Where in the contract do they agree to your security and privacy requirements?” ¹
• “What controls are you requiring the provider to employ, and how did you decide?” ¹
• “What evidence do you collect, who reviews it, and how do you track issues to closure?”
• “How do you manage subcontractors/subprocessors for this provider?”
• “What happens if the provider refuses a requirement? Show me an exception.”

Hangups that trigger findings:

• Inventory is incomplete or owned by one team without procurement alignment.
• Evidence exists but review is not documented.
• Contracts lack enforceable terms; security requirements are “policy links” without obligations.
• Shared responsibility is misunderstood; the provider’s controls are assumed to cover customer-side obligations. ¹

Frequent implementation mistakes and how to avoid them

1. Treating SA-9 as a one-time due diligence event
   Fix: implement recurring evidence review and a renewal workflow tied to contract dates and material changes.

2. Only applying SA-9 to “IT vendors”
   Fix: include any third party providing system services, including monitoring tools, analytics, and support platforms with production data access.

3. No clear control owner
   Fix: assign one accountable SA-9 owner (often Third-Party Risk or GRC), plus named approvers in Security, Privacy, and Procurement.

4. Storing evidence in email
   Fix: use a controlled repository with consistent naming, retention, and review records. Daydream is a natural place to centralize SA-9 mappings, owners, and evidence artifacts so you can answer audits quickly. ¹

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so don’t plan on “case law style” expectations here. Treat SA-9 risk as operational: external services expand your attack surface, create privacy exposure, and can break your system’s control effectiveness if provider obligations are not explicit and monitored. ¹

Practical 30/60/90-day execution plan

Use phases rather than day-count commitments; execution speed depends on procurement cycles and contract renewal dates.

First 30 days (Immediate: establish control and stop the bleeding)

• Appoint SA-9 control owner and approve scope definition for “external system services.” ¹
• Build a draft inventory from procurement records, SSO app catalog, cloud accounts, and finance spend.
• Publish a minimum security/privacy requirements addendum for new external services.
• Implement a temporary gate: Security/GRC sign-off required before new integrations go live.

Next 60 days (Near-term: contract + evidence workflow)

• Tier the inventory (criticality + data sensitivity + connectivity).
• Standardize contract language with Legal/Procurement (security exhibit + incident terms + flow-down).
• Define evidence requirements by tier and create review checklists.
• Start with top-tier providers: collect evidence, document reviews, open remediation items.

Next 90 days (Ongoing foundation: repeatable oversight + audit readiness)

• Integrate SA-9 into procurement tooling and intake forms.
• Implement renewal triggers and material-change monitoring.
• Document shared responsibility mappings for critical providers and systems.
• Run an internal “mock audit”: pick a provider and demonstrate end-to-end traceability (inventory → contract → evidence → review → exceptions). ¹

Frequently Asked Questions

Does SA-9 apply to SaaS tools that only store business data (not “federal” data)?

SA-9 applies when NIST SP 800-53 is your governing requirement and the SaaS is an external system service connected to your system boundary or handling in-scope data. If NIST is contractually required, treat any connected SaaS as in scope and tier it based on data and access. ¹

What’s the minimum acceptable evidence for an external provider under SA-9?

SA-9 doesn’t prescribe a single evidence type in the excerpt provided; you must define what evidence demonstrates compliance with your security and privacy requirements. Set evidence expectations by tier, and always retain proof of review and any accepted exceptions. ¹

How do we handle providers that won’t agree to our security addendum?

Treat it as a risk decision, not a negotiation footnote. Document the refused clauses, assess impact, add compensating controls where possible, and obtain formal risk acceptance or select an alternative provider. ¹

Do subcontractors/subprocessors fall under SA-9?

Yes in practice, because SA-9 requires the provider to comply with your requirements; your contracts should flow requirements down to the provider’s critical subcontractors where they affect your services. Track key subprocessors for high-tier services and require notification of changes. ¹

Who should own SA-9: Security, Procurement, or GRC?

Put single-point accountability in GRC/Third-Party Risk, with Procurement running the gate and Legal managing contract paper. Security and Privacy should be required reviewers for high-tier services, with documented approvals. ¹

How do we prove “ongoing compliance” without audit rights?

Use contract commitments to provide periodic assurance artifacts and to notify on incidents and material changes. Where full audit rights are unrealistic, document the assurance mechanism you do have and show that you consistently receive and review it. ¹

Footnotes

1. NIST SP 800-53 Rev. 5

2. NIST SP 800-53 Rev. 5 OSCAL JSON