SA-9: External System Services

SA-9 (External System Services) requires you to make third-party providers meet your security and privacy requirements before they connect to, store, process, or manage your system data, and to contractually obligate the specific controls you need them to operate. Operationalize it by standardizing (1) scoping which services count, (2) required contract clauses, (3) due diligence and continuous monitoring, and (4) evidence retention. ¹

Key takeaways:

• Treat SA-9 as a control-selection and contract-enforcement requirement for third-party services, not a one-time vendor questionnaire. ¹
• You need a repeatable intake process that maps each external service to required controls, assigns owners, and captures approvals plus exceptions. ¹
• Auditors will look for traceable evidence that contracts, due diligence results, and ongoing monitoring match your stated requirements. ¹

“External system services” is broad on purpose. It includes cloud hosting, SaaS business applications, managed security providers, data analytics platforms, outsourced development environments, and even niche tools that receive logs or production data. SA-9 exists because your boundary is porous: if a third party runs part of your system, they can weaken your controls unless you require equivalent safeguards and verify they operate.

For a Compliance Officer, CCO, or GRC lead, SA-9 becomes actionable when you translate it into a small set of operational decisions: Which third parties are “external system services” in your environment? What are your non-negotiable security and privacy requirements for them (baseline), and what requirements vary by data type, system criticality, or connectivity (risk-based overlays)? How do you ensure those requirements are embedded in contracts, validated through due diligence, and tracked over time?

This page gives you requirement-level implementation guidance: scoping rules, a step-by-step workflow you can hand to Procurement and Security, the evidence bundle auditors ask for, and the failure modes that create audit findings or customer diligence escalations. Primary requirement language comes from NIST SP 800-53 Rev. 5. ²

Requirement: SA-9 External System Services (plain-English meaning)

SA-9 requires you to ensure providers of external system services comply with your organization’s security and privacy requirements and that they operate specified controls you identify as necessary. You do this through defined requirements, contract terms, and verification activities, then keep evidence that the requirement is consistently executed. ¹

What counts as “external system services” in practice

Treat a third party as an external system service when any of the following are true:

• They host your systems or components (IaaS/PaaS hosting, managed databases).
• They process or store your organization’s data (SaaS apps, data warehouses, payroll providers).
• They administer, monitor, or secure your environment (MSSP/SOC, endpoint management, SIEM hosting).
• They integrate into production in a way that can affect confidentiality, integrity, or availability (CI/CD platforms, API gateways, identity providers).

A common scoping error is excluding “non-IT vendors” that still process regulated data (HR, marketing, support tooling). SA-9 is triggered by service impact, not the vendor’s label.

Who SA-9 applies to

Entity scope

SA-9 is written for federal information systems and organizations aligned to NIST SP 800-53. In practice, it also applies to contractors and service providers handling federal data or delivering services into federal environments, because external service dependencies are part of the system security posture. ²

Operational scope

SA-9 applies across:

• Procurement and sourcing (contract vehicles, renewals, order forms)
• Security engineering and architecture (control requirements, integration patterns)
• Privacy (data processing requirements, sub-processors)
• Vendor/third-party risk management (due diligence, monitoring, issue management)
• System owners and product teams (intake and accountability)

If you can’t identify a system owner for each external service relationship, SA-9 will fail in operation even if your policy reads well.

Regulatory text

Excerpt: “Require that providers of external system services comply with organizational security and privacy requirements and employ the following controls: [controls];” ¹

Operator translation (what you must do):

1. Define your security and privacy requirements for external system services (baseline + risk-based add-ons). ¹
2. Specify the controls the provider must employ (for example, encryption, access controls, incident response duties), and align them to your internal control baseline for the system. ¹
3. Bind those requirements contractually (MSA/DPA/SOW, security addendum, SLAs, right-to-audit where feasible). ¹
4. Verify compliance through due diligence and ongoing oversight, then track gaps to closure or formal exception. ¹

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

Step 1: Build a scoped inventory of external system services

Output: “External System Services Register” (subset of your third-party inventory).

• Pull from AP/procurement, SSO app catalogs, cloud marketplaces, and security tool lists.
• Tag each entry with: system supported, data types, connectivity (VPN/API/agent), hosting region constraints, and whether it can affect availability.

Decision rule: If the third party touches production data or production control planes, it belongs in SA-9 scope.

Step 2: Define your requirement baseline and control overlays

Create a short “External System Services Security & Privacy Standard” that includes:

• Minimum security requirements (authentication, logging, vulnerability management expectations).
• Privacy/data handling requirements (data use limits, retention/deletion, breach notification, sub-processing controls).
• Required assurance artifacts (SOC 2, ISO reports, pen test summaries, or equivalent evidence your program accepts).
• Overlay triggers (higher bar for regulated data, privileged access, critical availability dependencies).

Keep it implementable: procurement needs checklists, not essays.

Step 3: Translate requirements into contract language and gating controls

Implement “no contract, no access” gates:

• Contract templates: security addendum + DPA + SLA clauses mapped to your baseline.
• Approval workflow: system owner + Security + Privacy sign-off for in-scope services.
• Exception path: documented risk acceptance with compensating controls and expiry.

If you can’t get a clause (common in large SaaS), require compensating evidence (third-party audit reports, shared responsibility documentation) and document the gap and acceptance.

Step 4: Execute due diligence before go-live (not after)

Minimum pre-production checks should include:

• Security questionnaire aligned to your baseline controls.
• Review of independent assurance (as applicable to the service type).
• Architecture review for high-impact integrations (identity, network paths, key management, logging).
• Confirmation of incident notification contacts and timelines in writing.

Practical tip: Tie “go-live” to a procurement or change-management gate. If teams can deploy before review, SA-9 becomes advisory.

Step 5: Continuous monitoring and control health

Operate SA-9 as a lifecycle control:

• Track renewal dates and re-assess when scope changes (new data types, new integrations, new regions, sub-processor changes).
• Capture and manage provider-reported security incidents and material control changes.
• Maintain a remediation log with owners, due dates, and closure evidence.

This is where many programs fail: they collect a SOC report once and never revisit it.

Step 6: Package it into a control card (so it runs without heroics)

Create a one-page control card:

• Objective: External system service providers comply with your requirements and operate required controls. ¹
• Owner: Third-party risk lead (with Security/Privacy co-owners).
• Trigger events: new third party, renewal, scope change, incident, control report update.
• Steps: intake → classify → contract → assess → approve → monitor → remediate/except.
• Evidence bundle and retention location.

Tools like Daydream are useful here because they force a repeatable workflow, attach evidence to each execution cycle, and make exception handling auditable without spreadsheet drift.

Required evidence and artifacts to retain (minimum evidence bundle)

Auditors and customer assessors typically want traceability from requirement → contract → verification → monitoring. Retain:

• External System Services Register (scoped list with owners and risk tier)
• Approved security/privacy baseline standard and any overlays
• Contract artifacts: signed MSA/SOW/DPA/security addendum, SLA exhibits
• Due diligence package: completed questionnaire, assurance reports reviewed, architecture review notes (where applicable)
• Approval evidence: ticket/workflow showing required approvers, decision, and date
• Exception documentation: scope of exception, risk acceptance approver, compensating controls, expiration, and re-review outcome
• Ongoing monitoring records: renewal reassessments, remediation log, incident communications and post-incident actions

Common exam/audit questions and hangups

Expect these, and pre-stage the answers:

• “Show me all external system services for System X and who approved them.”
• “Where in the contract do you require security and privacy obligations?”
• “How do you decide which controls a provider must employ?”
• “What happens when a provider won’t accept your addendum?”
• “How do you monitor providers between onboarding and renewal?”
• “Show an example of a deficiency and how you tracked it to closure.”

Hangup pattern: teams can describe the process verbally but can’t produce time-stamped evidence per provider.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Treating SA-9 as procurement-only.
   Fix: Make system owners accountable for third-party selection and ongoing fit; require Security/Privacy sign-off for in-scope services.

2. Mistake: No written definition of “external system service.”
   Fix: Publish scoping rules and examples; align them to your inventory tagging.

3. Mistake: Contracts don’t match requirements.
   Fix: Maintain a clause library mapped to your baseline; require redline review for deviations.

4. Mistake: No exception process, so teams route around you.
   Fix: Offer a fast exception path with compensating controls and expiration; track it like risk, not like a favor.

5. Mistake: Evidence scattered across email and chat.
   Fix: One system of record for intake, approvals, and artifacts. Daydream (or an equivalent GRC workflow) helps by making the evidence bundle a required output of the process.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for SA-9, so this page does not cite enforcement actions. Operationally, SA-9 failures still create material risk: third-party incidents often become your incident, and auditors frequently treat weak third-party oversight as a systemic control breakdown because it affects multiple systems at once. ³

Practical 30/60/90-day execution plan

First 30 days (stabilize and stop the bleeding)

• Name an SA-9 owner and publish scoping rules for “external system services.”
• Stand up the External System Services Register for your highest-risk systems first.
• Implement a lightweight intake gate: no new in-scope third party goes live without Security/Privacy review.
• Draft baseline contract/security addendum requirements and route through Legal/Procurement.

Days 31–60 (standardize and make it repeatable)

• Finalize baseline requirements plus overlays (regulated data, privileged access, critical availability).
• Build contract clause library and fallback positions for non-negotiable SaaS terms.
• Define the minimum due diligence package by risk tier and service type.
• Implement exception workflow with approvals, expirations, and compensating controls.

Days 61–90 (operate and prove it)

• Run a control health check across in-scope providers: contract coverage, overdue reassessments, open remediation items.
• Test evidence retrieval: pick several providers and assemble the complete evidence bundle end-to-end.
• Tune monitoring cadence based on risk and renewal cycles.
• If you use Daydream, configure the SA-9 control card, required evidence bundle, and automated reminders for renewals and exception expirations.

Frequently Asked Questions

Does SA-9 apply to every vendor in our vendor list?

No. Apply SA-9 to third parties that provide external system services: hosting, processing, storing, or administering systems/data, or integrating into production in a way that affects security or privacy. Document your scoping rule and apply it consistently. ¹

What if a SaaS provider won’t sign our security addendum?

Document the gap, assess the risk, and require compensating evidence (independent assurance reports, security documentation) plus internal compensating controls where feasible. Record a formal exception with an expiration and a re-review trigger.

What evidence do auditors usually want first?

They typically start with the inventory of in-scope external services, then ask for one or two provider files showing contracts with required obligations, due diligence results, approvals, and ongoing monitoring records. Your goal is traceability per provider.

How do we decide which “controls” the provider must employ?

Start with your organizational baseline security and privacy requirements, then add overlays driven by data sensitivity, connectivity, and criticality. Keep the mapping simple enough that Procurement and system owners can apply it without re-inventing it each time. ¹

Is a SOC 2 report enough to satisfy SA-9?

A SOC 2 report can support due diligence, but SA-9 expects alignment to your specific requirements and the controls you require. You still need contract terms and a documented review that maps the report’s scope to your needs.

How do we operationalize SA-9 without slowing the business down?

Put clear gates at two points: contract signature and production access. Use risk tiers to right-size the diligence package, and use a workflow tool (for example, Daydream) to standardize intake, evidence collection, and exception handling.

Footnotes

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

2. NIST SP 800-53 Rev. 5; NIST SP 800-53 Rev. 5 DOI

3. NIST SP 800-53 Rev. 5