Ransomware is an attack that removes an organisation’s access to its own data by encrypting it and makes restoring that access conditional on payment. Preparation consists of settling a handful of questions in advance: where we restore from, within what time, who orders systems disconnected, and whom we notify.
Quick Overview
What you’ll learn:
- Which decisions have to be made before an attack, because there is no time during one
- What recovery thresholds are and why a plan without them is a wish
- Why a backup never tested by restoring is not a control
- How to separate roles in the first hour of an incident
Who this article is for:
- Executives and service owners in mid-size organisations
- Administrators accountable for backups and restores
- People running security awareness sessions for their teams
Reading time: 7 minutes
What Has to Be Settled Before the Attack
A ransomware attack takes away more than data: it takes away thinking time. That is why the list of decisions already made is the single most valuable part of preparation. You need to know who holds the mandate to isolate a network segment or shut down a production service without asking the board, who talks to customers, who talks to the supervisory authority, and whether contact with the attacker is considered at all.
The incident response recommendations from csrc.nist.gov (SP 800-61 Rev. 3) treat response as part of cybersecurity risk management and organise it around the CSF functions: govern, identify, protect, detect, respond and recover. What matters here is that responding and recovering are separate functions — restoring data into an environment where the attacker still holds access is the most expensive mistake available.
The second decision concerns internal communication. A team that learns about an incident from a message on a screen acts chaotically. A team that knows which number to call and what not to touch buys the organisation the minutes that decide how far the encryption spreads.
Recovery Thresholds Drive Everything Else
A recovery plan without named thresholds is a declaration. The contingency planning guide from csrc.nist.gov (SP 800-34 Rev. 1) names the quantities that must be set per service rather than once for the whole company: the tolerable data loss expressed as time (RPO) and the tolerable service outage (RTO).
Setting those thresholds is not a technical task. The service owner decides whether losing the last few hours of data is acceptable, because the service owner bears the consequence. Backup frequency, copy count and storage location all follow from that decision — and only then does a cost conversation make sense, because it concerns something specific rather than a general sense of safety.
The thresholds also produce a service tiering. Not everything needs restoring the same day; some systems can wait a week with no effect on operations. An organisation that skipped that tiering restores everything at once during an incident and restores nothing on time.
A Backup That Survives the Attack
The control set published by cisecurity.org treats data recovery as a control in its own right rather than an appendix to backup: it requires copies isolated from the production environment and periodic verification that restoring actually works. The distinction matters, because ransomware targets backups as deliberately as it targets production data.
Practice dictates the properties a copy needs in order to survive. It has to be immutable and undeletable by the account that administers production. It has to live outside the same authentication domain, otherwise compromising a privileged account covers the copies too. And it has to be verified by restoring, not by checking a job status — a “success” report attests that a copy was written, not that it is usable.
A restore test is also the cheapest way to discover the things nobody planned for: missing configuration documentation, an encryption key stored inside the system being restored, a dependency on a service that itself needs restoring first.
Roles in the First Hour, and Regulatory Duties
Response needs a named team. In a mid-size company the CSIRT function, or an internal response team, is usually a group combining an administrator, a communications person and a business decision-maker — what matters is that membership and deputies are written down, because incidents do not respect holidays.
Guidance on human-operated ransomware from learn.microsoft.com is worth reading alongside this, because it describes an attack run by operators who adapt to the defence rather than a self-propagating program: they look for privileged accounts, remove backups and choose the moment of encryption. The defensive consequence is that privileged account control and monitoring matter more here than any single detection product.
For entities in scope of the NIS2 directive — Directive (EU) 2022/2555, published on eur-lex.europa.eu — business continuity including backup management, and incident handling, are named explicitly among the risk-management measures in Article 21. The same act introduces reporting duties on short deadlines, which means the notification path has to be prepared rather than improvised.
Read Also
- Security Incident Analysis: From Detection to Lessons Learned — the analysis phase that containment quality depends on
- What Is ISO 22301 — Business Continuity Management? — the frame recovery thresholds belong to
- Human Risk Management in Cybersecurity: Building Awareness and Resilience — the human layer most incidents begin in
Build Your Skills
This topic is developed in the Ransomware Response — preparation, response and recovery and Cyber security incident response team (CERT) courses. The first works through an attack scenario and recovery, the second through team design and procedures. Contact us to match the scope to how your organisation is structured.
Frequently Asked Questions (FAQ)
How does ransomware differ from other malicious software?
In its goal and operating model. Conventional malware tries to stay hidden and keep access, whereas ransomware deliberately reveals itself at some point, because extortion is where its value sits. It increasingly combines encryption with data exfiltration, so restoring from backup ends the availability problem but not the disclosure one.
Is a cloud backup enough on its own?
That depends on permissions, not on location. A cloud copy accessible to the account administering production shares that environment’s fate. A copy resistant to overwriting and deletion, with its own authentication path and a tested restore, protects you even when it sits in the same cloud.
Are attack simulations worth running?
Yes, and worth running first in a form that uses no offensive tooling. Walking a scenario through at a table — who calls, who isolates, where we restore from, what we tell customers — exposes procedural gaps faster and more cheaply than a technical exercise. A technical simulation makes sense as the next step, once the procedure exists.
Do NIS2 entities face separate backup requirements?
The directive names backup management and recovery among its risk-management measures without prescribing a technology or a frequency. Choosing the parameters stays with the entity, and the evidence of compliance is a documented risk analysis, agreed recovery thresholds and a record of tests.