Guide
Moving a Regulated Firm to the Cloud: Plan for the Accountability That Stays With You
The provider can share the tasks. Accountability to the regulator stays with the bank and its board, and we plan the cloud programme on that footing from the first architecture review.
4-minute read5 November 2026
In Brief
- RBI directions for commercial banks say outsourcing does not diminish a bank's obligations, and that its board and senior management hold ultimate responsibility. A provider's diagram divides tasks and leaves that where it was.
- We see four actions that carry this into the plan: write down what stays with you, set the contract terms early, define who reports an incident and how fast, and design the exit before you enter.
- Thinqmesh agrees the reason for moving before choosing a provider, then migrates a first set of workloads with infrastructure defined in code, monitoring and backups in place.
A cloud programme usually starts from a diagram that divides security work between the provider and its customer. The diagram is useful, and in a regulated firm it is easily read as something it is not: a statement of who answers for what. Our view is that a bank should treat it as a list of tasks. Tasks can be shared with a provider, and accountability to the regulator and to customers stays with the bank, so we plan from the first architecture review on that footing.
The Provider Can Patch the Server and the Bank Still Answers
The RBI directions for commercial banks say that outsourcing an activity does not diminish the obligations of the bank, and that its board and senior management hold ultimate responsibility for it. The same directions expect the bank to approve any subcontractor, to recognise the regulator's right to inspect, and to keep a clear exit strategy.
These duties fall between teams easily. An infrastructure group runs the migration, a security group reviews the settings, and no one holds the board-level framework, the contract terms or the exit plan. The cost appears at the worst moment: an inspection, an incident or a provider change, when the missing owner has to be found quickly.
Four Actions That Keep Accountability in the Plan
Each is done before the first workload moves, because contracts and architecture are hardest to change once the migration is under way.
Write Down What Stays With You
List the duties that remain with the bank whatever the provider does, and give each a named owner.
The provider's diagram shows who patches what. The regulator looks at who answers. We list, for each workload, the duties that stay with you, including board approval of the outsourcing framework, the data across its whole life and oversight of the provider, and we name a person for each so that none falls between teams.
Get started
- Take one workload and list every duty the regulator would expect you to hold.
- Name an owner for each, outside the infrastructure team where the duty is a board matter.
Settle the Contract Terms Early
Subcontractor consent, regulator access and audit rights are agreed before the architecture is fixed.
The RBI directions expect the bank to approve any subcontractor the provider engages, and expect agreements to recognise the regulator's right to inspect the provider and its subcontractors. Standard terms may not read that way. We bring these points to the first conversation so that the contract and the design agree.
Get started
- Read your draft contract against the subcontractor and inspection requirements.
- List the clauses that need negotiation and put them in the first meeting.
Decide Who Reports an Incident, and How Fast
The route from the provider's detection to your regulator is written and rehearsed.
Cyber incident reporting to the regulator runs to a short clock, and the directions start it from the provider's detection. That makes the escalation route a contract matter and a rehearsal matter. We agree the route with you, and your team practises it before a real incident tests it.
Get started
- Write the route from provider alert to regulator report, with a name at each step.
- Run a short table-top exercise and note where time is lost.
Design the Exit Before You Enter
Return of data, portability, transition and secure removal are planned while the contract is still being written.
A bank needs a clear exit strategy that protects continuity. For cloud this covers getting the data back, moving it elsewhere and having it securely removed from the provider's environment. Infrastructure defined in code makes the move easier to rehearse, and a rehearsed exit is a credible one.
Get started
- Ask what your data export would look like on the day you needed it.
- Write an exit plan for your first workload, with its owner and a review date.
How Thinqmesh Solves This
We agree the reason for moving before selecting a provider or an architecture, and a regulated estate follows its own plan. A first set of workloads is running within four weeks.
- Week 1
A Review of Infrastructure, Spending and Risks
We review what you run, what it costs and where the risks sit, and record what stays with you whatever the provider does.
- Week 2
A Target Design and Migration Plan
We agree the reason for moving, decide for each workload whether it moves as it is, is rebuilt or stays, and compare the costs.
- Week 3
Infrastructure Defined in Code
The environment is defined in code so it can be reviewed and rebuilt, with monitoring that reports a problem before a customer does, and backups.
- Week 4
The First Workloads Running
The first workloads are migrated, tested and running. The full engagement runs to eight weeks, and regulated workloads follow their own plan.
You finish with workloads running in the cloud, infrastructure you can rebuild from code, a monthly view of cost by service and owner, and a written record of what remains yours.
