Business Continuity Planning in Malaysia: A Framework Guide

A business continuity plan in Malaysia is judged on one question: does the organisation keep operating when something breaks? This guide sets out the framework that business continuity practitioners work through, in the order they work through it, so you can build a plan from nothing or audit the one you already have.

It covers business impact analysis, recovery objectives, continuity strategy, plan development and testing. It also covers what Bank Negara Malaysia requires of regulated institutions, because for many organisations here that requirement is what started the project.

What a Business Continuity Plan Covers, and What It Does Not

Three terms get used interchangeably in procurement documents and mean different things in practice.

• Backup — a copy of your data held somewhere else. It protects the data. It says nothing about how long the restore takes or whether anyone has ever tried it.
• Disaster recovery — restoring IT systems and data to a working state after a disruption. It is an IT-scoped activity with IT-scoped measures. Strateq’s disaster recovery services sit at this layer.
• Business continuity — keeping the organisation delivering its critical functions during and after the disruption, including the people, the premises, the manual processes, the suppliers and the communications.

A continuity plan therefore contains a disaster recovery plan but is not the same document. If your systems come back in four hours and your claims processing team has nowhere to sit, no phone line and no authority to declare an incident, you have recovered the technology and not the business.

How to Build a Business Continuity Plan in Malaysia: 6 Stages

1. Risk assessment: Identify what could realistically disrupt operations, how likely each scenario is, and which sites, staff and systems it would affect.

2. Business impact analysis: Establish which business functions are critical and what it costs the organisation when each one stops.

3. Recovery objectives: Set a tolerable downtime and a tolerable data loss for each critical function.

4. Continuity strategy: Decide how each critical function will keep running, and fund it.

5. Plan development: Document who declares an incident, who is contacted in what order, where people go, which systems are recovered first, and how customers and regulators are told.

6. Testing and maintenance: Prove the plan works, record what failed, fix it, and repeat on a schedule.

How to Run a Business Impact Analysis

The business impact analysis produces a ranked list of critical business functions with a tolerable downtime attached to each. Everything downstream depends on it, and a weak analysis produces a plan that protects the wrong things well.

1. Start with functions, not systems. List what the organisation does: settle payments, admit patients, dispatch fuel, issue policies, pay staff. Systems are dependencies of those functions, not substitutes for them.

2. Quantify the cost of downtime for each. Lost revenue is the easy part. Add regulatory exposure, contractual penalties, patient or customer safety, recovery labour, and the cost of the manual workaround if one exists. Where a number is unavailable, an agreed ranking from the process owner is more useful than a precise figure nobody believes.

3. Map every dependency. People with specific authority or knowledge, applications, data, premises, network links, equipment, and third parties. Third-party dependencies deserve particular attention, because they are the ones you cannot fix on the day.

4. Get process owners to sign it off. An analysis run by IT alone documents what IT believes the business cares about, which is a different list from the one the business would produce.

Review the assessment and the analysis at least annually, and again whenever the organisation’s critical functions change.

Setting Recovery Objectives: RTO, RPO and MTD

Three measures do the work, and they are set per function rather than for the organisation as a whole.

• Maximum tolerable downtime (MTD) — the longest a function can be unavailable before the consequences become unacceptable. This is a business judgement, not a technical one.
• Recovery time objective (RTO) — how quickly the function must be working again. It sits inside the MTD, leaving margin for the things that go wrong during a recovery.
• Recovery point objective (RPO) — how much data the organisation can afford to lose, measured backwards from the moment of failure.

The two objectives drive different spending. RPO drives how often data is replicated, so a one-hour RPO rules out a nightly backup cycle. RTO drives how much standby infrastructure has to exist and how much of it is already running. A four-hour RTO for a core banking system and a plan to procure servers after the incident are not compatible.

Tier the objectives. If every function is classified critical with a one-hour RTO, the plan is unaffordable and nothing gets prioritised on the day.

Choosing a Continuity Strategy

Each critical function needs a strategy that meets its objectives. A plan can use several, matched to different tiers of criticality.

Strategy	How it works	Recovery speed	Suited to
Manual workaround	Staff revert to paper or offline processes for a defined period	Immediate, but sustainable only for a short window	Low-volume functions with a simple process
Backup and restore	Systems are rebuilt and data restored from backup media or cloud storage	Slowest of the options, and highly variable	Functions that can tolerate days of downtime
Second site or colocation	Equipment is held at a separate facility, ready to take over	Fast, depending on how warm the standby is kept	Core systems with a defined RTO in hours
Cloud-based recovery	Workloads replicate to recovery infrastructure and are failed over when needed	Fast, and governed by the replication interval	Organisations avoiding the cost of a permanent second site
Work-area recovery	Staff relocate to equipped office space at another location	Same day, once the call is made	Functions where people, not just systems, must keep working

Recovery sites come in recognised forms, and Bank Negara Malaysia lists them in its own policy: a cold site with infrastructure but no equipment, a warm site that needs current data restored before it can operate, a hot site that is fully equipped and operationally ready, a reciprocal arrangement between two organisations, full redundancy with the production system duplicated, and a commercial recovery facility subscribed from a service provider.

Two questions decide between the strategies. What does this function’s RTO actually allow, and what has the organisation tested? An untested strategy is an assumption with a budget line attached.

What Bank Negara Malaysia Expects From a Business Continuity Plan

Malaysia’s financial sector has explicit continuity requirements, and they are more prescriptive than most organisations expect.

Bank Negara Malaysia issued its policy document on Business Continuity Management on 19 December 2022. It came into effect on 19 December 2023, with one exception: the disaster recovery testing requirements in paragraph 9.48 took effect on 19 December 2025, and institutions were permitted to adopt them earlier. It supersedes the 2011 business continuity guidelines and the 2020 circular on disaster recovery readiness for critical systems and services. It applies to licensed banks, licensed investment banks, licensed Islamic banks, licensed insurers, licensed takaful operators, prescribed development financial institutions, operators of designated payment systems and approved issuers of electronic money.

The requirements track the stages above, with specifics that are worth reading against your own plan:

• Analysis. Risk assessment and business impact analysis are both mandatory, and both must be reviewed at least annually and whenever critical business functions materially change.
• Objectives. MTD and RTO are set per critical business function, the RTO must not exceed the MTD, and functions with significant customer impact carry shorter objectives.
• Recovery sites. The site must be far enough from the primary site to avoid the same disruption, and must draw on a separate telecommunications network and power grid.
• Third parties. Contracts with key service providers must carry recovery objectives aligned to the institution’s own, liability where they are missed, participation in integrated testing, and audit access.
• Testing. The business continuity plan, the disaster recovery plan and the crisis management plan are each tested at least annually. Disaster recovery testing includes a live run on a business day at recent peak load, a scenario of at least three consecutive business days operating from the recovery site, and a re-test within a year of any failed live run.
• Notification. Disruptions are reported to the regulator within timelines set by severity, down to two hours for the most serious levels and for confirmed cyber incidents.

Bank Negara Malaysia’s Risk Management in Technology policy document sits alongside it and covers the technology layer. Payment services regulatees have a further set of technology requirements issued on 12 March 2026 and taking effect on 12 March 2027, which is worth mapping against an existing plan now rather than in the final quarter.

Two obligations apply regardless of sector. Personal data does not lose its protection because it has moved to a recovery site, so PDPA obligations follow the data into whatever standby environment holds it. And organisations that run around the clock, hospitals in particular, need continuity arrangements for clinical systems that assume no maintenance window exists.

Organisations outside these regimes are not obliged to follow the structure. It is still the most complete template available locally, and it is the one your regulated customers will assess you against when they review their own third-party dependencies.

How to Test a Business Continuity Plan

Testing is the only stage that produces evidence. Four levels, in increasing order of realism:

1. Plan walkthrough: The team reads the plan and confirms names, numbers, systems and sequences are current. Cheap, and it catches documentation that has fallen out of date.

2. Tabletop exercise: A scenario is presented and the team talks through the response. This surfaces decision-making gaps, particularly around who has authority to declare an incident out of hours.

3. Component or failover test: An actual failover of a system to its recovery environment, with the results measured against the RTO and RPO set for it.

4. Full simulation: Systems fail over and staff relocate to the recovery location and work from it. This is the only test that validates the people and premises side of the plan.

Test at least annually, and again after any material change to systems, premises, suppliers or organisational structure. Record what failed, who owns the fix, and when it will be retested. Regulators and enterprise customers ask for test results, not for the plan document.

Business Continuity Planning Checklist

Work through this against your current plan. Every unchecked line is a decision someone will have to make during an incident instead.

• Risk assessment completed and dated within the last 12 months
• Business impact analysis signed off by process owners, not only by IT
• Critical business functions listed and ranked
• Maximum tolerable downtime agreed for each critical function
• RTO and RPO set per function, tiered rather than uniform, with RTO inside MTD
• Dependency map covering people, applications, data, premises and third parties
• Continuity strategy selected and funded for each critical function
• Recovery site or cloud recovery arrangement contracted, configured, and sited away from the primary location
• Key service provider contracts carrying recovery obligations aligned to your own
• Work-area recovery arrangement in place for functions that need staff on site
• Named authority for declaring an incident, including out of hours
• Crisis communication plan covering staff, customers, suppliers and regulators
• PDPA obligations addressed for personal data held in the recovery environment
• Regulatory requirements mapped to specific sections of the plan
• Test schedule defined, with results, owners and retest dates recorded
• Plan reviewed after every material change to systems, premises or suppliers

Where Strateq Fits

Strateq has operated data centres in Malaysia since 1989 and is one of Malaysia’s pioneer data centre providers.

Its business continuity consulting follows the methodology of the Disaster Recovery Institute International (DRII), and covers the stages set out above: business impact analysis, continuity analysis and strategy development, plan development and customisation, infrastructure development, plan testing and plan maintenance, alongside continuity policies and standards, training, and a quality assurance programme that keeps the plan current. The consultants running that work are DRII certified.

For the people side, Strateq provides more than 300 business continuity seats at its Malaysian facilities, on a dedicated or shared basis, so staff in critical functions have equipped space to relocate to rather than an arrangement that exists only on paper.

The data centre itself is audited by Bank Negara Malaysia and by the Chief Government Security Office, which matters when your own plan has to survive a regulator’s review of the third parties it depends on.

Take the checklist to your next planning session, and talk to Strateq’s business continuity team if you want the analysis and testing run alongside your own.