Ransomware Preparedness in APAC: Assume It Gets Through

Ransomware is not a trend that will pass. It is an industry, and a lucrative one: criminal groups run it with sales teams, affiliate programmes, customer support desks and negotiated revenue splits. They invest in their capability because it returns money reliably, which means they reinvest, hire skilled developers, and adapt faster than most defenders update anything. Prevention matters, but the honest starting point is this: assume that one day, despite everything, the encryption payload runs on your systems. Preparedness is what happens after that assumption.

This article covers both halves of that reality: why ransomware is so hard to stop outright, and what preparedness actually looks like in modern, cloud-connected environments, including backup strategies that attackers can touch but not destroy.

Why ransomware is so hard to stop #

Early ransomware was opportunistic: encrypt whatever the infected machine could reach, demand a few hundred dollars. The modern model is targeted and patient. Groups gain access through phishing, exposed remote access, or purchased credentials, then spend days or weeks quietly moving inward, escalating privileges, mapping backups, and exfiltrating data before triggering anything visible.

That evolution created two problems defenders cannot simply buy away:

Double extortion removes the backup escape hatch. Restoring from backup used to end the crisis. Now the stolen data is published or sold if you refuse to pay, so even a clean restore leaves you facing a data breach, regulatory notification duties under PDPA and equivalents, and public exposure. Backup is necessary; it is no longer sufficient.

The initial foothold only needs to happen once. Defenders must succeed against every phishing email, every unpatched appliance, every credential leak, every third-party connection. The attacker needs one success on one Tuesday. Asymmetries like that do not resolve in the defender’s favour by wishing.

None of this means defence is pointless; it changes the odds of being hit. But it cannot change the outcome of the hit. Only preparation changes that.

What it actually feels like #

Boards tend to imagine ransomware as a technical event. Organisations that have lived it describe something closer to a natural disaster with an invoice:

• Weeks of downtime. Even organisations that refuse to pay and have good backups routinely take weeks to fully restore production services, because rebuilding is sequenced, validated and slower than anyone plans for.
• Costs from everywhere at once. Incident response and forensics at crisis rates, emergency legal counsel, overtime across IT and operations, rebuilt hardware, lost revenue compounding daily, and later, regulatory investigations on top.
• Decisions under pressure without authority. Who decides whether to pay? Who tells staff? Who talks to customers, regulators, journalists? Companies that never rehearsed those questions answer them badly, slowly, and often publicly.
• A long tail of distrust. Customers churn, enterprise contracts get invoked, and the incident resurfaces in every future procurement conversation for years.

Understanding this shape matters because every preparedness measure below maps directly onto reducing one of these costs.

Immutable backups: the control that changes the outcome #

If there is a single technical investment that shifts ransomware from catastrophe to bad week, it is backups the attacker cannot alter or delete. Traditional backups failed at this precisely because they were reachable: attackers with domain credentials routinely delete or encrypt backup jobs first, then trigger the main event against an organisation with nothing left.

Modern object storage solves this with immutability:

• Object Lock / WORM storage writes backups in a form that cannot be modified or deleted for a retention period, by anyone, including your own administrators. AWS S3 Object Lock, Azure immutable blob storage and comparable offerings in other clouds all implement this pattern.
• Retention periods create a window of survival. Set immutability windows so that whatever an attacker destroys today, versions from before their access survive until the lock expires. This is where the cloud-specific design detail matters: restrict any write or delete access to protected copies until files age out of retention. Not just attacker accounts: all accounts. The credentials compromised during intrusion are your own, so the protection has to hold against them.
• Separate the backup identity entirely. Backup infrastructure should use dedicated credentials, separate authentication domains, and network paths unreachable from production user environments. If the same admin account manages production and backups, immutability is doing all the work alone, and it deserves help.
• Test restores on schedule. An untested backup is a hypothesis. Restore a full production service regularly, time it, and fix what the test reveals while the stakes are low.

Restricting access beyond backups #

Immutability protects the recovery path. The same principle of restricting any access until trust is earned applies elsewhere:

• Privileged access just-in-time. Standing administrative rights mean the intruder inherits them. Elevation with approval and expiry shrinks what any single compromised account unlocks.
• Staged recovery environments. A clean management enclave, built or verified offline, from which rebuilds are performed. Rebuilding from a compromised management plane reinstalls the attacker.
• Segregation of critical segments. Payment systems, domain controllers and industrial controls behind enforced boundaries limit what one encrypted workstation can cascade into.

The preparedness checklist #

Pulling this into a sequence a small team can execute over two quarters:

1. Backups first: immutable object-lock copies of critical systems, separate backup identity, documented retention, first full restore test.
2. Rehearse the decision: a cyber crisis tabletop exercise covering the payment question, notification duties and communication roles. The gaps found are cheap now and expensive later.
3. Establish response capacity in advance: a DFIR retainer means forensics and containment begin within hours under agreed terms, rather than beginning with procurement during a live crisis.
4. Shrink privileged standing access across identity platforms.
5. Verify boundaries annually: segmentation and isolation claims tested through penetration testing, not assumed.

Preparedness does not make ransomware impossible. It converts an existential event into a costly but survivable one, and the difference between those two outcomes is decided almost entirely before the incident begins.

Our DFIR retainer puts response capacity in place before you need it, and our Configuration & Architecture Assessment reviews your backup architecture, privilege model and segmentation against exactly this scenario. Or schedule an Engineering & Scoping Session to plan the checklist above with your team.