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.

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.[1] 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.[2] 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).

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.

References

[1] 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. ↩

[2] WORM (write-once, read-many) and hash-chained append-only logs are standard techniques for tamper-evidence: they let entries be added and read but not silently rewritten, so the trail can be trusted as evidence rather than edited to hide a disclosure. ↩