Use this incident decision log
Open a record as soon as the team learns of a suspected personal-data breach. Keep event time and discovery time separate. Add data fields, systems, recipients, containment action, and the source of each fact. Update uncertain facts without erasing earlier versions.
| Item | Check or owner | Evidence |
|---|---|---|
| Discovery | When did the team first know? | Timestamp and reporter |
| Data | Whose information was involved? | Categories and estimated scope |
| Containment | What stopped further access? | Change and time |
| Decision | Who assessed reporting? | Legal basis and signed record |
Apply the evidence map
Give the privacy lead a short decision log that links the facts to the Nigeria Data Protection Act and current NDPC guidance. Record who assessed notice, when they decided, and what new facts would change that decision. Keep customer messages tied to the same event ID.
Evidence to keep
The timeline should separate technical certainty from notice decisions. A responder may know an export went to the wrong address while still checking whether it contained personal data. Record both facts and the question still open. Use a restricted field for recipient identity and a broad field for incident status. When facts change, add a dated correction rather than overwriting the old entry. A later reviewer can then see what the team knew when it made each decision and whether new facts called for a fresh assessment.
Record the clock and decision
Synthetic case: an attacker reads a support export containing customer names and account numbers. Record when the system first logged the export, when the team found it, and when the controller became aware of a personal-data breach. Preserve those as separate times. Add the categories and number of people affected if known, the likely harm, containment steps, and the person who made the reporting decision. Do not wait for every detail before opening the record.
Section 40 of the NDP Act sets conditions and timing for notifying the Commission and affected people. The controller must assess the likely risk to rights and freedoms; not every security alert is a reportable personal-data breach. If notification is required, record what was sent and when. If it is not, keep the risk reasoning and later facts that could change it. A processor should record when it told its controller and what facts it supplied.
Track each notification duty
Section 40 of the NDP Act sets separate duties. A processor notifies the controller or processor that engaged it on becoming aware of the breach. A controller notifies NDPC within 72 hours of awareness when the breach is likely to risk individuals’ rights and freedoms. A likely high-risk breach requires immediate communication to affected people under Section 40(3). Section 40(9) allows information in phases without undue delay.
Keep separate fields for processor awareness, controller awareness, NDPC due time, risk decision, people-notice decision, sent time, and next update. In a synthetic case, controller awareness at 10:15 on 1 October gives a 72-hour deadline of 10:15 on 4 October in the same recorded time zone. That deadline does not postpone an immediate notice duty. Record the contact, consequences, safeguards, containment, unknowns, and proof of sending.
GAID Article 33 adds notification guidance, including immediate information where it helps containment. The privacy lead must record how both the Act and the directive apply. Keep breach facts, effects, and remedial actions even when a notification threshold is not met.