Data Residency and Retention Policy¶

This document defines where data can live (regions/clouds) per product, tenant isolation principles, and retention/deletion expectations for Factory logs, audit events, and platform data. It is written for compliance officers, enterprise customers, architects, and anyone evaluating data residency requirements.

ConnectSoft offers flexible data residency options: hosted SaaS with regional selection, or self-hosted deployments where customers have full control over data location. This policy guides architecture decisions, partner enablement, and contract discussions.

Important

Region Availability: Actual region availability is subject to infrastructure and agreements. This document describes conceptual options and principles. Specific region availability and deployment models are defined per product and contract.

Data Residency Objectives¶

Objectives¶

Meet Regional Requirements - Allow customers to meet regional/legal data requirements where possible
Keep Architecture Simple - Keep architecture simple and maintainable
Make Residency Explicit - Make residency and retention explicit per product
Support Compliance - Support compliance requirements (GDPR, HIPAA, etc.)

Scope¶

This policy covers: - AI Factory logs and execution data - Platform data (Identity, Audit, Config, Bot) - Customer application data - Audit events and logs - Factory run logs and traces

See: Product Portfolio - Platforms for platform details.

Supported Regions and Deployment Models¶

Default Deployment Models¶

Conceptual Description: - Default region(s) - One or more primary cloud regions - Potential multi-region setups - Region-per-customer or multi-region deployments (conceptual) - Self-hosted options - Customer-controlled deployments in any region

Product-Specific Residency Options¶

Product/Area	Default Deployment Model	Residency Options (Conceptual)
AI Factory	Central/shared control plane	Per-region runners (future option)
Identity Platform	Central, region-aware tenants	Potential regional instances
Audit Platform	Region-sensitive (due to logs)	Per-region or per-cluster
Config Platform	Central with per-tenant config	Possible local caches
Employment Services SaaS	Multi-tenant per region	Additional regions on-demand
Factory-Generated Services	Customer-controlled	Customer's Azure subscription/region

See: SaaS Platforms Business Model for platform deployment models.

Tenant Isolation Principles¶

Logical Multi-Tenancy¶

Default Pattern: - Per-tenant identifiers - Tenant context enforced at application level - Shared infrastructure with logical isolation - Tenant-specific data partitioning

Implementation: - Tenant ID in all data models - Tenant context in authentication tokens - Tenant-scoped queries and operations - Tenant-specific configuration

Physical Isolation (Optional)¶

Higher-Tier Option: - Per-tenant database (optional) - Per-region clusters (optional) - Dedicated infrastructure (enterprise)

Use Cases: - Compliance requirements - Performance isolation - Security requirements

Tip

Isolation Tiers: Stronger isolation may be offered in higher pricing tiers or custom deployments. Standard multi-tenant SaaS uses logical isolation; enterprise customers may require physical isolation.

See: Security & Compliance for security requirements.

Data Retention and Deletion Rules¶

High-Level Defaults¶

Application Data: - Retention tied to contract and product type - Deletion upon contract termination (with export option) - Customer-controlled retention for their own data

Audit Logs: - Longer retention (compliance-driven) - Tiered retention (e.g., X months by default, longer with premium) - Configurable per customer tier

Factory Logs: - Shorter default retention (mainly for debugging and improvement) - Periodic purge - Anonymization options

Retention by Data Type¶

Data Type	Typical Retention (Conceptual)	Deletion Behavior
Core application data	As long as contract active	Export + deletion on termination
Audit events	Longer-term (compliance-driven)	Configurable per customer tier
Factory run logs	Short-to-medium (debug)	Periodic purge; anonymization options
Customer configuration	As long as contract active	Deletion on termination
User data	As long as contract active	Deletion per GDPR/data protection requirements

Warning

Exact Numbers: Exact retention numbers are defined per product/contract. This document gives principles and typical ranges. Specific retention periods are negotiated per customer agreement.

Factory and Platform-Specific Considerations¶

Factory Logs¶

Considerations: - Factory logs may contain code snippets/config - Should avoid sensitive data where possible - Logs used for debugging and Factory improvement - Anonymization options available

Retention: - Short-to-medium retention (debugging) - Periodic purge - Anonymization before long-term storage

Audit Platform¶

Considerations: - Key for evidencing changes and access - Compliance-driven retention requirements - Region-sensitive (logs must stay in region) - Longer retention periods

Retention: - Longer-term retention (compliance-driven) - Configurable per customer tier - Region-specific retention policies

Identity/Config Platforms¶

Considerations: - Identity data may have separate retention requirements - Config data typically shorter retention - User data subject to GDPR/data protection requirements

Retention: - Identity data: As long as contract active + compliance requirements - Config data: As long as contract active - User data: Per GDPR/data protection requirements

See: Audit Platform API Overview for audit details.

See: Identity Platform API Overview for identity details.

Customer and Partner Responsibilities¶

Customer Responsibilities¶

Customer Controls: - Customers control content they store (PII, sensitive data) - Customers responsible for their own legal analysis regarding data residency and regulatory fit - Customers must specify residency requirements during onboarding

Data Classification: - Customers responsible for classifying their own data - Customers must inform ConnectSoft of special requirements - Customers responsible for compliance with their own regulatory requirements

Partner Responsibilities¶

Partner Requirements: - Partners implementing solutions must respect residency requirements of customer's environment - Partners must follow ConnectSoft data residency policies - Partners must inform customers of residency implications

See: Partner Program Overview for partner program details.

See: Delivery Standards and Quality Control for partner standards.