Data Residency
Customer data is pinned to the region the customer chooses at workspace creation. It does not leave that region for primary processing or backups. The choice is permanent — Appice does not migrate workspaces between regions without an explicit customer-driven project.
Three regions
India (IN)
api.in.appice.ioMumbai (ap-south-1) and Hyderabad (ap-south-2) availability zones. Backups in-country.
- Hosted on AWS India
- Compliant with India DPDP Act 2023
- Aligned with RBI Cyber Security Framework
- Data never leaves India
GCC
api.gcc.appice.ioBahrain and Saudi Arabia availability zones. Backups in-region.
- Hosted on AWS Bahrain (me-south-1) and AWS Saudi Arabia (me-central-1)
- Aligned with SAMA, CBUAE, CBB cybersecurity frameworks
- Saudi data resident in Saudi Arabia for KSA-regulated customers
- Data never leaves GCC
EU
api.eu.appice.ioFrankfurt (eu-central-1) and Ireland (eu-west-1) availability zones.
- Hosted on AWS EU
- GDPR Standard Contractual Clauses for any onward transfers to sub-processors
- Backups in-region
- Data never leaves EU/EEA
What stays in-region
- All raw event data and behavioural payloads
- Profile and identity data
- Computed segments, scores, and Allyvate decision outputs
- All backups and disaster-recovery copies
- Audit logs
- Allyvate model artifacts trained on customer data
What can cross regions (with customer authorization)
- Operational metadata. Aggregated, anonymized usage metrics (request counts, error rates) flow to Appice's central monitoring under EU SCCs. No personal data.
- Support sessions. When a customer raises a support ticket, Appice engineers may need to inspect specific workspace state. Access is logged, time-bounded, and requires customer approval.
- Outbound channels (push, SMS, email). When the customer instructs Appice to send a message to an end-user, the channel sub-processor may operate in a different region. The list and locations are documented in Sub-processors.
How regional isolation is enforced
| Layer | Control |
|---|---|
| Network | Each region is a separate VPC with no cross-region peering for data planes |
| Storage | Per-region database clusters and object storage buckets |
| Identity | Per-region IAM, separate KMS keys, no cross-region key sharing |
| Backups | Per-region S3 / Azure Blob with regional retention policies |
| Monitoring | Aggregated metrics only — no raw events leave the region |
Choosing a region
The correct region is usually obvious from where the data subjects live and the regulator the customer reports to. Some examples:
- An Indian bank with Indian customers → India (IN)
- A Saudi telco with KSA customers → GCC
- A German insurer with EU customers → EU
- A multinational with operations in two regions → typically two workspaces, one per region, with a higher-level integration on the customer side