SA-9 External system services: requirements and evidence

SA-9 external system services: what the requirement asks for

SA-9 requires that every external provider of a system service meets the organization's security and privacy requirements, that the roles for overseeing those services and the user roles for using them are documented, and that the provider's compliance with the required controls is monitored on an ongoing basis through defined processes. In short, the control asks for three things: contractual requirements for providers, named oversight roles, and continuous monitoring of provider compliance. The organization keeps ownership of its risk even when the provider runs the infrastructure, so a cloud or SaaS dependency does not transfer accountability for the data and services it touches.

A team that runs its workloads on cloud platforms and SaaS tools inherits the exposure of each of those systems. A weakness in a provider's identity service, logging pipeline or support access path can become the organization's weakness. SA-9 exists so that this inherited exposure is visible, bounded by contract and watched over time. The difficulty is practical. Provider evidence arrives in many formats: SOC 2 reports, ISO certificates, penetration test summaries, security questionnaires and console screenshots, each covering different periods and scopes. Many contracts were also signed before the organization had a defined list of security requirements to write into them, so the agreements may say little about logging, incident notice or data location. Reconciling these documents with the organization's own control set is usually the largest piece of work.

Start by listing every external system service in use, with its owner, the data it handles and the contract that governs it. Then compare each contract against the organization's security and privacy requirements and record the gaps as amendments or documented risk acceptances. Confirm the oversight role and the user roles for each service in writing. Finally, decide what evidence will be collected on a fixed schedule and who reviews it. Because the organization owns these decisions, a partner can prepare the inventory, the evidence register and the monitoring process, but the organization signs off on the risk decisions. Confirm with your legal and procurement teams which contracts can be amended before the assessment begins.

Which external services and data fall under SA-9 scope

SA-9 scope follows the system boundary, not the vendor list. The cards below cover the service models, data and system touchpoints, baseline selection and FedRAMP parameters that decide which providers and which data an assessor will expect you to govern.

IaaS, PaaS and SaaS providers

Infrastructure, platform and software-as-a-service providers each hold a different slice of your system. An IaaS provider may run your compute and storage, a PaaS provider your runtime and databases, and a SaaS provider your application or identity service. Inventory each one that processes, stores or transmits data inside your authorization boundary, and record which controls the provider performs and which remain yours.

Managed security and outsourced development

Managed detection, managed firewall and outsourced development partners often have administrative access to systems that fall within your boundary, which puts them in scope even when they never hold your business data. Confirm whether each partner can change configurations, read logs or push code, and document their oversight role and user roles as SA-9 requires.

Data and systems the provider touches

Scope depends on what the provider can reach, not only on what it was contracted to do. Map data flows, backups, support access, telemetry and log exports, because each one can move federal, controlled or personal data outside your boundary. Where a provider only receives metadata, state that explicitly in the boundary documentation so the assessor can confirm the decision.

Which baseline selects SA-9

SP 800-53B assigns SA-9 to the low, moderate and high security baselines and to the privacy baseline, so the control applies at every impact level. The moderate and high baselines also select SA-9(2). Confirm your system's impact categorization and whether the privacy baseline applies, since those choices set which external-service requirements you must document and test.

FedRAMP SA-9(2) coverage

FedRAMP sets SA-9(2) to cover every external system where federal customer data is processed or stored. That extends scope to subservice providers, including those that hold only a fragment of the data. Build an inventory that ties each external system to the federal data it touches, and ask your authorization sponsor how the parameter applies to edge services, logging pipelines and backups.

FedRAMP SA-9(5) data location

At Class D, FedRAMP's SA-9(5) requires that information processing, data and system services for federal customer data be located in the United States, its territories or other locations under U.S. jurisdiction. Any offshore support desk, replica or backup region that touches that data falls within this requirement. Confirm the location of every processing and storage point before you sign a provider contract, and treat any change of region as a scope change.

How an assessor tests SA-9 external system services

This table maps the SP 800-53A determination statements for SA-9 to the examine, interview and test methods an assessor uses, the evidence each one requests and the findings that commonly appear. Read each row as a question the assessor will ask of the organization, and prepare the matching evidence before fieldwork starts.

Assessment method	What the assessor examines, interviews or tests	Evidence the assessor expects	Common findings
Examine: contracts and agreements	Whether contracts, interagency agreements and licensing agreements with external providers state the security and privacy requirements the organization defined for them	Executed contracts, service agreements and licenses with security and privacy clauses mapped to the organization's requirement list	Requirements exist in policy but are absent from the signed contract or the renewal template
Examine: requirements list	Whether the organization maintains a current list of security and privacy requirements for external provider services and whether it reflects the defined controls	Dated requirements list with version history, owner and linkage to the systems that use each provider	List is out of date, or it covers only some provider types such as cloud but not SaaS or managed services
Examine: oversight and user roles	Whether roles for overseeing each external service and for its users are documented	Documented role assignments for each provider, such as a named business owner, security reviewer and contract administrator	No named oversight owner for shadow or departmental SaaS tools
Interview: system owners	How system owners know which external services support their system and how they verify provider controls are working	Inventory extract for their system, examples of recent provider reviews, and their escalation path for provider incidents	System owners cannot name the external services their system depends on
Interview: acquisition staff	How security and privacy requirements are added to procurement, renewal and change requests for external services	Procurement checklist, sample purchase request with security review sign-off, and renewal records	Requirements applied at initial purchase but not checked when scope or data use changes
Interview: security staff	How provider compliance is monitored between contract events and what triggers a review	Monitoring plan, schedule of provider reviews, collected provider attestations or reports and recorded follow-up actions	Monitoring happens only at contract renewal, with no interim checks or defined triggers
Test: monitoring activity	Whether the defined monitoring process runs as written for a sample of providers	Dated review records for sampled providers, evidence of receipt and analysis of provider reports, and tracked corrective actions	Reviews are planned but not performed, or findings are recorded without assigned remediation
Test: data location and oversight in practice	Whether the organization can show where external services process its data and who approved that use, where a federal or regulatory parameter applies	Provider data location statements, sub-processor lists and approval records for changes	Provider data locations are unknown or sub-processors changed without notice to the organization

How to implement SA-9 in five steps

This sequence moves an organization from knowing which outside providers touch its systems to a documented, recurring process that proves each provider still meets the security and privacy requirements the organization set. Each step ends with an artifact an assessor can examine.

Inventory every external system service
Start by listing each cloud platform, SaaS application, managed service, hosted tool and outsourced function that processes, stores or transmits organizational data or supports the system. Map each entry to a system boundary so it is clear which authorization or assessment it belongs to. Note whether the service handles federal customer data, personal data or only internal metadata, because that changes its scope. The output is a provider inventory with boundary mapping, reviewed by the system owner and the security lead. The step is done when every connection crossing the boundary has an owner and a named service.
Define security and privacy requirements for providers
Translate the organization's baseline controls into a written list of requirements that providers must meet, such as encryption, access logging, incident notification, vulnerability handling, personnel screening and data location where it applies. Tie each requirement to the SA-9 expectation that providers comply with organizational requirements and defined controls. Confirm with privacy and legal staff which requirements carry regulatory weight. The output is a requirements list that is versioned and approved by a named authority, and it becomes the reference for every provider review.
Write requirements into acquisition contracts
Move the requirements list into the contract, order form or data processing terms for each provider, including rights to receive assessment evidence, notification duties and the conditions for ending service. Legal and procurement own the contract text, while the security team confirms that each requirement is present and measurable. Ask providers to identify any agreements that are interagency or licensing in nature, since assessors look for those alongside the contract. The output is a signed contract set cross-referenced to the requirements list, and the step closes when no provider in the inventory lacks a contract term covering the listed requirements.
Document oversight and user roles
Record who oversees each external service inside the organization and who uses it, with the responsibilities of each role. The oversight owner approves changes to the provider relationship, reviews its assessment evidence and escalates problems. User roles define who may configure, administer or consume the service and under what permissions. Keep these roles in a controlled document that is updated when staff change. The output is a roles table per provider. The step is complete when every service has a named oversight owner and every role has an assigned individual, not a shared mailbox.
Set a review cadence and monitoring process
Define how often each provider's compliance is checked and what the monitoring process consists of, such as reviewing audit reports, certifications, security questionnaires, incident history and configuration evidence. Assign the monitoring activity to a role and link it to the organization's continuous monitoring strategy. Higher-risk providers warrant more frequent review, and the organization should set that cadence itself and record the reason. The output is a monitoring procedure and a schedule that appears in the risk register. The step is done when the schedule has been run at least once and the results are recorded.
Record findings and track provider gaps
Each monitoring cycle produces findings, such as an expired report, a missing control or a change in the provider's hosting location. Log every finding in the plan of action and milestones or equivalent tracker with an owner, a decision and a target date set by the organization. Verify that closed findings are supported by new evidence, not only by the provider's assurance. The output is a findings log with evidence references. An assessor will look for a traceable path from finding to closure.
Set a remediation path for non-compliant providers
Decide in advance what happens when a provider falls out of compliance: a corrective plan with the provider, a compensating control inside the organization, a risk acceptance signed by an accountable official, or migration away from the service. Define who may approve each option and what evidence closes the issue. Document the decision criteria so the response is consistent across providers. The output is a written remediation procedure and examples of how it was applied. The step is complete when the procedure has been tested on at least one real or tabletop scenario and the outcome is recorded for the next assessment.

Evidence that passes SA-9 external system services testing

An assessor testing SA-9 starts with the contract, then follows the requirements into the provider's assurance evidence and the monitoring records that show oversight continued after signing. The six artifacts below form one chain, so a gap in any link usually shows up when the assessor tries to trace a single provider from contract to review.

Contracts and security schedules

Assessors examine contracts, interagency agreements and licensing agreements to confirm that security and privacy requirements reach the provider in writing. Look for a security schedule that names the organization's requirements, incident notification duties, audit or assurance rights and the obligation to keep controls in place for the contract term. Check that renewal and amendment clauses carry the same requirements forward.

Provider security requirements list

SA-9 testing expects a documented list of the organization's security and privacy requirements for external provider services. This list is the yardstick for every provider review, so it should map each requirement to the controls it draws from and state which provider types it applies to. Confirm the list has an owner, a version and a review date, and that contracts reference the current version.

Provider assurance reports reviewed

Independent assurance reports, certifications and questionnaire responses only count when someone compares them against the requirements list. Keep a dated review record for each provider that notes which requirements the report covers, which it does not, the scope and period it applies to, and the compensating steps taken for any gap. Ask providers for updated reports on the cycle the contract sets, and record when a report is late.

Oversight and user role matrix

SA-9 requires the roles for overseeing external services and the roles of users who operate them to be documented. A role matrix names the internal owner for each provider, who approves access and changes, who receives provider alerts, and who can end the service. Keep it aligned with access control records so the people named in the matrix match the accounts that exist in each provider's console.

Ongoing monitoring records

The control requires provider compliance to be monitored on an ongoing basis using defined processes, so assessors look for dated monitoring entries with named reviewers. Records might include periodic security reviews, reviews of provider incident notices, changes in provider ownership or location, and follow-up on open findings. Entries that show what was checked, what was found and what was done are stronger than a single annual sign-off.

Interagency and licensing agreements

Where a service comes through an interagency arrangement or a software license, the agreement itself is evidence that the terms were agreed and are still in force. Confirm each agreement names the security obligations, data handling terms and the parties responsible for them, and that expiry dates are tracked. For FedRAMP-scoped systems, also record where federal customer data is processed or stored so SA-9(5) can be evidenced.

What meeting SA-9 costs in money and effort

This table breaks the cost of meeting SA-9 into its components, showing who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Use it to scope a quote and to see which costs stay with your team and which can be outsourced. No prices or durations are given because none are supplied for this control.

Cost component	One-time or recurring, and who pays	What drives it up or down
Contract and procurement review	Mostly one-time per provider, paid from procurement and security staff time	Up with the number of providers and new contracts. Down with a consolidated provider list and standard review checklists.
Legal effort to add security and privacy schedules	One-time per contract, recurring at each renewal, paid from legal counsel time or outside counsel fees	Up with data sensitivity and non-standard terms. Down with reusable schedule language approved once and applied to many contracts.
Staff time for provider assurance review	Recurring, paid from internal security and compliance staff, sometimes supplemented by consultants	Up with the number of providers, the depth of review and FedRAMP level. Down with reliance on existing independent reports where they cover the required scope.
Tooling or licenses to track providers	Recurring license or hosting cost, or internal effort for a self-hosted register	Up with the number of providers and integrations. Ask whether the tool is open source and self-hosted, and what hosting effort it needs.
External review or assessment support	Recurring or per engagement, paid to an outside firm for readiness work or independent testing	Up with scope breadth and FedRAMP class requirements. Down with a fixed written scope agreed before work starts.
Auditor sampling of provider oversight	Recurring each assessment cycle, paid to the independent assessor	Up with the number of providers sampled and gaps in records. Down with a current provider register and retained monitoring evidence.
Ongoing compliance monitoring	Recurring, paid from internal staff or a retainer for periodic reviews	Up with provider turnover and frequency of significant changes. Down with defined review triggers and automated reminders.

Self-hosted open-source tools that track SA-9 evidence

SA-9 produces records that most teams keep in spreadsheets and shared drives: contracts, provider requirement lists, oversight roles and compliance monitoring results. The three tools below can hold that material in a self-hosted form inside your own environment. None of them makes a provider compliant or replaces the judgment of your assessor, so confirm fit against your own evidence retention rules before relying on them.

Assessment tracking with CISO Assistant

CISO Assistant (AGPL-3.0-only) ships more than 200 frameworks, including ISO 27001, NIST CSF, SOC 2, PCI DSS, NIS2, DORA and GDPR, and can run assessments against them with automatic mapping between frameworks. For SA-9, that lets you record each provider's security requirements once and see how they relate to other obligations. Check the AGPL-3.0-only terms with counsel before you modify the software or offer it to third parties, and confirm the framework content matches the version you assess against.

Versioned oversight records in XWiki

XWiki (LGPL-2.1-or-later) keeps every change to a page under version control, recording what changed, when and by whom. Users can compare any two versions and roll back to an earlier one. This suits the written oversight role descriptions and provider requirement lists that SA-9 expects you to document and keep current. Confirm that the version history meets your retention period and that your access controls prevent edits to records an assessor will rely on.

Role-based oversight access in BookStack

BookStack (MIT) assigns user abilities through roles, and permissions can be overridden per role at the shelf, book, chapter or page level. For SA-9, this lets you give the team that monitors a provider full edit rights on its oversight pages while others can only read them. Map each role to the oversight and user roles you have documented, and test that the overrides behave as your documentation states before an assessment.

Confirm licensing before adoption

The three tools carry different licenses: AGPL-3.0-only, LGPL-2.1-or-later and MIT. Each has different obligations if you modify the code, host it for others or distribute it. Ask your legal team to review the license that applies to your deployment model. A license review belongs in your scope before any tool holds records that an independent assessor will examine.

Who owns SA-9 and who can help

Your organization owns SA-9. Only your leadership can decide which external providers the system relies on, what risk is accepted for each one, and whether a provider's controls are good enough to keep. Those decisions belong to the people who carry the risk, not to a consultant or an auditor. Your team also writes the contract requirements, names the oversight and user roles, and runs the ongoing monitoring of provider compliance.

Provider decision and risk acceptance: Approve each external service, record the business reason, and sign the risk decision when a provider cannot meet a requirement.
Contract requirements: Put security and privacy obligations, audit rights, incident notice and data location terms into agreements, licenses and interagency arrangements.
Oversight and user roles: Document who inside the organization administers each external service, who reviews its reports and who can approve exceptions.
Ongoing monitoring: Run the defined process that checks provider compliance on a schedule, and act on findings such as lapsed certifications or changed subprocessors.

Confirm with your own policy owner which roles, review cycle and approval chain are written into the SA-9 procedure before any outside party starts work.

Common gaps in SA-9 external system services programs

Most SA-9 weaknesses are not missing policies. They are gaps between what the policy says and what the contracts, inventories, monitoring records and data locations show when an assessor asks. Each card below names one gap, the artifact or owner that closes it, and what to check before the assessment starts.

Contracts without security requirements

Provider agreements often cover price and uptime but say nothing about the security and privacy requirements the organization set under SA-9. An assessor will look for the contracts and the list of requirements they are supposed to carry. Close the gap by adding a standard security schedule to every external service agreement, mapped to the organization's requirement list, and owned by procurement with security sign-off before signature. Check renewals too, since older contracts usually predate the schedule.

Oversight roles that exist only in policy

SA-9 requires that oversight and user roles for each external service be documented. In many programs the policy names a vendor owner, but no one holds that role for a specific service, and the named person has left or never accepted it. Keep a service register that records, for each provider, the business owner, the security oversight owner and the internal users, with the date each was confirmed. Ask the named owner to sign the entry once a year.

Monitoring that happens once at onboarding

Due diligence at onboarding satisfies the initial review, but SA-9 expects provider control compliance to be monitored on an ongoing basis using defined processes. Programs that stop after signature cannot show a current picture. Define a recurring review cadence by provider risk tier, collect the provider's current attestation or assessment report, and record the reviewer's conclusion and any follow-up actions. The monitoring procedure itself should be a written, dated document.

Provider inventories that miss SaaS tools

Procurement records rarely capture software bought on a corporate card, trialed by a team, or embedded in another product. Those tools still process organizational data, so they fall inside SA-9 scope. Build the provider inventory from several sources at once: the finance and expense export, single sign-on application lists, OAuth grants in the identity provider, and network or DNS logs for outbound SaaS traffic. Reconcile the results quarterly and route anything new to a security review.

Federal data location not checked at Class D

At FedRAMP Class D, SA-9(5) requires that information processing, data and system services for all federal customer data are located in the United States, its territories or other locations under U.S. jurisdiction. Programs often verify this once in a design document and never again. Ask each provider for written confirmation of data residency, including backups, support access, logs and subprocessors, and keep the evidence with the service record. Re-check when a provider announces a new region or subprocessor.

Evidence scattered across email

The same provider review may exist as an email thread, a shared drive file, a ticket comment and a spreadsheet tab, which makes it hard to show the assessor what happened and when. Store each provider's contract, requirement mapping, oversight roles, reports and monitoring records in one controlled location with version history and role-based access. Use one record per provider and link every artifact to the SA-9 review it supports, so the assessor can trace a single service from contract to latest review.

SA-9 external system services questions buyers ask

How much effort does SA-9 cost to implement?

No supplied figure sets a price for SA-9, and the effort depends on how many external providers your system depends on and how much of their compliance evidence you already hold. The main cost components are internal staff time for the provider inventory, contract review and monitoring, any assessor fees if you need an independent assessment, and implementation partner fees for preparing the records and monitoring process. Most of the cost recurs, because SA-9 requires ongoing monitoring of provider control compliance, not a one-time review. Ask any partner for a written scope that lists the providers covered, the evidence to be produced and who performs each task, then compare quotes against that scope rather than against a headline number.

How long does SA-9 work take, and what drives the timeline?

No supplied duration applies to SA-9, so confirm timing against your own environment and your authorization schedule. The biggest drivers are the number of external services in the boundary, whether contracts already contain security and privacy terms, how quickly providers supply their assessment reports, and whether your team has a documented oversight role for each service. Contract renegotiation with a provider is usually the slowest step because it depends on the provider's legal process. Ask for milestones tied to deliverables, with dependencies on provider responses called out explicitly.

What does SA-9 require from our internal team?

SA-9 requires your organization to own the decisions, even when a partner does the preparation work. Internal staff must define the security and privacy requirements that providers must meet, document oversight and user roles for each external service, and run the ongoing monitoring process. Legal or procurement must carry those requirements into contracts and agreements, and system owners must sign off on risk decisions where a provider cannot meet a requirement. Plan for named owners in each of these roles before work starts, because an implementation partner cannot accept accountability for decisions that belong to your organization.

Can a small team implement SA-9 without outside help?

A small team can implement SA-9 alone if it has a short list of external services, clear authority over its contracts and someone who can read provider assessment reports critically. The work becomes harder when the team manages many providers, must map contract terms to control requirements, or lacks a repeatable monitoring cadence. Test your capacity by estimating whether one person can review each provider's evidence at least once a year and handle change notifications between reviews. If that answer is uncertain, a fixed-scope engagement that builds the inventory, templates and monitoring workflow can reduce the load while your staff keeps ownership.

How do SA-9(2) and SA-9(5) change a FedRAMP program?

SA-9(2) requires you to identify external systems that process or store federal customer data, and SA-9(5) adds a data location requirement at Class D. Under FedRAMP's Rev5 rules, SA-9 and enhancements SA-9(1), (2) and (5) apply at the classes named in the Consolidated Rules for 2026, so confirm the class that applies to your offering in that document. The practical effect is a complete inventory of every service touching federal data, and for Class D, proof that information processing, data and system services for all federal customer data sit in the United States, its territories or other locations under U.S. jurisdiction. Verify each provider's hosting regions and support access locations, not only the primary region.

Can an implementation partner issue the SA-9 assessment?

No. An implementation partner can prepare the inventory, contract requirements, monitoring records and evidence, but only an independent assessor issues the assessment result that FedRAMP or another authorizing body relies on. DeployOpen prepares systems, controls and evidence for compliance assessments and does not issue audit reports, attestations or certifications. For FedRAMP work, confirm which assessor types are accepted for the assessment you need, and ask your authorizing body which independent assessment is required each year for SA-9 at your class.

What should a written scope for SA-9 work include?

A written scope should name the systems and external providers covered, the SA-9 requirements and enhancements in force for your impact level or FedRAMP class, and the list of deliverables with owners and dates. Ask for the contract requirement template, the provider oversight role definitions, the monitoring procedure and its cadence, the evidence index mapped to each determination statement in SP 800-53A, and the handover plan for your team. The scope should also state what is out of scope, which external dependencies are excluded, what your team must supply, and how changes to scope are priced and approved. Fixed scope agreed in writing before work starts makes quotes comparable.

How DeployOpen prepares SA-9 evidence

DeployOpen works on SA-9 External system services as a fixed-scope implementation partner. We prepare the systems, provider records and monitoring evidence your organization needs, while your organization owns its supplier decisions and an independent assessor issues any findings.

How we scope

We list the external services in your environment and agree which ones fall under SA-9 for your system.
The written scope names the security and privacy requirements, oversight roles and provider documents we will prepare.
Your team confirms which provider contracts and agreements exist before any build work starts.

How we build

We set up self-hosted open-source tooling inside your own infrastructure to hold provider records and requirement lists.
We configure role-based access so oversight and user roles for each external service are documented and enforced.
We build recurring review workflows that record provider control compliance checks and their results over time.

How we hand over

We deliver documented procedures, provider register entries and monitoring logs in formats your assessor can examine.
We walk your compliance and security teams through each artifact so they can maintain it after handover.
We record every change to the evidence set so your assessor can see what changed, when and by whom.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope work ends.
A retainer can cover periodic refreshes of provider monitoring records and updates to the requirement list.
Any change to the written scope is agreed in writing before the related work begins.