In one sentence
The File access log is the record of who has been pulling controlled files out of QFormance — every view, download, print preview, and AI-agent access of an external document, and every download of NCR, action, or audit evidence, with the SHA256 the user actually received so you can prove the bytes delivered matched the approved version.
- Every access is logged. Opening the detail page, downloading the file, generating a print preview, or letting Ask the Library reference the file all write a row here.
- The file hash travels with each access. SHA256 of the bytes delivered is captured at access time, so an inspector can correlate the served copy to the hash recorded on the approved version of the document.
- Admin-only. Reading the page is gated on the Access audit admin permission.
The title and the URL disagree, on purpose
The page started as a document-only viewer and still lives at /admin/documents/downloads. Now that it covers evidence files from other modules, the page title and the Documents-admin hub link read File Access Log — but the URL deliberately did not move, because changing it would break bookmarks and existing links for no audit benefit. If you have the old path bookmarked, it still goes to the right place.
What kinds of file are covered
Four record types share the log, each badged in its own Type column:
| Type | What it covers |
|---|---|
| Document | An external (file-backed) controlled document |
| NCR | Evidence attached to a non-conformance report |
| Action | Evidence attached to an NCR action — closure or verification files |
| Audit | Evidence attached to an audit |
They're one log rather than four because the event is identical in every module: someone was handed a controlled file. An inspector asking "who pulled this?" shouldn't have to know which page to ask.
What gets recorded
Every file access writes a row, tagged with one of four contexts:
| Context | What triggers it |
|---|---|
| Page view | Someone opened the document detail page in the dashboard |
| Download | Someone clicked Download, or a signed URL was minted for the file |
| Print preview | Someone opened the print-friendly view (typically before saving as PDF) |
| AI agent access | Ask the Library, the document agent, or another AI feature referenced the file's content while answering a user prompt |
The four contexts carry colored badges in the table so an admin scanning the page can distinguish reading from exfiltrating at a glance. Evidence files are reached by download link rather than by an in-app viewer, so NCR, action, and audit rows carry the Download context.
What each column means
The viewer shows the most recent 200 access events, newest-first.
| Column | What it carries |
|---|---|
| When | Date and time of the access |
| Who | Actor's name and role at the time. Snapshotted at write so deleting the user later doesn't erase the trail. |
| Type | Which kind of record the file hangs off — Document, NCR, Action, or Audit |
| Record | The record's number and title, linking to it. (deleted) if the record has been removed since, because the access itself is still the audit fact. |
| Context | One of the four context badges above |
| File hash | First 12 characters of the SHA256 of the served bytes (full hash is in the database). Captured for documents; evidence-file rows show a dash. |
File hash and content integrity
QFormance computes a SHA256 of every external document's bytes at the moment of approval, storing it alongside the document and the matching version snapshot. Every download / print / view re-captures the hash of what was actually served and records it on this page.
The pair of hashes lets an inspector answer the highest-stakes audit-trail question: "is the copy this person pulled the same one that was approved?" If the served hash matches the approved-version hash, the answer is yes. If they don't match, the served copy is different from the version of record — which shouldn't happen, because the external-document file store refuses overwrites and deletes (controlled-record immutability is enforced at the storage layer, not just the application).
This is part of the §11.10(e) controlled-record access trail. Inspectors looking for "prove to me that what was downloaded was the approved version" get the answer from the File hash column on this page paired with the version snapshot on the document.
Why this matters — 21 CFR §11 framing
Part 11 §11.10(e) requires a secure, computer-generated audit trail of operations on regulated electronic records. For controlled documents — SOPs, customer specs, regulatory standards — the "operation" inspectors care about most after creation and approval is who accessed it, when, and with what content integrity. This page is the answer.
On the documents side the trail covers external documents specifically. Internal (HTML-content) documents render their content live from the database without minting a separate file, so the question "who pulled SOP-007's PDF?" is answered by "nobody — they read it in the app", with the page-view captured on the underlying documents row history.
The same reasoning extends the log past documents. Evidence attached to an NCR, an NCR action, or an audit — failure reports, closure confirmations, supporting files — carries the same weight as a controlled document, so handing one to someone is recorded the same way and in the same place.
Who can read this page
Gated on the Access audit admin permission. The default Admin role has it; Standard User does not. If you've built a custom role for regulatory review, grant Access audit admin on that role so the reviewer can open this page without admin role on everything else.
Related
- External documents — the document register that feeds this trail
- Audit log access — the audit of who has been viewing audit pages
- Roles & permissions
- Signature manifestation — the §11.50 block carried on document exports
- Trash and Soft-delete — recoverable delete for documents and the file-cleanup limitation