The chief medical director is woken at 4am. The records system is encrypted, theatre cannot pull a patient's allergy history, and a note on every screen asks for payment in Bitcoin within seventy-two hours. By 9am the board is on a hurried call, and one question sits above all the others: do we pay? This is the decision a hospital board hopes it never has to make, and the worst time to think it through for the first time is while the clock the attacker set is running.
So decide it now, in the calm. This piece is the framework a board can reason from before the demand ever lands: what makes paying tempting, why it is almost always the wrong answer, and what Nigerian law obliges you to do the moment patient data is touched. The technical recovery (how you pull systems back from backup, who isolates what in the first hour) belongs to the response team. The choice to pay or not belongs to the board.
You are not buying your data back. You are buying a promise from a criminal, priced by how desperate they think you are.
The four questions that decide it
A ransom demand is a business proposition made under pressure. To answer it well, a board needs four facts on the table, and most of them should be known before the attack, not discovered during it.
Are the backups viable? This is the first question because it answers most of the others. If you hold clean, tested, offline backups and you know how long a restore actually takes, the ransom loses most of its power. The trap is the untested backup. Plenty of hospitals discover, mid-incident, that the backup drive was on the same network the malware swept through, or that nobody had ever timed a full restore and it runs to days rather than hours. Know your recovery time before you need it, and store at least one copy where ransomware cannot reach it. That single fact reframes the whole decision.
What did they take before they locked it? Modern ransomware crews steal the data first, then encrypt. This is double extortion: even if your backups are perfect, they hold a copy of your patient records and threaten to publish or sell it. Restoring from backup solves the outage. It does nothing about the copy already sitting on the attacker's server. A board that pays to restore systems is often shocked to learn the data-leak threat is a separate negotiation with a separate price.
How urgent is the patient-safety risk? A bank can run on paper for a day. A hospital with patients on monitored wards, a theatre list, and an emergency department cannot pause as cleanly. If clinical care is genuinely at risk and there is no manual fallback, the pressure to pay is real and it is not irrational. But the honest version of this question is whether the urgency is a backup failure in disguise. If downtime procedures exist and backups restore in hours, the patient-safety argument for paying weakens considerably.
Downtime cost against ransom cost? Boards reach for this comparison too quickly, as if it were a simple sum. It is not. The ransom is not a fixed price for a guaranteed outcome. It is the opening bid in a negotiation with someone who has every reason to lie about what they will deliver.
Why paying is the worst option on the table
Set aside the morality for a moment and look only at what paying actually buys. The case against it is practical before it is ethical.
You get no guaranteed decryptor. You are trusting a criminal to hand over a working key and to have written decryption software that does not corrupt your files. Some do. Some deliver a tool so slow or buggy that recovery from it takes longer than a restore would have. You are paying upfront for a promise with no recourse if it breaks.
You mark yourself as a payer. Crews share intelligence on who pays. A hospital that pays once is logged as a soft target, and a second demand months later is not a coincidence. In several documented cases worldwide, the same victim was hit again by the same group after settling the first time.
The money funds the next attack. Every naira paid underwrites the crew's operations, their next campaign, and the kit that lands on the next Nigerian institution. You are not closing the problem. You are financing its growth.
And there is legal exposure. Paying does not discharge your obligations under Nigerian law, and depending on who the recipient is, moving funds to them can create problems of its own. Paying is a cost you may still be liable for, on top of every duty the breach already triggered.
What the law obliges, whether you pay or not
Here is the part boards most often miss in the panic. The pay-or-not question is a commercial choice. Your legal duties are not optional, and they are triggered by the breach itself, not by your decision on the ransom.
Under the Nigeria Data Protection Act 2023, a hospital is a data controller holding some of the most sensitive personal data there is. When a breach is likely to result in risk to data subjects, the Act requires notification to the Nigeria Data Protection Commission (NDPC) within the timeline the regulation prescribes, and where the risk to those individuals is high, the affected patients must be informed too. Ransomware that exfiltrates patient records is squarely the kind of event that engages these duties. The National Health Act adds its own weight on the confidentiality of health records, so the obligation here sits on two statutes at once, not one.
There is a criminal channel as well. Ransomware is an offence under Nigeria's Cybercrimes Act, and incidents of this kind fall to law-enforcement bodies including the EFCC, which runs a cybercrime mandate. Reporting is not an admission of failure. It is part of doing this correctly, and it can matter later when you are accounting to the regulator for how you responded.
One more sobering point for the board. Cyber insurance in the Nigerian market is still thin, and a policy that covers ransom payment and recovery in the way some foreign cover does is the exception rather than the rule. A board that has quietly assumed insurance will absorb the hit should confirm exactly what the policy pays before treating it as a safety net.
Deciding before the demand lands
The board that handles this well did the thinking months earlier. Ask three things now, in a quiet boardroom, not at 4am with a Bitcoin address blinking on a screen. Do we hold tested, offline backups, and has anyone actually timed a full restore? Who here can declare a major cyber incident and rule on payment, and what is their number at 4am? Do we know the NDPC notification clock, and who files it? A hospital that can answer those is not negotiating from fear when the note appears. It is running a drill it has run before.
The mechanics of that plan, the hour-by-hour recovery and the order in which systems come back, are covered in our healthcare ransomware playbook. What this piece adds is the layer above it: the judgement the board exercises while the technical team works.
Key takeaways for the board
- Backups answer the ransom. Tested, offline backups with a known restore time remove most of the attacker's leverage. The untested backup is the one that fails you mid-incident.
- Restoring does not undo theft. Double extortion means they hold a copy of your patient data regardless of your backups. The data-leak threat is a separate problem from the outage.
- Paying is the weakest option. There is no guaranteed decryptor. It marks you as a repeat target, it funds the next attack, and it carries legal exposure of its own.
- Your NDPA duties stand either way. A breach of patient data triggers NDPC notification (and patient notification where risk is high) under the NDPA 2023 and the National Health Act, whether or not you pay.
- Decide in the calm. Confirm backups, name who has authority to declare an incident and rule on payment, and know your notification clock before a demand ever lands.
If your board has never sat down and answered the pay-or-not question on paper, do it at the next meeting, not at 4am with a Bitcoin address on the screen. A tabletop exercise that walks a hospital board through exactly this decision, and confirms the backups behind it, takes an afternoon. The attacker is counting on you not having had it.
Decide before the demand. Confirm the backups. Know who notifies the NDPC.