P6.3 Record of unauthorized disclosures: SOC 2 evidence

What P6.3 record of unauthorized disclosures asks for in plain words

P6.3 asks the organization to create and keep a complete, accurate and timely record of unauthorized disclosures of personal information that it detects or that someone reports to it, including breaches. If an auditor asks how you record these events, the answer should point to one place where every such event is logged with its facts, its owner and its outcome, and that record should exist before the auditor arrives, because the auditor will sample real events from the observation period. The criterion sits in the privacy category, so it applies only when privacy is in scope for your SOC 2. If privacy is out of scope, confirm that with your auditor in writing and keep the rest of this page as background for your incident process. The record matters because a disclosure that is never logged cannot be investigated, reported to a regulator or data subject, or learned from. Its absence also breaks the chain that links detection to notification under P6.6 and to incident evaluation under CC7.3 and CC7.4. In practice, each entry should capture what personal information was involved, whose data it was, when the disclosure occurred and when the organization learned of it, how it was discovered, what containment and notification decisions were made and by whom, and where the supporting evidence sits. Ask yourself whether a new team member could reconstruct any single event from the record alone. This is usually hard because detection lives in several places at once: alerts in a SIEM or EDR console, tickets in a service desk, emails from customers, notes from a support engineer and a spreadsheet kept by legal. Each tool was built for its own purpose, so the same disclosure may appear three times with three different timestamps and no shared identifier. Confirm early which systems can surface a potential disclosure, who owns each one, and how a report from a customer or vendor enters the same record. Confirm the exact wording of P6.3 and its points of focus in the AICPA 2017 Trust Services Criteria before you design the process.

Which systems, data and teams the P6.3 record must cover

The P6.3 record is only as complete as its scope. The decisions below determine which events reach the record, who classifies them and which outside parties must send notices in. Confirm each one with your privacy, security and legal owners before fieldwork, because a gap in scope is the most common reason a record looks incomplete to an assessor.

Systems that hold personal information

Start with an inventory of every production system, backup, analytics store and support tool that holds personal information. Each system is a place where an unauthorized disclosure can occur and be detected, so each one needs a defined path into the record. A narrow inventory keeps the record small but risks missing a bucket, export or log store that later turns out to hold personal data. Ask who keeps the inventory current and how new services are added to it.

Detection sources that feed the record

Each detection source determines what reaches the record. A SIEM, EDR platform, data loss prevention tool, support ticket queue and customer reporting mailbox each surface different events, and some will flag a suspected disclosure while others only confirm one. List every source you will rely on, mark which ones can reveal personal information exposure, and decide which alerts open a record automatically. More sources mean more records and more classification work.

Teams that classify and sign off events

Security analysts can triage an alert, but deciding whether it is an unauthorized disclosure of personal information usually needs privacy or legal input. Name the team that classifies each event, the team that approves closure, and the point at which legal or the data protection lead must be involved. Clear ownership reduces back-and-forth and keeps timestamps for each decision, which is the evidence an auditor will sample.

Third parties that must route notices in

Vendors, hosting providers, payment processors and support contractors may hold personal information on your behalf and may learn of a disclosure first. Their notices must reach your incident process and be logged in the same record. Review the notification commitments in each contract and confirm the contact path, because a notice that sits in a vendor's inbox produces no record on your side. Include subservice organizations in this list, since their events can affect your report.

Privacy category scope decision

The P-series criteria, including P6.3, apply only when the organization includes the privacy category in its SOC 2 scope. If it is out of scope, the record of unauthorized disclosures is not tested, although the common criteria on incident handling still are. Confirm the scope decision in writing with the auditor before building the record, because adding privacy later means reconstructing history that the report period did not capture.

How P6.3 differs from the authorized disclosure record and breach notification

P6.3 covers the internal record of unauthorized disclosures, and nothing else. An unauthorized disclosure, including a breach, is logged in the organization's own record of what happened, when it was detected or reported, who was involved, what personal information was affected and what was done about it. It does not belong in the record of authorized disclosures that P6.2 requires. That P6.2 record tracks disclosures the organization made deliberately under its privacy commitments, such as a permitted transfer to a payroll provider. Mixing an accidental exposure into that log would make both records unreliable: the authorized log would overstate what was approved, and the incident would be harder to find when an assessor samples it. Confirm that your authorized disclosure log has a field or status that routes exceptions to the incident case rather than accepting them silently.

P6.3 also sits apart from P6.6, which concerns notifying data subjects, regulators and others. Notification depends on the internal record, because the organization cannot state what was disclosed, to whom and when without it, but notification is a separate obligation with its own deadlines, recipients and content rules that come from applicable law and contracts. A complete P6.3 record does not show that notices were sent, and a sent notice does not prove the record is complete. Assessors will often test the two together, so keep notification decisions and copies of notices linked to the case, with the reason for any decision not to notify. CC7.3 and CC7.4, which cover evaluating and responding to security incidents, draw on the same incident data for triage, containment and recovery.

One case file can serve P6.3, P6.6, CC7.3 and CC7.4 without merging their evidence. Keep a single case with the timeline, the scope analysis and the decision log, then tag each entry with the criterion it supports, and keep notification copies, regulator correspondence and containment tickets as separate attachments. Tools such as DFIR-IRIS can hold the case, its assets, indicators and evidence with an audit trail, which helps show that records were not changed after the fact (see its documentation). Ask your CPA firm early how it expects these records to be presented in the description and tested in the examination, so the case structure matches what the auditor will sample.

How an SOC 2 assessor tests the P6.3 disclosure record

This table sets out how an independent CPA examiner typically tests the P6.3 record, the evidence they ask for, and the findings that come up most often. Read each row as a question the assessor will put to the organization's register of unauthorized disclosures, and use the findings column to check your own register before fieldwork begins.

Test area	What the assessor does and asks for	Common findings to avoid
Population completeness	Obtains the full register of detected and reported unauthorized disclosures for the examination period, then checks it against other sources such as incident tickets, security alerts, customer complaints, vendor notices and legal correspondence.	Disclosures reported by email or phone that never reached the register, or a register that starts after the period begins.
Sample selection	Selects individual entries from the population, including entries from different sources and severity levels, and asks for the underlying records behind each one.	Entries with no supporting record, or samples drawn only from easy, closed cases.
Accuracy of each record	Compares each sampled entry with its supporting evidence: what data was involved, who was affected, how the disclosure happened, and what was done about it.	Descriptions that conflict with the incident ticket, or missing fields such as data categories or affected population.
Timeliness against the organization's procedure	Checks the dates of detection, recording and review against the timeframes in the organization's own written procedure. The assessor measures against your stated procedure, not an external deadline.	Procedure sets a recording deadline that staff routinely miss, or no dates are captured at all.
Link to incident response	For entries that are breaches or incidents, traces the record to the incident ticket, the triage and containment steps, and the related CC7.3 and CC7.4 evaluation and response records.	Breach entries with no linked incident, or incident tickets that never reference the privacy register.
Independent review	Looks for evidence that someone other than the record's author reviewed and approved the entry, and when. Asks who holds approval authority and whether that person had the needed information.	Self-approved entries, reviews with no date or sign-off, or reviewers who were not in the reporting chain.
Follow-up and closure	Confirms that each entry records its outcome, including any notification decision under P6.6, corrective actions and their status, and the closure date.	Entries left open for long periods with no status update, or closures without a stated rationale.
Consistency across the period	Checks that the register was maintained the same way throughout the examination period, that fields and categories did not change without explanation, and that any gaps are disclosed.	Undocumented changes to how entries are classified, or periods with no entries and no explanation of why.

How to build the disclosure record step by step

This sequence turns detected and reported unauthorized disclosures into one complete, timely and auditable record that links to incident response and notification decisions. Each step leaves a named artifact that an assessor can sample and trace.

Define unauthorized disclosure and reporters
Write a short definition of what counts as an unauthorized disclosure of personal information in your environment, including misdirected emails, over-broad exports, access by unapproved parties and breaches. Name who may report one: employees, customers, vendors under their P6.5 commitments, and monitoring tools. The output is an approved definition with a reporter list, signed off by the privacy owner and security lead, so every later record has a shared threshold to apply.
Set one intake path
Route every detected or reported event into a single intake point, such as one mailbox, form or case queue monitored by the security team. Duplicate channels create gaps where an event exists in one inbox and never reaches the record. The output is a documented intake procedure with an owner, a backup owner and a logged first-contact entry for each event, so the population of events starts from one source.
Open one record per event
Create exactly one record for each event, with fields for dates of occurrence, discovery and report, the data categories involved, the affected data subjects or an estimate of their number, the root cause, containment actions and the decisions taken, including whether notification was required and why. Keep the fields mandatory so blank entries are visible. The output is a populated record template in your case management tool, reviewed when the record is first opened.
Agree a measurable timeliness standard
Set internal targets for how quickly each stage must be completed, from intake to triage, triage to record creation, and decision to closure, and state how the organization measures elapsed time. The SOC 2 criteria require a timely record, so the standard must be specific enough to test. The output is a written standard with the clock start and stop points defined, and a report that flags records that breach it. Confirm any regulator or contract timeframes with counsel rather than assuming them.
Link each record to incident response
Connect each disclosure record to the incident ticket that covers containment and investigation, and cross-reference the case timeline so the two describe the same facts. Where the event meets a notification requirement, record the P6.6 decision, the approver, the recipients and the dates notices were sent. The output is a traceable chain from intake to incident to notification, so an assessor can follow one event through CC7.3 and CC7.4 and into P6.6 without reconstructing it.
Run a periodic completeness check
Compare the population of disclosure records against source systems at a set interval: security alerts, data loss prevention and access logs, helpdesk and privacy inbox tickets, vendor notices and legal correspondence. Investigate every event found in a source but missing from the record. The output is a dated reconciliation worksheet with each discrepancy resolved or logged, which proves the record is complete rather than only accurate for the events someone remembered to file.
Review and retain the record for assessors
Have the privacy owner review sampled records for accuracy and consistency, and retain the record population, reconciliation worksheets and timeliness reports under your retention schedule. Ask your independent CPA firm early which population and sampling approach it expects, since the auditor selects the sample. The output is a versioned record set that can be produced for the examination period without manual rebuilding.

Evidence that passes a P6.3 test and how to keep it current

A P6.3 test asks whether the organization can show a complete, accurate and timely record of every unauthorized disclosure it detected or was told about. The artifacts below connect so that an assessor can start from one event and trace it to its alerts, decisions, evidence and closure. Each one needs a named owner and a routine that keeps it current between audits.

Written disclosure procedure

This document defines what counts as an unauthorized disclosure of personal information, who logs it, how quickly it is logged, and who approves closure. Assessors check that the procedure matches what staff actually do, so a procedure that names a tool or role nobody uses will produce exceptions. Review it at least once a year and after any incident that exposed a gap, and record each approved version with its date. Confirm that the procedure links to the incident response and breach notification steps covered under CC7.3, CC7.4 and P6.6.

Case register with unique identifiers

The case register lists every detected or reported disclosure, each with a unique identifier that never gets reused. In DFIR-IRIS, each case is kept as one record of assets, indicators of compromise, tasks and evidence with a full audit trail, which gives the register a single source for the count of events. Confirm in your own environment that case identifiers are not deleted or renumbered, and that closed cases remain searchable for the full retention period set in your policy.

Linked tickets and alerts

Each case should point back to the alerts, customer reports, vendor notices and tickets that started it, so an assessor can see how each event entered the record. DFIR-IRIS can triage alerts from SIEM, EDR and REST sources into cases, which reduces the chance that a disclosure signal is dropped between tools. Test the intake path by sending a sample alert from each source and confirming that a case is created, and check how vendor notifications received under P6.5 are routed into the same register.

Investigation timeline

The timeline shows when the disclosure occurred, when it was detected, when it was reported internally, and when containment and notification happened. Assessors compare these timestamps with the timeliness expected by the procedure and with any notification deadlines in contracts or regulations. DFIR-IRIS builds a consolidated timeline from case data, so entries should be made as events happen rather than reconstructed later. Confirm that time zones are consistent across sources and that manual corrections are recorded in the audit trail.

Evidence log with hash and custody

The evidence log records each artifact collected, such as logs, screenshots, emails and exports, with its SHA-256 hash value and a chain of custody that names every person who handled it. DFIR-IRIS logs evidence with SHA-256 verification and custody entries, which lets you show that a file has not changed since collection. Confirm the verification feature works in your deployment by re-hashing a sample file and comparing the result, and keep the custody entries for the full retention period.

Breach decision memo

For any event that involves personal information, a written memo records whether the event is a breach, which data subjects and regulators are affected, which notification requirements apply, and who made the decision and when. This memo links the P6.3 record to the notification work under P6.6, and assessors often read it to judge whether the organization applied its own criteria consistently. Ask counsel to review the template, store the signed memo with the case, and confirm that the case timeline shows the decision date.

Closure review and completeness reconciliation

Closure review confirms that the case has its root cause, containment steps, corrective actions and approvals filled in before the case is marked closed. The completeness reconciliation compares the case register against independent sources such as SIEM alert counts, customer complaint logs and vendor notice inboxes to find events that never became cases. Run the reconciliation on a fixed schedule, record the result, and investigate any gap. DFIR-IRIS can generate reports from case data, which helps produce these summaries, but confirm the report template covers every field your assessor will ask about.

What meeting P6.3 costs in money and effort

This table breaks down the money and effort behind a P6.3 disclosure record by cost component, showing who is paid, whether the cost is one-time or recurring, and what pushes it up. Use it to structure a quote request, since no supplied fact gives dollar figures or durations for these items.

Cost component	Who is paid or who does the work	One-time or recurring	Main cost drivers
Case tooling or licenses	Software vendor or internal platform team	Recurring if licensed; one-time setup if self-hosted	Named users, hosting, and whether the case tool is open source (DFIR-IRIS is LGPL-3.0-or-later, so confirm license terms with counsel)
Engineering to integrate detection sources	Internal engineers or implementation partner	One-time, with ongoing maintenance	Number of SIEM, EDR and REST sources feeding cases, and how many need custom parsing
Intake and timeliness process design	Privacy, legal and security staff, with an outside adviser if engaged	One-time, with periodic review	Number of disclosure types, notification obligations by jurisdiction, and who must approve records
Recurring evidence upkeep	Internal compliance or security operations staff	Recurring	Volume of disclosure events, quality of case notes, and how often records are reviewed
Completeness reconciliation	Internal staff, sometimes with an external reviewer	Recurring, usually at a set interval	Number of data stores and third parties that can disclose personal information, and how many feeds must be matched
External testing or review of the process	Independent assessor or implementation partner	Recurring or per engagement	Scope agreed in writing, number of sources reviewed, and whether tabletop exercises are included
Auditor sampling and fieldwork	The CPA firm conducting the SOC 2 examination	Recurring with each examination period	Population size of recorded disclosures, number of exceptions, and readiness of evidence
Third-party coordination	Internal legal, procurement and vendor managers	Recurring	Number of vendors with access to personal information and how their notices reach the record

Who owns the P6.3 record, who can prepare it and who tests it

Your organization owns criterion P6.3. That means it owns the decision about what counts as an unauthorized disclosure of personal information, who must be told when one is detected or reported, and how the record is kept complete, accurate and timely. Management also owns the description of the system that the auditor reads, so the record has to match what the organization says it does. A partner or auditor can support these tasks, but they cannot make the calls or stand behind them.

Procedure and decisions: Define what triggers an entry, who classifies it, who approves closure and how breaches are escalated to privacy and legal leads.
Record ownership: Name the person accountable for the register and for reviewing entries before they are relied on.
Personal information scope: Decide which data sets, systems and third parties fall within the record.
Staff training: Make sure support, engineering and vendor-management staff know how to report a suspected disclosure.
Operating evidence: Keep the record running day to day so that entries exist for the whole observation period in a Type 2 examination.

Confirm with your counsel and privacy lead which entries feed notification decisions under P6.6, since that link shapes what the record must capture.

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

A P6.3 record fails less often because it is missing than because it is incomplete, late or unverifiable. The gaps below share one root cause: the record is treated as a document written after the fact rather than a working log that runs alongside incident handling. Each fix turns a habit into a control that an examiner can test.

Disclosures handled in chat or email

Staff often confirm a disclosure in a message thread, a ticket comment or a phone call, then move on. Nothing in the record shows what was disclosed, to whom, or on what authority. Route every reported or suspected disclosure into one case intake, even if it turns out to be a false alarm, and require the intake to name the data involved and the recipient. Check a sample of recent chat threads against the record to see whether anything slipped through.

Customer-reported breaches missing

A record may capture what the security team detected while leaving out incidents that a customer, vendor or data subject reported first. Those reports often arrive through support queues or account managers. Define a single intake path for external reports and confirm with support and account teams that they know to use it. Test by tracing a few external complaints forward to see whether each one has a matching record.

Timestamps that cannot show timeliness

A record with only a close date cannot show when the disclosure was detected, reported or contained. Capture separate times for detection, reporting, triage and containment, each in one time standard. Without these fields, an examiner cannot judge whether the organization acted in time under its own commitments. Ask the team to show how a timestamp was set, not only what it says.

No link to the notification decision

Many records describe what happened but not why the organization did or did not notify affected data subjects, regulators or customers. Add a required field that points to the notification decision, the reasoning, the approver and the date. This ties P6.3 to P6.6 and shows the examiner that the record drove the response. Confirm the notification obligations that apply to each data set before relying on the field.

No periodic completeness check

A record can look correct for every entry it contains and still miss whole categories of events. Assign an owner to reconcile the record each period against sources such as the help desk queue, SIEM alerts, vendor notices and the access logs for systems holding personal information. Keep the reconciliation itself as evidence, including the items it found and how they were resolved.

Records edited after closure

Closed records that can be changed without a trace undermine every other field. Restrict edits to closed cases, require a reason for each change, and keep the original value alongside the revision. An audit trail with user, time and before-and-after values lets an examiner confirm that the record reflects what was known at the time. Ask the platform owner to show the audit log for a closed case during testing.

Questions buyers ask about the P6.3 disclosure record

What does it cost to keep a P6.3 disclosure record?

The cost is mostly the time of the people who run the record and the time spent preparing evidence for the examination, not a fixed fee for the criterion itself. Costs fall into three groups: internal staff time to define the record fields, triage detected events and close out entries; any tooling licenses or hosting; and external help, such as an implementation partner who prepares the case workflow, or the CPA firm's examination fees. No supplied figure gives a price for this work. When you request a quote, ask the provider to separate one-time setup (defining the record, building the workflow, backfilling existing entries) from recurring work (monthly review, quarterly testing of the log, support for each examination period). The main drivers are how many disclosure events you handle a year, how many systems and vendors touch personal information, and whether the process already exists in your incident response program.

How long does it take to set up before the audit window opens?

Set-up time depends on how far your incident and privacy processes already go, so no duration can be stated for every organization. In a Type 2 examination, the auditor tests operating effectiveness over a period, so the record must be running for that whole period before the examination window begins. Work backward from your planned window: define the record fields and ownership, connect the intake sources (incident queue, customer reports, vendor notices), run the process through at least one real or tabletop event, and confirm that entries are reviewed on the schedule you have written. Ask any implementation partner to propose a written timeline tied to your examination dates, and confirm with your CPA firm whether they want the process operating before the period begins.

What must our team supply to build the P6.3 record?

Your team owns the criterion. The record needs input from several roles:

Privacy or legal, to define what counts as an unauthorized disclosure of personal information and which reports must be recorded.
Security operations, to route alerts, tickets and incident reports into one place and to keep the timeline accurate.
Engineering and data owners, to identify which systems hold personal information and to confirm what was exposed.
Vendor management, to pass on notices from third parties under their contracts.

An implementation partner can prepare the workflow, case structure and evidence trail, but cannot decide whether an event was a disclosure or what was notified. Confirm with your legal and privacy leads which decisions they will sign off on and record those approvals in the process.

Can we keep a P6.3 disclosure record in-house?

Yes, an organization can run this record in-house, provided it owns the criterion and can show consistent operation. The work is documentation discipline more than specialist tooling: a defined definition of disclosure, a single register, clear owners, timestamps, and periodic review by someone outside the day-to-day process. In-house teams often struggle with three points: entries recorded late or not at all when events are handled informally, gaps between the privacy team and security operations, and reviews that never happen after the first few months. Assess your capacity against those three points. If they are weak, bring in outside help for the process design and a readiness review, and keep the decisions in-house.

Do we need a single tool to meet the P6.3 criterion?

No. The criterion asks for a complete, accurate and timely record, not a particular product. A spreadsheet, a ticketing system or a case management platform can each serve, provided the entries are complete, versioned and traceable. A dedicated case management tool helps when volume is high or when you need evidence handling. For example, DFIR-IRIS (licensed under LGPL-3.0-or-later) keeps each case as one record of assets, indicators, tasks and evidence with an audit trail, and builds a consolidated timeline. Confirm with your examiner whether the tool's audit trail and access controls satisfy your evidence expectations, because the tool does not make the process compliant on its own.

How does the P6.3 record differ from the P6.2 authorized disclosure record?

P6.2 covers authorized disclosures, where personal information was shared with a third party for a permitted purpose and the record shows that the disclosure was made. P6.3 covers unauthorized disclosures, including breaches, that were detected or reported and that must be recorded regardless of whether they were later confirmed. The two records use different triggers and different owners, and a single register can hold both if each entry is clearly labeled. Most organizations keep P6.3 tied to incident response, because detection and reporting of unauthorized disclosures usually arrive through security channels. Document the boundary between the two records so the auditor can see how events are classified.

What will the auditor ask for in a sample of P6.3 entries?

The auditor typically selects a sample of recorded disclosures and unauthorized disclosure reports from the examination period, then checks each entry against its source. Expect requests for the original alert or report, the timestamps showing when it was detected and recorded, the investigation notes, the decision on whether it was an unauthorized disclosure, and any notification or remediation steps tied to it. The auditor also looks for evidence that the record is complete, meaning that events were not omitted, and that reviews happened on schedule. Exact sampling methods are set by the examining firm and the examination's testing plan, so confirm them with your CPA firm before fieldwork begins.

How DeployOpen scopes and prepares the P6.3 record

DeployOpen prepares the systems and evidence behind a P6.3 record inside the client's own infrastructure, so the organization keeps a complete, accurate and timely log of unauthorized disclosures that an independent CPA firm can examine. DeployOpen does not issue SOC 2 reports; the examining firm does.

How we scope

We agree in writing which systems, teams and disclosure channels feed the P6.3 record before work starts.
The written scope names the intake sources for reported disclosures, such as security mailboxes, SIEM alerts and vendor notices.
Engagements are fixed-scope, with deliverables and timelines confirmed in writing; ongoing support is available as a retainer.

How we build

We configure a self-hosted case management platform, DFIR-IRIS, so each disclosure becomes one case with assets, tasks and evidence.
We set up an audit trail and a case intake workflow so every entry shows who recorded it and when.
We connect alert sources such as SIEM and EDR into case triage so that reported and detected disclosures are logged on time.

How we hand over

We document the record procedure, case fields and roles so the organization can run it without DeployOpen.
We produce sample case records and report templates that show the examiner the entries, timelines and evidence handling.
We walk the client's named owners through the record, the evidence log and the open items before handover.

How we support

We can review new disclosure cases against the documented procedure as part of an agreed retainer.
We update the platform, case templates and intake connections when the client's systems or notification duties change.
We confirm with the client's CPA firm which record fields and evidence the examiner expects before fieldwork begins.