A customer data breach is not a problem to hide until your IT team finishes its investigation. For a Nigerian business, the priority is to contain the exposure, preserve evidence, assess possible harm, and determine whether the Nigeria Data Protection Commission (NDPC) and affected customers must be notified. Under section 40 of the Nigeria Data Protection Act (NDPA) 2023, controllers must notify the NDPC within 72 hours of becoming aware of a personal-data breach likely to risk individuals' rights and freedoms. Where there is high risk, the business must also communicate immediately with affected people.
Not every failed login or malicious email is a reportable personal-data breach. And the clock is not an automatic 72-hour grace period for every incident. This guide explains the distinction and gives shop owners, schools, clinics, hotels, online merchants and software companies an actionable response sequence.
Research checked: 2 November 2026. General editorial guidance, not incident-specific legal advice. If an incident is happening now, involve qualified cybersecurity and Nigerian data-protection advisers promptly.
First, establish whether personal data may have been breached
A security incident might involve an attempted attack that was blocked. A personal-data breach concerns personal information subject to accidental or unlawful destruction, loss, alteration, unauthorised disclosure or access. Examples include an employee emailing a customer spreadsheet to the wrong recipient, a public cloud storage folder containing identity documents, ransomware that exposes payroll files, and stolen account credentials that permit access to customer profiles.
Personal information can include names combined with phone numbers, addresses, purchase histories, government identifiers, credentials, medical details and financial records. Paper records matter too: a lost file of customer application forms can be a breach even where no hacker was involved.
At discovery, do not require proof that criminals have already sold or misused the data. Establish what is known, what is suspected and what remains unverified. Treat uncertain exposure as a live investigative question, not evidence that no breach occurred.
The first 72 hours: a practical response plan
| Time | Priority actions | Lead |
|---|---|---|
| Immediately | Raise incident alert, protect people and services, isolate relevant access, preserve evidence, record time of awareness | Incident lead and IT/security |
| First 4 hours (suggested) | Identify affected systems and data, assess initial risk, notify engaging controller if acting as processor | Security, operations, privacy lead |
| Hours 4–24 (suggested) | Continue forensic assessment, take protective measures, decide whether high-risk customer notices are required; make them immediately once the legal test is met | Controller, DPO, counsel |
| Before hour 72 where triggered | Submit NDPC notification for breaches likely to risk individuals; send available verified facts even if the investigation remains incomplete | Controller and authorised representative |
| Following days and weeks | Supplement notifications, restore safely, monitor misuse, document root cause, test corrective controls | Response team and management |
These internal time bands are operational suggestions, not additional statutory deadlines. The NDPA's reporting clock is based on awareness of the qualifying breach, and the high-risk notification duty to individuals is immediate. A serious public-impact incident may warrant urgent engagement with the NDPC and other relevant authorities earlier than 72 hours.
Step 1: Activate your incident team and establish a timeline
Appoint one accountable incident commander. Bring together the relevant technical team, operations, management, customer support, the data protection officer where applicable, and legal advisers. If the business has no specialist team, appoint an owner who can coordinate a reputable external incident-response provider.
Write down when the first alert arrived, who saw it, what evidence supports it, when the organisation became aware of the breach, and every decision taken. Record times with timezone information. This is essential for reconstructing the sequence and demonstrating when the 72-hour period began.
Centralise communications in a restricted incident channel; avoid circulating spreadsheets containing exposed personal details through ordinary group chats. Use a single version of the incident log so staff do not work from conflicting facts.
Step 2: Contain the breach without destroying evidence
Containment means stopping ongoing exposure, not wiping everything immediately. Depending on the incident, restrict a compromised account, revoke leaked API tokens, remove a publicly accessible file, disable exposed integrations or isolate an infected device from the network. Protect unaffected services and ensure decisions about critical operations are coordinated.
Preserve logs, system snapshots, alerts and relevant communications before they are overwritten. Forensic specialists may need volatile memory and other evidence that a reboot or aggressive cleanup could erase. Do not publish discovered passwords, personal records or attacker material in your investigation report.
The US Federal Trade Commission's business breach-response guidance emphasises securing operations and preserving evidence; the NIST incident-response recommendations, revised in 2025 , offer a useful technical structure. These are operational references, not substitutes for Nigeria's law.
If the breach involves a third-party payment platform, hosting provider, booking system, CRM or outsourced payroll company, urgently contact the vendor's security team and obtain its incident timeline, affected datasets, containment evidence and escalation contact.
Step 3: Identify the affected people, data and risk
A credible assessment should determine the categories of information, approximate numbers of people and records, exposure period, likely recipients, whether the data was encrypted, and how an unauthorised person could misuse it. Separate confirmed facts from estimates. Record any uncertainty expressly.
Do not confuse one million database rows with one million unique customers. Equally, do not assume a small breach is harmless: one exposed record containing financial credentials or sensitive health information may create serious risk.
Consider consequences such as account takeover, identity theft, targeted fraud, phishing, unwanted disclosure, discrimination, physical harm or loss of confidentiality. The NDPA directs attention to the nature, scope and sensitivity of the data; the likely effectiveness of encryption or other protections; and subsequent mitigation measures. These factors help determine the level of risk, not whether the business is embarrassed by publicity.
A simple risk record should capture: affected dataset, data-subject category, access circumstances, likely harm, mitigating controls, residual risk and who approved the assessment.
Step 4: Decide who needs notification—and when
Section 40 makes different demands on processors, controllers and breaches with different risk profiles. The correct response is not to notify everybody automatically, nor to keep silent until every detail has been proved.
| Situation | Core NDPA obligation |
|---|---|
| Processor discovers a personal-data breach in records handled for a client | Notify the engaging controller or processor on awareness and provide required information and cooperation (section 40(1)) |
| Controller becomes aware of a breach likely to risk individuals' rights and freedoms | Notify the NDPC within 72 hours of awareness (section 40(2)) |
| Controller becomes aware of a breach likely to create high risk for affected individuals | Communicate immediately with affected individuals in clear language and offer protective advice (section 40(3)) |
| Personal-data breach not meeting a regulatory notification threshold | Maintain a breach record including facts, effects and remedial action (section 40(8)); reassess if facts change |
The full text of section 40 also allows information to be supplied in phases without undue delay where it cannot be provided all at once. An incomplete investigation is therefore not, by itself, a reason to miss the required deadline.
Businesses should not confuse this with NDPC registration. An enterprise that is not required to register as a data controller or processor of major importance may still be subject to breach-response duties under the Act. FlyingEze's separate registration guide addresses the different question of when formal NDPC registration is necessary.
Step 5: Prepare and submit the NDPC breach report
Use the Commission's official NDPC Data Breach reporting portal , beginning from its government website or verified service page. Check the live channel and any supporting requirements at the time of reporting rather than relying on an unofficial intermediary.
Prepare a regulator-facing summary containing:
- Organisation name, responsible contact person and secure contact details.
- Incident discovery and awareness dates, with timezones, and the known or estimated exposure window.
- What happened, how it was discovered, and which systems or suppliers are implicated.
- Categories and approximate counts of affected individuals and personal-data records, where feasible.
- Likely consequences for people and the reasoning behind the risk assessment.
- Containment completed, remedial actions planned and measures available to reduce harm.
- Status of affected-person communications and the intended timing of updates.
- Information still unknown and a plan for supplementary submissions.
Under section 40(4), the notifications must include an appropriate point of contact, likely consequences and action taken or planned to mitigate adverse effects. Preserve the submission receipt, reference number, submitted text and timestamps.
Never invent exact exposure numbers, claim a system is safe before verification, or wait past a binding deadline for a polished final forensic report. If the risk threshold is met but figures remain uncertain, make that clear and supplement the report as verified information emerges.
Step 6: Tell affected customers clearly when high risk is likely
Where a personal-data breach is likely to cause high risk to individuals, section 40(3) requires the controller to communicate the breach to them immediately, using plain, clear language and explaining practical mitigation steps. When direct contact would be disproportionate, expensive or otherwise infeasible, the Act provides for appropriate public communication through widely used media likely to reach the individuals.
Useful customer notices answer six questions: What happened? What information may be involved? When did it happen? What have you done? What should the customer do? How can they contact your organisation?
Illustrative customer notice: We are investigating unauthorised access to a system containing some customer information. Our current assessment indicates that [describe verified data categories] may have been involved. We have restricted the affected access and are working with specialists to confirm the scope. Please be cautious of unexpected messages claiming to represent our business, and do not share passwords or one-time codes. We will provide further verified updates through our official channels. For assistance, contact [verified company contact].
Use placeholders only until your own verified facts and channels are available; the example is not a statement about an actual incident. Avoid promises such as "no financial data was accessed" unless the investigation supports them. If account credentials were exposed, advise relevant customers to change passwords through a trusted app or typed website address and review account activity. Where appropriate, provide dedicated support for vulnerable customers.
Step 7: Handle third parties, contracts and law enforcement responsibly
Many breaches involve cloud tools, contractors, external software, payment processors or outsourced services. A controller should not assume a vendor's incident notice completes its own regulatory assessment. Request the affected systems and data categories, the number of impacted customers, technical evidence of containment, and a trustworthy schedule for updates.
For organisations acting as processors, promptly notify the engaging organisation and cooperate. Contractual obligations may require an even earlier alert than the statutory framework; check the agreement rather than waiting until 72 hours.
Depending on the facts, other regulatory, sectoral, contractual or criminal-reporting duties may apply. Banks, healthcare providers, telecom operators and public agencies should consult their sector rules. If there is extortion, fraud or an active crime, seek appropriate professional advice about law-enforcement involvement and preserve evidence carefully.
Step 8: Restore operations safely, then monitor for repeat attacks
Recovery should take place after the entry point and persistence mechanisms have been investigated, not merely because a website or app can be restarted. Rebuild affected systems from trusted sources, rotate compromised credentials, inspect connected integrations, validate backups, patch verified vulnerabilities and test access permissions.
For a small Nigerian merchant this could mean disabling a stolen administrator account and verifying whether order records were exported. A hotel may need to review access to guest identity documents and booking exports. A school must consider whether children's information has been disclosed and how families should be contacted. Each scenario requires its own risk assessment.
Monitor for suspicious logins, account abuse, fraudulent customer contact and new evidence of exfiltration. If the investigation expands, update the breach record and revisit notifications. A premature statement that the matter is closed can damage trust when fresh facts emerge.
The FlyingEze coverage of the NDPC's investigation into an alleged CAC breach illustrates the importance of regulatory scrutiny; an investigation or allegation is not proof that the organisation violated the law. FlyingEze has also reported on the NDPC's investigation involving allegations about the handling of Temu users' information .
A breach-response checklist you can use in your business
- Record the first alert, incident awareness time and responsible decision-maker.
- Contain exposed systems or access while preserving relevant forensic evidence.
- Identify the controller, processors, service providers and affected systems.
- List affected data types, estimated distinct people and records, and exposure duration.
- Document the risks, likely harm and safeguards such as encryption.
- Decide whether NDPC reporting within 72 hours is triggered and identify the deadline.
- Decide separately whether individuals face high risk and must be told immediately.
- Use verified official channels, retain receipts and send phased updates if necessary.
- Provide practical customer protection advice and support contact details.
- Keep the mandatory breach record, even if no regulatory notice is required.
- Validate recovery, test fixes, update access controls and reassess after new findings.
- Conduct a lessons-learned review and assign dates and owners to each corrective action.
A spreadsheet or incident register is sufficient for a small business if it is secure, restricted to authorised staff and consistently maintained. Larger organisations may use ticketing and governance software, but no product substitutes for competent legal judgments, accurate records and tested response processes.
Five mistakes that make a customer breach worse
Waiting for full certainty before starting the notification assessment
The investigation and the reporting decision should advance together. Record what is known and fill gaps without treating uncertainty as permission to ignore a deadline.
Deleting logs or rebuilding everything immediately
Rapid cleaning can erase the only evidence of how the attacker entered or which data was accessed. Containment and preservation must be coordinated.
Confusing all security alerts with reportable breaches
The law has a risk-based test. Apply it carefully and keep records. A blocked phishing email is not automatically a customer-data breach.
Making reassurances you cannot substantiate
Statements such as "all customer data is safe" should only be made after the evidence supports them. People need reliable facts and practical steps, not marketing language.
Assuming an NDPC registration certificate solves incident obligations
Registration, security, breach reporting and individual rights are separate responsibilities. Compliance must work in daily business operations.
After the crisis: build a response plan before the next incident
Within the following month, review what failed and convert the findings into control improvements. Establish incident severity criteria, responsible contacts, escalation paths, supplier notice clauses, backup recovery tests, security awareness training and a working log retention policy. Conduct at least one tabletop exercise covering a realistic incident: for example, a compromised online store account or a publicly exposed guest-list export.
Review privacy notices, data retention and staff access. Remove personal information that has no valid business or legal retention purpose. For customer-facing software, ensure the organisation knows who owns incident communication and how it can isolate integrations without inadvertently deleting evidence.
The NDPC-focused report on cyberattack concerns at government institutions is useful background on why preventive skills and governance matter. However, the strongest practical lesson for a business is to make its own controls measurable and tested.
Frequently asked questions
Must every Nigerian business report every cyberattack to the NDPC?
No. Section 40(2)'s 72-hour regulatory notification rule applies when a data controller is aware of a personal-data breach likely to risk individuals' rights and freedoms. Every personal-data breach still needs an internal record, and other laws or contractual duties may apply.
Does the 72-hour period begin when the forensic report is completed?
No. The Act uses awareness of the qualifying breach, not completion of a forensic report. Record the awareness timeline carefully and use phased reporting if the necessary details are not all available together.
Must customers be notified at the same time as the NDPC?
The tests are different. A qualifying risk requires reporting to the NDPC within 72 hours; a likely high risk to affected individuals triggers immediate communication to them. The duties can operate in parallel.
Does a vendor breach remove my business's obligations?
Not necessarily. A processor must alert the engaging controller or processor, while the controller must evaluate its own duties. Review both the Act and relevant contracts.
What if only one customer was affected?
Do not use an arbitrary minimum count. One person's exposed sensitive information can create serious risks. Assess consequences, safeguards and the statutory thresholds.
Conclusion
When customer information is exposed, the responsible approach is to contain, preserve, assess, notify where required and recover safely. Nigerian law makes the distinction between an ordinary security alert, a personal-data breach likely to risk individuals, and a high-risk breach especially important. Start the incident record immediately, involve the correct people, communicate verified facts and take deadlines seriously.
The best time to prepare a data breach plan is before the breach. The second-best time is the moment you discover one.
