72 Hours After a Breach: Six Questions Your Database Must Answer

The clock starts the moment a data breach is noticed. The notification to the data protection authority has to state which data, how many people and which time range the breach affected. Most of that information sits in the database, and at that very moment it is the hardest to find. This article covers the six answers the database team will be asked for in the first days of a breach, which record each answer comes from, and why those records must be in place before the breach.

This article is not legal advice; ask your legal team about the scope of the notification duty.

What the 72 Hours Cover

Under the EU General Data Protection Regulation (GDPR), Article 33, the controller notifies the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of a breach; where the full information is not available yet, it can be provided in phases. In Turkey, decision 2019/10 of the Personal Data Protection Board, dated 24 January 2019, sets the same 72 hour limit for notifying the Board and asks for affected people to be told within the shortest reasonable time.

In practice this means the first notification is built from the records the team already has. Where there is no record, the notification says "unknown", and "unknown" forces the widest assumption: the whole table, everyone in it, the whole period.

Six Questions on the Database Side

1. Which data? Which tables and which columns were read or taken out?
2. How many people? How many distinct people's data was affected?
3. When? When was the first access, and the last?
4. With which account, from where? Which login, which machine, which application?
5. Is there a copy? Was the data exported to a file or another system, and if so where?
6. What was done? Was the account disabled, the permission revoked, the passwords changed?

Where Each Answer Lives

The weakest row in the table is "is there a copy". A database audit tells you who ran which query; it does not tell you whether the result was saved to a spreadsheet or emailed on. That question has an answer only if extracting data goes through a recorded path.

How to Count the People Affected

The number asked for is not the row count but the number of people. The sound way is this: take the text of the unauthorised query from the audit record, restore the database to the moment of the event (point in time restore in the full recovery model), and count the same query on that copy by the person key:

-- On a copy restored to the time of the event, never on production:
SELECT COUNT(DISTINCT c.CustomerId) AS PeopleAffected
FROM dbo.Customer AS c
WHERE c.City = N'Izmir';        -- the WHERE clause copied from the audited statement

Restoring to the moment of the event matters: a count taken on today's data is wrong because of people added or removed after the event. Without the query text, all you can give is the total number of people in the table that was accessed, which is the widest assumption.

What to Set Up Before a Breach

1. An inventory of sensitive columns. You cannot choose which tables to audit without knowing where personal data sits.
2. Read auditing on sensitive tables. SELECT recording on those tables with SQL Server Audit, and the files moved into the SIEM. This specification is added to an existing server audit (named ChangeTrail in the example; its setup is in this article):

   CREATE DATABASE AUDIT SPECIFICATION SensitiveReads
     FOR SERVER AUDIT ChangeTrail
     ADD (SELECT ON dbo.Customer BY public),
     ADD (SELECT ON dbo.CustomerAddress BY public)
     WITH (STATE = ON);

3. Login and permission change auditing at server level.
4. Retention. Breaches are often noticed weeks later; a few days of records are not enough.
5. One recorded path for extracting data. "Run this query and send me the result" requests going through a recorded process.
6. A rehearsal. Try answering the six questions with a test scenario while there is no breach, and measure how many hours it takes.

SQL Change Guard covers the fifth item, only for data requests opened through it. For those requests the record holds which query ran on which server, which columns were masked and which went out in the clear with a reason, the address the result was delivered to, the file's digest, who downloaded the file and for what stated reason, and when the file was deleted. The "Query Result Activity" and "Data Access and Export Log" reports give this as one list for a period. A read made outside the product, directly with a database tool, is not seen by the product; for that path the audit records above are needed.

Frequently Asked Questions

When do the 72 hours start?

They start when the controller becomes aware of the breach, not when the breach happened. That is why "when it became known" must be recorded too; it is the first line of the breach record.

What do we write if there is no audit record?

The unknown field is written as unknown and the impact is assumed at its widest: every reachable table and every person. If a record turns up later, the notification is updated. No record is invented, and an estimate is not presented as a fact.

Does masked data that went out count as a breach?

That is a legal assessment. The technical side's job is to show precisely which columns went out masked and which in the clear; the assessment is made with that information. That is why a column level decision record matters.

Should read auditing be on for every table?

No. Recording SELECT on every table produces serious volume. Limit it to tables holding personal and special category data; that is why the sensitive column inventory is the first step.