Pension administrator: ransomware, 240,000 contributors and a CEO who wants silence

Evaluate the instruction

The instruction is understandable and wrong. Four reasons:

1. Legal exposure: the Nigeria Data Protection Act requires notification to the Commission within 72 hours of becoming aware of a breach likely to result in a risk to data subjects. Silence converts a technical incident into a regulatory breach with its own penalties.
2. Contractual exposure: the insurer requires notification within 48 hours and prior approval for payment. Delay can void cover - the one resource that funds recovery.
3. Data subject harm: names, dates of birth, BVNs and balances are sufficient for identity fraud and targeted phishing against retirement savings. Contributors cannot protect themselves if they do not know.
4. Forensic damage: the instruction to withhold information often becomes an instruction to contain internally, which risks tipping off the attacker or destroying evidence.

First 72 hours - decisions and owners

• Declare a formal incident and activate the response plan; appoint an incident commander (CISO).
• Contain: isolate affected segments, disable the VPN path, reset privileged credentials, preserve logs and disk images before rebuilding (forensics lead).
• Engage external forensics and legal counsel; establish privilege over the investigation (General Counsel).
• Notify the insurer within 48 hours and confirm coverage and approved vendors (CFO).
• Notify the data protection officer to prepare and file the regulatory notification within 72 hours; determine whether pension-sector and financial regulators also require notification (DPO, General Counsel).
• Brief the board risk committee and chair; log decisions (Company Secretary).
• Prepare contributor communication and a call-centre script; do not wait for full forensics to warn about phishing (Head of Communications).
• Report to law enforcement as advised by counsel.

Speed on containment and notification; patience on root cause.

Frame the decision properly

Payment is a commercial and ethical judgement, not a technical one, and it is not a legal safe harbour. It should be a documented board decision taken on advice.

Factors in favour

• Restoration of contributor services and pension processing could be accelerated if a working decryptor is supplied.
• Harm to 240,000 contributors may be time-critical.
• The amount, 0.9 BTC, may be small relative to downtime cost.

Factors against

• No guarantee: attackers frequently fail to provide a working key or re-extort after payment.
• It funds criminal activity and may raise sanctions exposure depending on the recipient, requiring legal screening.
• Paying does not address the exfiltration - the data is already out, so payment buys confidentiality promises of no value.
• It rewards the intrusion and increases the likelihood of targeting, including by affiliates who share victim lists.
• The insurance policy requires prior approval; paying unilaterally risks non-coverage.
• Recovery is achievable without payment if clean backups or rebuild capacity exist, even at higher cost.

Process

1. Quantify recovery without payment: what can be restored from offline or immutable copies, at what cost and duration.
2. Obtain legal advice on sanctions and regulatory implications; notify the insurer and obtain approval.
3. Engage law enforcement and a specialist negotiator; verify any decryptor on a sample before payment.
4. Require board sign-off with reasoning recorded, including why alternatives were rejected.

Recommendation

Do not pay unless independent evidence shows recovery without a key is impossible and contributor harm is demonstrable. On these facts, the backup failure is the real problem and should be fixed rather than bought around.

Priorities, in risk order

1. Backup resilience: implement a 3-2-1 model with at least one immutable, offline or air-gapped copy, separate credentials and network path, encrypted catalogue stored separately, and quarterly tested restores with recorded recovery time. The 14-month gap between verified restores is the single most serious finding.
2. External access and patching: inventory internet-facing assets, enforce patch SLAs, require MFA on all remote access, and retire or replace the appliance that was exploited.
3. Identity and privilege: unique accounts, privileged access management, removal of standing administrative rights, and monitoring of privileged activity.
4. Segmentation and detection: segment servers so encryption cannot spread laterally; deploy endpoint detection and centralised logging with alerting for unusual access patterns; the 19-day dwell time indicates detection was absent.
5. Data minimisation and protection: question why a folder of BVNs and balances was accessible in that form; apply classification, access control and encryption.
6. Response capability: tested incident response plan, a communications protocol that does not depend on the CEO's instinct, and a pre-agreed notification matrix.

How the board assures delivery

• A remediation programme with named owners, dates and a single accountable executive, reported monthly to the board risk committee.
• Metrics that test reality, not activity: percentage of critical patches within SLA, restore test results and recovery time, MFA coverage, number of standing privileged accounts, mean time to detect in tabletop exercises.
• Independent validation - internal audit or an external assessor - before closure is declared.
• A board-approved cyber risk appetite that states explicitly what downtime and data loss the organisation will tolerate.
• A lessons-learned review that names the governance failures, including why backup verification and patching were not treated as board-visible risks.