An exit plan is not an exit proof
Why inventories and documents matter—but cannot tell you whether a declared workload can actually move.
Read the article →Discover
Observe resources, relationships, identities and unresolved gaps.
Regulatory resilience
Turn exit planning into evidence.
DORA and UK operational-resilience expectations raise a practical question: can you show what was tested, what worked and what remains uncertain? PortabilityLabs captures that technical record without making every user complete a regulatory questionnaire.
The normal product journey stays short
Technical facts first. Regulatory context only when requested.
A team should be able to discover, define and test a workload without knowing which filing template might consume the evidence later.
Review
Approve the workload boundary and the target being considered.
Test
Run versioned checks against declared application material or an explicit mock.
Retain
Keep results, time, scope, caveats, execution mode and cleanup together.
What we do not ask during normal setup
Legal-entity identifiers, contract references, regulatory applicability, critical-function declarations and management attestations. Those require customer judgement and wider governance. If a future customer chooses a DORA-aligned output, that context can be added then.
The evidence layer
Enough detail to challenge the result.
We collect reusable technical evidence rather than embedding one regulator’s form into the product model.
Read the requirement, then inspect the evidence
A practical regulatory reading room.
Our commentary links to primary sources and separates legal requirements from the technical evidence PortabilityLabs can supply.
ICT third-party exit strategies
Exit plans for relevant ICT services are expected to be comprehensive, documented, sufficiently tested and periodically reviewed.
Primary source →Realistic exit plans
The detailed standard calls for documented plans that are realistic, feasible, based on plausible scenarios and periodically reviewed and tested.
Primary source →Challenge the assumptions
Continuity testing should cover severe but plausible scenarios, relevant third-party ICT services and documented deficiencies.
Primary source →Register of information
The reporting templates cover arrangements, services, functions, substitutability, exit-plan existence and alternatives—not test execution.
Primary source →Mapping and scenario testing
In-scope firms identify important business services, set impact tolerances, map dependencies and test vulnerabilities.
Primary source →Stressed exit
The March 2026 SS2/21 update says stressed-exit plans should be appropriately documented and tested as far as possible.
Primary source →Important: This material is product information, not legal or regulatory advice. PortabilityLabs does not determine applicability, certify compliance, submit regulatory returns or replace governance, contracts, business-impact analysis or supervisory engagement.
Field notes
Go deeper without reading a sales brochure.
Plan ≠
proof
proof
Method · 6 min
DORA
28
28
Regulation · 7 min
DORA makes exit planning operational
What Article 28 says about tested, reviewed exit plans, and where technical assurance can contribute.
Read the article →Tested
means?
means?
Evidence · 8 min
What makes an exit test defensible?
A practical evidence record for scope, target, execution, results, limitations, freshness and cleanup.
Read the article →RoI ≠
test
test
Reporting · 7 min
The DORA register is not an exit test
How the register of information and technical exit evidence answer different, complementary questions.
Read the article →UK
resilience
resilience
Regulation · 7 min
Cloud exit in the UK resilience regime
Where FCA mapping, scenario testing and PRA stressed-exit expectations meet technical portability evidence.
Read the article →Clouds
change
change
Continuous assurance · 5 min
Your cloud changed after your last test
A practical model for connecting provider updates, workload changes and proportionate re-assurance.
Read the article →Start with the workload, not the form.
Discover one representative workload and see whether the resulting architecture and evidence model are useful before adding regulatory context.