Document Management with Data Residency

Where is data actually stored?

In vendor-managed SaaS platforms, the answer to this question depends on the vendor's infrastructure decisions, which may not be fully transparent or independently verifiable. Data may be stored in one region, processed in another, backed up in a third, and indexed in a fourth — with the vendor's residency claims covering some of these locations but not all.

In a customer-managed FormKiQ deployment, the answer is precise and verifiable: documents are stored in S3 buckets in your account in the selected region, metadata is stored in DynamoDB tables in the same region, search indexes are maintained in OpenSearch in the same region, and processing functions run as Lambda functions in the same region. There is no cross-region replication unless you build it, and no vendor-controlled data movement that could take data outside your specified boundary.

Who controls data movement?

In shared infrastructure environments, the vendor controls where data moves — for backup, disaster recovery, performance optimization, or operational reasons. In a customer-managed FormKiQ deployment, data movement is entirely under your control. No data leaves your specified region without your explicit architectural decision.

What counts as data?

Data residency requirements typically apply to personal data, sensitive data, or defined categories of regulated data — not necessarily all data. Document content, metadata, search indexes, audit logs, and processing outputs may each be subject to residency requirements independently or collectively. FormKiQ stores all of these within the deployed region by default, with no components outside the region boundary unless explicitly configured.

Can residency be demonstrated?

Compliance with data residency requirements must be demonstrable to auditors, regulators, and procurement authorities — not just asserted. In a customer-managed FormKiQ deployment, residency can be demonstrated through AWS account configuration, CloudTrail audit logs, and infrastructure documentation that shows exactly where each component is deployed and what data it holds.

Regional deployment

FormKiQ deploys into individual AWS regions through AWS CloudFormation. Every component of the FormKiQ platform — S3 storage, DynamoDB metadata, Lambda processing, API Gateway, Cognito, CloudFront, OpenSearch, and Bedrock — is deployed within the selected region. Documents, metadata, search indexes, audit logs, and processing outputs all reside within the region where FormKiQ is deployed.

FormKiQ does not replicate data across regions by default. Cross-region replication — for disaster recovery, performance, or operational reasons — requires explicit architectural decisions and configuration by the customer, ensuring that any cross-region data movement is deliberate and documented rather than automatic.

Per-jurisdiction instances

For organizations operating across multiple jurisdictions with different residency requirements, FormKiQ supports separate deployment instances per jurisdiction — each within its own AWS account or organizational unit, deployed in the appropriate regional AWS data center, with its own document collection, metadata, access controls, and audit logs.

Cross-region authentication allows users to operate across jurisdictions where authorized — logging in once and accessing documents in multiple regional instances — while data remains isolated within each regional deployment. This provides a unified user experience without cross-border data movement.

No vendor-controlled data movement

In a customer-managed FormKiQ deployment, FormKiQ has no access to your infrastructure and no ability to move data outside your specified region. Data movement is entirely under your control, through your AWS account configuration. This makes residency verifiable and auditable in a way that vendor assurances cannot match.

Audit and documentation

AWS CloudTrail logs every API call and resource operation across your FormKiQ deployment — providing an independently verifiable record of all data access and movement within your account. Combined with AWS Config's resource inventory and S3 access logging, your residency posture is fully documented and auditable without relying on vendor-provided reports.

Pattern A: Separate instances per jurisdiction

Deploy independent FormKiQ instances in separate AWS regions, each within its own AWS account or organizational unit. Each instance holds only the documents and metadata for its jurisdiction, with no cross-region data movement. Cross-region authentication allows authorized users to access documents in multiple regional instances through a single identity. This pattern provides the strictest residency boundary and is appropriate for organizations with non-overlapping jurisdictional requirements.

Pattern B: Hub and spoke with regional data stores

A central administrative instance handles governance configuration, policy management, and cross-jurisdiction reporting — while regional instances hold the actual document content and metadata for each jurisdiction. Administrative metadata — policy configurations, user assignments, audit summaries — is held centrally, while document data remains in the appropriate regional boundary. This pattern supports centralized governance oversight without centralizing sensitive document data.

Pattern C: Shared global with regional classification

A shared global instance with strict metadata classification and attribute-based access control enforces regional boundaries at the access layer rather than the infrastructure layer — documents are tagged with jurisdiction attributes, and access policies ensure that users in each jurisdiction can only access documents tagged for their jurisdiction. This pattern is appropriate where the regulatory requirement is for access control rather than physical data location, and where the hosting jurisdiction is acceptable to all jurisdictions served.