Breach Response

A breach, in the sense this course uses, is a security failure that destroys, loses, alters, or discloses personal data without authority. The engineers will patch the hole. You will build the record and decide who must be told.

The curriculum’s picture of the split is simple. Engineering closes the gap in the server. Legal writes down when the company knew, what left, and whether a notification clock has started.

The first hours

If the call is that a bucket was opened and passwords and email addresses are on the internet, three moves come before a press statement.

Isolate and write. Ask for a root-cause account: how entry happened. Start a log with times, not adjectives. Who knew, at what hour, what systems, what data.

Decide if this is the kind of incident that must be notified. Not every glitch is a public event. Unencrypted passwords and financial data are the sort of harm the course treats as the high-risk end. A failed job that exposed nothing may not be. The judgement is fact-specific. This lesson does not make it for you.

Watch the clock. The source material describes a practice, under Nigerian data-protection rules, of notifying the NDPC within about 72 hours of becoming aware of a high-risk breach. Treat “typically 72 hours” as the course’s warning, not as a paraphrase you should paste into a filing without reading the current rule. Missing the window can be its own problem, separate from the breach.

Say, in the log, whether the exposed passwords were hashed. Lesson 2.5 is why that adjective matters.