Recording of PII disclosures

To meet the ISO/IEC 27018 recording of PII disclosures requirement, you must maintain a disclosure register for every disclosure of PII to a third party, capturing the PII disclosed, the recipient, the time of disclosure, and the legal basis. Operationalize it by defining what counts as a “disclosure,” instrumenting systems and teams to log them, and routinely reconciling logs to reality.

Key takeaways:

• Maintain a single, auditable record of every PII disclosure to a third party, with four minimum fields: what, who, when, legal basis.
• Define “disclosure” broadly enough to catch support access, subprocessor transfers, exports, and incident-related sharing.
• Treat completeness and traceability as the goal: auditors will test samples from systems, tickets, and contracts against your register.

“Recording of PII disclosures” is a requirement about evidence, not intent. ISO/IEC 27018 expects a cloud service provider acting as a PII processor to be able to answer, quickly and accurately: what personal data left our control, which third party received it, when it happened, and why it was allowed. That answer needs to be backed by records you can produce under audit, during customer due diligence, or in response to a controller’s question.

In practice, most programs fail here for predictable reasons: teams treat disclosures as “rare,” disclosures happen through multiple pathways (APIs, support tooling, subprocessors, legal requests, incident response), and no single owner reconciles technical logs, operational tickets, and contractual permissions. The result is an incomplete register that cannot withstand sampling.

This page translates ISO/IEC 27018 Annex A.6.2 into an operator-ready control: scope decisions, data model, process flows, required evidence, and an execution plan you can run. The goal is simple: if asked “show me all third-party disclosures of PII for customer X,” you can respond with a reliable record and supporting artifacts.

Regulatory text

Requirement (verbatim): “A record of PII disclosures to third parties shall be maintained, including what PII has been disclosed, to whom, at what time and on what legal basis.” ¹

Operator interpretation:
You need a durable, queryable disclosure record that is complete enough to reconstruct each disclosure event and defend why it was permitted. The minimum viable record has four required attributes:

1. What PII was disclosed (data elements or dataset, plus identifier for the customer/tenant and system of record).
2. To whom (specific third party legal entity; include subprocessor name and, if relevant, destination environment).
3. At what time (timestamp, and ideally time range if access occurred over a period).
4. On what legal basis (the contractual/authorized basis for processor-to-third-party disclosure, such as controller instructions, subprocessor agreement/authorization path, or other documented authorization).

ISO/IEC 27018 is explicit that this is about third-party disclosures. Internal access by your workforce may be governed by other controls, but once PII is shared outside your organization, this requirement applies.

Plain-English requirement

If PII leaves your environment to any third party, you must be able to show an auditable trail that answers: what left, who got it, when it happened, and why it was allowed. “Allowed” must map to a documented permission path, not a verbal assurance.

Who it applies to

Entity types: Cloud Service Providers acting as PII processors. ¹

Operational context where this shows up:

• Subprocessors (hosting, observability, ticketing, email delivery, analytics) that receive or can access customer PII.
• Support and professional services where data is exported and shared with an external consultant, partner, or tool.
• Customer-authorized integrations that route PII to a third-party destination.
• Legal/regulated disclosures routed via counsel or external eDiscovery providers.
• Incident response where indicators, logs, or datasets are shared with external forensics or security firms.

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

1) Define “PII disclosure” for your program

Write a short standard that draws a bright line: a disclosure occurs when PII is transmitted, made accessible, or otherwise provided to a third party, whether by API, file transfer, shared workspace, or third-party console access.

Include an explicit list of in-scope disclosure paths, such as:

• Data exports (CSV, database dumps, backups restored to third-party tools)
• API pushes to third parties
• Subprocessor processing (automated transfers)
• Third-party support access (temporary credentials, screen shares that reveal PII, shared troubleshooting bundles)
• External legal/forensics access

2) Build a disclosure register with a minimum data model

Create a register (tool or database) with required fields that match the requirement and support audit sampling.

Minimum fields (recommended):

• Disclosure ID (unique)
• Customer/tenant identifier
• PII categories / dataset identifier (link to data inventory entry)
• Recipient third party legal name and role (subprocessor, partner, regulator via counsel, etc.)
• Timestamp (and start/end if applicable)
• Legal basis (choose from controlled values; link to evidence)
• Disclosure mechanism (API, file transfer, support portal, shared bucket, etc.)
• Authorization reference (ticket ID, controller instruction, contract clause, DPA/subprocessor listing approval)
• Approver (where your process requires approval)
• Data minimization notes (what was excluded, redacted, or tokenized)
• Retention/disposition reference (where applicable)

3) Map disclosure events to the systems that can prove them

A disclosure register fails if it relies on memory. For each disclosure pathway, decide the system of record that will feed the register:

• Automated transfers to subprocessors: integration logs, data pipeline logs, outbound message logs.
• Support-driven disclosures: support ticketing system + attachment store + access logs.
• Ad hoc exports: change management tickets + export logs + storage access logs.
• Legal requests: legal intake ticket + counsel engagement record + transfer log.

Then document how each pathway gets logged into the register: automated ingestion, required form fields in tickets, or manual entry with mandatory evidence links.

4) Implement “no record, no disclosure” gates

Put lightweight friction where it matters:

• Require a ticket type for any non-routine disclosure (support bundle, ad hoc export, third-party forensics share).
• Make “Recipient third party,” “PII scope,” “time,” and “legal basis” required fields.
• Require attachment or link to proof (export log, secure transfer receipt, controller instruction).

For routine, automated subprocessor flows, treat the register as an inventory of disclosure streams plus change records when scope changes (new dataset, new region, new subprocessor, new purpose). The point remains the same: you can evidence what flows exist and when they changed.

5) Tie “legal basis” to contracts and controller instructions

ISO/IEC 27018 requires recording the legal basis for each third-party disclosure. For a processor, that usually translates into: “per contract and controller instructions.” Operationalize it as controlled options, for example:

• Listed/authorized subprocessor under DPA and subprocessor list
• Customer-configured integration (customer instruction)
• Customer support request (documented instruction in ticket)
• Legal request handled per documented process (reference the internal legal intake record)

Your goal is consistency: the same type of disclosure should map to the same type of basis, with a link to the controlling document.

6) Reconcile and test completeness

Auditors and customers will not trust a register that no one tests. Build two checks:

• Operational reconciliation: periodically sample outbound transfer logs and verify each event is in the register.
• Process adherence testing: sample support tickets tagged “data export” and verify required fields and evidence are present.

Document findings, remediation, and ownership. If you use Daydream for third-party risk workflows, treat disclosure recording as a control with mapped evidence requests to system owners and subprocessors, so you can close gaps before renewals and audits.

Required evidence and artifacts to retain

Keep artifacts that let you defend each record:

• Disclosure register extract (filtered by customer, third party, date range)
• Source logs supporting the event (export logs, API logs, transfer receipts)
• Ticket/work order authorizing the disclosure (support, change, legal intake)
• Contractual basis artifacts (DPA terms, subprocessor listing/approval evidence, customer instruction record)
• Access records where “disclosure” was by access rather than transfer (temporary access approvals, console access logs)
• Data classification or inventory link showing what PII categories were involved
• Exception approvals for unusual disclosures (executive/legal sign-off)

Common exam/audit questions and hangups

Expect these lines of questioning:

• “Show me your record of PII disclosures to third parties.”
• “Pick one third party subprocessor. What PII do they receive and since when?”
• “Pick a customer. Provide all third-party disclosures in a date range.”
• “How do you ensure your record is complete?” (They want reconciliation, not a policy.)
• “Where is the legal basis documented for this disclosure?” (They want a traceable link.)
• “How do you prevent ad hoc exports from bypassing the register?”

Hangup to plan for: teams confuse third-party disclosure logging with vendor inventory. Inventory lists who exists; the disclosure record proves what was shared, when, and why.

Frequent implementation mistakes (and how to avoid them)

1. Only logging subprocessors, not disclosure events or streams
   Fix: for each subprocessor, record the PII scope and effective date, and record changes over time; for ad hoc disclosures, record per event.

2. “PII disclosed” captured as “customer data”
   Fix: use PII categories/dataset identifiers and link to your data inventory. Make “unknown” an exception that requires follow-up.

3. No legal basis mapping
   Fix: controlled values + required evidence link. If you can’t point to a contract term or instruction record, treat it as noncompliant until corrected.

4. Support teams bypass the process under pressure
   Fix: pre-approved paths (standard support bundles, redaction defaults) and a ticket template that takes less time than improvisation.

5. No completeness testing
   Fix: reconciliation checks tied to owners and tracked to closure.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so you should treat enforcement risk here as indirect: weak disclosure records increase the chance you cannot answer regulator, controller, or customer inquiries, and they raise the impact of any incident involving third parties. The operational risk is practical: incomplete records slow down investigations, breach assessments, and customer escalations.

Practical 30/60/90-day execution plan

First 30 days (Immediate)

• Assign a single owner for the disclosure register (often Privacy Ops, Security GRC, or Compliance).
• Publish a one-page standard defining “PII disclosure” and in-scope pathways.
• Stand up the register with required fields and controlled values for “legal basis.”
• Identify top disclosure channels (subprocessors, support exports, integrations) and name system owners.

By 60 days (Near-term)

• Implement ticket templates and approval gates for ad hoc disclosures (support bundles, exports, external forensics).
• Connect routine subprocessor flows to the register: document what PII, recipients, and effective dates; add change triggers for scope changes.
• Start reconciliation: sample logs/tickets and measure gaps; open remediation tasks.

By 90 days (Operationalized)

• Expand coverage to remaining disclosure pathways (legal requests, partnerships, regional transfers where applicable).
• Formalize ongoing controls: periodic reconciliation, exception review, and reporting to the privacy/security governance forum.
• Prepare an audit-ready evidence pack: register extract + sample records with end-to-end traceability.

Frequently Asked Questions

Does “PII disclosures” include sharing with subprocessors we already list in our DPA?

Yes, disclosures to subprocessors are still disclosures to third parties; the “legal basis” will usually be the DPA/subprocessor authorization path. Your record should show what PII is disclosed, to whom, when the disclosure stream became effective, and where that authorization is documented.

What counts as “what PII has been disclosed” if we can’t list every field?

Use PII categories and dataset identifiers tied to your data inventory, then link to the system(s) involved. If the exact fields vary by customer, record the maximum scope and document customer-specific scoping through configuration or ticket evidence.

Do we need a record for every API call that sends PII to a third party?

You need a record that can support auditability. For high-volume automated disclosures, record the disclosure stream (recipient, dataset/PII scope, start time, configuration) and retain the underlying logs that prove actual transfers.

How do we record “time” for disclosures that occur over days, like third-party support access?

Record start and end timestamps for the access window, plus the access method and logs. If access is renewed, treat the renewal as a new disclosure window or a documented extension with approval.

Who should own the disclosure register: Privacy, Security, or Legal?

Pick one accountable owner and make other functions contributors. Privacy often owns the requirement, Security often owns the technical evidence, and Legal often owns legal-request pathways; the register needs a single operational owner to keep it consistent.

How can Daydream help without turning this into a paperwork exercise?

Use Daydream to route evidence requests to the systems and teams that create disclosure proof (support, engineering, vendor management), track completeness testing, and package disclosure records for customer due diligence without rebuilding the same artifacts each time.

Footnotes

1. ISO/IEC 27018:2019 Information technology — Security techniques — Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors