The encryption note appears at 2:14 a.m. By breakfast, three decisions have already been made that a regulator, a client, or a plaintiff's lawyer will ask about months later: who was told, what was preserved, and whether anyone hinted at a payment. Ransomware is an operational crisis, but it is also a legal event with its own clock running alongside the recovery work.
Most of the costly mistakes are not technical. They are made by tired people trying to do the right thing quickly, without a lawyer in the room.
Paying the ransom before anyone checks the legal ground
Paying feels like progress. It produces an action, a receipt, a reason to hope. It also creates a record that follows the company.
Several problems arrive at once. Sanctions rules in the United States and elsewhere can restrict or prohibit payments to listed groups or to the intermediaries who move money for them, and paying through a broker does not launder that risk. Insurance policies frequently require the insurer's prior consent before any payment, and many exclude payments to sanctioned parties entirely. Customer contracts increasingly contain clauses prohibiting ransom payments outright, particularly in healthcare, defence and financial services supply chains. And where regulators assess whether the company took reasonable security measures, a fast payment can look like an attempt to make the problem disappear rather than fix it.
There is also the practical point: decryption tools from criminal groups are unreliable, and restoring from clean backups remains the more dependable path in many cases.
What to do instead: bring counsel and the insurer into the payment decision before it is authorised, not after. Write down the alternatives you considered and why you rejected them. If a payment does happen, document who approved it, who screened the recipient against sanctions lists, and when.
Delaying notification, or notifying the wrong people first
Under the GDPR, personal data breaches generally must be reported to the supervisory authority within 72 hours of the controller becoming aware of them. EU rules such as NIS2 set staged deadlines for essential and important entities. Sector regulators, state breach laws, and publicly traded disclosure duties each carry their own triggers. On top of that sit contracts: managed service providers, insurers, payment processors and enterprise customers often require notice within 24 to 72 hours.
The instinct to wait until the picture is complete is understandable and usually wrong. Deadlines are built on what you know, not on what you eventually conclude. Late notification is one of the few ransomware failures that regulators can measure objectively, and it carries penalties without much room for argument.
Two related mistakes show up often:
- Notifying IT and the incident response vendor but not legal, compliance or the board. The people with the reporting obligation need to know within hours, not at the post-mortem.
- Sending a vague holding statement that contradicts the detailed notification you file a week later. Regulators compare documents.
Notify on time with what you know, mark it clearly as preliminary, and update it. An amended filing is normal. Silence is not.
Destroying, overwriting or never collecting the evidence
Recovery pressure pushes teams to reimage endpoints, rebuild servers and hand staff new laptops so work can resume. Every one of those steps can erase the artefacts that show how the intruder got in, what they touched, and whether data left the building.
Once litigation, a regulatory investigation or an insurance dispute is reasonably anticipated, a duty to preserve relevant material usually attaches. Deleting logs after that point is not just careless; it can be treated as spoliation of evidence and can damage a defence far more than the original breach.
Before anything is rebuilt or wiped, get these captured and stored offline:
- Endpoint and server logs, including authentication, VPN and remote access records
- Volatile memory on key systems, which holds evidence that disappears at shutdown
- The attacker's communications and the ransom note itself — it is evidence of the demand
- Email, chat and ticketing records from the response, including the messy early hours
- Backup catalogues showing which sets were intact, and when
Note also what you never collected. If logs are retained for 30 days and the intruder was inside for 90, the gap will be noticed. Fixing log retention after the fact does not fix the gap, but it does help with the next incident.
Treating it as purely an IT problem
When the technical lead also runs the legal analysis, decisions get made for engineering reasons. Forensics get commissioned without protections around privilege. Internal emails start speculating about the unpatched server everyone knew about, and those emails are read aloud later.
Engaging outside counsel early, and having counsel direct forensic and communication work where appropriate, is a common way to structure a response so that advice stays advice. It is not a magic shield, and it will not protect facts or business records. But it does change how the work is scoped and documented.
Keep the lanes clear: technical people rebuild, legal people handle obligations, communications people handle what the world hears, and one senior person owns the decision log.
Losing control of what you say and to whom
Early statements tend to be either too generous or too thin. Admitting a specific failure before the forensics are in can become an admission you cannot walk back. Saying nothing at all while customers read about it elsewhere damages trust you will need for the next two years.
Other communication errors worth avoiding: negotiating with the attacker from a personal email account with no preserved records; offering an explanation to a journalist that differs from the notification filed with a regulator; and failing to brief your bank, insurer and key customers while there is still time for them to act on fraudulent payment instructions.
Prepare two or three lines of approved language early, cover the known facts, and say plainly that the investigation is continuing. Then update.
A short checklist for the first 72 hours
- Stand up the response team with legal, compliance, communications and insurance in the room.
- Issue a legal hold: nothing is wiped, reimaged or deleted without sign-off.
- Capture logs and volatile data before rebuilding anything.
- Check every notification clock you are subject to — regulatory, contractual and sector-specific — and diarise them.
- Do not authorise or discuss a ransom payment until counsel and the insurer have weighed in.
- Keep a running decision log: who decided, when, on what information.
- Draft external language once, share it widely internally, and keep it consistent across regulators, customers and the press.
Ransomware response turns on facts, contracts and the jurisdictions you operate in, and the right answer differs from one company to the next. This is general information rather than legal advice; for a real incident, get qualified counsel involved before the first filing and before any payment is made.
Photo: cottonbro studio / Pexels
