Data Residency
Keeping data within a jurisdiction, including backups, logs and support access.
7 to work through
-
advanced
A client says "our data must stay in country". What do you ask before designing anything?
2 min answer -
advanced
A communications platform must keep customer data in-region for several markets. What does that actually require?
1 min answer -
advanced
A delivery marketplace of Swiggy's shape serves five countries from two regions. Its India payments partner points at the Reserve Bank of India's directive of 6 April 2018 requiring payment system data to be stored only in India. Finance asks what a dedicated in-India cell would cost annually before the partnership is signed. Work the number and say what it rules out.
3 min answer -
advanced
A global payroll platform must keep certain data within specific jurisdictions. What does that force into the architecture?
2 min answer -
advanced
A product must keep certain customers' data within specific jurisdictions. What are the architectural options, and which parts are hardest?
3 min answer -
advanced
An e-commerce group of Flipkart's shape runs an in-India cell for regulated payment data and an EU cell for everything else. A quarterly control test samples 500 rows from the EU warehouse and finds 38 carrying Indian cardholder identifiers. The routing layer is correct and the replication topology is correct. Where do you look and in what order?
3 min answer -
advanced
Six weeks before launch, legal confirms that customer data for one market must be processed and stored in-country. The architecture is single-region in another jurisdiction. What do you do?
3 min answer
2 terms in this topic
Neighbouring topics
Regulatory & Data Protection Architecture
General material on designing under legal and regulatory obligation.
Privacy by Design
Data minimisation, default protection and purpose binding as structural decisions.
Lawful Basis & Purpose Limitation
Why you may hold the data, and why that forbids the second use somebody proposed.
Data Subject Rights
Access, correction, portability and erasure across systems that never planned for them.
Consent Architecture
Capturing, versioning and propagating consent to every system that acts on the data.
Digital Sovereignty
Control over data, operations and the operator, beyond where the bytes physically sit.
Cross-Border Transfer
The legal mechanism that permits data to leave, and the architecture that respects it.
PCI-DSS Scoping
Segmentation and tokenisation to shrink what is in scope, because scope is the cost.
Healthcare Data Protection
PHI handling, minimum necessary access, and audit expectations in clinical systems.
Financial Services Regulation
Operational resilience, payment rules and supervisory expectations as design inputs.
Records Retention & Legal Hold
Keeping what must be kept, deleting what must go, and freezing both on demand.
Erasure vs Immutability
Deletion obligations against event logs, backups and ledgers designed never to forget.
Pseudonymisation
Separating identity from record, and the re-identification risk that remains.
Privacy-Enhancing Technologies
Differential privacy, secure enclaves and federated computation, and what each buys.
Regulatory Reporting Pipelines
Submissions with fixed deadlines, fixed formats, and a regulator who audits the lineage.
Sector Cloud Rules
Regulator expectations for cloud use, exit plans and material outsourcing notification.
Exit & Concentration Risk
Being able to leave a provider, and what the regulator asks when you cannot.
Third-Party Risk
Assessing, contracting and monitoring the vendors your architecture now depends on.
Geo-Restriction & Sanctions
Blocking access by jurisdiction, and the accuracy and evasion problems that come with it.