Control Where Your Documents Are Stored and Processed — Down to the Specific AWS Region — with Hard-Boundary Guarantees You Can Verify
Data residency is the requirement that certain categories of data be stored and processed within a defined geographic boundary. For organisations subject to GDPR, PIPEDA, Quebec Law 25, Australia's Privacy Act, Brazil's LGPD, India's DPDP Act, or any of dozens of national and regional frameworks, residency is not a preference — it's a compliance obligation that carries regulatory penalties when breached and contractual consequences when violated.
The challenge with data residency in document management is that documents are the most common container for regulated personal data — and most document management platforms don't give organisations the ability to verify where their documents actually reside. Vendor-hosted SaaS platforms store your documents in the vendor's infrastructure, in regions the vendor chooses, under data movement policies the vendor defines. The vendor may provide a residency attestation, but the organisation cannot independently verify that documents, metadata, search indexes, and processing outputs all remain within the required boundary.
FormKiQ eliminates this verification gap. Every FormKiQ deployment is scoped to a single AWS region by default. Documents, metadata, search indexes, audit logs, and AI processing outputs all reside within the region you select — in your own AWS account, verifiable through your own AWS console, and auditable by your own infrastructure team. Data does not replicate across regions unless you explicitly configure cross-region architecture. The residency boundary is hard, verifiable, and under your control.
What Is Data Residency?
Data residency and related concepts are often conflated. Understanding the distinctions matters because they drive different architectural decisions:
| Concept | Definition | Architectural Implication |
|---|---|---|
| Data residency | The requirement that data be stored within a specific geographic boundary — typically a country or economic region | Deploy to an AWS region within the required boundary; ensure all data components (storage, metadata, indexes) are in-region |
| Data localisation | A stronger form of residency — data must not only be stored within the boundary but may not be transferred outside it under any circumstances | Single-region deployment with no cross-region replication; restrict all processing to in-region services |
| Data sovereignty | The principle that data is subject to the laws of the jurisdiction where it is stored — and that foreign governments or entities cannot compel access to it | Account-level controls; encryption with customer-managed keys; legal and contractual protections beyond technical architecture |
| Data protection | The broader legal framework governing how personal data is collected, processed, stored, and shared — data residency is one element of data protection | Residency controls combined with access controls, retention policies, consent management, and processing records |
Data residency is the foundation. Without knowing where your data physically resides, you cannot assess whether sovereignty, localisation, or protection requirements are met. See the companion guide: Data Sovereignty for Document Management on AWS.
How FormKiQ Enforces Data Residency
FormKiQ's residency enforcement is architectural, not policy-based. Data stays in-region because of how the platform is deployed — not because of a configuration setting that could be changed or overridden.
Single-Region Deployment by Default
Every FormKiQ instance is deployed to a single AWS region via CloudFormation. All platform components deploy to that same region:
| Component | AWS Service | Residency Enforcement |
|---|---|---|
| Document storage | Amazon S3 | S3 bucket created in the selected region; data does not leave the region unless explicitly configured for cross-region replication |
| Metadata | Amazon DynamoDB | DynamoDB table created in the selected region; data does not replicate outside the region unless explicitly configured |
| Search indexes | Amazon OpenSearch | OpenSearch domain created in the selected region; indexes remain in-region |
| Audit logs | AWS CloudTrail + FormKiQ audit log | Audit data stored in S3 and DynamoDB within the selected region |
| Encryption keys | AWS KMS | KMS keys created in the selected region; keys do not replicate across regions |
| Compute | AWS Lambda | Lambda functions execute in the selected region; document content processed in-region |
| Identity | Amazon Cognito | User pool created in the selected region; authentication data remains in-region |
| AI processing | Amazon Bedrock | Inference region controls specify which region is used for AI processing — configurable to match the deployment region |
This means that when you deploy FormKiQ to eu-central-1 (Frankfurt), every document, every metadata record, every search index entry, every audit log, and every encryption key resides in Frankfurt. No component stores data outside that region as part of normal operation.
Verifiable Residency
A critical advantage of deploying FormKiQ in your own AWS account: residency is verifiable, not attested. Your infrastructure team can confirm residency by examining:
- S3 bucket region — visible in the AWS console and API; the bucket physically resides in the specified region
- DynamoDB table region — visible in the console; the table and its data reside in the specified region
- OpenSearch domain region — visible in the console; the search domain resides in the specified region
- KMS key region — visible in the console; the key exists only in the specified region
- CloudTrail configuration — visible in the console; audit logs are delivered to S3 in the specified region
- Lambda function region — visible in the console; functions execute in the specified region
This is fundamentally different from vendor residency attestations, where the organisation trusts the vendor's claim without the ability to verify it independently.
Supported AWS Regions
FormKiQ supports deployment across 20 AWS regions, providing residency options across six continents:
| Region | AWS Region Code | Key Data Residency Frameworks |
|---|---|---|
| Frankfurt, Germany | eu-central-1 | GDPR, German BDSG, German banking regulations |
| Ireland | eu-west-1 | GDPR |
| London, UK | eu-west-2 | UK GDPR post-Brexit, UK FCA requirements |
| Paris, France | eu-west-3 | GDPR, French CNIL requirements |
| Stockholm, Sweden | eu-north-1 | GDPR, Nordic data protection legislation |
| Milan, Italy | eu-south-1 | GDPR, Italian healthcare and financial services |
| N. Virginia, US | us-east-1 | US state privacy laws, HIPAA, federal workloads |
| Ohio, US | us-east-2 | US state privacy laws, HIPAA |
| Oregon, US | us-west-2 | US state privacy laws, HIPAA |
| Montreal, Canada | ca-central-1 | PIPEDA, Quebec Law 25, provincial privacy legislation |
| Calgary, Canada | ca-west-1 | PIPEDA, Alberta PIPA |
| Mumbai, India | ap-south-1 | India DPDP Act, RBI data localisation |
| Singapore | ap-southeast-1 | Singapore PDPA |
| Sydney, Australia | ap-southeast-2 | Australian Privacy Act, APRA CPS 234 |
| Tokyo, Japan | ap-northeast-1 | Japan APPI, financial data localisation |
| Seoul, South Korea | ap-northeast-2 | South Korea PIPA, financial data localisation |
| Cape Town, South Africa | af-south-1 | South Africa POPIA |
| São Paulo, Brazil | sa-east-1 | Brazil LGPD |
| UAE | me-central-1 | UAE PDPL, DIFC/ADGM data protection |
| Bahrain | me-south-1 | GCC data localisation, Saudi Arabia PDPL-adjacent |
FormKiQ Core also supports AWS GovCloud (US West) for US federal workloads requiring FedRAMP High-authorised infrastructure. For unlisted regions, SAM CLI installation is available. AWS China regions are not currently supported.
Multi-Jurisdiction Residency
Organisations operating across multiple jurisdictions often need documents from different regions to remain in their respective geographic boundaries. The typical pattern is separate FormKiQ instances per region, with centralised identity but no cross-region data movement:
┌──────────────────────────┐
│ Central Identity (SSO) │
│ Microsoft Entra / Google │
└──────┬─────────┬──────────┘
│ │
┌─────────────┘ └──────────────┐
▼ ▼
┌──────────────────────────┐ ┌──────────────────────────┐
│ FormKiQ Instance — EU │ │ FormKiQ Instance — CA │
│ Region: eu-central-1 │ │ Region: ca-central-1 │
│ (Frankfurt) │ │ (Montreal) │
│ │ │ │
│ EU documents │ │ Canadian documents │
│ EU metadata │ │ Canadian metadata │
│ EU search indexes │ │ Canadian search indexes │
│ EU audit logs │ │ Canadian audit logs │
│ EU encryption keys │ │ Canadian encryption keys│
│ │ │ │
│ GDPR-governed │ │ PIPEDA/Law 25-governed │
└──────────────────────────┘ └──────────────────────────┘
This architecture provides:
- Hard residency boundaries — each instance's data stays in its region; no cross-region data movement
- Centralised authentication — users authenticate through a single SSO provider, with access to the appropriate regional instance based on their role and jurisdiction
- Independent governance — each instance has its own retention policies, access controls, and compliance configuration appropriate to the jurisdiction
- Independent audit — each instance produces its own audit trail, enabling jurisdiction-specific audit responses
Multi-instance and multi-region licensing is available on FormKiQ Advanced and Enterprise.
Data Residency for AI Processing
AI processing creates a specific residency concern: when a document is sent to an AI service for classification, extraction, or analysis, the document content must be processed within the residency boundary — not just stored within it. FormKiQ addresses this through Amazon Bedrock's inference region controls:
| Residency Concern | How FormKiQ Addresses It |
|---|---|
| Processing location | Bedrock inference region controls specify which AWS region is used for AI processing — configurable to match the document's residency region |
| Data in transit | Documents sent to Bedrock for processing travel within the AWS network within the specified region — they do not leave the region boundary |
| Processing output | AI outputs (classifications, extracted metadata, summaries) are stored in the same region as the source document |
| No external sharing | Bedrock processing occurs within your AWS account — document content is not shared with third parties or used for model training |
This is a critical distinction from third-party AI services, where documents may be processed in any region the service provider chooses — and where the processing location may change without notice.
Data Residency and Related Governance Controls
Data residency doesn't operate in isolation. It intersects with other governance controls that together form a complete data protection posture:
| Governance Control | How It Relates to Residency |
|---|---|
| Encryption | Documents encrypted at rest with KMS keys in the same region — keys cannot be used from outside the region unless explicitly configured |
| Access control | ABAC policies can include jurisdiction as an access attribute — EU documents accessible only to EU-authorised users |
| Retention | Jurisdiction-specific retention policies applied to documents within each regional instance — ensuring retention compliance aligns with residency compliance |
| Audit trail | Audit logs stored in the same region as the documents they describe — audit evidence is co-located with the data it evidences |
| Data subject rights | GDPR right-to-erasure, right-of-access, and other data subject requests processed within the same regional instance where the data resides |
Regulatory Frameworks Requiring Data Residency
| Framework | Residency Requirement | FormKiQ Support |
|---|---|---|
| GDPR / UK GDPR | Personal data of EU/UK residents must be protected regardless of processing location; many organisations implement EU-only storage as a compliance measure | EU region deployment (six regions); UK region (London) |
| PIPEDA / Quebec Law 25 | Canadian personal information subject to Canadian jurisdiction; Quebec Law 25 imposes additional notification requirements for out-of-province transfers | Canadian deployment (Montreal, Calgary) |
| Australia Privacy Act / APRA CPS 234 | Financial sector data localisation requirements; general privacy obligations with cross-border transfer restrictions | Australian deployment (Sydney) |
| India DPDP Act / RBI guidelines | RBI mandates that payment data be stored within India; DPDP Act introduces broader data localisation provisions | Indian deployment (Mumbai) |
| Brazil LGPD | Personal data protection with cross-border transfer restrictions | Brazilian deployment (São Paulo) |
| South Korea PIPA | Personal information localisation requirements with consent-based transfer mechanisms | South Korean deployment (Seoul) |
| Japan APPI | Cross-border transfer restrictions with adequacy-based exceptions | Japanese deployment (Tokyo) |
| South Africa POPIA | Personal information must be processed in accordance with South African law; cross-border transfer conditions | South African deployment (Cape Town) |
| UAE PDPL / DIFC / ADGM | Data localisation requirements for certain data categories; free zone-specific data protection frameworks | UAE deployment (Dubai region) |
| Saudi Arabia PDPL | Data localisation requirements for certain categories of personal data | Bahrain deployment (regionally proximate) |
Who Needs Data Residency Document Management
| Organisation Type | Residency Challenge | Key Drivers |
|---|---|---|
| Multi-national corporations | Employee, customer, and vendor data across jurisdictions — each jurisdiction with different residency requirements | GDPR, PIPEDA, LGPD, APPI, PIPA, PDPA — simultaneous compliance across regions |
| Financial services | Client data subject to both privacy residency and financial regulatory localisation | APRA CPS 234, RBI data localisation, FCA, OSFI, MAS — financial regulators increasingly require in-country processing |
| Healthcare | Patient data subject to health-specific residency requirements alongside general privacy frameworks | HIPAA (US region), GDPR (EU region), provincial health privacy legislation (Canadian regions) |
| Government and public sector | Citizen data subject to government data sovereignty requirements; some governments mandate domestic processing | National security frameworks, government cloud requirements, citizen data protection mandates |
| Technology and SaaS | Customer data from multiple jurisdictions requiring per-customer or per-region residency guarantees | Customer DPA requirements, GDPR, SOC 2, customer security assessments |
| Legal and professional services | Client data subject to professional confidentiality obligations and client-specified residency requirements | Bar association requirements, client security requirements, engagement-specific residency commitments |
| Research institutions | Research data subject to funder-specified residency, ethics board requirements, and data protection legislation | Research ethics frameworks, funder data management requirements, international collaboration protocols |
FormKiQ Editions for Data Residency
| Capability | Core | Essentials | Advanced | Enterprise |
|---|---|---|---|---|
| Single-Region Deployment (20 regions) | ✓ | ✓ | ✓ | ✓ |
| GovCloud Deployment (US West) | ✓ | |||
| Document Storage (S3) & API | ✓ | ✓ | ✓ | ✓ |
| Tagging, Search & Classification | ✓ | ✓ | ✓ | ✓ |
| Encryption (KMS — in-transit & at-rest) | ✓ | ✓ | ✓ | |
| Workflows, Queues & Rulesets | ✓ | ✓ | ✓ | |
| Document Control & Versioning | ✓ | ✓ | ✓ | |
| AI Processing with Inference Region Controls | ✓ | ✓ | ||
| Multi-Instance & Multi-Region Licensing | ✓ | ✓ | ||
| Document Gateway Modules | ✓ | ✓ | ||
| Integration Framework Modules | ✓ | ✓ | ||
| Vendor-Managed & Hybrid Deployment | ✓ | |||
| Compliance Consulting | ✓ | |||
| Support | Community | 2-business-day SLA | Private Slack + 40 hrs onboarding | 8-business-hour SLA + strategic support |
Getting Started
FormKiQ Core can be deployed to any of 20 supported AWS regions in fifteen to twenty minutes. Multi-instance and multi-region licensing for organisations with residency requirements across multiple jurisdictions is available on Advanced and Enterprise.
Frequently Asked Questions
What is data residency?
Data residency is the requirement that certain categories of data — typically personal data — be stored within a specific geographic boundary, usually a country or economic region. Data residency requirements arise from privacy legislation (GDPR, PIPEDA, LGPD), sector-specific regulations (financial data localisation, health data requirements), and contractual obligations (customer DPAs, government procurement requirements).
How is data residency different from data sovereignty?
Data residency addresses where data is physically stored. Data sovereignty addresses whose laws govern the data and who can compel access to it. You can satisfy data residency (store data in Germany) while failing data sovereignty (if a foreign government can compel your vendor to produce the data under its own laws). FormKiQ supports both — residency through regional deployment, and sovereignty through customer-account ownership and customer-managed encryption keys.
How do I verify that my documents are stored in the correct region?
Because FormKiQ deploys into your own AWS account, you can verify residency directly through the AWS console — checking the region of your S3 buckets, DynamoDB tables, OpenSearch domains, KMS keys, and Lambda functions. This is a verifiable confirmation, not a vendor attestation.
Can I deploy FormKiQ in multiple regions simultaneously?
Yes. Multi-instance and multi-region licensing on Advanced and Enterprise allows separate FormKiQ deployments in different regions — each containing only the documents appropriate for that region. Centralised authentication through SSO provides a single identity plane across regional instances.
What about data that needs to be accessed from multiple regions?
FormKiQ's default architecture is single-region with no cross-region data movement. For organisations that need cross-region access, the recommended pattern is separate regional instances with centralised authentication — users are directed to the appropriate regional instance based on their role and the jurisdiction of the documents they need to access. Documents themselves do not move between regions.
Does AI processing respect data residency?
Yes. FormKiQ's AI processing through Amazon Bedrock includes inference region controls that specify which AWS region is used for AI processing. When configured to match the deployment region, AI processing occurs within the same residency boundary as document storage — documents do not leave the region for AI processing.