Evidence
SDS Data Residency and Retention Model
Data residency defines where SDS documents are processed, stored, and deleted. This page explains the regional deployment, retention, and deletion options teams typically review before approving a production SDS workflow.
Last updated: 2026-03-11
Residency options by deployment model
| Deployment model | Residency pattern | Best fit |
|---|---|---|
| Shared evaluation flow | Short-lived evaluation processing with tighter abuse controls. | Teams validating extraction quality before procurement. |
| Regional production lane | Regional processing aligned to the agreed operating region, including EU and India options. | Programs with procurement or regional governance requirements. |
| Dedicated enterprise deployment | Residency, retention, and deletion behavior pinned to the contracted deployment model. | Large-volume or regulated customers that need explicit governance terms. |
Retention and deletion model
| Lifecycle stage | What teams usually define | Governance reason |
|---|---|---|
| Upload intake | Whether sample documents are processed transiently or retained for a defined review window. | Controls how long source documents remain accessible. |
| Structured outputs | How long JSON, XML, CSV, warnings, and request metadata are retained. | Supports audit trails without keeping source files longer than necessary. |
| Deletion policy | Time-based deletion, manual purge requests, or contract-specific retention windows. | Aligns service operation with customer data policy. |
| Regional transfer rules | Whether data can leave the agreed operating region for support or processing. | Clarifies cross-border handling before go-live. |
Questions procurement and privacy teams usually ask
- Which region processes the source SDS document and the derived structured output?
- What is the default retention window for evaluation traffic versus production traffic?
- Can deletion behavior be aligned to internal customer policy?
- Are submitted SDS documents used for public model training? They should not be.
- Which legal, privacy, and security pages define the operating model in one place?
Update log
- 2026-03-11: Replaced generic FAQ and page scaffolding with topic-specific AI-citable content and cleaner internal links.
- 2026-03-07: Published proof-page baseline and governance framing for this topic.
- 2026-03-07: Added citation-ready structure with explicit sectioned answers and FAQs.
- 2026-03-07: Added descriptive internal links to related proof and implementation pages.
FAQ
Which data residency options are available?
EU and India data residency options are available today, and regional deployment choices can be aligned to the agreed enterprise operating model.
How long are SDS files retained?
Retention is configurable by workflow. Evaluation flows can use shorter windows, while enterprise programs can define retention and deletion behavior contractually.
Are submitted SDS documents used to train public models?
No. Submitted SDS documents are processed to return extraction results and are not used to train public foundation models.
Related pages in this topic graph
- SDS extraction API
- SDS security controls and deployment model
- SDS schema versioning guide
- Privacy policy and retention notice
- Request data residency review
Need a residency and retention review for procurement?
Request data residency review
or see the
privacy policy.