What P6.7 asks for when a data subject requests an accounting
When a SOC 2 includes the privacy category and a data subject or customer asks what personal information is held about them and who has received it, P6.7 is the criterion that expects the organization to answer. In plain terms, it asks the organization to give data subjects, on request, an accounting of the personal information it holds about them and of its disclosures of that information. The criterion addresses a specific risk: personal information shared with third parties that nobody can trace, so that the organization cannot say who holds a person's data, for what purpose, or when it was sent. An assessor will test whether a request can be answered from records rather than from memory or a manual search of inboxes.
The difficulty is that an accounting is only as good as the records beneath it. The answer depends on the authorized disclosure records covered by P6.2 and on the unauthorized disclosure and breach records covered by P6.3, so an organization that does not log transfers to processors, subprocessors, or integrated services cannot produce a complete list. It also depends on locating personal information across production databases, backups, analytics platforms, support tools and exports, which is hard when no inventory of personal information exists. Before the examination, the reader should confirm with the auditor how the points of focus on responding to requests, identifying types of personal information and handling processes, and capturing and communicating requests will be evidenced in their environment.
Which systems, data and third parties P6.7 covers
P6.7 work grows or shrinks with a handful of scoping choices made before evidence collection starts. Each choice below changes which systems, records and people the accounting process must reach, so settle them in the written scope and the system description first.
Whether the privacy category is in scope
Privacy is one of five categories and adds P1 to P8 only when included. P6.7 is only tested if the privacy category is in the examination, so confirm the category decision with the CPA firm before building a request process. If privacy is out of scope, the work described here is not part of the report, though customer contracts may still ask for it.
Personal information stores in the boundary
Every database, object store, data warehouse, log pipeline, backup and support tool that holds personal information about data subjects must be known. An accounting response is only as complete as this inventory, so map where identifiers such as names, emails and account numbers land, including copies made for analytics or testing. Ask the auditor how they expect the inventory to be kept current.
Processors and subservice organizations
Third parties that receive personal information from your systems, such as hosting providers, email delivery services and support platforms, create disclosures that may need to appear in the accounting. Record each transfer with the recipient, the data category and the date, and identify which vendors are carved out as subservice organizations versus covered in your own controls.
Controller versus processor role
If your organization decides why and how personal information is used, it acts as controller and answers data subject requests directly. If you process data on a customer's instructions, the customer is usually the party that receives the request, and your role is to route it and support the response. Confirm the role for each product and contract, because the same data set can have different roles across customers.
Self-hosted deployments outside your boundary
When customers run your software in their own environment, personal information may sit outside systems you operate. Decide whether those deployments are in scope for your report or handled through the customer's own controls and complementary user entity controls. Document the division of responsibility so the accounting process does not promise data you cannot retrieve.
Authoritative sources for disclosure records
An accounting of disclosures depends on a record of disclosures that is complete and dated. Identify which system is the authoritative source, such as a disclosure log, the ticketing system or the vendor register, and decide how entries from support staff, automated integrations and ad hoc exports reach it. Test a sample of disclosures against the source systems before the observation period begins.
How an assessor tests the accounting process
The assessor starts by walking the accounting process from end to end, from the moment a request arrives to the response sent back to the data subject. The walkthrough confirms that the process is documented, that people know their roles, and that the system and the workflow match what management describes. In a Type 1 examination, the assessor evaluates whether the design of these controls is suitable as of a specific date. In a Type 2 examination, the walkthrough supports the testing of operating effectiveness over the full observation period, because the assessor needs to know what the controls are supposed to do before checking whether they did it.
- Process documentation: A written procedure that names the intake channel, the owner, the identity checks, the search steps and the response format.
- Identification of personal information types: Evidence that the organization knows which systems hold personal information about data subjects, such as a data inventory or system list.
- System demonstration: A live or recorded run of a request from intake to closure, showing the ticket, the search and the response.
- Role clarity: Named owners for intake, fulfillment and approval, with evidence that they understand their responsibilities.
- Change awareness: An explanation of how changes to systems that hold personal information are reflected in the process.
Before the walkthrough, confirm that the procedure matches the tooling in use, since a mismatch is one of the most common reasons an assessor raises questions at this stage.
For operating effectiveness, the assessor selects requests from the period under review and traces each one through the process. The assessor does not test the process in the abstract. The assessor looks for proof that each sampled request was logged, verified, searched across the relevant systems, answered within the timeframe the organization committed to, and closed with a record of what was provided. Sample sizes are set by the assessor according to their own methodology and the population of requests, so the organization should ask the assessor to confirm how the sample will be drawn.
- Complete request population: A full log of requests received in the period, so the assessor can confirm that the sample comes from all requests and not only those someone remembers.
- Identity verification: Records showing how the requester was authenticated before personal information was disclosed.
- Search evidence: Queries, system exports or checklists showing which systems were searched for each request.
- Response records: Copies of the response sent, the date sent, and any exemption or denial with its stated reason.
- Timeliness: Timestamps that allow the assessor to compare response dates with the organization's stated commitment.
Common findings include requests logged in email but missing from the tracker, searches that cover only the primary database, and responses sent without a record of what was disclosed.
The accounting covers disclosures of personal information as well as the information itself, so the assessor also tests the records that show to whom personal information was disclosed. This testing ties the accounting to the disclosure controls in the P6 group, including the record of authorized disclosures. The assessor usually takes a sample of disclosures from the period and checks whether each one appears in the accounting records with the recipient, the date, the purpose and the category of information shared. Where a disclosure was made to a vendor that processes data on the organization's behalf, the assessor may also ask how that vendor relationship is captured.
- Disclosure register: A record of disclosures showing recipient, date, category of data and purpose.
- Source reconciliation: Evidence that the register draws on integration logs, export jobs, API calls and vendor transfers, not only manual entries.
- Vendor and subprocessor linkage: Links between disclosure records and the third parties named in contracts and privacy commitments.
- Completeness checks: Comparisons between system logs and the register that show gaps are identified and corrected.
- Accuracy checks: Sampled entries compared against the underlying transfer records.
Common findings include disclosures made through automated pipelines that never reached the register, and registers that record a vendor name without the categories of data shared. Confirm with the assessor whether they expect the register to be reconciled to system logs and how often.
How to build an accounting process that answers requests
This sequence turns P6.7 into a working process: a defined way in for requests, a map of where personal information and disclosures live, a link to the disclosure records, a fixed response, and a rehearsal before a real request arrives.
Define request intake and identity verification
Decide how a data subject can ask for an accounting, which channels are accepted, and who logs each request. Set out how the requester is authenticated before any personal information is returned, and how the request is routed to a named owner. Done when the intake procedure is written, the channels are published in the privacy notice, and every request receives a logged reference that can be traced from receipt to close.
Inventory where personal information and disclosures live
Map the systems, databases, backups, logs, analytics tools and vendors that hold personal information, and note which ones have shared it outside the organization. Record the types of personal information held in each location and the process that creates, changes or deletes it. Done when the inventory is reviewed by the data owners and each system has a named contact who can search it for a specific individual.
Link the workflow to the P6.2 and P6.3 records
Connect the request workflow to the records of authorized disclosures (P6.2) and of unauthorized disclosures, including breaches (P6.3). Confirm that each record captures the recipient, the date, the category of information and the purpose, so that a search for one individual returns a complete list. Done when a test lookup on a sample individual returns every disclosure entry the records hold, and gaps are assigned to an owner for correction.
Set response content and ownership
Define the fields the accounting response must contain, such as the categories of personal information held, the disclosures made, the recipients and the dates, and the process for explaining any limits on what is returned. Assign who approves each response, typically privacy and legal, with a documented review step. Done when a response template exists, each field has a source system, and the approver is named in the procedure.
Test the process with a mock request
Run a mock request for an illustrative individual through intake, verification, system searches, record matching and response approval. Record every step, the time each takes, any system that could not be searched and any disclosure missing from the records. Done when the mock produces a complete response draft, the gaps are logged as corrective actions with owners, and the procedure is updated to reflect what the test showed.
Keep evidence for the examiner
Retain the completed mock request, the inventory, the workflow records, the response template and the corrective action log. These records show the auditor how the process operates and how it was tested. Done when the evidence set is stored in a location the audit team can access, and the owner confirms it covers intake, search, record matching, approval and response.
How the request flow connects to disclosure records and data stores
A P6.7 accounting is only as complete as the records behind it, so the request flow should be designed backward from the disclosure log. The lifecycle runs in six steps: capture the request in a single intake channel, verify that the requester is the data subject or an authorized representative, search every data store that may hold the person's information, pull the disclosure history from the disclosure log, compile the findings into the response, and log the request, its handling and its delivery date. Each step needs an owner and a written procedure, and the intake record should carry a unique request identifier that follows the request through every later step. Confirm with the organization's counsel which disclosures and data categories must appear in a response, because that decision sets what the search and the disclosure pull have to return.
The accounting depends on the quality of disclosure logs. The disclosure record step asks the team to answer who received the person's information, when, for what purpose and under what authority, and those answers come from logs written at the time of each transfer. Common gaps include API integrations that send data to a vendor without writing a log entry, support staff who export records to a spreadsheet, and sub-processors added through a change that nobody recorded. A request is often the first time these gaps surface, so a team should test the log before a request arrives by picking a sample of recent transfers and confirming that each one has a matching entry with the recipient, date and purpose populated. The data store search is where the inventory of personal information meets reality. Map each store, including backups, analytics warehouses, logs and exports, to the fields it holds and to the system of record for each field. In a self-hosted platform, that map usually lives in the infrastructure team's configuration and data catalog, and the search should query those stores directly with documented queries rather than relying on memory. The diagram that follows shows these connections between intake, verification, data stores, disclosure records and the response, so that each arrow can be checked against a real system during planning.
Evidence that passes an assessor's review of P6.7
An assessor testing P6.7 looks for records that show requests were received, verified, traced to the right data and answered on time. The cards below cover the evidence set that connects those steps, and each one needs a current, sampleable record before fieldwork begins.
Request log with timestamps
A single register of every accounting request, with the date received, the date identity was confirmed, the due date, the date the response was sent and the owner. Assessors usually select requests from the period under review and trace each one through the log, so gaps between receipt and response are what they examine first. Keep entries for rejected or withdrawn requests too, with the reason. Review the log monthly for requests approaching their deadline, and confirm that the timestamps come from the ticketing or case system rather than manual entry.
Identity verification records
Records showing how the organization confirmed that the requester was the data subject or an authorized representative before releasing an accounting. Keep the method used, the documents or account checks relied on, and who approved the match. Assessors sample requests and check that verification happened before any personal information left the organization. Confirm with counsel what your jurisdictions require for verification, and store verification artifacts with the same access controls applied to the personal information itself.
Data inventory mapping
A map from each category of personal information to the systems that hold it, the processes that use it and the third parties that receive it. This is what allows the organization to say what it holds about a person and where it went. Assessors compare the inventory against a sample of accounting responses and against system configurations. Update it when a new system, data flow or vendor is added, and record the date of the last review so the assessor can see the map was current during the period.
Disclosure register extracts
Extracts from the record of authorized disclosures, filtered to a named data subject, showing each recipient, the date, the purpose and the category of data shared. The accounting depends on this register being complete, so assessors test it against a sample of disclosures and check that the extract matches what the response reported. Keep the extract query and its run date so the output can be reproduced for the assessor, and confirm with the register owner that disclosures from integrations and support tools are captured.
Response templates with approvals
Standard response letters and accounting formats, each with a version number, the approver's name and the approval date. Templates show that responses follow a consistent, reviewed structure rather than ad hoc wording. Assessors check that the response sent for a sampled request used the approved template in force at that time, and that changes to the template went through review. Keep prior versions available so historical responses can be matched to the template they used.
Test request record
A documented test in which the team submits a sample accounting request end to end, from intake through verification, data retrieval and response, and records each step with dates and results. Running this test before the examination period shows the process works and gives the assessor a walk-through. Record the defects found and their fixes, and repeat the test after any change to systems or the request process. Confirm with the audit firm whether it wants a test performed within the examination period or before it.
What meeting P6.7 costs in money and effort
This table breaks down the money and effort behind P6.7 by cost component, showing who is paid, whether the cost is one-time or recurring, what drives it, and how to keep it down. No prices or durations are given because none are supplied for this topic, so use the table to shape your quote requests. The main takeaway is that most of the cost comes from building request-handling and disclosure records, and keeping them current each audit period.
| Cost component | One-time or recurring | What drives it | How to keep it down |
|---|---|---|---|
| Tooling and licenses | Recurring | Commercial privacy request platforms, data discovery scanners and GRC suites priced by user, data volume or module | Use self-hosted open-source ticketing, workflow and data catalog tools inside your own infrastructure to avoid license spend, then confirm they meet your evidence needs |
| Data mapping and inventory build | One-time, then recurring upkeep | Number of systems, databases, backups and third-party feeds holding personal information | Start with systems that hold the most personal data, and tie the inventory to existing asset records |
| Request intake and accounting tooling | One-time build, recurring operation | Number of intake channels, identity checks, and how disclosure logs are queried across systems | Standardize one intake path and one disclosure log schema before integrating additional sources |
| Engineering time | One-time, with ongoing changes | Connectors needed to pull records from each system, and changes whenever new services or processors are added | Plan connectors around the systems with the largest personal data footprint, and use infrastructure as code so changes are recorded |
| Evidence upkeep | Recurring | Volume of requests, number of disclosure events, and how often the data inventory changes | Log requests and disclosures automatically at the point they occur rather than reconstructing them later |
| External review | Recurring, usually once per audit period | Scope of the examination, the auditor's depth of testing, and whether an outside advisor reviews your procedures first | Ask the auditor early which evidence they expect so that preparation work is not repeated |
| Auditor sampling effort | Recurring, per examination | Population size of requests and disclosures, the observation period, and the number of exceptions found | Keep complete, sortable records so the auditor can select samples without manual reconstruction |
Who owns the accounting process, who can build it and what the auditor checks
Your organization owns the P6.7 control. Your privacy function decides what counts as an accounting request, who verifies the requester, which systems hold personal information about that person, and what the response contains. Those decisions are management decisions and they must be recorded, because the auditor will ask how the process was designed and who approved it. Your team also signs off on each response before it leaves the organization.
- Process ownership: A named owner maintains the procedure, the escalation path and the list of systems in scope.
- Requester verification: Your team defines how identity is confirmed before personal information is disclosed in an accounting.
- Response decisions: Your team decides what is included, what is withheld and how disclosures to third parties are described.
- Sign-off records: Approvals, dates and reasons for exceptions are kept as evidence.
- Regular review: Management reviews the process on a schedule and after material changes to systems or vendors.
Confirm with your CPA firm which of these records they will sample during the examination period so your team builds them from the start.
An implementation partner can help build the machinery behind the process. DeployOpen, for example, works inside the client's own infrastructure to prepare the request workflow, map where personal information lives and how disclosures are logged, and assemble the evidence the auditor will request. This work is preparation. The partner does not decide the control design on the organization's behalf, does not approve responses and does not issue any report or opinion.
- Workflow build: Ticketing or case management steps that capture, identify and route each request to the owner.
- Data mapping: Documentation of the systems, databases and third-party recipients that hold or receive personal information.
- Disclosure logging: Configuration that records what was disclosed, to whom and when, so the accounting can be produced.
- Evidence packs: Exported logs, tickets and approval records organized by request for the auditor.
- Handover: Runbooks and training so your staff can operate the process without the partner.
When you request a quote, ask for the written scope, the named deliverables and which parts remain with your team after handover.
The CPA firm performing the SOC 2 examination is the only party that tests the control and expresses an opinion on it. Under the AICPA attestation framework, the service auditor obtains written representations from management and then gathers its own evidence. The auditor does not design the process for you, and a firm that designs the control it later tests creates a conflict that can affect the report. Independence is the line that separates preparation from assurance.
- Design evaluation: The auditor assesses whether the process, as documented, addresses the criterion and its points of focus.
- Operating tests: For a Type 2 report, the auditor samples requests across the observation period and checks the evidence against the procedure.
- Exceptions: Missed deadlines, incomplete accountings or unlogged disclosures are reported as exceptions in the report.
- Representation letter: Management confirms in writing that the description and the control are accurate.
- Report issuance: Only the CPA firm issues the SOC 2 report.
Ask your auditor early how they will test P6.7 and whether they accept evidence exported from the tools you plan to use.
Where accounting processes fall short at audit
Most P6.7 failures are not caused by a missing response process. They come from gaps upstream: nobody knows where personal information lives, disclosures to processors are not logged, and requesters are not verified before records go out. Each card below names one gap and the check that closes it.
No inventory of personal information stores
An accounting is only as complete as the list of places it searches. Many teams keep customer records in a production database, but also in logs, exports, support tickets, analytics warehouses and backups. Build a data inventory that names each store, its owner and the personal information types it holds, then test one request end to end against it. Ask the auditor which systems they expect you to cover before the examination period starts.
Disclosure logs that miss processor transfers
Teams often record disclosures to customers and regulators but overlook transfers to hosting providers, email services, support platforms and other processors that act on the organization's behalf. For P6.7 these transfers still belong in the accounting. Reconcile the disclosure log against the vendor list and the data flows in the inventory, and confirm which transfers the organization considers disclosures under its own privacy commitments.
Unverified requesters
Sending an accounting to someone who has not been authenticated can itself be a disclosure of personal information. Before a request is fulfilled, confirm the identity of the requester through a method proportionate to the sensitivity of the data, and record how that verification was done. Keep the verification step in the request ticket so an examiner can see that it happened for each sampled request.
Responses sent without review
An accounting that is generated by a script and sent automatically can omit systems, misstate dates or list recipients incorrectly. Add a documented review step by someone who is not the requester handler, and record the reviewer, date and any corrections. The review record is often the evidence an auditor asks for when testing whether responses are complete and accurate.
Request intake spread across channels
Requests for an accounting may arrive by email, web form, support chat or through a customer's own contact channel. When intake is not centralized, some requests are never logged and their response dates cannot be tested. Route every channel into one ticketing queue with a timestamp, and confirm that the queue captures the request before any work starts.
No tested example before the examination
Organizations often assume the process works until an auditor selects a sample. Run at least one full accounting for an internal test identity before the examination window, following the written procedure and the inventory. Keep the test record, note what failed and show the fix. Confirm with your auditor how they plan to test P6.7 across the period, including whether they want evidence from a sample of real requests.
Questions buyers ask about P6.7
How much effort does P6.7 take to meet in a SOC 2 examination?
The effort depends mostly on how many systems hold personal information and how many disclosures the organization already tracks. P6.7 asks the organization to answer requests from data subjects with an accounting of what it holds about them and where it has sent that information. If the data inventory and disclosure records already exist, the work is mainly documenting the request process and testing it. If personal information is spread across many applications, backups and vendor systems with no shared inventory, the effort rises sharply because each source must be found before any accounting can be produced. No fixed figure is reliable without a scoping review. Ask any consultant or DeployOpen to show which systems, data stores and disclosure records the scope would cover before agreeing to a quote.
How long does it take to build a P6.7 process?
The timeline is driven by the state of the data inventory, not by the criterion itself. Organizations that already know where personal information lives and who receives it can usually define the request workflow quickly. Organizations without a current inventory need time to map systems, confirm data flows with product and engineering teams, and agree who owns each source. Because P6.7 is tested over a period in a Type 2 examination, the process must also operate consistently for the whole observation window, so the build phase should finish with enough time for the process to produce real requests and records before fieldwork starts. Confirm the expected timeline in writing with your auditor and implementation partner, since the auditor sets the period the evidence must cover.
Can our team prepare P6.7 evidence without outside help?
Often yes, if the team has someone who owns the privacy process and access to engineering. The work is documentation, tooling and testing rather than a specialized audit skill, but it is easy to miss sources. The most common gaps are backups, analytics platforms, support tools and third-party processors that hold personal information but sit outside the main application. A useful self-check is whether the team can take one data subject, locate every record, and show every recipient within a short working session. If that proves difficult, outside help can focus on the inventory, the request workflow and the evidence trail. Remember that DeployOpen prepares systems and evidence but does not issue audit reports, and the CPA firm performing the examination makes the determination.
What does P6.7 require from engineering and legal?
Engineering owns the technical part: knowing where personal information is stored, being able to query those stores by data subject identifier, and keeping logs that show which external parties received data. Legal and privacy owners define what the accounting must contain, how requests are verified, what exceptions apply, and how responses are worded and approved. In practice, both teams need to agree on a few points before building:
- The systems and data stores in scope, and who maintains each inventory entry.
- The identifiers used to find a person's records across systems.
- The format of the accounting, the response deadline and the approval step.
- How disclosures to processors and other third parties are logged at the time they happen.
Without this shared model, responses tend to be incomplete, and the auditor will test whether they are.
Can a consultant prepare the P6.7 evidence for us?
A consultant can prepare the systems, process documentation and evidence that a P6.7 test will examine, but cannot issue the conclusion. The organization remains responsible for its controls and for the accuracy of its own description. An implementation partner can map personal information flows, configure logging, build the request workflow, run walkthroughs with staff and assemble the records an auditor will sample. Only an independent CPA firm performs the SOC 2 examination and issues a report. When you request a quote, ask for the deliverables in writing, who performs each task, which records the partner will leave behind for the auditor, and what happens if the auditor requests additional samples. DeployOpen works under a fixed scope agreed in writing before the work starts.
How does P6.7 differ from P5.1 data subject access?
P5.1 covers letting an identified and authenticated data subject review and obtain copies of their stored personal information. P6.7 covers something broader on the same request channel: an accounting of the personal information held about them and of the disclosures made of it. In practice, a single request handling process can serve both, but the evidence differs. A P5.1 test looks at whether access was granted, verified and explained when denied. A P6.7 test looks at whether the organization can show what it holds and to whom it has disclosed it, which depends on the disclosure records covered by P6.2 and P6.3 and on the third-party commitments covered by P6.4. Confirm with your auditor how these criteria are scoped and sampled, because the overlap affects which records are tested under each one.
What evidence will an auditor ask for to test P6.7?
Auditors usually ask to see the documented process, the data inventory it relies on, and a sample of past requests with their outcomes. They will also check disclosure records to confirm that the accounting can be completed for a given data subject. Useful evidence includes the request procedure, identity verification steps, request logs with dates and responses, the disclosure register, and screenshots or query outputs that show how records were located. Ask your auditor which period the samples must cover and whether the requests in the sample period must exist, since an organization with few requests may need to explain how the process was tested. Treat this as a question to confirm with the CPA firm, because sampling practice varies with the engagement.
How DeployOpen prepares P6.7 evidence for your environment
DeployOpen starts with a written scope that names the systems that hold personal information, the request channels your organization accepts, and the populations whose data is in play. Once the scope is agreed, DeployOpen implements or customizes self-hosted workflows inside your own cloud accounts, data center or air-gapped network. Typical components include a request intake form or ticket queue, a register of personal information types and the systems that store them, and logging that records each request, the disclosures made in response and the disclosure recipients. Every element runs in your environment, under your administrators, so the records remain yours.
The evidence side is where most P6.7 work is won or lost. DeployOpen configures the workflow so that each accounting request produces a traceable record: the identity verification step, the data sources queried, the disclosures identified and the date of the response. It also prepares the supporting material an assessor will ask for, such as a walkthrough of the request process, samples of completed requests with their supporting logs, and a mapping of the process to the P6.7 points of focus. Confirm with your auditor which sample sizes and time periods they will test before the build is finished, because a Type 2 examination depends on evidence that exists across the whole observation window.
DeployOpen does not issue SOC 2 reports, attestations or opinions. Only an independent CPA firm can examine your controls and report on them. Your organization owns the P6.7 control, including the decisions about what personal information is held, how requests are answered and who approves them. DeployOpen's role is to prepare the systems, controls and evidence, and to document how they operate so your team can run them after the engagement closes. Ask any implementation partner to state this division of responsibility in the written scope, and ask your CPA firm to confirm which evidence it will accept.
