Ransomware Recovery Planning for Malaysian Businesses

Ransomware recovery planning is the work of deciding, before an attack, how your organisation will restore systems and data from copies the attacker could not reach, in what order, and who makes each decision. It sits inside your wider disaster recovery plan, but it needs its own steps, because a ransomware event damages the backups and credentials a conventional recovery depends on.

A well-prepared business treats ransomware as a recovery exercise it has already rehearsed, with clean backups, a restore sequence and named owners in place, whichever backup and recovery tools it uses.

Why Ransomware Is a Recovery Problem as Well as a Security One

Ransomware is a recovery problem because attackers deliberately target the systems you would use to recover. The United States Cybersecurity and Infrastructure Security Agency (CISA) notes in its #StopRansomware Guide that many ransomware variants try to find and delete or encrypt accessible backups, so that restoration is impossible unless the ransom is paid.

Malaysian businesses face the same pattern. The Malaysia Computer Emergency Response Team (MyCERT) at CyberSecurity Malaysia reported in its first-quarter 2025 summary that businesses were the most affected by ransomware incidents, with Active Directory servers the primary targets, and it also observed attackers stealing sensitive data and holding it hostage, as reported by The Star. A ransomware recovery plan therefore has to cover two things at once: restoring encrypted systems, and handling stolen data that restoration cannot bring back.

Protecting Backups From Ransomware

Backups protect against ransomware only if the attacker cannot reach, alter or delete them. CISA recommends maintaining offline, encrypted backups of critical data, regularly testing their availability and integrity in a disaster recovery scenario, and keeping up-to-date “golden images” of critical systems, meaning preconfigured operating systems and applications that can be redeployed quickly.

Four design choices put backups out of an attacker’s reach:

1. Isolation: At least one copy is offline or logically isolated from the production network, so that compromised production systems cannot connect to it.
2. Immutability: Backup copies cannot be changed or deleted before their retention period ends, even by an administrator account.
3. Separate credentials: The backup system uses its own accounts and authentication, separate from the production directory, so stolen domain credentials do not unlock it.
4. Offsite storage: A copy is held at a separate site, with controlled transport and storage of backup media.

For Malaysian financial institutions, these choices are also a regulatory requirement. Bank Negara Malaysia’s Risk Management in Technology policy document requires a tamper-proof backup arrangement and an isolated recovery environment so that critical banking and payment services can resume within tolerable limits after a destructive cyber attack such as ransomware.

Setting RTO and RPO for a Ransomware Event

Recovery objectives for ransomware differ from those for a hardware failure or a flood. Your recovery point objective (RPO), the amount of data you can afford to lose, is set by the last clean restore point rather than the last backup, because an attacker may have been inside the network for some time before encrypting anything. If recent backups contain the attacker’s tools or already-affected data, restoring them can restart the attack.

Two planning decisions follow. Keep enough backup history to reach a point before the likely start of an intrusion, and plan time to scan restore points for malware before use. Your recovery time objective (RTO), the time within which a service must be back, also has to include rebuilding systems in a clean environment and validating them, not only copying data back.

Recovery Sequencing: What to Restore First

Recovery sequencing after ransomware starts with the systems that every other system depends on. Restoring business applications onto compromised infrastructure only gives the attacker a second chance.

1. Contain and preserve evidence: Isolate affected systems from the network, and preserve logs and disk images for investigation before rebuilding.
2. Rebuild identity: Restore directory and authentication services, such as Active Directory, in a clean environment, and reset privileged credentials before reconnecting anything else.
3. Restore core infrastructure: Bring back networking, name resolution, security monitoring and the backup platform itself, so that later restores happen under observation.
4. Restore critical business services: Recover applications in the priority order agreed in your business impact analysis, starting with those that carry customer or regulatory deadlines.
5. Validate data: Confirm restored data is complete and consistent with the business before users return.
6. Restore remaining systems: Bring back lower-priority systems once the critical services are stable and monitored.

Planning for Stolen Data as Well as Encrypted Systems

Ransomware recovery planning has to account for data theft, because restoring systems from backup does nothing about copies the attacker has already taken. When an attacker threatens to publish stolen data, the questions change from “how fast can we restore” to “what was taken, whose data was it, and who must be told”.

Those questions are easier to answer if the groundwork is done before an incident. Keep an up-to-date record of which systems hold personal data, customer records and commercially sensitive information, and which logs would show data leaving the network. That record lets the legal and compliance owner assess more quickly whether a breach is notifiable, and it shows the security team which systems to examine first for signs of exfiltration.

Who Does What in the First 24 Hours

The first 24 hours of a ransomware incident decide how quickly recovery can start, and many of the early tasks are decisions rather than technical work. Agree these roles in advance and name a deputy for each.

Notification deadlines start early in a ransomware event. Under the Personal Data Protection Commissioner’s Data Breach Notification Guideline, in force since 1 June 2025, a data controller must notify the Commissioner no later than 72 hours after a notifiable personal data breach, and notify affected individuals no later than 7 days after that initial notification where the breach is likely to cause significant harm. Organisations designated as national critical information infrastructure entities have a shorter clock: under the Cyber Security Act 2024, an initial report is due within six hours of discovering a cyber security incident. Incidents can also be reported to Cyber999, CyberSecurity Malaysia’s incident response centre.

Deciding Whether to Pay a Ransom

Whether to pay a ransom is a decision for the board, taken with legal advice, and a recovery plan exists so that the business is not forced into it. CISA strongly discourages paying a ransom to criminal actors, as Healthcare IT News reported when the agency issued its guidance on ransomware-caused data breaches.

Even where a decryption key is provided, restored systems still need to be rebuilt and validated in a clean environment, and payment does not change the notification duties that apply to any stolen personal data. A tested plan with isolated backups gives the board a realistic alternative to weigh against the attacker’s demand.

Testing a Ransomware Recovery Plan

A ransomware recovery plan is only reliable once it has been tested against the conditions an attack creates. Restore from the isolated or immutable copy, not from the most convenient one, and rebuild into a clean environment rather than onto existing servers. Measure the time taken against your RTO, and record which restore point was usable against your RPO.

Run a tabletop exercise alongside the technical test, so that the incident lead, legal, communications and business owners practise their first-24-hour decisions. For the wider testing programme, see our guide to disaster recovery testing for Malaysian businesses.

Ransomware Recovery Readiness Checklist

Where We Fit

At Strateq, we have operated data centres in Malaysia since 1989, and disaster recovery hosting and management is part of our core data centre service. Our recovery sites span three data centres in two countries: Petaling Jaya and Shah Alam in Malaysia, and Chai Chee in Singapore.

We also provide offsite storage and media transportation for backup copies, and our CBCP-certified consultants support business continuity planning, including business impact analysis, strategy, testing and maintenance, so that the restore order in a ransomware plan reflects your business priorities.

To see where backups stop and disaster recovery begins, read our guide to backup vs disaster recovery in Malaysia.