Accounting of Disclosures

To meet the accounting of disclosures requirement, you must keep a retrievable log of every disclosure of personal information and be able to provide that log to the individual upon request. Each entry must capture the disclosure date, what was disclosed, why it was disclosed, and who received it (including name and address). (HITRUST CSF v11 Control Reference)

Key takeaways:

• Maintain an end-to-end disclosure inventory that includes third parties, affiliates, and internal disclosures outside the original purpose. (HITRUST CSF v11 Control Reference)
• Build a repeatable workflow to fulfill individual requests for an accounting of disclosures quickly and consistently. (HITRUST CSF v11 Control Reference)
• Evidence matters: auditors will test completeness (are you logging all disclosure paths?) and retrievability (can you produce a coherent report per individual?). (HITRUST CSF v11 Control Reference)

“Accounting of disclosures” is a deceptively operational requirement: it forces you to prove you know where personal information goes after you collect it. In practice, that means two things. First, you maintain ongoing records of disclosures (not just a policy statement). Second, you can translate those records into an individual-specific report when someone asks.

For most organizations, the hard part is not writing the rule. The hard part is defining what counts as a “disclosure” across real systems and workflows: support tooling, email, SFTP drops, cloud storage sharing, subcontractors, claims processors, data enrichment providers, and emergency disclosures during incident response. If you don’t define the event types and log sources up front, your “accounting” becomes a manual scavenger hunt that fails under audit and fails under an individual request.

This page gives you requirement-level guidance you can implement fast: scope decisions you must make, a practical logging model, step-by-step operating procedures, and the evidence package auditors expect, mapped to HITRUST CSF v11 Control 13.c. (HITRUST CSF v11 Control Reference)

Regulatory text

Requirement (verbatim): “Organizations shall maintain an accounting of disclosures of personal information and make that accounting available to individuals upon request. Records of disclosures shall include the date, nature, and purpose of each disclosure and the name and address of the person or entity to whom the disclosure was made.” (HITRUST CSF v11 Control Reference)

Operator interpretation:
You need a system of record (not necessarily a single tool, but a controlled process) that:

1. Captures disclosures of personal information as they occur, and
2. Produces an accounting per individual when requested, showing date, nature, purpose, and recipient identity and address for each disclosure. (HITRUST CSF v11 Control Reference)

If you cannot reliably answer “who received this person’s data, when, and why,” you are not meeting the control.

Plain-English interpretation (what the requirement is really asking)

A disclosure is any release, transfer, provision of access, or sharing of personal information to another person or entity. Treat disclosures broadly unless you have a formally approved exception model, because auditors will test completeness against your data flows and third-party relationships. The control also expects that an individual can request this accounting and receive it in a usable form. (HITRUST CSF v11 Control Reference)

The “records must include” clause is the non-negotiable minimum dataset:

• Date: when the disclosure occurred (or started, for ongoing access).
• Nature: what personal information categories/fields were disclosed (and ideally the method, such as API, file transfer, portal access).
• Purpose: business reason/legal basis in plain terms (e.g., “claims processing,” “customer support escalation,” “fraud investigation”).
• Recipient name and address: the receiving person/entity and their address (practically, the third party legal name and business address, or an internal department location if internal disclosures are in scope for your program). (HITRUST CSF v11 Control Reference)

Who it applies to (entity and operational context)

Entity scope: All organizations implementing HITRUST CSF v11 that process personal information. (HITRUST CSF v11 Control Reference)

Operational scope (where teams get tripped up):

• Third-party disclosures: sharing with vendors, partners, consultants, subcontractors, and service providers.
• Affiliate and intra-group disclosures: sharing across subsidiaries or business units, especially when systems are segmented.
• Support and operations: ad hoc disclosures via ticket attachments, screen shares, email forwarding, or “temporary” access grants.
• Security/incident workflows: disclosures to forensic firms, outside counsel, cyber insurers, or law enforcement if personal information is shared as part of response activities.
• Product and engineering: data exports for testing, debugging, analytics, and machine learning pipelines, if personal information is present. (HITRUST CSF v11 Control Reference)

The control does not care which department did it. If personal information was disclosed, it belongs in your accounting.

What you actually need to do (step-by-step)

1) Define “disclosure events” and your logging boundaries

Create a short standard that answers:

• What constitutes a disclosure in your environment (API share, file export, read access, onward transfer by a third party, etc.).
• Which disclosures are in scope for the accounting log (recommendation: default to inclusion unless excluded via written rationale and approval).
• What “address” means for recipients (recommendation: business address for entities; for individuals, document how you store addresses safely and consistently). (HITRUST CSF v11 Control Reference)

Output: Accounting of Disclosures Standard (1–2 pages) that your privacy, security, and data owners can follow.

2) Build a disclosure inventory (data-flow-driven)

Start from what you already have:

• Data map / RoPA-like inventory (if you have it)
• Third-party list (procurement, AP, security intake)
• System integrations catalog (IAM, enterprise architecture, engineering)
• High-risk workflows (support, billing, claims, identity verification) (HITRUST CSF v11 Control Reference)

For each disclosure pathway, capture:

• Source system(s)
• Recipient (entity/person)
• Transfer mechanism (API, SFTP, portal, email, direct DB access)
• Data elements/categories
• Business purpose
• Owner (who can explain it and approve changes)

Output: Disclosure Pathway Register (spreadsheet or GRC system record).

3) Implement the minimum disclosure log schema

You need a log format that can be searched by individual. At minimum, include:

• Individual identifier(s) used in systems (customer ID, patient MRN, employee ID, email)
• Disclosure date/time (and time zone convention)
• Nature of disclosure (data categories/fields; dataset name; “full record” vs subset)
• Purpose (controlled list plus free text for edge cases)
• Recipient legal name
• Recipient address (from master third-party record)
• Disclosure channel (API/SFTP/portal/email/etc.)
• Authorizing ticket/approval reference (change request, DPA, support escalation ticket)
• Operator/system actor (service account, user, automated job)
• Retention tag (how long the record is kept under your retention schedule) (HITRUST CSF v11 Control Reference)

Practical note: if you cannot link disclosures to an individual deterministically, you won’t be able to satisfy “make that accounting available to individuals upon request.” Fix identity linking early.

4) Instrument collection: automate where possible, control the rest

Use a tiered approach:

• Tier 1 (automate): recurring system-to-third-party transfers (ETL jobs, API pushes, SFTP feeds). Generate logs from integration platforms, data pipelines, or application audit logs.
• Tier 2 (workflow-controlled): one-off exports and manual sharing. Require a ticket with required fields and route it through an approved mechanism (secure transfer tool, controlled shared drive with access logging).
• Tier 3 (exception-only): emergency disclosures (incident response). Allow fast execution but require after-action logging within your defined exception process. (HITRUST CSF v11 Control Reference)

5) Stand up an “individual request” operating procedure

Your procedure should cover:

1. Intake channel(s) and identity verification steps (align with your privacy request process if you have one).
2. Request scoping: the individual, time window (if the request specifies one), and which data domains apply.
3. Retrieval: query the disclosure log(s), plus any manual sources for Tier 2/3.
4. Quality check: confirm required fields exist (date, nature, purpose, recipient name/address).
5. Response format: produce a readable report; record what you provided and when.
6. Exception handling: if records are missing, document root cause, corrective actions, and how you will remediate the logging gap. (HITRUST CSF v11 Control Reference)

6) Make it governable: ownership, reviews, and change control

Assign:

• Control owner: Privacy or GRC lead accountable for the accounting program.
• Data/process owners: system owners responsible for ensuring their disclosure pathways are logged.
• Third-party owner: procurement/TPRM owner responsible for recipient master data (legal name, address). (HITRUST CSF v11 Control Reference)

Add a review mechanism:

• Periodic reconciliation between your third-party list and your disclosure pathways.
• Change triggers: new third party, new integration, new export capability, new dataset classification.

7) Use Daydream to keep the accounting tied to third-party reality (where it helps)

The fastest way this control breaks is stale recipient data: the legal entity name changes, addresses are missing, or teams disclose to a subcontractor that never made it into your third-party inventory. Daydream can help centralize third-party profiles (including recipient name/address), tie them to disclosure pathways, and keep evidence linked to each recipient relationship so you can produce cleaner accountings during audits and individual requests.

Required evidence and artifacts to retain

Auditors typically want proof of design and operating effectiveness. Keep:

• Accounting of Disclosures policy/standard defining disclosure events and logging requirements. (HITRUST CSF v11 Control Reference)
• Disclosure Pathway Register (systems → recipients → purposes → data categories). (HITRUST CSF v11 Control Reference)
• Disclosure log extracts showing required fields populated (sampled entries). (HITRUST CSF v11 Control Reference)
• Third-party master records with recipient legal name and address (source of truth). (HITRUST CSF v11 Control Reference)
• SOP for individual accounting requests, plus completed request files (redacted as needed) showing you provided the accounting. (HITRUST CSF v11 Control Reference)
• Exception records for emergency/incident disclosures and post-event completion of logging. (HITRUST CSF v11 Control Reference)
• Training or enablement evidence for teams that perform manual disclosures (support, operations, security). (HITRUST CSF v11 Control Reference)

Common exam/audit questions and hangups

Expect questions like:

• “Show me your accounting of disclosures log, and demonstrate how you retrieve all disclosures for one individual.” (HITRUST CSF v11 Control Reference)
• “How do you know the log is complete? What are your sources of disclosure events?” (HITRUST CSF v11 Control Reference)
• “Where do recipient name and address come from, and how do you keep them current?” (HITRUST CSF v11 Control Reference)
• “How do you handle disclosures done by support or engineering outside automated integrations?” (HITRUST CSF v11 Control Reference)
• “Provide evidence of an individual request and the accounting you produced.” (HITRUST CSF v11 Control Reference)

Hangup to anticipate: auditors may sample a third party from AP/procurement and ask you to prove whether any personal information disclosures occurred to that entity. If your disclosure inventory is not reconciled to your third-party list, you will scramble.

Frequent implementation mistakes (and how to avoid them)

1. Logging transfers but not access grants. If a third party has portal access, that is an ongoing disclosure pathway. Record access start dates, scope, and purpose. (HITRUST CSF v11 Control Reference)
2. Storing recipient “name” as a system nickname. Use legal entity names tied to contract records; otherwise you cannot produce credible accountings. (HITRUST CSF v11 Control Reference)
3. No individual linkage. A dataset-level export log that doesn’t identify impacted individuals won’t satisfy “available to individuals upon request.” Add identifiers or maintain a joinable mapping. (HITRUST CSF v11 Control Reference)
4. Manual disclosure chaos (email attachments). Force disclosures through approved channels with required metadata capture via ticketing and secure transfer. (HITRUST CSF v11 Control Reference)
5. Missing purpose statements. “Operational” is not a purpose. Use a controlled list aligned to your processing purposes and require selection at disclosure time. (HITRUST CSF v11 Control Reference)

Risk implications (why operators should care)

Failing this control creates two concrete risks:

• Response risk: you cannot satisfy an individual request without excessive manual effort, and you may produce an incomplete or inconsistent report. (HITRUST CSF v11 Control Reference)
• Control risk: if you can’t account for disclosures, you often also lack control over them (shadow exports, unauthorized onward sharing, untracked subcontractors). That increases the chance of privacy incidents and audit findings. (HITRUST CSF v11 Control Reference)

A practical 30/60/90-day execution plan

First 30 days (stabilize scope and design)

• Assign control owner and working group (privacy, security, IT, procurement/TPRM, key app owners).
• Publish the Accounting of Disclosures Standard with the minimum log schema and disclosure-event definition. (HITRUST CSF v11 Control Reference)
• Build the first Disclosure Pathway Register from your top systems and top third parties.
• Pick your “system of record” approach: centralized GRC record, SIEM + reporting layer, or a governed spreadsheet plus audit-log attachments.

Days 31–60 (instrument the highest-risk disclosures)

• Automate logging for your major recurring integrations (Tier 1).
• Implement the manual disclosure workflow (Tier 2) with required fields and approvals.
• Normalize third-party recipient records (legal name, address) and connect them to disclosure pathways. (HITRUST CSF v11 Control Reference)
• Run a tabletop: simulate an individual request and produce an accounting from your new records.

Days 61–90 (prove operating effectiveness and close gaps)

• Expand coverage to remaining systems and edge-case pathways (analytics, support tools, incident response).
• Establish reconciliation checks between third-party inventory and disclosure pathways.
• Package audit-ready evidence: SOPs, sample logs, completed request file, exception examples. (HITRUST CSF v11 Control Reference)
• If you use Daydream, link each third party to its disclosure pathways and evidence so audits become a structured pull, not a scramble.

Frequently Asked Questions

What counts as a “disclosure” for accounting of disclosures?

Treat disclosures as any sharing or provision of access to personal information outside the original collection context, including transfers to third parties and access granted through portals or shared systems. Your internal standard should define your event types so logging is consistent. (HITRUST CSF v11 Control Reference)

Do I need to track disclosures made by subprocessors and subcontractors?

If personal information is disclosed onward, you need a defensible way to account for that disclosure pathway and recipient identity. Practically, capture subcontractor relationships through third-party management and require notice/approval paths that feed your disclosure register. (HITRUST CSF v11 Control Reference)

How detailed does “nature of the disclosure” need to be?

It should be detailed enough that an individual can understand what categories of personal information were shared and enough that an auditor can validate scope. Most teams use data categories plus a dataset name or export profile. (HITRUST CSF v11 Control Reference)

What if our systems don’t log disclosures at the individual level?

Then you need a compensating approach, such as export manifests that list impacted identifiers or a joinable mapping between exported records and individuals. Without that, you cannot reliably produce an individual-specific accounting. (HITRUST CSF v11 Control Reference)

Do we have to provide the accounting automatically, or only upon request?

The control requires that you maintain the accounting and make it available to individuals upon request. Design for on-demand production, with a documented workflow and evidence of completion. (HITRUST CSF v11 Control Reference)

How do we keep recipient names and addresses accurate over time?

Put recipient legal name and address in your third-party master record and treat it as controlled data maintained by procurement/TPRM. Tie disclosure logging to that master record so updates flow into future accountings without manual rework. (HITRUST CSF v11 Control Reference)