The Record Read Log
Changes are only half of what happens to data. The record read log records who has looked.
Where to find it
Architect Panel → Activity:
- Record Read Log — the reads themselves
- Activity Log — changes, kept separately
What a read entry holds
- Datastore — what was read.
- Record IDs and a row count — which records, and how many.
- Context — the kind of access it was.
- Identity — method, unique ID and domain, as with changes.
- IP address and timestamp.
Why it is separate
Volume, mostly. A system generates far more reads than writes, and mixing them would bury every change in a haystack of routine lookups. Keeping them apart means the change log stays readable and the read log can be retained on its own terms.
They also answer different questions. Changes answer "how did this get like this". Reads answer "who has seen this" — which is the question that arises in data protection, in HR matters, and any time information about a person has evidently travelled further than it should.
Row counts matter as much as row IDs
An entry recording that one record was read is routine. An entry recording that eleven thousand were read in one operation is a different event entirely, and it is the shape that indicates bulk extraction rather than somebody doing their job.
When reviewing, sort by row count before reading chronologically. The interesting entries are rarely the typical ones.
Context tells you how
The same record read on screen, returned by an API call, or included in an export are different events with different risk. The context field is what separates them, and it is what turns "this account read the customer table" into a statement you can act on.
Read logging is a decision
Logging reads has a cost in volume, so it is applied where it is warranted rather than universally. Turn it on for the datastores holding information about people, or anything where "who has seen this" is a question you might have to answer to somebody else.
Turning it on for everything produces a log nobody reviews, which provides the storage cost of assurance without the assurance.
Tell people it is on
Read logging is much more effective as a known control than as a hidden one — most inappropriate access is casual curiosity, and casual curiosity stops when people know access is recorded. It also belongs in your privacy notice: you are processing data about your staff's activity.
Worked example
A council enables read logging on its resident records. A monthly review sorted by row count shows the usual pattern of single-record lookups, and one entry where an account read 4,000 records through an export in a single afternoon. It turns out to be a legitimate mailing extract that nobody had told the data protection officer about — which is a process problem found in five minutes rather than a breach found by a regulator.
Recommendations
- Enable it on personal data, not on everything.
- Review by row count first, then by time.
- Tell staff it is enabled — the deterrent is most of the value.
- Cover it in your privacy notice.