ISO 27001:2022 Certified SECP Registered PEC Licensed PSEB Registered
+92 312 5463398  ·  support@cyberedgetechs.com
Home / Insights / Ransomware readiness for a public sector department
Cybersecurity

Ransomware readiness for a public sector department

The question is not whether your antivirus will stop it. It is whether you can restore a working service without paying, and how long that takes.

Cybersecurity11 June 20267 min read

Ransomware planning goes wrong when it is treated as a prevention problem. Prevention matters, but it is a probability exercise — you are reducing the chance of an event you cannot reduce to zero. Recovery is a capability question, and it has a testable answer.

The only backup that counts is a restored one

Every organisation we assess reports that backups are running. A materially smaller number can state when they last restored a complete service from those backups and how long it took. Those are different claims, and only the second one is useful during an incident.

Run a restore test on a schedule, restore to isolated infrastructure rather than over production, and time it. The number you get is your actual recovery time objective, whatever the policy document says.

Offline or immutable, not merely off-site

Modern ransomware operators look for the backup system first, because encrypting or deleting backups is what converts an incident into a payment. A backup reachable from a compromised domain account with the credentials in use during the attack is not a backup. You need at least one copy that is offline, or on immutable storage where deletion is prevented by the storage layer rather than by permissions.

Decide the payment question before the day

A department that has not decided its position on payment will decide it under pressure, badly, with a countdown running. Put the position in writing, get it approved at the level that would have to approve a payment, and record who is authorised to communicate with an attacker if anyone is. Note that payment does not reliably return data and may carry its own legal consequences.

The plan needs to work without your systems

  • Contact lists on paper or a phone, not in the email system that will be down.
  • A pre-agreed out-of-band channel for the response team.
  • Named authority to disconnect a network segment without seeking approval first.
  • A holding statement for staff and the public that does not require sign-off from six people.
  • Your incident response supplier's number, and confirmation they will answer it.

Segmentation limits the blast radius

Flat networks are why a single compromised workstation becomes a departmental outage. Segmenting administrative traffic, restricting lateral movement between offices, and removing standing domain administrator rights are unglamorous projects that do more for survivability than most security product purchases.

None of this requires exotic technology. It requires deciding that recovery is a service the organisation owes itself, and funding it as one.

Sources and further reading

External links, provided for verification. CyberEdge is not responsible for third-party content.