Responding to Data Breaches in Nigeria Under the NDPA
Every Nigerian organisation that processes personal data will face a security incident at some point. A misconfigured cloud system, a compromised vendor, and an employee clicking a phishing link are not exceptional events. They are routine features of operating with digital data.
What the Nigeria Data Protection Act (NDPA) 2023 adds is a formal framework of obligations: timelines, notification requirements, documentation standards, and regulatory oversight. Having a breach response plan is no longer optional. What matters is whether that plan holds up when the Nigeria Data Protection Commission (NDPC) looks at it.
This guide explains what a personal data breach is under Nigerian law, what triggers notification obligations, what the NDPC expects from a response, and how organisations should prepare before an incident occurs.
It is the practical companion to the Data Protection Compliance Strategies guide: that article covers building a compliance program; this one covers what happens when something goes wrong inside it.
This article is part of PlanetWeb’s NDPA compliance series. (If you’re dealing with sector-specific regulatory follow-ups, see SNAG Process in Nigeria.) For the foundational framework, see the NDPA Compliance Guide for Nigerian Businesses and Key Features of the NDPA 2023.
For the regulator structure, see the Nigeria Data Regulators Guide.
What Counts as a Data Breach Under the NDPA
A security incident is any event that affects the confidentiality, integrity, or availability of personal data. A notifiable breach is a narrower category: one reasonably likely to result in harm to the individuals whose data is affected. The NDPA is concerned with harm to data subjects rather than unauthorised access alone, and treating every incident as if it clears that bar diverts resources from genuine response.
| Security Incident | Notifiable Breach | |
|---|---|---|
| Definition | Any event affecting confidentiality, integrity, or availability of data | An incident reasonably likely to cause harm to data subjects |
| Typical examples | A failed phishing attempt, a misdirected email, a lost encrypted laptop | Ransomware, an unencrypted database exposed, a vendor breach affecting customer records |
| NDPC notification | Not usually required | Required within 72 hours of awareness |
The NDPA defines a personal data breach as a breach of security leading to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data. That covers ransomware attacks, salary spreadsheets emailed to the wrong person, an exposed database with no access controls, and vendor systems compromised while holding customer data.
Sensitive personal data, including health records, financial data, biometric identifiers, and data about minors, generally carries a lower threshold for notification than general personal data. A breach affecting fifty medical records may require notification, whereas a breach affecting fifty names and email addresses may not.
What Triggers the 72-Hour Notification Requirement
Two separate notification obligations exist under the NDPA, and they operate independently.
Notifying the NDPC
The NDPA requires notification to the NDPC within 72 hours of becoming aware of a breach that is likely to result in a high risk to the rights and freedoms of data subjects. The operative phrase is “becoming aware”: the clock starts when someone with decision-making responsibility knows a breach has occurred, not when it is fully understood.
Organisations often delay notification while waiting for a complete forensic picture. That delay is legally precarious. If a breach is discovered Monday morning and the investigation is still running Thursday, the window has closed. The NDPA anticipates this: an initial notification is acceptable when the full scope is not yet known, and organisations can provide supplementary information in phases.
The 72-hour window runs continuously, including weekends and public holidays. A breach discovered Friday afternoon cannot wait until Monday.
When assessing high risk, the NDPC considers the volume of records affected, the sensitivity of the data, whether the data was encrypted, the probable intent behind the breach, whether harm has already materialised (such as fraudulent transactions), and the vulnerability of the affected individuals.
When NDPC Notification Is Not Required
Not every breach requires NDPC notification, and documenting the reasoning for not notifying is as important as the notification itself. An NDPC auditor will expect to see a documented assessment for every incident, including those that did not meet the threshold.
Notification may not be required if the data was encrypted and the key remains secure, if the breach is contained before any data is accessed, or if the incident involves only internal operational data with no third-party personal data. The standard is not whether a breach occurred in a technical sense, but whether it poses a real risk of harm to identifiable individuals.
Notifying Affected Individuals
Individual notification is a separate and higher obligation. It is required when the breach is likely to result in a high risk to the rights and freedoms of the individuals concerned: harm, financial loss, identity theft, or serious disruption to their lives must be genuinely probable.
Not every NDPC-notifiable breach requires individual notification. When it is required, it must be direct and in plain language. A general notice on a company website does not satisfy the obligation. The notification must explain what happened, what data was affected, what the organisation has done in response, what steps individuals should take, and provide a direct contact point for follow-up.
The Breach Register: The Obligation Most Organisations Miss
The NDPA requires every organisation to maintain an internal record of all personal data breaches, regardless of whether they triggered NDPC notification. This is one of the most consistently overlooked obligations in Nigerian compliance programs.
It’s exactly the kind of documentation the General Application and Implementation Directive (GAID), the audit framework that replaced the older NDPR in September 2025, expects an organisation to produce on request.
The register should document when the incident was discovered, the nature of the breach and data involved, the number of individuals affected, the likely cause, the harm risk assessment, actions taken, whether NDPC notification was made and when, and the outcome.
An organisation that has never notified the NDPC but has no register at all is in a weaker position than one that can demonstrate years of documented incident assessments, even where none met the notification threshold. The absence of a register signals that the compliance program is not functioning, regardless of breach history.
The register starts now, not when the next incident occurs.
Before a Breach Happens: What Preparation Requires
The Incident Response Plan
An incident response plan (IRP) needs to be specific enough to use under pressure. A document that lists “notify relevant stakeholders” as a step is not a plan.
The IRP should identify named individuals, rather than only job titles, for each response role. Pre-approved NDPC notification templates save valuable time during an active response.
It should set out escalation authority: who authorises NDPC notification, who briefs the board, who engages legal counsel, and who speaks externally. It should include pre-vetted contacts for forensic firms and legal advisors, and a decision log template so every judgment call during a response is recorded as it is made.
Who Needs to Be in the Room from the Start
Legal counsel should be engaged the moment a potential breach is identified. Engaging forensic investigators through legal counsel protects investigation findings from disclosure under privilege, which matters if the breach leads to litigation or a regulatory investigation.
The data protection officer or compliance lead should be the primary interface with the NDPC, not IT or communications. The guide to data protection officers in Nigeria covers what that role requires in more depth.
A single spokesperson for external communication should be designated before a breach occurs; conflicting statements from different parts of an organisation during an active incident are common and damaging.
Testing the Plan
Running a tabletop exercise at least once a year is worth the time it takes. One scenario worth running specifically: a vendor breach with no data processing agreement (DPA) in place, covered in full below.
That is the scenario most likely to generate compounded liability, and the one most Nigerian businesses are least prepared for. The NIST Computer Security Incident Handling Guide (SP 800-61) provides a widely referenced framework for structuring incident response exercises.
Staff communication protocols are also part of preparation, not only incident response. Employees who fill information gaps with speculation during an active breach, whether to clients, contacts, or on social media, can undermine both the legal position and the regulatory relationship.
Staff should know before an incident occurs that there is a designated spokesperson, that the incident is being handled, and that external communication is not their call to make.
The First 72 Hours
These four phases typically overlap rather than run in a strict sequence, but each has a distinct job:
| Phase | Priority |
|---|---|
| Immediately on discovery | Contain the incident and preserve evidence |
| Early hours | Assess scope and escalate internally |
| Before the 72-hour mark | Decide on NDPC notification and prepare it |
| After 72 hours | Remediate, update the breach register, run a post-incident review |
Contain Without Destroying Evidence
Isolating affected systems, disabling compromised accounts, changing credentials, and blocking suspicious access come first. Systems should not be wiped or reimaged before forensic investigators have cleared them; logs should be preserved and write-blocking enabled where possible. Evidence destroyed during containment can make it impossible to establish what happened, and it reflects poorly on regulators.
Assess Scope: Early Estimates Are Usually Wrong
Initial assessments consistently undercount affected records and individuals. A seemingly contained incident often expands when log analysis reveals lateral movement. Scope estimates should be formally reviewed before finalising any external communication.
Start the Notification Process Immediately
If there is any reasonable possibility that the breach meets the high-risk threshold, preparing the NDPC notification should begin before the forensic assessment is complete.
An initial notification acknowledging the breach and providing what is known, with a commitment to follow up as the investigation progresses, is the right approach. Waiting for certainty is the most common reason organisations miss the 72-hour window.
Vendor Breach Scenarios
When a vendor is breached and customer data is affected, the obligations still fall on the organisation that controls that data. The NDPA does not transfer accountability to the vendor. The NDPC will ask whether a data processing agreement was in place; its absence doesn’t reduce the notification obligation, but it does add a second compliance failure on top of the breach itself.
This is the same dynamic that played out in Sterling Bank’s January 2025 incident, where insiders reportedly colluded with external actors through a third-party system.
The Nigerian Data Breach Case Studies collection and the guide to insider threats in Nigeria cover vendor and insider risk in more depth.
Notifying the NDPC and Other Regulators
What the NDPC Notification Must Contain
A complete notification should cover the nature of the breach, the categories and approximate number of data subjects and records affected, the likely consequences, and the measures taken or proposed.
If full information is not available within 72 hours, it should include what is known and a realistic timeline for supplementary details. The guide to the Nigeria Data Protection Commission covers its notification requirements and enforcement powers in more depth.
Managing Simultaneous Notifications in Regulated Sectors
For regulated organisations, notification obligations stack. A fintech may need to notify both the NDPC and the Central Bank of Nigeria (CBN), with different information requirements and potentially different timelines. Healthcare organisations may have additional sector-specific NDPC obligations.
Notifications for each regulator should be prepared separately, with the timing of each documented independently; notifying one regulator should never be assumed to satisfy obligations to another. Criminal breaches should also be reported to the Economic and Financial Crimes Commission (EFCC).
What Happens After Notification, and What a Late One Costs
The NDPC may close the matter, request further information, or open an investigation. An organisation that notifies promptly, demonstrates a credible response, and can show a functioning compliance program prior to the breach is in a materially better position than one that notifies late and cannot produce a breach register. Documented good faith is a legitimate mitigating factor.
A missed 72-hour deadline doesn’t need to be treated as unrecoverable. Late notification tends to draw additional scrutiny, but it should still be made as soon as possible, with a clear explanation for the delay and evidence that the response was otherwise handled responsibly. Proactive engagement with the NDPC, even after the window has closed, is consistently treated better than silence.
In due diligence contexts, breach history is increasingly reviewed. Investors and acquirers now ask for breach registers, NDPC correspondence, and remediation documentation. An organisation that handled incidents transparently and improved its controls is viewed very differently from one that concealed or failed to document them.
Notifying Affected Individuals
When the individual notification threshold is met, the communication must be direct, plain, and actionable: what happened, what data was involved, what the organisation has done, what the individual should do, and who to contact. Corporate language that obscures accountability satisfies neither the legal obligation nor the individuals reading it.
When financial data is involved, offering practical remedies such as account monitoring guidance, a dedicated contact line, or fraud protection assistance is worth considering.
Cyber Insurance: What It Covers and What Voids a Claim
A well-structured cyber liability policy typically covers forensic investigation costs, legal fees from regulatory investigations or third-party claims, individual notification costs, and business interruption losses during recovery.
The IBM Cost of a Data Breach Report found that organisations with an incident response plan and team in place consistently incur lower breach costs than those without one, reinforcing the case for preparation over reaction.
Several factors can void or reduce a claim: delayed notification to the insurer, no documented IRP at the time of the breach, failure to patch known vulnerabilities cited in the policy application, and missing data processing agreements with vendors handling insured data.
The compliance work that protects against NDPC liability, a documented IRP, vendor DPAs, a breach register, and staff training records, also makes an insurance claim defensible.
Policy wording varies, and notification and cooperation clauses should be reviewed carefully before an incident occurs. Cyber insurers should be notified as soon as a breach is confirmed or suspected if the policy’s notification requirements are broad; waiting until the response is complete is a common and avoidable mistake.
After the Breach: Learning and Remediation
A formal post-incident review should produce a root cause analysis, an updated IRP, a revised training plan for any staff failures identified, and a board briefing for material incidents.
The review should also feed back into the compliance program itself: policies get updated to close the gap that was exploited, vendor contracts get revisited if a third party was involved, and whatever fix was put in place gets tested rather than assumed to work.
Many of the incidents that trigger this process start the same way: phishing, an unsecured API, or a stolen credential- patterns covered in more depth in the phishing attacks in Nigeria guide.
The NDPC may request evidence of remediation following a notified breach. An organisation that can demonstrate documented improvements is in a stronger position for any follow-up regulatory engagement than one that closed the incident without review.
How PlanetWeb Can Help
The breach register starts today. The IRP gets reviewed and tested before it’s needed. Vendor DPAs are in place before a third-party incident makes their absence a problem. Breach response under the NDPA is an extension of the compliance program an organisation is already building, not a separate exercise.
PlanetWeb works with Nigerian organisations to build and test breach response functions, from incident response plans to vendor agreements to the documentation the NDPC expects to see. If your business needs help getting this in place, get in touch.
