P6.2 Record of authorized disclosures: SOC 2 evidence

What SOC 2 P6.2 asks for and why auditors test it

P6.2 asks the organization to create and keep a complete, accurate and timely record of each authorized disclosure of personal information. For a compliance lead, the practical test is simple: for any disclosure the company has made, can it show to whom the information went, when, what was shared and on what basis? If the answer depends on memory or on a support engineer's recollection, the privacy commitment in the system description is hard to support in an examination. The risk is disclosures nobody can reconstruct, which undermines data subject requests, vendor reviews and any later question about whether a disclosure was permitted at all.

Authorized disclosures rarely arrive as a single, labeled event. They happen through bulk exports from the production database, API calls that return customer records to a partner, screenshots attached to support tickets, data sent to a subprocessor for analytics or email delivery, and ad hoc files shared during implementation work. Each path can bypass the place where a record would normally be kept. A workable approach is to inventory every channel that can carry personal information out of the system, assign an owner to each, and decide which events must write a record, such as the export tool, the API gateway and the ticketing workflow. Confirm with your auditor how they expect that inventory to be documented before fieldwork begins.

P6.2 is often confused with its paired criterion, P6.3, which covers detected or reported unauthorized disclosures, including breaches. The distinction matters for evidence. P6.2 records disclosures that were permitted, so the evidence is a log of approved transfers and the authority behind each one. P6.3 records disclosures that should not have happened, so the evidence is an incident and breach register. Auditors commonly test the two separately, so a team that keeps one register for both may still need to show that the authorized side is complete on its own.

Which disclosures, systems and third parties fall in scope for P6.2

P6.2 is only as complete as the boundary drawn around it. Before the record can be built, the organization has to decide which personal information counts, which kinds of sharing count as disclosures, which systems write or hold the evidence, and who may approve a disclosure. Each decision below changes what the auditor samples and what the team must keep.

Personal information categories in scope

Start by listing the categories of personal information the service handles for customers, including data the customer uploads, data generated by the platform such as logs and usage events, and support material. P6.2 applies to whatever the organization's privacy objectives define as personal information, so a narrow definition shrinks the record and invites a gap at audit. Confirm the definition with privacy counsel and write it into the privacy policy and the system description so the auditor and the disclosure log use the same terms. Where a category is excluded, record the reason.

Regular data sharing arrangements

Recurring transfers, such as scheduled exports to an analytics provider, a payroll partner or a customer's own reporting system, are the disclosures most often missed because nobody files a request for them. Inventory each feed with its recipient, data elements, frequency, legal or contractual basis and the approver who authorized it. Each recurring transfer should produce a dated entry or a reproducible record, not an assumption that the arrangement is still active. Ask engineering to confirm that no integration was added outside the approval process.

One-off exports and manual extracts

Ad hoc queries, spreadsheet exports for a sales review, and database dumps shared with a consultant are disclosures too, even when they happen once. Decide who may run extracts from production data, whether extracts need a ticket that names the recipient and purpose, and how the extract is logged. Without this rule, the record reflects only the sharing that went through a formal channel. Ask for a sample of recent extracts and trace each one back to an authorization.

Subprocessor transfers

Hosting providers, email delivery services, error trackers and backup vendors receive personal information on the organization's behalf. Whether each transfer counts as an authorized disclosure depends on the terms agreed with the customer and the privacy commitments in place, so map every subprocessor to the customer contracts that permit it. When a subprocessor is added or replaced, the change should generate a record that identifies the new recipient and the date it began receiving data. Coordinate this list with the vendor management records used for P6.4.

Law enforcement and legal requests

Subpoenas, court orders and government demands are disclosures that the organization may be required to make, and the record must show the legal basis for each one. Decide who in legal reviews a request, what validity checks apply, and which requests are permitted to be disclosed to the affected individual or customer. Keep the request, the review notes and the scope of what was produced together. Confirm with counsel how these entries should be handled where a notice to the data subject is restricted.

Systems that write and hold disclosure records

Disclosure records come from several places: the application audit trail, the file sharing platform, the secrets and access layer, and the ticketing system where approvals are recorded. Decide which system is the system of record for each type of disclosure and how entries from the others are correlated to it. Self-hosted platforms can supply part of this evidence. For example, Nextcloud's admin_audit app writes additional event information to audit.log in the data directory, or to a path set with logfile_audit. OpenBao audit devices keep a detailed JSON log of API requests and responses, with most sensitive values hashed with HMAC-SHA256. Confirm each log captures the recipient and purpose, since a log that shows only access may not prove a disclosure was authorized.

Decision owners and approval authority

Each disclosure needs a named owner who can approve it, usually the privacy office with input from the business owner of the data and legal counsel for unusual requests. Write down which requests each role may approve and the point at which escalation is required. The authorization step is what makes a disclosure authorized, so the record should capture the approver, the date and the reference to the approval. Auditors commonly test this by selecting disclosures and asking for the approval that preceded them, so an approval that exists only in a chat thread will not satisfy the test.

How an assessor tests the disclosure record

This table compares what an assessor does, what they ask for and where records usually fail when testing P6.2 across an observation period. Read it as a checklist for building a disclosure record that holds up for sampling, cross-checking and consistency over the whole Type 2 window.

Test step	What the assessor does	Common findings
Population and sample	Obtains the population of authorized disclosures of personal information for the period and selects a sample across the window, not only recent items	Population incomplete because disclosures made through email, ad hoc exports or support tickets were never logged
Trace to record	Traces each sampled disclosure to a record showing recipient, data categories, date, purpose and authorization basis	Records exist but lack the recipient, the authorization reference or the date of transfer
Completeness check	Compares the record against outbound transfer logs, API or integration logs and the vendor list to look for disclosures missing from the record	Transfers visible in logs or contracts with no matching record entry
Commitment check	Compares record fields against the details the organization committed to in its privacy notice, contracts or internal policy	Required fields the organization promised to capture are absent or inconsistently filled
Consistency over time	Checks that the same method and fields were applied from the first to the last day of the Type 2 period, since a Type 2 opinion covers operating effectiveness across that span	Logging changed mid-period after a platform or staffing change with no documented transition, producing gaps in some months
Audit trail integrity	Checks that entries and changes to the record are attributable, time-stamped and not silently overwritten	Spreadsheet records edited without version history or with shared logins
Evidence retention	Requests the underlying logs and records for the period, confirming they are retrievable and were retained according to policy	Application or audit logs rotated or purged before the examination ends

How to build the disclosure record step by step

This sequence turns the P6.2 requirement into a working disclosure record: a defined scope, complete records, one system of record with a named owner, timeliness and completeness checks, and periodic reconciliation. Each step ends with an output the auditor can inspect.

Define what counts as a disclosure
Write a short disclosure standard that states which transfers of personal information count as disclosures to third parties, which internal transfers do not, and who may authorize them. Include the categories of personal information in scope and the data subject consent or legal basis that must exist before a disclosure happens. Have privacy, legal and the system owners approve the definition. The step is done when the standard is approved and every team that moves personal data has received it.
Set the fields each record must hold
Specify the data each disclosure record must contain, such as the date and time, the recipient, the categories of personal information, the purpose, the authorization reference (consent record or legal basis), the requester, the approver and the method of transfer. Decide which fields are mandatory so a record cannot be saved without them. The output is a field specification and a sample record that a reviewer can check against the standard.
Map every path that moves personal information out
Inventory each route by which personal information leaves the organization: production APIs, scheduled exports, data warehouse shares, third-party integrations and webhooks, email and file transfers, and manual handling by support or operations staff. For each path, record the owner, the trigger and whether it already writes a log entry. The output is a disclosure path register that lists the gaps where no record is created today.
Designate a single system of record and owner
Choose one system where all authorized disclosure records are kept and assign a named owner accountable for its accuracy. Where possible, feed records into it automatically from the paths in the register rather than relying on memory or chat messages. Platform logs can supply supporting evidence: Nextcloud's admin_audit app writes additional event information to audit.log, and OpenBao audit devices keep a detailed JSON log of API requests and responses with most sensitive values hashed. Confirm with each vendor which events their logs capture and how they are retained before relying on them. The output is a documented system of record, its owner and a list of which sources feed it.
Set the timeliness rule and completeness check
Define how quickly a disclosure must be recorded after it occurs and what a complete record looks like against the field specification. Ask the privacy lead and counsel to confirm the timing rule with reference to the organization's own commitments and any applicable law, because the criteria do not supply a fixed period. Build a completeness check that flags any record missing a mandatory field or an authorization reference. The output is a written timeliness rule and a check that runs against new records.
Reconcile records against source systems
On a set schedule, compare the disclosure record with the source logs for each path in the register, looking for transfers that happened without a record and records that point to transfers that never occurred. Investigate each difference, correct the record, and note the root cause, such as an integration that was never added to the register. Keep the reconciliation results, the sign-off and the corrective actions. The output is a dated reconciliation report that shows exceptions were found, explained and closed.
Review the record and feed corrections back
Have the owner review reconciliation results with privacy and security leads and decide whether the standard, the field specification or the path register needs to change. Update the controls when a new integration, vendor or product feature creates a new disclosure path. The output is a change log for the standard and the register, which shows the record stays current as the platform changes.

Evidence that passes P6.2 and how to keep it current

An assessor testing P6.2 looks for one thing above all: a register that is provably complete for the period under review. Each artifact below feeds that register, and each needs a named owner and a routine that keeps it current between examinations. Build them as a single chain so that every disclosure can be traced from its authorization to the transfer that made it.

The disclosure register and its fields

The register is the core record: one row for each authorized disclosure of personal information, capturing the date, the data subject or population affected, the categories of personal information, the recipient, the purpose and the system or channel used. Check that the fields are mandatory, so that a disclosure cannot be logged without a recipient or purpose. Ask whether the register is a controlled system with access limits and change history, not a spreadsheet anyone can edit. Assign an owner, often in privacy or legal, who reviews new rows against the change log each month.

Authorization basis for each entry

Every row should point to the basis that permitted the disclosure: the data subject's explicit consent (as collected under P6.1), a contract with the recipient, or a legal requirement. Store the reference, such as a consent record identifier, a contract clause or a statute, not a general statement. Rows without a basis are the first exception an assessor raises. Review bases when a contract ends or a consent is withdrawn, and record the date the basis lapsed so the register stays accurate.

Transfer and export logs

Disclosures often happen as file transfers, API calls, exports or database reads, so the register needs evidence from the systems that moved the data. For a self-hosted Nextcloud deployment, the admin_audit app writes additional event information to audit.log in the data directory, or to a path set with logfile_audit. For secrets and credentials used by integrations, OpenBao audit devices keep a JSON log of each API request and response. Confirm the logs capture the recipient and the object shared, and that they are shipped to storage the platform team cannot silently alter.

Reconciliation between logs and the register

Reconciliation compares what the systems show was sent with what the register says was authorized. Run it on a fixed schedule, for example monthly, and match counts by recipient and date range, then investigate every unmatched item. Keep the reconciliation worksheet, the list of exceptions and how each was resolved. Ask whether the reconciliation can be reproduced from raw logs, because an assessor may test a sample by re-performing the match. Automating the comparison with scripts kept under version control makes the procedure easier to rerun.

Sign-off and review records

A reconciliation without a reviewer is weak evidence. Record who prepared each reconciliation, who reviewed it, the date of each sign-off and the outcome, with the reviewer independent of the person who maintains the register where practical. Keep signatures or approval tickets in the same repository as the worksheet. Between audits, confirm that sign-offs continue on the agreed cadence, since gaps in a monthly series are visible to an assessor and often lead to questions about whether the control operated throughout the period.

The written procedure that defines the record

The procedure states what counts as a disclosure, which systems feed the register, who may authorize a disclosure, how bases are checked, how often reconciliation runs and how exceptions escalate. It also links to the related P6.3 record of unauthorized disclosures, so that a disclosure found to be unauthorized moves into that record. Version the procedure, record approval dates and review it at least once a year, and update it when a new system starts disclosing personal information. The assessor will compare what staff actually do against this document.

Showing the assessor a complete population

Auditors test samples, but they first need to know the population the sample came from. Export the register for the full examination period with a system-generated report, record the query or filter used, and confirm the row count matches the source logs. Ask whether any disclosures came from systems outside the register, such as manual email attachments or a vendor portal, and bring those into scope. Keep a dated copy of each export so the population cannot change after the auditor requests it.

How self-hosted open-source logging supports the disclosure record

Logs from self-hosted platforms can show who accessed personal information and when, which is useful evidence for a P6.2 disclosure record. They do not replace the register itself, which must capture the recipient, purpose, date and authority for each authorized disclosure. The cards below describe what two named tools log and what the team must confirm before relying on them.

Nextcloud admin_audit logging

The admin_audit app writes additional event information to audit.log in the data directory, or to a path set with logfile_audit. Its license is AGPL-3.0-only. For P6.2, the useful question is whether the events that matter for disclosures, such as file sharing with external recipients, exports and access by administrators, are among the events captured. Confirm in your own environment which events the app records in your version, where the file is stored, who can read or alter it, and whether it is shipped to a central store. Do not assume the log names the recipient or the legal basis for a disclosure.

OpenBao audit device records

OpenBao audit devices keep a detailed JSON log of every API request and response, including errors. Most sensitive values are hashed with HMAC-SHA256, which limits exposure of secret content while keeping a traceable record of requests. Its license is MPL-2.0. For P6.2, this log can show which identity requested access to a secret that protects personal information and when. Confirm which audit devices are enabled, that failed requests are captured, and that the hashing meets your own review needs, since a hashed value cannot be read back to show what was disclosed.

Confirming logs reach the register

Logs show activity, not authorization. A log entry proves that a system action occurred, but it does not prove the disclosure was approved by the data subject or permitted by the organization's privacy objectives. Build a documented link from each register entry to the log events that support it, such as a request identifier, timestamp and account. Test this link by selecting a sample of disclosures and tracing each one back to its log entries. Record gaps as deficiencies to correct.

Log retention and protection

Logs that support a disclosure record must be kept long enough to cover the period the auditor examines and must be protected from alteration or deletion. Confirm the retention period you set for each source, the storage location and who holds write or delete rights. Restrict administrator access to the logs themselves, and forward copies to a store that the platform administrators cannot silently modify. Document the retention rule in your privacy and logging policies so that the evidence remains available when the auditor asks for it.

Coverage across all platforms

A disclosure can occur through a path that no single platform logs, such as an email export, a manual file transfer or a call to a third party API. Map each channel through which personal information leaves the environment and check whether a log source covers it. Where coverage is missing, decide whether to extend logging, add a manual register entry with a named owner or change the process. Confirm the coverage map is reviewed when systems are added or upgraded.

What meeting P6.2 costs in money and effort

This table breaks down the cost and effort of keeping a record of authorized disclosures, showing who is paid for each component, whether it is one-time or recurring, and what pushes it up or down. Use it to build a written scope and quote request, since no price or duration is published here for this criterion.

Cost component	One-time or recurring	Who is paid	What drives it up or down
Engineering time to build the disclosure register	One-time	Internal engineers or an implementation partner	Number of systems that disclose personal information, and whether a register already exists
Integrations with disclosure paths	One-time, then recurring when paths change	Internal engineers or an implementation partner	Count of APIs, exports, file transfers and sharing features that send data outside the organization
Tooling and licenses	Recurring	Software vendors, or no license fee for self-hosted open-source components	Commercial GRC or logging products versus self-hosted tools such as the Nextcloud admin_audit app or OpenBao audit devices, plus storage and hosting for logs
Log storage, retention and access controls	Recurring	Internal platform team or hosting provider	Volume of logged events, retention period set by policy, and how protected the log store must be
Ongoing evidence upkeep and reconciliation	Recurring	Internal compliance or operations staff	Frequency of disclosures, number of vendors, and how often the register is reconciled against contracts and logs
External review of the design	One-time, optionally repeated	Independent consultant (not the auditor), if engaged	Complexity of the disclosure model and whether the organization wants a readiness check before fieldwork
Auditor sampling and testing effort	Recurring each examination period	Independent CPA firm, under its engagement letter	Number of disclosures in the period, population size, and how complete and well-indexed the register is
Remediation of gaps found in testing	Variable	Internal staff or implementation partner	Number of missing or late entries and whether root causes sit in process or tooling

Who owns P6.2, what a partner prepares and what the auditor tests

The organization owns P6.2 in full. Its own people decide whether a disclosure of personal information is authorized, record the basis for that decision, and keep the register that the criterion requires. A partner can configure the tools that hold the record, but no partner can decide that a disclosure was authorized. Management also signs the description of the system and the representations that the auditor relies on, so the register has to be complete enough to support those statements.

Disclosure decisions: Named owners approve each disclosure of personal information and state the authority for it, such as a data subject's consent, a contract term or a legal demand.
Authorization basis: Written criteria define which disclosures are permitted, who may request them and what documentation must accompany each request.
The register: The team decides which fields each entry carries, such as recipient, categories of data, date, purpose and approver.
Review routines: Someone checks the register on a set schedule for gaps, late entries and disclosures made outside the approval path.
Management assertions: Leaders confirm in writing that the register and the system description are complete for the examination period.

Before fieldwork, confirm who signs each disclosure approval and where the register is stored and reviewed.

Where P6.2 records usually fall short and how to close each gap

Most P6.2 records fail for process reasons rather than missing data. Disclosures happen in inboxes, a single person holds the list, and entries lack a stated authorization basis. The cards below pair each gap with one fix that an assessor can test against the record itself.

Disclosures sent through informal channels

Personal information often leaves through ad hoc email attachments, file shares or chat threads that never reach the register. An assessor testing P6.2 will look for disclosures that exist in transfer evidence but not in the record. Fix this by routing every outbound transfer through one sanctioned path, such as a managed file transfer service or an approved export job, and by logging each transfer automatically. Check the mail gateway and file share logs for personal data flows that the register does not show.

A register that depends on one person

When one privacy analyst or administrator maintains the register by hand, entries stop when that person is on leave or leaves the company, and the record loses its completeness. Assign a named owner and a backup, and write the entry steps into a procedure. Where possible, generate entries from system events rather than from memory, so the record does not rely on any single person's diligence.

Entries without an authorization basis

A P6.2 record that lists a recipient and a date but not the consent, contract or legal requirement that permitted the disclosure cannot show that the disclosure was authorized. Add a required field for the authorization reference to each entry, linked to the consent record or the contract clause. Sample entries during preparation and confirm that each one points to evidence an assessor can open.

No reconciliation against transfer logs

A register can look complete while missing transfers that the systems actually performed. Run a periodic reconciliation that compares register entries against outbound logs such as API gateway records, export job history and SFTP or object storage access logs. Investigate every unmatched transfer, record the outcome, and keep the reconciliation as evidence. In Nextcloud, the admin_audit app can add event detail to audit.log, which gives the reconciliation a source to compare against.

Vendor-side disclosures that never reach the register

When a subprocessor or hosting partner shares personal information on your behalf, the disclosure may be recorded only in their systems. Require each vendor to report the disclosures it makes or causes under your contract, and to send those reports in a set format on a set schedule. Review those reports against your register each cycle, and confirm with each vendor which of its own logs can support the entries.

Questions buyers and practitioners ask about P6.2

How much effort does P6.2 take to meet in a SOC 2?

The effort depends mainly on how many systems, teams and external recipients handle personal information, and on whether disclosures already leave a trail. P6.2 asks for a complete, accurate and timely record of authorized disclosures, so the work is less about building a new system and more about defining what counts as a disclosure, who may approve it, and where each approval is stored. Teams with few recipients and a clear data-sharing approval step usually need less ongoing effort than teams where engineers share exports ad hoc. Ask any quote to break down the discovery of existing disclosure paths, the design of the register, and the recurring review of entries before the auditor's observation period begins.

How long does it take to set up a P6.2 disclosure record?

Setup time is driven by how quickly the organization can agree on the disclosure categories and locate the sources of truth for them. The first stage is an inventory of every route by which personal information leaves the environment, including API integrations, data exports, support tooling and subprocessors. The second stage is defining the register fields and the approval workflow. The third is running the record for long enough that the auditor can see it operating during the examination period, which matters most for a Type 2 report. Any timeline in a written scope should be tied to these stages, and you should confirm with your CPA firm which period it will test.

What does the work need from the internal team?

The work needs a named owner for the disclosure register, a privacy or legal reviewer who can judge whether a disclosure is authorized, and engineering staff who can explain how data leaves each system. Without those three roles, the register tends to be filled in after the fact, which weakens the timeliness part of the criterion. Plan for a few hours of review each cycle from each role, and for someone to reconcile the register against logs and ticket records. Confirm these commitments in the scope before work starts so that approvals are not delayed by staff availability.

Can our own team build and run P6.2 without outside help?

Yes, many organizations build the register in-house, provided they have the time, the privacy knowledge and the engineering access to connect it to their systems. The areas where outside help most often saves time are the initial mapping of disclosure paths, the design of a register that an auditor can sample against, and the independent check that records match actual transfers. Your own team owns the controls and the decisions. If you lack capacity in one of those areas, a partner can prepare systems and evidence for review, but the disclosure decisions and the report remain with your organization and the independent auditor.

What does an implementation partner change about P6.2 readiness?

A partner changes the speed and structure of the work rather than the accountability for it. In a fixed-scope engagement, DeployOpen would plan the register, connect it to self-hosted platform logs and approval records, document the procedure, and prepare the evidence the auditor will request. It does not decide what is an authorized disclosure, and it does not issue any report. Ask for the written scope to list each system covered, each deliverable, and who signs off on the register design. Ongoing support can cover periodic reviews between audits if the organization wants them.

Can the CPA firm build the disclosure register for us?

Usually not. The CPA firm performing the SOC 2 examination is an independent party, and it tests the controls that management designs and operates, so building the register would blur that independence. Auditors can explain what evidence they expect and how they will sample entries, which helps you design the record. Check your firm's engagement letter and its independence policies before asking for any design work. The register itself, its approvals and its review belong to your organization, and a separate implementation partner can prepare the systems behind it.

How DeployOpen scopes and prepares P6.2 evidence

DeployOpen is a Chainscore Labs company that implements self-hosted open-source platforms inside the client's own infrastructure. For P6.2, we prepare the systems and records that hold authorized disclosure entries, while the organization owns the control and an independent CPA firm performs the examination and issues any report.

How we scope

Agree in writing which systems disclose personal information to third parties and which of them must log authorized disclosures.
Define the required record fields, such as recipient, data categories, legal basis, date and approving owner, before any tooling is changed.
Confirm with your auditor which period and evidence samples they expect, since the scope document is fixed before work starts.

How we build

Configure audit logging in self-hosted platforms, for example enabling the Nextcloud admin_audit app and setting a dedicated audit log path.
Route OpenBao audit device output to protected storage so API-level access to sensitive data is recorded and retained.
Build a disclosure register template that links each authorized entry to the consent or contract that permitted it.

How we hand over

Deliver a written runbook describing how authorized disclosures are logged, reviewed, corrected and retained.
Provide a sample evidence pack showing log exports and register entries, mapped to P6.2 and its sibling P6.3 for unauthorized disclosures.
Document what the organization must still perform, including periodic reviews of the register and ownership of approvals.

How we support

Offer ongoing support and upgrades as a retainer after handover, including checks that logging stays enabled after platform updates.
Help the organization answer auditor sample requests from the register and logs without issuing any attestation ourselves.
Confirm with the auditor, in writing, which evidence formats they accept before the examination period begins.