In one sentence
The Audit Log Access page records every time someone in your organization loads the audit trail or a per-record history — actor, timestamp, what they were looking at, how many rows they saw — so when an inspector asks "who has been reading the audit logs?" the answer is on screen, not a shrug.
- It's the audit of the audit. Every time the auth-activity page, a record-history tab, the document-downloads viewer, or this page itself is loaded, an entry is written here.
- Recursive on purpose. Opening this page logs an entry recording that you opened it. An admin reading the logs can't read them invisibly.
- Admin-only. Reading is gated on the Access audit admin permission. The default Admin role has it; Standard User doesn't.
Question-bank events live here too
A note up-front: edits to the audit question bank now flow into the same activity feed that powers this page (and every other module's audit trail). What used to live in a separate question-only changelog is now in one timeline alongside every other module's history — so an admin reviewing "who touched the audit content?" doesn't have to open a separate page for question-bank changes.
This means a question-bank edit and an NCR status change might appear in the same inspector's view, depending on what filter you apply. The unification is intentional — one trail, one place to look.
What gets recorded
An entry is written every time anyone loads one of the inspection surfaces. The view types you'll see:
| View type | When it's recorded |
|---|---|
| Auth activity (global trail) | A user opened /admin/organization/auth-activity — the org-wide auth-events feed |
| Record history | A user expanded the History tab on a record's detail page, or opened its print-history page |
| Row-change feed | An admin tool queried the underlying field-change feed directly |
| Audit-log access viewer | A user loaded this page (yes, it tracks views of itself) |
| Document downloads | An admin loaded /admin/documents/downloads |
The list is intentionally inclusive — anywhere someone could pull regulated-record history from, a read event is recorded here so the answer to "who looked at this?" is data, not memory.
What each column means
The viewer shows the most recent 200 events, newest-first.
| Column | What it carries |
|---|---|
| When | Date and time of the view, in the reader's local timezone |
| Who | Actor's name and role at the time of the view. Identity is snapshotted at write time so deleting the user later doesn't erase the trail. |
| View | One of the view-type labels above |
| Target | For record-history views, the table + first 8 chars of the record ID. For trail-wide views, blank |
| Results | Number of rows the viewer was shown (so an inspector can tell page-of-20 from download-the-lot) |
Why this matters — 21 CFR §11 framing
Part 11 §11.10(e) calls for a secure, computer-generated audit trail that records the creation, modification, and deletion of regulated records. An inspector reading those audit logs is themselves an event of interest — knowing who has been reviewing the audit trail (your QA lead? a customer auditor? an unexpected name?) is part of an open system posture under §11.30.
This page is the record of those reads. It's not a regulatory requirement on its own, but most inspectors accept it as inspection-grade evidence that you're managing access to the audit trail, not just to the records the trail describes.
You don't need to do anything to maintain the page — every load of an audit surface writes an entry automatically.
Who can read this page
The page is gated on the Access audit admin permission. The default Admin role has it. The Standard User role does not. If you've built a custom role that gates regulatory review, grant Access audit admin on that role so the reviewer can open this page. See Roles & permissions.
What it doesn't capture
- Reads that don't go through an audit surface. Direct database access from outside the application bypasses the read-logging. Every customer-initiated read path inside the application logs; system jobs (scheduled tasks, integration callbacks) don't, since "who" wouldn't have a meaningful value.
- Searches that returned zero results. Each load is captured regardless of how many results it returned, but a search that errored before the log entry is written isn't recorded. Errors are rare; if you suspect a missing entry, check the application logs.
- The contents of what was viewed. This is an access log, not a snapshot. The viewed data lives in the audit-trail tables themselves and is unchanged by the read.
Related
- Record history — the per-record History tab whose loads are tracked here
- Auth activity — the narrow feed of auth events; loads of that page also land here
- Document downloads — the per-document access trail
- Trash and Soft-delete — where deleted records live and how restore works
- Signature manifestation — the §11.50 manifest on document exports
- Auth & sign-in policy
- Roles & permissions