Financial services
DORA made your cloud architecture a supervised question.
What changed
Since DORA became applicable in January 2025, "we run on AWS" stopped being an architecture answer.
Regulation (EU) 2022/2554 put ICT risk management, third-party dependency, and operational resilience inside the supervisory perimeter for financial entities. The questions it asks are not questions a compliance function can answer alone, because the answers are properties of the architecture: what the dependency actually is, what happens when it fails, and whether you could leave.
Most estates can answer the first question and struggle with the other two. That is the gap this practice exists to close.
Where the work sits
Four things a supervisor will press on.
- Concentration risk, named per workload
- Article 29 asks you to assess ICT concentration risk before contracting and on an ongoing basis. Doing that credibly means naming, workload by workload, which proprietary services carry the dependency, where data gravity has accumulated, and what a provider-level failure actually takes down. Generic statements about "multi-region resilience" do not survive the follow-up.
- Exit strategies that could actually be executed
- The regulation requires exit plans for functions supported by ICT third parties, tested and comprehensive enough to leave without disrupting the business. An exit plan is only worth the paper it is on if someone has costed the rebuild, identified what is genuinely portable, and been honest about the timeline under pressure.
- Register of information that matches the estate
- The register has to describe your contractual arrangements as they are, not as they were at the last audit. When the architecture changes and the register does not, the gap is exactly what a supervisor finds. Keeping the two in step is an ongoing architectural discipline, not an annual document exercise.
- Resilience testing with evidence attached
- Digital operational resilience testing has to be evidenced, and for significant entities that extends to threat-led penetration testing. Architecture determines whether a recovery objective is demonstrable or merely asserted - and whether the test produces evidence a supervisor accepts.
The evidence position
What the track record actually is.
DORA became applicable in January 2025. Any firm claiming a deep DORA delivery history today is counting something else, and you should ask them what. So here is the honest version.
What is evidenced is regulated financial-services delivery. Our founder, as CTO, led a regulated UK lending back office built and run on AWS, with Open Banking, credit-bureau, identity, and regulatory reporting integrations and the regulated-data security model to match. Before it carried the Northkeep name, our company delivered loan origination platforms grown into full lending ERPs for central-bank-supervised consumer lenders, under the same discipline.
That is the same discipline DORA formalizes - architecture written to be read by a supervisor, dependencies named rather than assumed, recovery demonstrable rather than asserted, and evidence produced as the work happens instead of reconstructed afterwards. The regime is newer than the practice. The questions are not.
Why this advisor
Zero AWS revenue share.
The most credible advisor on reducing AWS dependency is the one who knows exactly where the lock-in lives - and has no incentive to keep you there.
An exit strategy written by a party that earns a margin on your cloud spend is a document with a conflict of interest attached. Northkeep takes no share of your AWS spend, no resale margin, and no vendor commission, and is not part of any consultancy group. Where your register needs it, the engagement can be staffed and contracted for EU-resident delivery under EU jurisdiction.
The engagement
EU Cloud Resilience and Exit Strategy.
A core engagement producing the architecture and the evidence behind it: what the dependency is, what it would cost to leave, what the estate can actually demonstrate under test, and the target-state changes that close the gaps. Signed by the accountable architect on the engagement.
- ICT concentration-risk analysis across the estate, workload by workload
- Cloud exit and portability architecture, with the rebuild honestly costed
- Resilience design against stated recovery objectives, testable rather than asserted
- Register of information support, kept in step with the architecture
- Target-state changes needed to close the gaps, prioritized and costed
- Architecture and evidence
- Northkeep designs the architecture and produces the evidence pack behind it, signed by the accountable architect on the engagement.
- Not audit, not attestation
- Formal audit, certification, and regulatory attestation are scoped out and referred. Blurring the two would help nobody standing in front of a supervisor.
- Not legal advice
- How the regulation applies to your entity is a question for your counsel and your compliance function. What your architecture can evidence is the question Northkeep answers.
Start here
Start with the readiness assessment.
Fixed scope and paid. It establishes what your estate can currently evidence and what it cannot, and ends in a signed evidence pack with a costed plan. You keep it whatever you decide next.