PM-21: Accounting of Disclosures

PM-21 requires you to keep an accurate, maintainable record of every disclosure of personally identifiable information (PII) outside your organization, so you can prove who received what, when, why, and under what authority. To operationalize it, define “disclosure,” standardize a disclosure log, route disclosures through an intake/approval workflow, and retain evidence that the log is complete and reviewed. ¹

Key takeaways:

• Treat “accounting of disclosures” as a governed log plus workflow, not a spreadsheet you update after the fact. ¹
• Scope hinges on what your program defines as a “disclosure” of PII and which channels count (APIs, SFTP, email, portals, manual exports). ¹
• Auditors will test completeness: they will trace from data egress, tickets, and third-party transfers back to your accounting record. ¹

The pm-21: accounting of disclosures requirement is one of those privacy program controls that fails in practice for a simple reason: teams track sharing inconsistently. A business unit sends a file to a third party, Engineering opens an API endpoint, HR responds to a data request, Legal approves a one-off disclosure, and none of it lands in a single system of record. PM-21 pushes you to fix that by building an accurate accounting of disclosures of PII and keeping it current. ¹

For a Compliance Officer, CCO, or GRC lead, the operational goal is straightforward: you need an inventory-grade record that can answer “who got PII from us” quickly and defensibly, with enough detail to reconstruct the event and validate authorization. That record must be supported by process controls (intake, approval, logging, and review) and by evidence that the process is actually followed. ¹

This page gives requirement-level implementation guidance you can put into a control narrative, configure into a workflow tool, and hand to control owners with minimal translation work. It also highlights what assessors typically probe: completeness, authorization, and retention. ¹

Regulatory text

Control excerpt (PM-21): “Develop and maintain an accurate accounting of disclosures of personally identifiable information, including:” ¹

Operator translation: you must (1) define what counts as a disclosure of PII, (2) record each disclosure with enough detail to be “accurate,” and (3) keep the accounting current over time. The requirement is ongoing: the accounting must be maintained as new disclosures occur and as disclosure mechanisms change (new vendors, new data feeds, new integrations). ¹

Plain-English interpretation (what “accounting of disclosures” means)

An “accounting” is a structured record you can query. For each disclosure of PII, you can show:

• Recipient: the third party or external entity that received the PII
• What was disclosed: dataset, fields, identifiers, approximate volume if you track it, and sensitivity flags
• When: date/time (and, if relevant, duration of access)
• Why and authority: business purpose, legal/contractual basis, approval reference
• How: channel (API, secure file transfer, portal access, email, manual handoff)
• Safeguards: encryption in transit, authentication method, data minimization steps, and any restrictions agreed to (contract clauses, DPA terms) ¹

Your log is only “accurate” if it is complete enough to reconcile against real-world disclosures across systems and teams. ¹

Who it applies to (entity and operational context)

PM-21 is most directly applicable where you handle PII in:

• Federal information systems
• Contractor systems handling federal data ¹

Operationally, you should treat it as applicable to any environment where:

• PII leaves your logical boundary to a third party (processors, subprocessors, consultants, managed service providers, benefits providers, background check providers, analytics vendors, cloud services, or government entities)
• PII is disclosed externally through automated integrations (APIs, ETL pipelines) or manual disclosures (exports, emailed reports, ad hoc queries)
• Multiple teams can disclose data without a single gatekeeper (Procurement, Customer Success, HR, Legal, Engineering) ¹

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

Step 1: Establish scope and definitions you can enforce

Define, in writing:

• PII for your organization (reference your privacy policy or data classification standard)
• Disclosure: external sharing or access provision of PII to any third party or external recipient, including “view” access via portals or admin consoles where applicable
• Excluded events (be careful): internal access is typically not a “disclosure,” but disclosures to affiliated entities may still count depending on your boundary and contracts ¹

Deliverable: a one-page “PM-21 Disclosure Logging Standard” that control owners can apply consistently.

Step 2: Create a standard disclosure log schema (minimum viable fields)

Build the accounting as a database table, GRC object, or ticket-backed register. At minimum, capture:

Field	What auditors expect	Example
Disclosure ID	Unique identifier	DISC-2026-00123
Date/time	When the transfer/access occurred	2026-02-15 14:03 UTC
Requestor / owner	Internal accountable person	HR Ops Manager
Recipient	Legal name + third-party ID	Acme Benefits, Inc.
System of record	Source system(s)	HRIS, data warehouse
PII elements	Categories/fields	Name, SSN (last4), DOB
Purpose	Business purpose	Benefits enrollment
Authority	Contract, DPA, legal basis, approval	MSA #1234, DPA v2, ticket
Method	Transfer mechanism	SFTP nightly feed
Safeguards	How protected	TLS, SFTP key, least privilege
Retention / expiration	How long access persists	Access revoked on termination
Evidence pointers	Links to artifacts	DPA link, ticket link, logs

If you cannot implement all fields immediately, start with recipient, what, when, why/authority, and evidence pointers, then expand. ¹

Step 3: Implement an intake and approval workflow so disclosures get logged “by design”

A disclosure log fails if it depends on memory. Put a gate in front of common disclosure paths:

• Third-party onboarding: require a “PII disclosure record” as part of Procurement/TPRM intake before data is shared.
• Engineering integrations: require a disclosure record before enabling an external integration to access PII.
• Ad hoc exports: route through a service request queue (ticket) that includes the disclosure fields. ¹

Practical design pattern:

1. Request submitted (ticket form with required fields).
2. Privacy/Security review (data minimization, safeguards).
3. Legal/Procurement confirmation (contract/DPA in place).
4. Approval recorded.
5. Disclosure log entry created automatically from the ticket.
6. Periodic reconciliation against egress signals (see Step 5). ¹

Step 4: Assign ownership and RACI

You need named roles:

• Control owner: typically Privacy, GRC, or Security Compliance
• Data owners: business owners of systems disclosing PII
• Operators: Procurement/TPRM, Legal, IT/Engineering, HR Ops
• Approvers: Privacy + Security + Legal (as fits your model) ¹

Write a RACI that states who must create the record and who validates it.

Step 5: Prove completeness with reconciliation checks

Assessors will not accept “we log disclosures” without evidence it’s complete. Build at least one reconciliation method:

• Compare disclosure log entries against new third parties onboarded in Procurement/TPRM.
• Compare against data transfer mechanisms (SFTP accounts, integration allowlists, API keys issued to third parties).
• Sample email/export events from a controlled mailbox or reporting tool where feasible. ¹

Document the reconciliation procedure and retain results.

Step 6: Operate the control (review, update, and retire)

Operational routines:

• Review new entries for required fields and approvals.
• Update entries when recipients change, integrations expand scope, or contracts renew.
• Retire entries when access ends; keep the accounting record and evidence per your retention standard. ¹

Daydream fit (earned mention): if you’re tracking PM-21 in a control library, Daydream can map PM-21 to a control owner, implementation procedure, and recurring evidence artifacts so you stop rebuilding the same control packet each audit cycle. ¹

Required evidence and artifacts to retain

Store evidence so an assessor can trace from a disclosure to authorization and execution:

Core artifacts

• PM-21 control narrative (scope, definition of disclosure, system of record for the accounting) ¹
• Disclosure log export or read-only report (with immutable history or change tracking)
• Workflow configuration or ticket template used to capture disclosures

Per-disclosure evidence pointers (linked, not duplicated)

• Contract/DPA or other authorization reference
• Security review notes (data minimization, encryption, access controls)
• Technical evidence of the transfer/access (integration configuration, SFTP setup, API key issuance record)
• Approvals (ticket approvals, email approvals routed into the ticketing system) ¹

Ongoing operation evidence

• Reconciliation results and follow-ups (exceptions, remediation tickets)
• Periodic review sign-off (who reviewed, what period, what changed) ¹

Common exam/audit questions and hangups

Expect questions like:

• “Show me your accounting of disclosures. How do you know it’s complete?” ¹
• “Pick a third party that receives PII. Walk me from contract to actual data transfer.” ¹
• “How do engineering-led integrations get into this accounting?” ¹
• “How do you handle one-off disclosures (spreadsheets, urgent requests)?” ¹
• “What happens when a disclosure changes scope over time?” ¹

Hangup: teams often show a vendor list, not a disclosure accounting. A vendor list does not tell an auditor what PII was disclosed, when, or through which method. ¹

Frequent implementation mistakes and how to avoid them

1. Logging only “vendors,” not disclosures. Fix: log each disclosure event or disclosure relationship with sufficient detail (what/when/how/authority). ¹
2. Relying on manual updates. Fix: generate log entries from the approval workflow, not after-the-fact admin work. ¹
3. No clear definition of disclosure. Fix: publish a definition and examples; train high-risk teams (HR, CS, Engineering). ¹
4. No completeness check. Fix: reconcile against integration inventories and Procurement onboarding records; track exceptions to closure. ¹
5. Evidence stored in inboxes. Fix: require ticket-based approvals and link artifacts in a system of record. ¹

Enforcement context and risk implications

No public enforcement cases were provided in the available source catalog for this requirement, so this page does not summarize enforcement outcomes. ¹

Risk-wise, PM-21 gaps commonly surface as audit findings because they undermine your ability to demonstrate controlled sharing of PII, validate authorization, and respond to downstream inquiries about where PII went. Treat the accounting as audit-critical evidence, not just a privacy documentation exercise. ¹

Practical execution plan (30/60/90-day)

The requirement benefits from staged delivery. Use phases to avoid blocking on perfect tooling.

Immediate (stabilize and define)

• Name the PM-21 control owner and publish the “Disclosure Logging Standard.”
• Stand up the disclosure log in your existing GRC tool, spreadsheet-with-change-control, or ticketing system.
• Identify the highest-risk disclosure channels (common third-party feeds, HR disclosures, support exports) and route them through the workflow first. ¹

Near-term (instrument and reconcile)

• Convert the disclosure request form into a mandatory intake for third-party PII sharing.
• Integrate with Procurement/TPRM so new third parties cannot receive PII until a disclosure record exists.
• Implement a reconciliation routine against at least one technical source of truth (integration inventory, SFTP account list, API key registry) and track exceptions. ¹

Ongoing (mature operations)

• Expand coverage to lower-risk disclosure paths and ad hoc requests.
• Add periodic review and sign-off, and incorporate PM-21 evidence into your audit binder.
• Use Daydream (or your GRC system) to map PM-21 to owner, procedure, and recurring evidence artifacts so audits do not trigger a scramble for screenshots and exports. ¹

Frequently Asked Questions

Do internal data shares count as a “disclosure” under PM-21?

PM-21 focuses on disclosures of PII, which operators typically treat as sharing outside the organizational boundary. Define this boundary clearly and document exclusions in your PM-21 control narrative. ¹

Is a third-party inventory the same as an accounting of disclosures?

No. A third-party list rarely captures what PII was shared, when it was shared, and the method and authority for the disclosure. PM-21 expects an accounting record detailed enough to reconstruct the disclosure. ¹

How granular should the accounting be: one row per vendor or one row per transfer?

Use a level of granularity that stays accurate as reality changes. Many teams log a “disclosure relationship” per recipient and dataset, then record material changes (new fields, new transfer method, new purpose) as updates with change history. ¹

What if Engineering ships a new integration without telling GRC?

Treat that as a control design gap: your SDLC and access provisioning must require a disclosure record for third-party access to PII. Back it with a reconciliation check against API keys, allowlists, or integration inventories so you can detect misses. ¹

What evidence satisfies auditors if we can’t capture perfect technical logs for every disclosure?

Keep the approval record, the contractual authority reference, and a reliable pointer to how the disclosure happened (integration config, SFTP setup ticket, or system configuration). Pair that with documented reconciliation and exception follow-up to demonstrate completeness controls. ¹

Where should we store the accounting of disclosures?

Store it in a system with access control, change history, and export capability for audits. If you start in a spreadsheet, add change control and a documented owner, then migrate to a ticket- or GRC-backed register as operations mature. ¹

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON