MAS Business Continuity Management Guidelines: Service Recovery Objectives in Practice

The MAS Business Continuity Management guidelines are organised around services, not systems. That single design choice is where most firms’ existing continuity documentation stops being fit for purpose.

The Monetary Authority of Singapore issued its revised Guidelines on Business Continuity Management on 6 June 2022. A lot of the coverage treats them as a refreshed disaster-recovery checklist. They are not. The revision reorients continuity around the continuous delivery of critical business services to customers, and it asks firms to prove recovery rather than assert it. If your continuity plan is a binder of system-level failover procedures, you have the raw material, but you do not yet have what the guidelines expect you to demonstrate.

What “service-centric” actually changes

The older way of thinking about continuity starts from the asset: this server, this data centre, this network link. You work out how long each takes to restore and you call the sum of that your recovery posture. The guidelines invert it. You start from the service the customer receives — a payment executed, a redemption processed, a trade confirmed — and you work backwards to everything that has to function for that service to be delivered.

MAS draws a distinction worth getting right. A critical business service is external-facing: something a customer or counterparty depends on, whose disruption could threaten the firm’s safety and soundness, harm customers, or spill over into the wider financial system. A critical business function is the internal activity that supports it — settlement operations, reconciliation, the identity checks behind a login. The service is the outcome; functions are how the outcome is produced. The whole framework hangs on identifying the services first and only then decomposing them into functions, because it is the service the customer notices when it is gone.

You are expected to review the catalogue of critical business services at least annually, and whenever there is a material change to the resources supporting them. That review is not administrative. A new vendor, a re-platformed ledger, a merged team — any of these can quietly change what “critical” means, and the catalogue has to keep up.

Set the SRTO before you touch the technology

The pivotal number in the guidelines is the Service Recovery Time Objective — the target duration within which a critical business service must be restored to a minimum acceptable service level after disruption. Note what it is measured against: the service, at a minimum level, not full capacity. It is a business commitment to the customer, expressed in time.

This is where the discipline separates from technical recovery targets. A recovery-time objective for a system and a recovery-point objective for its data are engineering parameters; they describe how fast a component comes back and how much data you can afford to lose. The SRTO sits above them. Once you have committed to an SRTO for a service, every underlying function’s RTO has to be arranged so that the chain, end to end, delivers within the SRTO. If a payment service has a four-hour SRTO but one function in its chain cannot recover inside six, you do not have a defensible plan — you have an aspiration and a gap. The point I have made before, that RTO and RPO are business decisions and not technical ones, is exactly what MAS has now codified for the service layer.

Sensibly, the guidelines do not hand you a single mandated recovery figure. Setting the SRTO is the firm’s job, informed by a business impact analysis that asks how quickly a disruption to each service starts to threaten the firm or its customers. The number has to be owned by the business, defended, and revisited — not inherited from a vendor default.

Map the dependency chain end to end

An SRTO you cannot trace to its dependencies is a guess. The guidelines require firms to identify end-to-end dependencies across people, processes, technology and third parties for each critical business service. The failure mode here is predictable: the obvious dependencies get charted — the core application, the primary database — and the awkward ones do not. The identity provider that gates every login. The message queue between two internal systems. The single operations specialist who knows how to run the manual reconciliation when the automated one fails. The outsourced print house that issues the statements. Each is a link, and the chain recovers only as fast as its slowest link.

Third parties deserve specific attention because their recovery is not under your direct control. The guidelines expect firms to satisfy themselves that a third party supporting a critical service can meet the firm’s SRTO — which means the objective has to be pushed into the contract and the testing, not merely hoped for. A supplier whose own recovery target is slower than your SRTO has silently capped what you can promise your customers, and you will only discover it during an incident unless you find it during mapping.

The test is the evidence

A recovery objective that has never been exercised is a claim, not a control. The guidelines lean hard on testing that validates BCM preparedness across the full service chain, and on keeping plans current as threats and operations change. The useful test is not the tabletop where everyone agrees the plan looks sound. It is the exercise that actually attempts to restore a critical service to its minimum level, against the clock, and records whether the SRTO was met, which links lagged, and what was learned. That record is the artefact. Singapore’s supervisory posture, visible across its revised technology risk management expectations, consistently favours demonstrable operation over documented intent.

The governance wrapper reinforces this. Senior management is expected to attest annually to the board that the firm’s BCM preparedness aligns with the guidelines, and to be candid about residual risks. An attestation is only as good as the testing beneath it; signing off on untested objectives is precisely the exposure the annual attestation is designed to surface. On the assurance side, the framework anticipates an independent BCM audit at least once every three years, with audit plans established inside the first year and initial audits inside two.

The sequence that holds up

Reduced to a working order, the playbook is short. Identify the critical business services your customers actually depend on. Run a business impact analysis and set an SRTO for each. Decompose each service into its functions and third parties, and map the dependency chain end to end. Arrange every underlying recovery target so the chain delivers within the SRTO. Then test against the clock, capture what the test shows, and feed the gaps back in. That evidence trail — catalogue, objectives, dependency map, test results, attestation — is what turns a continuity binder into the kind of technology evidence Singapore now expects.

Organise resilience around services and outcomes, rehearse until the recovery objectives are believable, and the regulator’s questions answer themselves. Organise it around systems and hope, and you will be explaining the gap during the incident, which is the worst possible moment to discover it.