If you run a bank, a fintech, a lender, or any business that holds customer data in Nigeria, 2026 has given you a steady drip of bad headlines. The useful question is not which institution was hit last. It is what these incidents have in common, because the answer tells you exactly where to spend your next naira of security effort.
What actually happened
Over a few weeks in early 2026, a single attacker known as ByteToBreach moved through Sterling Bank, the payments platform Remita, and the Corporate Affairs Commission (CAC). The breaches are not in dispute: Nigeria's Data Protection Commission opened an investigation into Remita, Sterling, and others, and the CAC publicly confirmed an incident and asked users to update their login credentials. Separately, in August, Zenith Bank confirmed a breach that exposed customer email addresses and phone numbers, while stating that no banking information was affected.
The scale is harder to pin down. The attacker claimed to have taken data on roughly 900,000 Sterling customers and around 25 million CAC documents. The institutions said little, and the CAC described its incident as "unauthorised access to limited aspects." So treat the headline numbers as claims rather than confirmed figures. The pattern underneath them, though, is clear enough to act on, and that is what should concern you.
The uncomfortable part: these were preventable
None of this required a sophisticated adversary. According to analyses of the incidents, the openings were ordinary hygiene failures that would show up in any honest audit:
- Production credentials stored in plain text inside a code repository, which turned access to one system into a key for the next.
- A cloud storage bucket left misconfigured and reachable.
- User records that could be stepped through one by one, with sequential IDs and no authentication challenge in the way.
- An internet-facing server left unpatched for months.
Read that list again. There is no zero-day, no nation-state, no clever social engineering. These are the security equivalent of leaving a labelled key hanging by the door. The reason that should give you confidence, not despair, is simple: if the way in was basic, the way to close it is basic too. You do not need to outspend an attacker. You need to stop handing them the easy routes.
What to audit first
Hand this list to your team and ask for evidence, not reassurance. For each item, the right answer is a demonstration, not a "yes, we are fine."
- Secrets. Are any credentials, API keys, or tokens sitting in your code repositories, config files, or chat history? Rotate anything exposed and move secrets into a managed vault.
- Cloud configuration. Is every storage bucket, database, and admin console private by default? Scan for anything publicly reachable, and check it continuously, not once.
- Access control. Can a request reach customer records without authentication? Are user IDs guessable in sequence? Is anyone holding admin rights they no longer need?
- Exposed surfaces. What of yours is reachable from the public internet, including test and pilot servers, and is all of it patched and accounted for? Forgotten systems are where attackers live.
- Detection. If someone spent nine days inside your systems, would you know? Make sure access is logged and that unusual activity actually raises an alert someone sees.
- Data minimisation. Are you storing sensitive data, like BVNs or identity documents, that you do not strictly need? Data you never collected cannot be stolen.
- Incident response. Do you have a written plan for the first 24 hours, including who decides what to tell customers and the regulator?
If you cannot get a confident, evidenced answer on each of these, you have found your priorities for the quarter.
Why this is now a board-level question
Two things have changed the stakes. First, the regulator is active: the Data Protection Commission is investigating, and silence after a breach is no longer a safe option. Second, the compliance calendar is converging. The data-localisation rules and the Sovereign Cloud mandate both land on 1 January 2027, and both are, at heart, about keeping customer data protected and accountable. A breach is no longer only a reputational problem. It is a compliance problem with a deadline attached.
The organisations that come through this well will not be the ones with the biggest security budget. They will be the ones who treated the boring checklist as urgent, found their own exposed keys before someone else did, and could prove it.
If you want an honest, outside read on where your exposed gaps are, a technical audit is a low-risk place to start. The first conversation is a free, no-pressure 45-minute structured call: start the conversation.
Sources: reporting on the 2026 Sterling Bank, Remita, and CAC incidents (Nairametrics, Technext24, TheCable, FIJ) and the NDPC investigation; Zenith Bank's confirmed August 2026 breach (Techeconomy). Scale figures are attacker claims relayed by media and are treated as unconfirmed.
