Skip to content

Disclosure Audit Log

Disclosure register — instantiates Role-Scoped Disclosure Minimization

Records every disclosure — who received which fields, when, and under what justification — as an append-only trail that answers 'who saw this?' after the fact and drives subject notification.

Version
v2 · 2026-09-14 · History
Mechanism #
2797
Type
Register
Form family
Record, Log & Register
Solution family
Allocation & Prioritization
Problem family
Boundary, Scope, Access & Spillover Failure
Problem subfamily
Containment, Disclosure & Inference Leakage
Domain group
Professional & Organizational Practice
Origin domain
Law & Governance
Also from
Computer Science & Software Engineering, Medicine & Healthcare
Instantiates
Role-Scoped Disclosure Minimization

A Disclosure Audit Log is the accountability register of the archetype: every time the producer releases data, it writes an entry — recipient, which fields, timestamp, and the justification — to an append-only trail. Its defining move is to make disclosure answerable after the fact: it decides nothing about what may be released, but it turns "who saw this record, and why?" from an unanswerable question into a query. That backward-looking accountability is what keeps the forward-looking controls honest — a granted access can be compared against what the task actually used, and a subject can be told what happened to their data. The log is the one mechanism here that is purely observational: it neither shapes nor blocks, it records, and from that record it drives notification.

Example

A hospital discloses a patient's record three times in a month: to an outside specialist for a referral, to an insurer for a claim, and — under subpoena — to a court. Each disclosure writes an append-only entry: recipient, the fields released, the timestamp, and the justification. Months later the patient exercises their right to an accounting of disclosures and the hospital produces the list straight from the log — every external disclosure, who received it and why.[n1] The same log drives a notification rule: because the court disclosure crossed a defined threshold, the patient (or their steward) is notified that it occurred. The log changed none of these decisions; it made them accountable, and it turned "your record was disclosed" into something the subject actually learns.

How it works

  • Write on every release. At the disclosure boundary, record who received what fields, when, for which purpose, and under whose authorization.
  • Make it append-only. Entries can be added but not silently altered or deleted, so the trail resists the insider who would edit history to hide a disclosure.
  • Support the accounting query. Structure the log so it answers "everything disclosed about subject X" and "everything role Y received" on demand.
  • Trigger notification. Fire a subject- or steward-notice when a logged disclosure meets a rule — a sensitive recipient, a threshold, a subject request.

Tuning parameters

  • Event granularity — log at the record, field, or query level; finer logging answers more precise questions but grows the trail.
  • Captured attributes — who/what/when only, versus also the purpose and justification; more context aids audit but the log itself then holds more sensitive metadata.
  • Tamper-resistance — a plain log, an append-only store, or a cryptographically sealed one (WORM or hash-chained); stronger integrity resists edited history.
  • Retention — how long entries are kept: long enough for accountability, short enough that the log doesn't become its own liability.
  • Notification trigger — which logged events fire a subject or steward notice, and how promptly.

When it helps, and when it misleads

Its strength is deterrence and recourse: a credible, queryable record makes over-disclosure detectable and gives the subject both an accounting and a notification, which disciplines even accesses no one ends up reviewing. It is also what lets a purpose-based grant be checked against actual use. Its failure modes are the quiet ones. A write-only-never-read log is theatre — the record exists but nobody queries it, so misuse is logged and ignored. An editable log can be altered to erase the very disclosure that mattered, which is why append-only integrity is load-bearing.[1] The classic misuse is pointing to "we have audit logs" as a control while no one reviews them and the log is quietly tamperable. The discipline is append-only or sealed storage, scheduled review with alerting on anomalies, and keeping the log's own contents minimal.

How it implements the components

  • disclosure_audit_record — the append-only entry of recipient, fields, time, and justification is exactly this component: the durable record of what was disclosed.
  • subject_or_steward_notification_rule — because the log holds who-received-what, it is what fires the rule that tells a data subject or steward when their information was disclosed.

It records and notifies after the fact; it does not assess risk before release (Privacy Impact Review), shape the payload (Role-Based View, Field-Level Redaction), or govern retention and revocation of the data itself (Tokenization or Masking).

Editorial Notes

Form Classification

Form family: Record, Log & Register

Rationale: Disclosure Audit Log operates as a durable record, ledger, register, or trace whose value depends on preserving actual state or history because it records every disclosure — who received which fields, when, and under what justification — as an append-only trail that answers 'who saw this?' after the fact and drives subject notification.

Independent corroboration: The frozen evidence defines Disclosure Audit Log as 'Records every disclosure — who received which fields, when, and under what justification — as an append-only trail that answers 'who saw this?' after the fact and drives subject notification', so its operative form is Record, Log & Register.

Review outcome: Independent reviewer agreement; high confidence.

Origin Attribution

Primary origin: Law & Governance

Origin pattern: Cross-disciplinary synthesis

Present-day reach: Multi-domain

Rationale: Privacy and records law cohered accountable disclosure as a reviewable history of recipient, fields, time, and justification, including rights to an accounting.

Related originating lineages:

Review resolution: Both current reviews place disclosure_audit_log primarily in law_governance; the reconciled classification retains only lineages that materially shaped the mechanism and keeps breadth of origin separate from reach.

Attribution caveat: The duty to account is legal and clinical-governance based, while trustworthy realization depends on computer-security logging.

Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.

Review outcome: Reconciled after independent review; high confidence.

Notes

The log is itself a disclosure surface: a record of who-saw-what is sensitive, and a badly scoped one becomes a second over-collected copy of exactly the information the archetype set out to minimize. The point is answerability, not accumulation — capture what accountability needs, protect it as tightly as the data it describes, and retain it only as long as that purpose lasts.

[n1] Under the HIPAA Privacy Rule, patients have a right to an accounting of disclosures — a list of certain disclosures of their protected health information; a disclosure log is what makes producing that accounting possible. ↩

References

[1] Kent, Karen, and Souppaya, Murugiah. Guide to Computer Security Log Management. NIST SP 800-92. National Institute of Standards and Technology (2006). Recommends protecting log files from unauthorized modification, including through write-once media where stronger integrity is required. registry ↩