External System Services | Processing, Storage, and Service Location

SA-9(5) is a practical requirement with a simple exam question behind it: “Can you prove where your information is processed, stored, and serviced when a third party is involved, and can you restrict it to approved locations?” If your cloud provider offers multi-region features, or a SaaS product uses global sub-processors, location control can drift quickly from an intended design to an ungoverned reality.

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat this as an acquisition and architecture control: define location rules up front, bake them into third-party onboarding and contracting, and require technical enforcement evidence from engineering and providers. “Location” must cover three things: (1) where computation happens (processing), (2) where data at rest resides (storage), and (3) where the service is delivered from (service location, including support access, sub-processing, and managed operations). ¹

This page gives you requirement-level implementation guidance you can hand to procurement, security engineering, and service owners, with specific artifacts to retain for FedRAMP-oriented audits and continuous monitoring.

Regulatory text

Requirement (SA-9(5)): “Restrict the location of information processing, information or data storage, or system services to organization-defined locations based on organization-defined requirements or conditions.” ¹

Operator interpretation: You must (a) define what locations are acceptable and under what conditions, (b) ensure external system services only operate within those approved locations, and (c) be able to prove it with contracts, architecture decisions, and ongoing evidence. This is not satisfied by a generic “data is encrypted” statement; it is a residency and service-delivery control. ¹

Plain-English interpretation (what SA-9(5) is really asking)

SA-9(5) treats location as a controllable security property of third-party services. If an external provider can move your workloads, store your data in new regions, or route support/admin access from unapproved places, you have lost control of a core risk variable: legal jurisdiction, incident response reach, foreign access exposure, and downstream sub-processing.

“Organization-defined requirements or conditions” is your responsibility. You decide:

• Which geographies are approved (for example, specific countries, economic areas, or cloud regions).
• What triggers strict residency (data sensitivity, customer contract obligations, government workload boundary conditions).
• What is allowed for support operations, backups, logs, telemetry, and disaster recovery.

Auditors typically look for two things: clear definitions and enforceable controls. Vague residency language without enforcement and evidence fails in practice.

Who it applies to

Entity scope

• Cloud Service Providers and federal agencies implementing NIST SP 800-53 controls in their environments. ¹

Operational scope (what “external system services” includes)

• SaaS platforms that handle organizational information (HR, ticketing, CRM, logging, CI/CD, email, collaboration).
• IaaS/PaaS services (compute, storage, managed databases, queues, analytics).
• Managed service providers (monitoring, SOC services, managed backups).
• Sub-processors used by any of the above (support tooling, CDNs, DDoS providers, observability pipelines).

If a third party touches your data or performs a system function on your behalf, assume SA-9(5) applies and confirm location controls explicitly.

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

Step 1: Define your location control standard (your “organization-defined locations”)

Create a short, enforceable standard that answers:

1. Approved processing locations (where compute executes)
2. Approved storage locations (primary, backups, replicas, logs)
3. Approved service locations (where the service is operated from, including admin/support access and sub-processing)

Add conditions that tighten or loosen restrictions, such as:

• Data classification level
• Government-facing vs. internal-only workloads
• Customer contractual commitments
• Cross-border transfer restrictions imposed by your risk posture

Keep this implementable. If the standard lists dozens of exceptions, it will not survive procurement velocity.

Step 2: Inventory external system services and map data flows to locations

Build or refresh:

• A list of external services by system owner and business purpose
• A data flow map per service: ingress, processing, storage, egress, backups, analytics, support access
• Location fields for each leg of the flow (region/country and provider facility type if relevant)

Practical tip: start with the services that process the highest-impact data types (regulated, mission critical, or customer data), then expand.

Step 3: Convert the standard into third-party due diligence questions and contract clauses

Your third-party intake should require explicit answers for:

• Primary region(s) and storage region(s)
• Backup/DR region(s)
• Logging/telemetry destination region(s)
• Support/admin access locations and constraints
• Sub-processor list and their locations (and change-notification obligations)

Contracting must include:

• Location restriction clause tied to your approved locations
• No material location change without prior written approval
• Sub-processor controls: location restrictions flow down; notice and approval rights based on your conditions
• Right to audit/attest: provider must supply evidence (attestation, configuration screenshots, architecture statements) upon request
• Breach/incident cooperation aligned to where response actions must occur

This is where many programs fail: they ask the questions, but they don’t bind the answers to enforceable obligations.

Step 4: Enforce locations technically (don’t rely on policy)

Technical enforcement depends on the service model:

IaaS/PaaS (you control configuration)

• Restrict provisioning to approved regions via policy-as-code / org policies.
• Disable global replication features unless explicitly approved.
• Force storage buckets, databases, and backups into approved regions.
• Restrict admin actions by geography where feasible (conditional access, bastions, JIT, logging).

SaaS (provider controls most of it)

• Choose the correct tenant region at purchase/onboarding.
• Configure data residency options (if offered) and document settings.
• Require provider evidence for residency and sub-processing constraints.
• Add compensating controls if the SaaS cannot meet strict location conditions (for example, prevent regulated data from entering the tool).

Service location (operations and support)

• Require restricted support access pathways (ticket-based, time-bound, logged).
• Require named support locations or approved location lists for privileged access.
• Ensure sub-processors are enumerated, with location restrictions and change controls.

Step 5: Establish an exception process that auditors can follow

Exceptions will happen (global SaaS, multi-region DR, acquisitions). Make them auditable:

• Written risk acceptance with scope, data types, and duration/termination conditions
• Compensating controls (data minimization, tokenization, restricted dataset copies)
• Decision owner (business + security/compliance)
• Trigger for re-review (contract renewal, provider change, new data type)

Step 6: Monitor and re-validate location claims

Your continuous monitoring should include:

• Contract renewal checks: sub-processor and location changes
• Configuration drift monitoring (for IaaS/PaaS)
• Periodic provider attestations or evidence refresh for SaaS
• Review of incident reports that may indicate data movement or emergency processing outside normal regions

If you use Daydream for third-party risk management, this is a strong fit for automating location-specific intake, routing approvals for residency exceptions, and maintaining an audit-ready evidence trail across procurement, security, and system owners.

Required evidence and artifacts to retain

Keep these artifacts in a single audit package per external service:

1. Location Control Standard (approved locations + conditions)
2. Service inventory entry with data classification and owner
3. Data flow diagram showing processing/storage/service locations
4. Provider documentation stating data residency and sub-processor locations (as provided by the third party)
5. Contract language (MSA/DPA/SOW) with location restriction and change-notice terms
6. Technical configuration evidence
   • Cloud org policies / region restrictions (screenshots/export)
   • Residency settings in SaaS admin console (screenshots)
   • Backup/replication configuration evidence
7. Exception records (risk acceptance, approvals, compensating controls)
8. Ongoing validation records (re-attestations, renewal reviews, monitoring outputs)

Your goal is simple: a reviewer should be able to pick one high-risk service and trace “requirement → contract → configuration → ongoing checks” without guessing.

Common exam/audit questions and hangups

Expect questions like:

• “Show me your organization-defined locations and the conditions that apply.”
• “For this SaaS, where are production data, backups, and logs stored?”
• “How do you prevent an engineer from deploying into an unapproved region?”
• “What happens if a third party adds a new sub-processor in a new geography?”
• “Do support personnel access production from other countries? How do you control it?”
• “Prove the setting/config that enforces residency.”

Hangups that slow audits:

• “Region” defined for storage but not for logs/telemetry.
• DR/backups left out of scope.
• Contracts that describe intentions but lack enforceable restrictions or notification.
• No exception paperwork, just email threads.

Frequent implementation mistakes (and how to avoid them)

1. Defining residency only as “data at rest.”
   Fix: include processing and service delivery explicitly, as SA-9(5) requires. ¹

2. Forgetting sub-processors and support tooling.
   Fix: require sub-processor lists with locations and change controls in procurement and contracting.

3. No technical enforcement for IaaS/PaaS.
   Fix: implement org-level region restrictions and drift monitoring; treat this as a guardrail, not a guideline.

4. Approving one region, but allowing global features by default.
   Fix: baseline configurations that disable cross-region replication unless an exception is approved.

5. Exception process without termination conditions.
   Fix: require a “what would make this exception go away” plan (migration path, data minimization, alternate provider).

Enforcement context and risk implications

No public enforcement cases were provided in the supplied source catalog, so this page does not cite specific actions.

Risk-wise, SA-9(5) failures tend to surface during:

• Authorization assessments where boundaries and data flows are tested against documented controls
• Incident response, when responders discover logs, backups, or replicas exist outside intended regions
• Contract disputes, when a customer requires proof of residency and you lack enforceable obligations from sub-processors

Treat the control as both compliance and operational resilience. If you cannot confidently answer “where is it?” you also cannot confidently contain it.

Practical 30/60/90-day execution plan

First 30 days (Immediate)

• Publish a one-page Location Control Standard (approved locations + conditions).
• Identify the highest-risk external services and map processing/storage/service locations for each.
• Update third-party intake forms to capture location, DR, logs, sub-processors, and support access locations.
• Draft standard contract language for location restriction and change notification.

By 60 days (Near-term)

• Implement technical region restrictions for IaaS/PaaS accounts/subscriptions where you have control.
• For top SaaS, collect provider evidence of residency settings and sub-processor locations; store in the service’s evidence package.
• Stand up an exception workflow with documented approvals and compensating controls.

By 90 days (Operationalize)

• Expand coverage to the remaining external services, prioritizing those that process sensitive data.
• Add location checks to renewal playbooks and periodic third-party reviews.
• Establish a recurring re-validation cadence tied to material changes (new regions, new sub-processors, new data types).
• Centralize evidence and approvals in your GRC/TPRM system so audits don’t become an email archaeology exercise.

Frequently Asked Questions

Does SA-9(5) require data to stay in the United States?

No. SA-9(5) requires restriction to organization-defined locations based on your requirements or conditions. You choose the locations and must be able to enforce and evidence them. ¹

What counts as “service location” versus processing or storage?

“Service location” covers where the service is operated from, including administrative/support access and sub-processing that delivers the service. Treat support tooling, managed operations, and sub-processors as part of service location scope. ¹

If a SaaS provider can’t guarantee residency for logs or backups, can we still use it?

Yes, but route it through an exception decision. Limit the data allowed into the SaaS, document compensating controls, and bind the provider to notify you before location or sub-processor changes.

How do we prove compliance if the provider won’t share detailed facility information?

SA-9(5) focuses on restricting to approved locations, which can be expressed as regions/countries and provider-controlled residency settings. Retain provider statements/attestations, contractual commitments, and your tenant/configuration evidence. ¹

Do we need to restrict where our own employees access systems from?

SA-9(5) is about external system services, but admin/support access paths are part of service delivery risk. If third-party personnel administer systems, define allowed access locations and enforce with identity controls and logging.

What’s the fastest way to operationalize this across many third parties?

Standardize the location questions and contract clauses, then make “location evidence” a required onboarding artifact. A TPRM workflow tool such as Daydream can keep location requirements, approvals, and evidence tied to each third party and renewal cycle.

Footnotes

1. NIST Special Publication 800-53 Revision 5