SA-9(5): Processing, Storage, and Service Location

SA-9(5): processing, storage, and service location requirement means you must define where a third party is allowed to process and store your system data, then enforce those geographic/location limits through contracts, technical controls, and ongoing verification. Operationalize it by mapping in-scope services to approved locations, blocking non-approved regions, and keeping auditable evidence of enforcement. ¹

Key takeaways:

• You need explicit, documented location restrictions for third-party processing and storage, tied to your risk basis. ¹
• Contracts alone are not enough; you must implement and verify location enforcement in the service configuration and operations.
• Your audit pass/fail hinges on evidence: approved location list, enforcement settings, and monitoring results.

The sa-9(5): processing, storage, and service location requirement is a practical control: decide which locations are acceptable for third-party processing and storage, then make those limits real in how systems run. For many teams, the hidden work is scoping. “Location” can mean cloud region, data center country, support/administration location, backup location, DR location, logging/telemetry location, and even where managed service engineers access data.

This requirement usually shows up during ATO work, FedRAMP-aligned reviews, or any assessment that follows NIST SP 800-53. It also becomes a day-to-day vendor due diligence issue: you cannot claim location restrictions if you do not know where the third party actually processes data, or if your cloud configuration silently replicates data outside your approved boundary.

A fast, operator-friendly approach is to treat SA-9(5) as a three-part control: (1) a written rule for allowed locations, (2) enforceable configuration and contract language, and (3) monitoring that detects drift. If you use Daydream to manage third-party risk, this requirement maps cleanly to a control owner, an implementation procedure, and recurring evidence artifacts, so you can stay assessment-ready without rebuilding the same packet each review cycle.

Requirement: SA-9(5) processing, storage, and service location

Plain-English interpretation: You must restrict where a third party is allowed to process, store, or provide the service for your system or data, and you must base those restrictions on defined criteria (for example, mission needs, legal/regulatory drivers, threat considerations, or data sensitivity). Then you must be able to show the restriction is implemented and working. ¹

Who it applies to (entity and operational context)

Applies when:

• You operate a federal information system or a system assessed against NIST SP 800-53.
• You are a contractor handling federal data and rely on third parties (cloud providers, SaaS, MSPs, data processors, subcontractors) that can process or store that data. ¹

Operationally, SA-9(5) is triggered by:

• Cloud services with selectable regions (IaaS/PaaS/SaaS).
• Third-party support models that allow remote admin access from multiple countries.
• Backup, DR, and logging architectures that copy data cross-region by default.
• Subprocessors and “shadow” fourth parties used by the primary third party.

Regulatory text

“Restrict the location of [organization-defined processing, storage, and/or service components] to [organization-defined locations] based on [organization-defined criteria].” ¹

What the operator must do: define the components and allowed locations, document the criteria for the restriction, implement controls that prevent non-approved locations, and keep evidence that enforcement exists and is monitored. ¹

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

Step 1: Define scope and the “location objects”

Build a short scoping statement that you can hand to engineering and procurement:

In-scope components (typical):

• Primary data storage (databases, object storage, file stores)
• Application processing (compute, managed runtimes)
• Backups and snapshots
• Disaster recovery / failover regions
• Logs, monitoring, and APM telemetry
• Customer support tooling that can display production data
• Key management/HSM location (if managed by a third party)

Location objects to capture:

• Cloud region(s) (e.g., “US-East”, “EU-West”)
• Country(ies) and legal jurisdiction for data residency
• Data center location (if non-cloud)
• Remote admin/support access location constraints

Deliverable: a one-page “SA-9(5) scope” note in your control record.

Step 2: Set your allowed locations and decision criteria

You need two lists and a rationale:

• Allowed locations (approved regions/countries/data centers)
• Disallowed locations (explicitly prohibited, or “everything else”)
• Criteria that drives the choice (your organization-defined criteria) ¹

Keep the criteria practical and reviewable, for example:

• Data type and impact level
• Customer/agency contractual restrictions
• Threat model (foreign access, supply chain exposure)
• Business continuity needs (multi-region within boundary)

Deliverable: an “Approved Processing/Storage Locations Standard” referenced by procurement and architecture review.

Step 3: Translate the restriction into third-party contract terms

Add SA-9(5) language to:

• MSA/DPA
• Order form / SOW
• Security addendum
• Subprocessor flow-down clause

Minimum contract elements to include:

• Approved processing/storage locations (by region/country)
• Prohibition on moving data outside approved locations without written approval
• Subprocessor disclosure and location controls
• Audit/attestation right or equivalent evidence delivery
• Incident notification if location drift occurs

Deliverable: approved clause library and executed agreements for in-scope third parties.

Step 4: Enforce the restriction technically (don’t stop at paper)

Common enforcement patterns:

• Cloud region restrictions: policies that prevent resource creation outside approved regions; deny-by-default for non-approved regions.
• Data residency settings in SaaS: configure the tenant to the approved region; disable “global” features that replicate data cross-border.
• Backups/DR: ensure backups stay in approved regions; validate failover targets meet the boundary.
• Support access controls: require support to use controlled access paths (bastions, PAM, JIT) and document allowed support geographies where feasible.

Deliverable: screenshots/exports of relevant configuration settings and policies.

Step 5: Verify location in onboarding due diligence

During third-party onboarding, require:

• Data location statement (where data is stored/processed, including backups)
• Subprocessor list with locations
• Description of replication and DR behavior
• Support model and admin access locations
• Evidence package (attestation reports if available, plus architectural statements)

Deliverable: completed third-party intake with explicit location answers.

Step 6: Monitor for drift and revalidate on change

Add operational checks:

• Trigger review when the third party adds subprocessors, opens new regions, or changes hosting.
• Require notice/approval before location changes (contract + process).
• Periodic revalidation (aligned to your third-party review cadence and system risk).

Deliverable: change log, review tickets, and periodic revalidation records.

Step 7: Assign ownership and make evidence recurring

Auditors fail SA-9(5) most often on “we do it, but we can’t prove it.” Treat evidence as a scheduled output.

• Control owner: Security/GRC with engineering and procurement contributors
• Evidence owner: the team that can export settings (cloud platform, IT, vendor manager)
• Cadence: tied to third-party review and significant changes

Daydream fit: track SA-9(5) as a requirement with a named owner, a repeatable procedure, and a recurring evidence list so your assessment packet stays current.

Required evidence and artifacts to retain

Keep these artifacts per in-scope third party/system:

Governance

• Approved location standard + criteria statement ¹
• Data classification / impact rationale that drives location choices
• Architecture diagrams showing data flows and storage/processing points

Third-party documents

• Executed contract addendum with location restrictions
• Subprocessor list with locations (current and versioned)
• Third-party data residency statement and DR/backup location details

Technical proof

• Configuration exports/screenshots showing region pinning, residency settings, replication controls
• Access control evidence for admin/support pathways (PAM/JIT/bastion logs or configuration)

Operational proof

• Onboarding due diligence record with explicit location answers
• Change management tickets for any location-related changes
• Periodic revalidation results and exceptions/risk acceptances

Common exam/audit questions and hangups

Expect assessors to ask:

• “Show me where you defined the allowed locations and the criteria.” ¹
• “Which third parties can process/store system data, and where?”
• “How do you prevent a team from deploying to an unapproved cloud region?”
• “Where do backups, logs, and DR live?”
• “How do you know your SaaS provider isn’t using subprocessors in other locations?”
• “Show evidence from the last review period that location settings remained compliant.”

Typical hangups:

• Confusing “company HQ location” with “data processing location.”
• Missing backup/logging/telemetry locations.
• Relying on a sales email instead of contract terms and configuration evidence.

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails	Fix
“US-only” statement with no defined regions/services	Too vague to enforce or audit	Convert to explicit allowed cloud regions/countries and map each service to them
Contract clause exists, but tenant is set to “global”	Data can replicate outside boundary	Enforce residency settings and disable cross-region replication features
No subprocessor location control	Fourth parties can break residency	Require subprocessor list + location, approval for changes, and periodic revalidation
Only primary storage reviewed	Backups/logs/DR often drift	Include backups, DR, logs, and support tooling in the SA-9(5) scope
No evidence capture plan	Control “exists” but can’t be demonstrated	Create an evidence checklist and store exports/screenshots per review cycle

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so you should treat SA-9(5) primarily as an assessment and contractual compliance risk within NIST SP 800-53-aligned programs.

Risk shows up as:

• Regulatory/contract noncompliance if federal/agency requirements mandate specific hosting boundaries.
• Data exposure risk if data crosses into jurisdictions that change government access, discovery, or incident response constraints.
• Operational risk when DR fails over to a non-approved region during an outage.

Practical 30/60/90-day execution plan

First 30 days (stabilize)

• Name the SA-9(5) control owner and approvers (Security, Legal/Procurement, Cloud/IT).
• Publish an approved location standard: allowed locations + criteria. ¹
• Inventory in-scope third parties and services that process/store system data.
• Identify quick wins: obvious region pinning and SaaS residency settings you can turn on now.

Days 31–60 (implement and contract)

• Add contract language for location restrictions and subprocessor controls to your templates.
• Remediate top-risk third parties: amend contracts or document exceptions with risk acceptance.
• Implement cloud region guardrails and confirm backups/logs/DR locations meet the boundary.
• Stand up an evidence folder structure per third party with a checklist.

Days 61–90 (verify and operationalize)

• Run a location verification pass: configuration exports + third-party attestations/statements.
• Add “location change” to vendor change management triggers and intake checklists.
• Schedule recurring revalidation and evidence capture.
• In Daydream, map SA-9(5) to the owner, the procedure, and the evidence artifacts so the control stays audit-ready.

Frequently Asked Questions

Does SA-9(5) apply only to cloud hosting?

No. It applies to any third party processing or storing your data, including SaaS, MSPs, data centers, and subcontractors. Cloud just makes location drift easier because regions and replication are configurable. ¹

What counts as “service location” versus “data location”?

Treat “service location” as where the service is delivered or administered in a way that can access data, such as support and operations. “Processing/storage location” is where the system actually processes and stores data, including backups and logs. ¹

If a third party says “data may be processed globally,” can I still be compliant?

Usually not without an approved exception. SA-9(5) expects you to restrict locations to defined allowed locations based on your criteria, so “global” typically conflicts with a restrictive boundary unless your allowed locations truly include global processing. ¹

Do I need to block non-approved regions technically, or is a contract clause enough?

Assessors often expect enforcement, not just intent. Use contract language plus technical guardrails where you control configuration, and require verifiable evidence from third parties where you do not. ¹

How do I handle subcontractors and subprocessors?

Require disclosure of subprocessors and their processing/storage locations, then flow your location restrictions through the contract and revalidate on change. Keep versioned subprocessor lists as evidence.

What if the business needs multi-region resilience but residency is strict?

Design for redundancy inside the approved boundary first (for example, multiple regions within the allowed geography). If cross-boundary DR is necessary, document the criteria, get written approval, and record a risk acceptance with compensating controls. ¹

Footnotes

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