MAS's proposed Third-Party Risk Management Guidelines: what cloud accountability and exit plans mean if you self-host on AWS or GCP

Key points:

• MAS's proposed Guidelines on Third-Party Risk Management (consultation paper P004-2026, published 6 March 2026) would replace both sets of Outsourcing Guidelines and apply the same expectations to every third-party service an FI uses, not only outsourcing. The consultation closed on 20 April 2026 and MAS proposes a 6-month transition after the final text is issued. As of mid-November 2026 the guidelines are still a proposal.
• Accountability does not move to AWS or Google Cloud. The draft says oversight "continue[s] to rest with the FI, its board and senior management", and that the board keeps ultimate responsibility even where the contract describes "shared responsibility". Annex 4 restates that MAS treats cloud services run by cloud providers as a form of outsourcing.
• Exit becomes an engineering deliverable. FIs should maintain exit plans for "different plausible termination scenarios", regularly updated and tested for budget, people, technical infrastructure, knowledge transfer and access to data, and contracts must cover the transfer of data, software and models on termination, including timeline and format.
• Self-hosting on AWS or GCP helps, but only if the stack is portable. Running containers on Kubernetes in your own account, with open-source-compatible databases and infrastructure as code, turns "we can leave" into something you can rehearse. Workloads wired into provider-specific services make the exit plan a paragraph nobody can execute.
• Every tool in the path is a third party too, including Qovery. Qovery runs your apps on Kubernetes in your own AWS, GCP, Azure or Scaleway account, and running workloads keep serving if the Qovery control plane is unavailable. That keeps it out of your critical runtime path, but it still belongs in your register, assessed like any other provider.

The MAS consultation on third-party risk is short on surprises and long on homework. Most of the expectations already existed in the Outsourcing Guidelines. What changes is the reach (every third-party service, not only outsourcing), the reporting (a register filed with MAS semi-annually) and the tone on exit (plans that are tested, not written once for the audit file).

I spend a lot of my time with platform and infrastructure teams at regulated companies, and the question I keep hearing from Singapore is simple: "We run our own stack on AWS or GCP. What do we actually have to change?" This article answers it paragraph by paragraph, using the consultation paper itself (MAS, P004-2026) as the primary source. I am not a lawyer and this is not legal advice. It is the engineering read.

What has MAS actually proposed, and when does it take effect?

MAS has proposed new Guidelines on Third-Party Risk Management that supersede the Guidelines on Outsourcing (Banks) and the Guidelines on Outsourcing (Financial Institutions other than Banks), and extend their expectations to all third-party services. The consultation paper was published on 6 March 2026, comments closed on 20 April 2026, and MAS proposes the guidelines take effect 6 months after issuance (MAS consultation paper, para 1.2 and 3.39).

The timeline as it stands:

• 6 March 2026: consultation paper P004-2026 published, with the draft guidelines as Annex A and a register template as Annex B (MAS).
• 20 April 2026: consultation closed.
• Mid-November 2026: no final text or response to feedback published that I could find. Industry bodies such as ASIFMA have published their submissions.
• Issuance + 6 months: proposed effective date (para 3.39).

Banks should note two details. First, MAS Notices 658 and 1121 on outsourced relevant services stay in force and keep setting the baseline for banks and merchant banks (para 1.3). Second, MAS did not wait for the final text: pending issuance, it "expects FIs to manage the operational, technology and cyber risks associated with their third-party arrangements", including re-performing risk evaluations after a significant incident at a provider (para 2.4).

The draft also explicitly builds on international work: the Financial Stability Board's third-party risk toolkit and the Basel Committee's principles (para 1.4). The Basel Committee published its final Principles for the sound management of third-party risk on 10 December 2025, so the direction of travel is global.

Who does the guidance cover, and does it apply if we self-host on AWS or GCP?

It covers every MAS-regulated FI that relies on third-party services, scaled by size, complexity and the materiality of each arrangement (para 3.1). Self-hosting on AWS or GCP does not take you out of scope, because the cloud provider is the third party.

Annex 4 is blunt about it: "MAS considers CS [cloud services] operated by CSPs as a form of outsourcing. FIs are ultimately responsible and accountable for maintaining oversight of CS and managing the attendant risks of adopting CS." (Annex 4, para 2).

"Self-hosting" usually means one of three things in a Singapore FI, and each one lands in the register differently:

• IaaS in your own account. You run Kubernetes (EKS, GKE) or VMs in your AWS or GCP account. AWS or Google is the material provider; your team owns everything above the hypervisor.
• Managed services in your own account. RDS, Cloud SQL, managed Kafka, managed Redis. Still the same provider, but you now depend on provider-specific services that shape your exit.
• Tools that touch production. CI/CD, deployment platforms, observability SaaS, secret managers, AI coding agents with deploy rights. Each is a third-party arrangement, and some will be material.

Under the old outsourcing lens, a SaaS observability tool that receives your production logs might never have been formally assessed. Under the third-party lens, it is an arrangement that touches customer information, and it has to be assessed, contracted and, if material, registered.

Who stays accountable when AWS or Google Cloud runs part of the stack?

The FI's board and senior management stay accountable, full stop. The draft says that while an FI "may delegate day-to-day operational duties to the service provider", oversight and risk management "continue to rest with the FI, its board and senior management" (para 5.3).

Footnote 24 closes the escape hatch every cloud team knows: "Third-party service arrangements may provide for 'shared responsibility' between the FI and the service provider. The board retains ultimate responsibility for oversight of the FI's third-party risks even in such cases."

In practice the board (or a delegated committee) has to approve and regularly review (para 5.5):

• the third-party risk management strategy, including risk appetite and tolerance for disruptions;
• the framework that rates the materiality of every existing and prospective arrangement;
• the frequency of independent audits of material arrangements (para 6.30).

My read for engineering leaders: shared responsibility models map who does the work, and the board still answers to MAS. AWS's and Google's shared responsibility pages tell you where your controls start. Annex 4, para 3 asks you to "clearly identify and implement controls that fall within [your] responsibilities under the different service models" and to monitor the provider's side. On IaaS, that is almost everything from the OS up: Kubernetes version, node patching, network policies, IAM, encryption keys, backups.

What must a cloud contract and the register contain?

For material arrangements, the draft lists 16 contract provisions (para 6.19 (a) to (p)) and asks FIs to file a register of third-party arrangements with MAS semi-annually and on request (para 4.3). Most hyperscaler financial services addenda already address several of these clauses. Check each one against your own addendum.

The clauses most relevant to a cloud deployment:

Source for every row: MAS consultation paper, Annex A, para 6.19.

The register is the operational novelty. Para 4.1 asks you to understand concentration risk "at the service provider level or geographical level" and to "map its dependencies and interconnections relating to its material third-party arrangements". If your core banking front end, your payments API, your fraud scoring and your logging all live in one AWS region, the register will show it, and MAS will see it twice a year.

On sub-contracting, the draft asks that material sub-contractors appear in the register "where possible" and that providers notify you in writing before engaging one (section 7 of the draft). For a self-hosted stack, the practical version is a dependency inventory: which SaaS tools sit between your engineers and production, and which of their providers see your data.

What does a tested cloud exit plan look like under the draft?

A tested exit plan is a rehearsed migration with a budget, owners, a data transfer path and a target environment, run often enough to stay true. The draft asks FIs to "maintain exit plans as needed to cater for different plausible termination scenarios", "regularly updated and tested for availability of budget, human resources, technical infrastructure, transfer of knowledge, access to data and other factors" (para 6.34).

Para 6.35 lists what the plan must provide for:

• adequate transition periods and adequate budget;
• clear roles to coordinate the exit, and an escalation group kept up to date;
• the operationalisation of contractual rights, including destruction of the FI's information at the provider;
• processes to transfer tangible and intangible assets (and people, such as contractors) in time;
• a budget approval process for contingencies and outside expertise.

The level of detail should be "commensurate with the materiality and substitutability of the services provided". For a hyperscaler hosting critical business services, that means detailed.

What the 2023 DBS and Citibank outage showed about recovery paths

Singapore has a recent, well-documented example. On 14 October 2023, a cooling system malfunction at a data centre hosting both DBS and Citibank systems took their digital banking down. Both banks activated backup data centres, and both hit problems that "prevented them from fully recovering their affected systems": a network misconfiguration at DBS and connectivity issues at Citibank (MAS response to media queries).

MAS's parliamentary reply put numbers on it: up to 810,000 failed attempts to access the two banks' digital platforms and about 2.5 million payment and ATM transactions that could not be completed between 14 and 15 October (MAS oral reply to Parliamentary Questions). MAS later imposed a six-month pause on DBS's non-essential activities (MAS).

This was a data centre incident rather than a cloud exit, and it could have happened to any bank. Both banks had backup paths, and both paths hit a configuration problem on the day they were needed. An exit plan is a slower version of the same path, and it breaks the same way if nobody exercises it.

What "tested" means for an AWS or GCP workload

A defensible exit test for a workload on AWS or GCP has five measurable parts:

1. Rebuild the platform from code. Recreate the cluster, networking and IAM in another region or provider from Terraform or OpenTofu, and time it.
2. Redeploy the applications from the same artefacts. Same container images, same Helm charts, same configuration, no hand edits.
3. Move the data and prove it. Restore databases from backups into the target, then reconcile row counts and checksums.
4. Cut over traffic. DNS or load balancer switch, with a measured recovery time against your Service Recovery Time Objective.
5. Record the evidence. Duration, gaps found, owners, cost. That record is what you show the board and, if asked, MAS.

If step 2 needs a rewrite because the application depends on a provider-only service, the test fails, and it is better to learn that in a rehearsal.

Is self-hosting on AWS or GCP easier to exit than a managed platform?

Self-hosting on Kubernetes in your own cloud account is usually the easiest model to exit, because the artefacts (container images, manifests, Terraform, standard database engines) run on any other cloud. It is not automatically easier: a self-hosted stack built on provider-specific services can be harder to move than a managed platform. Annex 4, para 5 says it directly: to mitigate lock-in or concentration, an FI "may adopt cloud portability or interoperability solutions, and use open standards for data and software interfaces".

The common deployment models compare like this against the draft's exit and accountability expectations. This is my assessment, and every option can be made compliant with enough work.

Two points I would stress to any Singapore team choosing between these:

• The exit plan is cheaper when the runtime is standard. Kubernetes runs on AWS, GCP and Azure in Singapore (AWS ap-southeast-1 and Google Cloud asia-southeast1 both have three zones, per the AWS Regions list and Google Cloud regions and zones). A second provider in the same jurisdiction is a credible exit target, which matters if data location is part of your obligations.
• Pass-through sub-contracting is now named. Para 7.3 describes a provider that "sub-contracts all or the bulk of the service" and asks the FI to manage the extra layer. A PaaS that runs on a hyperscaler is a textbook example. It is not prohibited, but it adds work.

What does this mean for concentration risk in one cloud region?

It means you have to show MAS you know how concentrated you are, and that the concentration sits within the risk appetite your board approved. The draft defines concentration risk as dependency on one or more third parties that could affect critical business services, and lists examples such as "multiple services provided by the same third-party" (Annex A, definitions). Para 6.15 asks FIs to assess how each new arrangement changes concentration before onboarding it.

This does not mean MAS wants every FI to run active-active across two clouds. That doubles the operating cost and complexity, and for most institutions it is the wrong answer. What a proportional approach usually looks like:

• Multi-AZ by default for anything supporting a critical business service, inside one region.
• A warm or cold standby path to a second region or second provider, rehearsed as part of the exit test.
• Backups stored outside the primary provider's blast radius, in a format the target can restore.
• The same deployment pipeline for primary and standby, so the standby is not a museum.

MAS's own 2021 cloud advisory already listed cloud resilience and concentration risks, IAM, data protection and key management as areas FIs should control. The third-party guidelines add the register and the board reporting on top.

How does the MAS draft compare with DORA and APRA CPS 230?

The MAS draft lands close to the EU's DORA and Australia's CPS 230 on substance: accountability stays with the institution, material providers go in a register, contracts carry audit and exit clauses, and exits must be planned. If you already built evidence for one regime, most of it carries over.

Sources: MAS P004-2026, Regulation (EU) 2022/2554 on EUR-Lex, APRA CPS 230. For the EU side in more depth, we wrote a platform-by-platform guide to DORA third-party risk.

The practical takeaway for a group with entities in Singapore, the EU and Australia: build one register, one set of contract clauses and one exit-test runbook, and map them to each regime. Three parallel programmes is how teams burn a year.

What should an engineering team change in the next six months?

Start with the inventory and the exit test, because both take longer than people expect and both feed the register MAS will ask for. The contract work can run in parallel with legal.

Here is the checklist I would hand to a platform team at a Singapore FI running on AWS or GCP:

• Inventory every third party that touches production: cloud providers, CI/CD, deployment platforms, observability, secret managers, AI coding agents with write access.
• Rate materiality using your board-approved framework, and flag which arrangements support critical business services.
• Map data locations per service (para 6.19(l)): primary region, backup location, log and metrics destinations, any global control planes.
• Check contracts against para 6.19, starting with MAS audit rights, asset transfer on termination and minimum termination periods.
• Remove provider-only dependencies where cheap, or document the replacement for each one in the exit plan.
• Run one exit test per material arrangement, rebuilding from code into a second region or provider and restoring data.
• Measure recovery against your Service Recovery Time Objectives, and record evidence the board can read.
• Scope agent and tool permissions with least privilege (para 6.19(f)), with an audit trail per identity.
• Wire provider incident notices into your incident process so you can notify MAS "as soon as possible" (para 8.1).

If you only do two things before the final text lands, do the inventory and one real exit test. Everything else gets easier once you know what you depend on and how long leaving takes.

Where does Qovery fit, and where does it not?

Qovery fits the engineering half: running your applications on Kubernetes in your own cloud account in a way that keeps the exit cheap and the evidence clean. It does not maintain your register, negotiate your contracts or file anything with MAS. Pair it with your GRC tooling for that.

What Qovery does, concretely:

• Runs in your own account. Qovery deploys and operates applications on Kubernetes inside your own AWS, GCP, Azure or Scaleway account, or on an existing cluster (EKS, GKE, AKS, on-premise) through the Qovery Operator. Qovery is not a PaaS and never hosts your applications. Your data, workloads, logs and metrics stay in your account, in the region you choose.
• Keeps the exit artefacts standard. What runs in your cluster is standard Kubernetes resources and Helm releases. If you stop using Qovery, the cluster and the workloads are still there and still yours. The Qovery Terraform provider lets you describe environments as code, which is step 1 of the exit test above.
• Makes rehearsals cheap. Environment cloning lets you stand up a copy of a production environment in another cluster, region or cloud and run the restore and cut-over steps without a ticket queue.
• Produces evidence. RBAC per environment, audit logs for every change, and API Policy Tokens with OPA policies so AI agents act with least privilege and a named identity.
• Stays out of the critical runtime path. The control plane handles orchestration and configuration. Your cluster initiates the connection to it, and if the control plane is unavailable, running services keep serving; only new deployments wait. We explain the split in detail in how Qovery stores secrets across the control plane and data plane.

What you still have to do with Qovery in the picture:

• Register Qovery as a third-party arrangement and assess its materiality yourself. Our security page lists SOC 2 Type II and the frameworks we map to, including MAS TRM. Use our trust center documents as inputs, not as a substitute for your own assessment.
• Decide what you let the control plane hold. Secret values can stay in AWS Secrets Manager or GCP Secret Manager in your account, with Qovery holding only a reference.
• Own the Kubernetes version and add-on policy with us: Qovery manages cluster upgrades on Qovery-managed clusters, but your change management still needs to approve them.

How do I set this up with Qovery from Claude Code or Cursor?

Install the Qovery Agent Skills and your coding agent can set up a cluster in your own AWS or GCP account and deploy your services through the Qovery API, with each action attributed and scoped. You approve each install command, and the MCP Server opens an OAuth login in your browser.

curl -fsSL https://skill.qovery.com/install.sh | bash

# 2. Or scope the skills to the current project only
curl -fsSL https://skill.qovery.com/install.sh | bash -s -- --project

# 3. MCP Server for Claude Code over OAuth, read-only by default
claude mcp add --transport http qovery https://mcp.qovery.com/mcp --callback-port 4242

# 4. Write access, only when you explicitly want it (also needs write access enabled in the Qovery Console)
claude mcp add --transport http qovery "https://mcp.qovery.com/mcp?read_write=true" --callback-port 4242

Then ask in plain language, for example "set up Qovery on our AWS account in ap-southeast-1" (the qovery-onboard skill) or "generate Terraform for our staging environment so we can rebuild it in another region" (the qovery-terraform skill). The skills deploy; the MCP Server operates what already exists. For a regulated team, start with the read-only MCP Server and keep write access for named, scoped identities. See the AI agent quickstart and the Claude Code integration.