Ensuring Your Documents Are Subject to Your Jurisdiction's Laws — Not a Foreign Vendor's — with Customer-Owned Infrastructure, Customer-Managed Encryption, and No Vendor Access to Content
Data sovereignty goes beyond data residency. Residency answers the question "where is the data stored?" Sovereignty answers the harder question: "whose laws govern the data, and who can be compelled to produce it?"
An organisation can satisfy residency by storing documents within its own country — but if those documents are stored in a platform operated by a foreign-headquartered vendor, that vendor may be subject to foreign government data access demands. The US CLOUD Act, for example, allows US authorities to compel US-headquartered companies to produce data regardless of where the data is physically stored. Similar cross-border access mechanisms exist in other jurisdictions. The result: your data may be physically in your country, but legally accessible to a foreign government through the vendor that controls it.
This is why data sovereignty requires more than choosing the right region. It requires controlling who operates the infrastructure, who holds the encryption keys, and who can access the data — not just where the data physically sits. FormKiQ addresses data sovereignty architecturally. The platform deploys into your own AWS account, operated by your own team, encrypted with keys you manage in your own KMS, and accessible only to users you authorise in your own identity system. No FormKiQ personnel have access to your documents, your metadata, your encryption keys, or your audit logs during normal operation.
Data Residency vs. Data Sovereignty
These concepts are related but distinct, and conflating them creates a false sense of compliance:
| Data Residency | Data Sovereignty | |
|---|---|---|
| Core question | Where is the data physically stored? | Whose laws govern the data, and who can compel access? |
| What it controls | Geographic location of storage and processing | Legal jurisdiction over the data and the infrastructure that holds it |
| How it's achieved | Deploy to a specific AWS region | Deploy in an account you own and operate, with encryption keys you control and no vendor access to content |
| What it doesn't address | Whether a foreign vendor can be compelled to produce the data under its own country's laws | Where the data is physically stored (sovereignty can be achieved regardless of physical location, but residency adds geographic certainty) |
| Verification | Check the AWS region of your S3 buckets and services | Verify that the AWS account is owned by your organisation, that KMS keys are under your control, and that no foreign vendor has administrative access to your data |
Most regulatory frameworks care about both. GDPR requires data protection regardless of processing location (sovereignty concern) and strongly favours EU/EEA storage (residency concern). Achieving one without the other leaves a compliance gap. See the companion guide: Data Residency for Document Management on AWS.
Why Vendor-Hosted Platforms Create Sovereignty Risk
The most common threat to data sovereignty in document management is the vendor relationship itself. When documents are stored in a vendor-operated platform — even if the data physically resides in your country — the vendor's corporate jurisdiction introduces sovereignty exposure.
The CLOUD Act Problem
The US Clarifying Lawful Overseas Use of Data (CLOUD) Act, enacted in 2018, allows US law enforcement to compel US-headquartered companies to produce data in their possession, custody, or control — regardless of where the data is physically stored. This means:
- If your document management vendor is US-headquartered, US authorities can potentially compel the vendor to produce your documents — even if those documents are stored in the EU, Canada, Australia, or any other jurisdiction
- The data access demand may be issued without notifying you — the vendor, not your organisation, is the party served with the demand
- The vendor may comply without informing you, depending on the type of legal process involved
The CLOUD Act is the most discussed example, but it's not unique. Similar cross-border data access mechanisms exist or are being developed in other jurisdictions, including the UK's Crime (Overseas Production Orders) Act 2019 and Australia's International Production Orders framework.
How Vendor Architecture Creates the Exposure
| Architecture Element | Vendor-Hosted Platform | FormKiQ in Your AWS Account |
|---|---|---|
| Account ownership | Vendor owns the AWS account (or equivalent infrastructure) where your data resides | You own the AWS account where your data resides |
| Infrastructure control | Vendor operates the servers, databases, and storage systems | You operate the infrastructure (or FormKiQ manages it on your behalf within your account) |
| Encryption key control | Vendor manages encryption keys — and can decrypt your data | You manage encryption keys in your own KMS — FormKiQ does not hold your keys |
| Administrative access | Vendor's engineering and operations teams have access to your data as part of platform operation | No FormKiQ personnel have access to your documents, metadata, or encryption keys during normal operation |
| Legal jurisdiction over infrastructure | Vendor's corporate jurisdiction determines which government can compel data access | Your corporate jurisdiction determines legal authority over your data; AWS's role is as infrastructure provider, not data controller |
| Compelled disclosure | Vendor can be compelled to produce your data under its home jurisdiction's laws | No vendor to compel — access demands must be directed to your organisation under your jurisdiction's legal process |
How FormKiQ Protects Data Sovereignty
FormKiQ's architecture provides sovereignty protection through three mechanisms: customer account ownership, customer-managed encryption, and no vendor content access.
1. Customer Account Ownership
FormKiQ deploys into an AWS account that you own and control. This is the foundational sovereignty protection — the AWS account is registered to your organisation, subject to your jurisdiction's laws, and accessible only to personnel you authorise. This means:
- Your organisation is the data controller — not FormKiQ, and not AWS. Data access demands must be directed to your organisation under your jurisdiction's legal process
- AWS is the infrastructure provider — AWS operates the data centre and the services, but your data is encrypted with your keys and accessible only through your account. AWS cannot read your encrypted data without your keys
- FormKiQ is the software provider — FormKiQ provides the application code deployed via CloudFormation, but does not operate your instance, host your data, or hold your keys
2. Customer-Managed Encryption
FormKiQ encrypts every document at rest using AWS KMS customer-managed keys — keys that reside in your KMS, under key policies you define, with access restricted to services and roles you authorise.
| Encryption Aspect | Sovereignty Implication |
|---|---|
| Key ownership | You own the KMS keys — they exist in your AWS account and cannot be accessed by FormKiQ |
| Key policies | You define who and what can use the keys — including the ability to deny access to any party |
| Key rotation | You control key rotation schedule and can rotate keys at any time |
| Key deletion | You can delete keys — rendering encrypted data permanently inaccessible, even to AWS |
| Decryption authority | Only services and roles authorised in your key policy can decrypt documents — no external party can decrypt without your authorisation |
Customer-managed encryption is the technical enforcement of sovereignty. Even if a foreign authority were to gain access to the S3 bucket containing your documents, the documents would be encrypted and inaccessible without the KMS keys — which are under your control in your account.
3. No Vendor Content Access
During normal operation, FormKiQ personnel do not have access to your documents, metadata, encryption keys, or audit logs. The platform deploys as CloudFormation infrastructure into your account — FormKiQ's role is to provide the templates and the code, not to operate your instance.
| Access Scenario | FormKiQ's Access |
|---|---|
| Normal operation | No access to your documents, metadata, keys, or logs |
| Support and troubleshooting | Access only when explicitly granted by your team, for the duration of the support engagement, and limited to the scope you authorise |
| Vendor-managed deployment (Enterprise) | FormKiQ manages infrastructure operations on your behalf within your account — access is governed by your IAM policies and auditable in your CloudTrail |
| Platform updates | Updates delivered as new CloudFormation templates — you review and deploy them; FormKiQ does not push updates into your environment without your action |
Sovereignty by Deployment Model
FormKiQ's three deployment models offer different sovereignty profiles. All three deploy into AWS accounts owned by or designated by the customer — FormKiQ does not operate a shared multi-tenant environment.
| Deployment Model | Sovereignty Profile | Best For |
|---|---|---|
| Customer-Managed AWS | Strongest sovereignty — your account, your keys, your operations, no vendor access | Organisations with internal cloud operations capability and strict sovereignty requirements |
| Hybrid | Strong sovereignty — your account, your keys, FormKiQ manages specific operational aspects under your IAM policies | Organisations that want sovereignty protection with reduced operational burden |
| Vendor-Managed | Managed sovereignty — your account, your keys, FormKiQ manages infrastructure operations; access governed by your IAM and auditable in your CloudTrail | Organisations that want the sovereignty benefits of own-account deployment without internal operations capability |
Data Sovereignty and AI Processing
AI processing introduces a specific sovereignty concern: when documents are sent to an AI service for analysis, the AI service provider may have access to document content during processing. FormKiQ addresses this through Amazon Bedrock's architecture:
- Processing within your account — Bedrock inference runs within your AWS account; document content is not sent to an external service
- No model training on your data — Amazon Bedrock does not use customer data for model training
- Inference region controls — you specify which AWS region is used for AI processing, ensuring content is processed within your sovereignty boundary
- No third-party access — document content is not shared with model providers (Anthropic, Amazon, or others) during inference
This means AI document processing does not compromise sovereignty — the same protections that apply to document storage and metadata apply to AI processing outputs.
Sovereignty Frameworks and Legislation
Data sovereignty concerns are driven by a combination of national legislation, cross-border access mechanisms, and government data protection mandates:
| Framework | Sovereignty Concern | FormKiQ Mitigation |
|---|---|---|
| US CLOUD Act | US-headquartered vendors can be compelled to produce data regardless of storage location | FormKiQ deploys in your account — no US vendor custody of your data during normal operation |
| GDPR — Schrems II implications | EU-US data transfers require adequate safeguards; vendor access from US jurisdiction creates transfer concerns | EU-region deployment in customer's own account; customer-managed encryption; no FormKiQ personnel access to content |
| Canada — PIPEDA & provincial legislation | Personal information subject to Canadian law; cross-border disclosure concerns | Canadian-region deployment (Montreal, Calgary) in customer's account; customer-managed encryption |
| Australia — Privacy Act & APRA CPS 234 | Financial sector data subject to Australian jurisdiction; offshore outsourcing restrictions | Australian-region deployment (Sydney) in customer's account; customer-managed encryption |
| India — DPDP Act & RBI guidelines | Payment data localisation; broader personal data sovereignty provisions | Indian-region deployment (Mumbai) in customer's account |
| Government cloud mandates | Many governments require government data to be stored on government-authorised or domestically controlled cloud infrastructure | Customer-managed deployment on AWS GovCloud (US), or standard AWS regions in customer's government-designated account |
Who Needs Data Sovereignty Document Management
| Organisation Type | Sovereignty Concern | Key Drivers |
|---|---|---|
| Government agencies | Citizen data must be subject to domestic law; foreign government access to citizen data is unacceptable | National security; public trust; government cloud mandates |
| Defence and intelligence contractors | Classified and sensitive defence information must be protected from foreign government access | National security; ITAR; defence procurement regulations |
| Financial institutions | Client financial data subject to domestic financial regulation; foreign government access creates regulatory and client trust risk | APRA CPS 234; OSFI B-10; FCA; MAS; financial regulatory sovereignty requirements |
| Healthcare organisations | Patient data subject to domestic health privacy legislation; foreign government access violates patient trust and may violate law | HIPAA; GDPR; provincial health privacy legislation; patient trust |
| Legal and professional services | Client data subject to professional privilege; foreign government access may violate privilege and professional obligations | Legal professional privilege; bar association obligations; client confidentiality |
| Critical infrastructure operators | Operational and customer data for energy, water, telecommunications, and transport must be protected from foreign interference | Critical infrastructure protection legislation; national security frameworks |
| Research institutions | Research data subject to ethics board restrictions, funder requirements, and participant consent that may prohibit foreign government access | Research ethics frameworks; funder data sovereignty requirements; participant consent conditions |
| Multi-national corporations | Different sovereignty requirements across jurisdictions — EU, Canadian, Australian, and Asian requirements may differ substantially | Multi-framework compliance; customer DPA requirements; corporate risk management |
FormKiQ Editions for Data Sovereignty
| Capability | Core | Essentials | Advanced | Enterprise |
|---|---|---|---|---|
| Customer-Account Deployment | ✓ | ✓ | ✓ | ✓ |
| Single-Region Deployment (20 regions) | ✓ | ✓ | ✓ | ✓ |
| GovCloud Deployment (US West) | ✓ | |||
| Encryption (KMS — customer-managed keys) | ✓ | ✓ | ✓ | |
| SSO (SAML — Entra, Google, Auth0) | ✓ | ✓ | ✓ | |
| Document Control & Versioning | ✓ | ✓ | ✓ | |
| Workflows, Queues & Rulesets | ✓ | ✓ | ✓ | |
| AI Processing with Inference Region Controls | ✓ | ✓ | ||
| Multi-Instance & Multi-Region Licensing | ✓ | ✓ | ||
| Document Gateway Modules | ✓ | ✓ | ||
| Integration Framework Modules | ✓ | ✓ | ||
| Vendor-Managed Deployment | ✓ | |||
| 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 your own AWS account in any of 20 supported regions in fifteen to twenty minutes. Customer-managed encryption is available from Essentials onward. Multi-instance and multi-region licensing for multi-jurisdiction sovereignty requirements is available on Advanced and Enterprise.
Frequently Asked Questions
What is data sovereignty?
Data sovereignty is the principle that data is subject to the laws of the jurisdiction where it is stored and processed, and that foreign governments or entities cannot compel access to it outside of established legal cooperation mechanisms. For document management, sovereignty means ensuring that your documents are subject to your jurisdiction's laws — not to a foreign vendor's home jurisdiction.
How is data sovereignty different from data residency?
Data residency is about where data is physically stored. Data sovereignty is about whose laws govern the data and who can compel access to it. You can have residency without sovereignty — storing data in your country in a platform operated by a foreign vendor that can be compelled to produce it under that vendor's home jurisdiction's laws. FormKiQ provides both: residency through regional deployment, and sovereignty through customer account ownership and customer-managed encryption.
Why does deploying in my own AWS account matter for sovereignty?
Because the AWS account is registered to your organisation and subject to your jurisdiction's laws. When your documents are in a vendor's account, data access demands can be directed to the vendor under the vendor's home jurisdiction's legal process — potentially without your knowledge. When your documents are in your own account, access demands must be directed to your organisation under your jurisdiction's legal process.
Can FormKiQ access my documents?
During normal operation, FormKiQ personnel do not have access to your documents, metadata, encryption keys, or audit logs. FormKiQ provides the application code (deployed via CloudFormation into your account), but does not operate your instance or host your data. Support access, when needed, is granted by your team, limited in scope and duration, and auditable in your CloudTrail.
How does customer-managed encryption protect sovereignty?
Customer-managed KMS keys ensure that only services and roles you authorise can decrypt your documents. Even if a party were to gain access to the S3 bucket containing your documents, the documents would be encrypted and inaccessible without your KMS keys. You can revoke key access at any time, and you can delete keys to render data permanently inaccessible.
What about the CLOUD Act?
The US CLOUD Act allows US authorities to compel US-headquartered companies to produce data in their possession, custody, or control. FormKiQ mitigates this risk because your documents are in your AWS account — not in FormKiQ's possession, custody, or control during normal operation. FormKiQ does not hold your data or your encryption keys, which limits the applicability of compelled disclosure mechanisms directed at FormKiQ.
Does FormKiQ support data sovereignty for AI processing?
Yes. AI processing through Amazon Bedrock runs within your AWS account, in the region you specify through inference region controls. Document content is not sent to external services, not shared with model providers, and not used for model training. The same sovereignty protections that apply to document storage extend to AI processing.