A support tool's credentials are found in a public repository. The GDPR's Article 33 gives 72 hours from becoming aware of a personal data breach to notify the supervisory authority, including the categories and approximate number of data subjects affected. Which capability decides whether you can answer in time?

What is being tested

Whether you recognise that the notification obligation is a question about scope, not about detection. The regulator does not ask whether you were attacked; it asks what was affected, for whom, and roughly how many. Answering that requires joining two things: what the compromised credential could reach, and what it actually touched.

The mechanism

The clock starts on awareness, and 72 hours is short enough that the answer has to come from systems rather than from investigation. The question decomposes into three:

1. What could that credential reach? An authorisation model you can query, plus a record of which stores hold which categories of personal data. Without the second half, you know the credential had access to support_db and not what that means for a data subject.
2. What did it actually touch? Access logs on the store itself, at a granularity that distinguishes a dashboard view from a bulk export. Application logs are usually not enough, because the compromised path may bypass the application.
3. How many people? A count by category, which is the inventory joined to the log.

The two halves are independently useless. Access logs with no inventory tell you which tables were read and nothing about who is affected. An inventory with no logs tells you the worst case and forces you to notify as if everything was taken, which is the honest but expensive answer and the one most organisations give.

Why the other options fail

• Long retention of monitoring events is valuable and answers a different question: how the attacker got in and what else they did. It supports the forensic narrative, which the regulator also wants, and it does not tell you the categories or the number of data subjects unless something else maps stores to personal data.
• Egress data-loss prevention is a preventive control, and a good one. After the fact it is a partial and noisy evidence source: it sees what crossed a monitored boundary, misses anything taken through a sanctioned channel, and still needs the inventory to interpret what the bytes were.
• Encryption at rest protects against physical media loss and almost nothing else here. A credential with application-level access reads decrypted data by design. It can reduce the notification obligation in a stolen-disk scenario, which is exactly why people over-claim it, and it does not help when the key was used legitimately.

When this is the wrong answer

If the architecture genuinely cannot answer the scope question and the breach is real, do not spend the 72 hours building the capability. Notify on the basis of the maximum plausible scope, say explicitly that the assessment is provisional, and use Article 33's provision for supplying information in phases. The regulator is far more tolerant of a provisional notification that is later refined than of a late one.

Common weak answers

• "We would investigate and then notify." The clock does not pause for an investigation, and an organisation that plans to investigate first is planning to be late.
• "Our logs would show it." Logs without a data inventory produce a list of table names, which is not a notification. The join is the capability.
• "We encrypt everything." Encryption answers a question about media, not about an authorised credential used by the wrong person.