Exit & Concentration Risk
Being able to leave a provider, and what the regulator asks when you cannot.
6 to work through
-
advanced
A regulator asks a financial institution to demonstrate it could exit its cloud provider. What must exist, and what makes the answer credible?
2 min answer -
advanced
A regulator asks for evidence that your exit plan from your primary cloud provider is credible. The plan is a twelve-page document. What will they find, and what should you do?
2 min answer -
advanced
A regulator requires a credible exit plan from a critical cloud provider. What does a genuine exit capability require, and what makes most exit plans fiction?
3 min answer -
advanced Multiple choice
Concentration on one cloud provider is a recognised risk. Is multi-cloud the answer?
1 min answer -
advanced
Your entire site is served through one CDN. What happens if that provider has a global outage, and what would you do about it?
2 min answer -
advanced
Your regulator asks for evidence that your cloud exit plan works. You have a 60-page document. What is the gap?
2 min answer
2 terms in this topic
Exit and Concentration Risk
The regulatory concern that an institution cannot leave a critical provider, and that too much of the sector depends on the same few providers.
practiceProvider Exit Plan
A documented and tested plan for moving a workload off a provider, whose credibility is measured by what has actually been rehearsed rather than described.
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.
Data Residency
Keeping data within a jurisdiction, including backups, logs and support access.
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.
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.