The recovery gap
The Sterling Bank, Remita, and Corporate Affairs Commission breaches of March 2026 were a technical failure. What followed was an organizational one.
Forensic investigations stretched into weeks. Customer notifications were delayed or never issued. Business continuity plans — where they existed — had been designed for power outages and natural disasters, not for an adversary living inside core banking infrastructure for nine days. Communication broke down at every level: regulators were not notified within the 72-hour GAID window, boards received fragmented briefings, and customers learned about the compromise of their BVNs and NINs from journalists rather than their banks.
The breaches exposed something more dangerous than unpatched servers or misconfigured S3 buckets. They exposed a sector that had invested in perimeter defenses but not in the capacity to respond when those defenses failed. The gap between "we were compromised" and "we have contained and recovered" is where reputational, regulatory, and financial damage compounds. For many of the affected organizations, that gap stretched from days into months.
Recovery capability is not an abstract concept. It is the difference between a contained incident and a crisis that reshapes your relationship with regulators, customers, and the market.
Why prevention alone fails
Every security program has a fundamental constraint: no combination of tools, policies, and personnel stops 100% of attacks. A motivated adversary with time and patience will find a way in. ByteToBreach demonstrated this clearly — the Sterling compromise began with a single unpatched CVE, and from there the attacker moved laterally into Remita using plaintext credentials stored in source control. Two organizations, two different control environments, one continuous compromise.
The organizations that recover fastest from breaches are not the ones with the most firewalls. They are the ones that have invested proportionally across four capabilities: prevention, detection, response, and recovery. Most Nigerian financial institutions have concentrated spending on prevention — next-generation firewalls, endpoint protection, email filtering — while leaving the other three underfunded.
The cost of this imbalance is measured in dwell time. ByteToBreach maintained access to Sterling Bank's T24 core banking system for nine days before detection. Industry benchmarks from organizations with mature security operations centers bring that number down to hours. The difference is not a question of budget — it is a question of architecture. Detection requires tuned SIEM rules, behavioral baselines, and analysts who know what normal looks like in their environment. Response requires playbooks, authority to act, and practiced coordination. Recovery requires tested backups, forensic capability, and continuity plans that account for the specific characteristics of a cyber event.
Prevention is necessary. It is not sufficient.
Incident response capability
Most organizations in Nigeria's financial sector have an incident response plan. Few have an incident response capability. The distinction matters.
A plan is a document. A capability is a team that has practiced executing that document under pressure, with the tools and authority to act. After the 2026 breaches, several affected institutions discovered that their IR plans had never been tested, their designated responders had no forensic training, and their communication templates had not been updated since initial drafting.
A functional IR capability requires:
- A designated IR team — not the IT department wearing a second hat. A cross-functional team including IT, legal, communications, compliance, and business leadership, with clear roles and a designated incident commander.
- Pre-built playbooks for the scenarios most likely to affect your organization: ransomware, data exfiltration, insider threat, third-party compromise, and payment fraud. Each playbook should specify containment actions, evidence preservation steps, escalation triggers, and communication sequences.
- Communication templates drafted and legally reviewed before an incident occurs. You need separate templates for four audiences: the regulator (NDPC, CBN), the board, affected customers, and the media. Writing these under the pressure of an active incident guarantees errors.
- Forensic tool access — either in-house capability or a pre-negotiated retainer with an incident response firm. Procuring forensic support after a breach introduces delays measured in days. A retainer ensures response within hours and establishes the engagement terms before emotions and urgency distort negotiations.
- Regular tabletop exercises — at minimum, twice per year. Walk through a realistic scenario with the full IR team and measure decision-making speed, communication accuracy, and handoff coordination. The exercise should be uncomfortable. If everyone leaves the room feeling good about the outcome, the scenario was too easy.
The first time your IR team coordinates a response should not be during a real incident.
The 72-hour notification challenge
The GAID, effective since September 2025, requires data controllers to notify the Nigeria Data Protection Commission within 72 hours of becoming aware of a personal data breach. This is not a suggestion — it is a legal obligation with enforcement consequences.
The practical challenge is severe. Most organizations cannot determine the scope of a breach within 72 hours, let alone prepare a regulatory notification that accurately describes the nature, extent, and likely consequences of the compromise. Forensic investigation takes time. Log analysis takes time. Understanding what data was accessed versus what data was exfiltrated takes time. The clock starts ticking when you become aware of the breach, and regulators have limited patience for notifications that say "we are still investigating."
The solution is to build the notification process before the incident:
- Pre-drafted notification templates for NDPC and CBN, covering the required fields: nature of the breach, categories of data affected, approximate number of individuals, likely consequences, measures taken or proposed. Leave blanks for incident-specific details.
- Decision trees that define when a security event qualifies as a reportable breach. Not every alert is a breach. Your IR team needs clear criteria — developed in consultation with legal — for when the 72-hour clock starts.
- Legal review triggers that automatically engage your data protection officer and external counsel when an incident meets notification thresholds. Legal review of the notification should be built into the 72-hour timeline, not bolted on after the fact.
- Regulator relationships established during peacetime. The first time your CISO contacts NDPC should not be during a breach notification. Engage with the Commission during non-crisis periods — attend briefings, participate in consultations, understand their expectations. Organizations with established regulatory relationships navigate the notification process with less friction.
The organizations that failed to notify after the 2026 breaches did not make a deliberate decision to violate GAID. They simply had no process to follow when the moment arrived.
Business continuity for cyber events
Traditional business continuity planning in Nigeria's financial sector was built for physical disruptions: generator failures, flooding, building evacuations. These plans share a common assumption — that once the disruption is resolved, systems can be restored from known-good states and operations resume.
Cyber events break this assumption in three ways.
First, systems may be available but untrusted. After a breach, you cannot assume that any system the attacker may have touched is operating with integrity. Servers may be running, databases may be online, but until forensic analysis confirms they are clean, using them risks extending the compromise or destroying evidence.
Second, backups may be compromised. Sophisticated attackers target backup systems deliberately. Ransomware operators routinely encrypt or delete backups before triggering their payload. If your recovery plan assumes backups are intact and available, you are planning for the best case while experiencing the worst.
Third, recovery requires forensic clearance. You cannot simply restore from backup and resume operations. Forensic investigators need to identify the root cause, confirm containment, and validate that restored systems do not reintroduce the vulnerability or the attacker's persistence mechanisms. This process takes time and must be sequenced correctly — premature restoration can re-compromise the environment.
Financial institutions need cyber-specific continuity plans that address these realities: degraded-mode operations when primary systems are under investigation, manual processing procedures for critical transactions, communication protocols for customers during extended outages, and recovery sequences that integrate forensic requirements. These plans should be tested through exercises that simulate a cyber scenario, not a power outage.
Board and executive engagement
Security resilience is not a technology problem. It is a capital allocation problem, and capital allocation decisions are made at the board level.
The 2026 breaches created a window that security leaders in Nigeria's financial sector should not waste. Boards are asking questions. Audit committees want to understand exposure. Risk committees are revisiting their cyber risk appetite statements. This attention is temporary — it will fade as the breaches recede from headlines — and the investments secured during this window will define institutional resilience for the next three to five years.
Use this moment to establish three things:
Regular board reporting on cyber risk. Not annual presentations buried in the IT committee agenda. Quarterly briefings to the full board or risk committee, using metrics that connect to business outcomes: mean time to detect (MTTD), mean time to respond (MTTR), mean time to recover, percentage of critical assets with current vulnerability assessments, and status of regulatory compliance obligations. These metrics should be trended over time and benchmarked against sector peers where data is available.
Board-level tabletop exercises. At least annually, walk the board through a realistic breach scenario. Not a technical deep-dive — a strategic decision exercise. The board should practice making decisions about public disclosure timing, regulatory notification, customer communication, and resource allocation under simulated crisis conditions. The exercise reveals whether the board understands its role during an incident and whether governance structures support rapid decision-making.
Security investment tied to business outcomes. Boards approve budgets, not architectures. Frame security investments in terms of risk reduction and regulatory compliance, not technical specifications. "We need a SIEM" means nothing to a board. "Our current mean time to detect is nine days — matching Sterling's dwell time. This investment reduces it to under 24 hours and addresses three CBN CSAT domains" is a business case.
A 90-day resilience roadmap
Resilience is not built in a single initiative. It is built through sustained, sequenced investment. The following roadmap provides a practical starting point for financial institutions that recognize the gap between their current state and the capability the threat environment demands.
Days 1-30: Assess and establish
- Assess current IR capability against actual requirements. Do you have a designated team? Tested playbooks? Forensic access? Be honest about the gaps — the CSAT self-assessment process may have already surfaced some of these.
- Establish a cross-functional IR team with named individuals, defined roles, and an incident commander with authority to make containment decisions without waiting for committee approval.
- Select and engage a forensic retainer. Negotiate the engagement terms, response time SLAs, and scope of services now. Establish secure communication channels and share your network architecture documentation so the firm can respond effectively when called.
Days 31-60: Build and practice
- Develop playbooks for your top three scenarios. For most Nigerian financial institutions, these are: ransomware affecting core banking systems, customer data exfiltration, and third-party/supply chain compromise. Each playbook should be specific enough to guide action, not so rigid that it cannot adapt to the unexpected.
- Conduct the first tabletop exercise. Walk through one scenario with the full IR team. Measure response time, decision quality, and communication accuracy. Document gaps and feed them back into the playbooks.
- Implement the 72-hour notification process. Draft templates, define decision trees, establish legal review triggers, and assign ownership. Test the process end-to-end using a simulated breach.
Days 61-90: Detect, test, report
- Deploy detection improvements. If you lack EDR on critical servers, deploy it. If your SIEM has default rules that have never been tuned, tune them for your environment. Develop use cases based on the TTPs observed in the 2026 breaches — Sliver C2 beaconing, lateral movement via credential reuse, bulk data exfiltration patterns.
- Test business continuity for a cyber scenario. Run an exercise that simulates a ransomware attack affecting your core banking system. Test degraded-mode operations, backup integrity verification, forensic sequencing, and recovery procedures. Identify where the plan breaks.
- Establish a board reporting cadence. Deliver the first quarterly cyber risk briefing. Present the current state honestly, the roadmap for improvement, and the investment required to close the most critical gaps. Set the expectation that this briefing will recur every quarter.
This is a starting point, not a destination. Resilience is a continuous capability that requires sustained investment, regular testing, and honest assessment. The 2026 breaches demonstrated what happens when that investment is deferred. The organizations that act now will be better positioned when — not if — the next incident occurs.
Sources: NDPA 2023, GAID 2025 directive, CBN CSAT framework, NDPC enforcement guidance, incident reporting from Technext24, Nairametrics, and Businessday.