P5.1 Data subject access: SOC 2 requirements and evidence

What P5.1 data subject access asks a SOC 2 service organization to do

P5.1 asks a service organization to let identified and authenticated data subjects review the personal information it stores about them, provide physical or electronic copies when they ask, and tell them when access is denied and why. In practice that means three linked duties: confirm who is asking before releasing anything, find and assemble the information held about that person, and respond within a reasonable time with either the information or a reasoned refusal. The criterion sits in the privacy category, so it only enters your SOC 2 if privacy is in scope, and it applies to the personal information your system stores on behalf of customers or on your own account.

The risk runs in two directions. If identity checks are weak, personal data goes to the wrong person, which is a disclosure incident in its own right. If the process is slow or incomplete, individuals cannot see what is held about them, and the organization cannot show an assessor that its handling is controlled. The criterion is hard for three practical reasons: proving identity without collecting more data than necessary, locating a person's records across production databases, backups, logs, support tickets and third-party tools, and meeting a response window that the organization's own privacy commitments set. Each of these is a place where a documented procedure and a retained record matter more than the technology.

Before the examination, decide who owns the request workflow, which systems count as stores of personal information, how identity is verified for each request channel, and what reasons justify a denial. Then run a sample request end to end and keep the ticket, verification record, search results and response as evidence. Confirm with your CPA firm how it expects the population of requests to be sampled, and with your privacy counsel which statutory deadlines apply in the markets you serve, since those obligations are set by law rather than by the criterion.

Which systems and teams fall under P5.1 scope

P5.1 only applies when the privacy category is included in the SOC 2 examination, so the first decision is whether privacy is in scope at all. Once it is, the systems, intake channels, people and third parties that touch stored personal information define what the access process must cover.

Confirm the privacy category is in scope

P5.1 is one of the privacy criteria (P1 to P8), and those criteria apply only when the privacy category is included in the examination. Security is covered by the common criteria CC1 to CC9 in every SOC 2, but privacy is added only when the organization and its auditor agree on scope. Confirm this in the written engagement and system description before building the access process, because a mismatch here changes what the auditor tests.

Stores holding personal information

Map every place personal information lives: production databases, object storage, file shares, analytics warehouses, search indexes, logs and backups. Access requests must reach all of them, or the organization cannot give a complete copy or explain a denial accurately. Ask engineering for a current data inventory, and check whether backup and log copies are included in the response process and how they are retrieved.

Request intake channel

Identify every channel through which a data subject can ask for their information: a web form, a privacy mailbox, a support ticket, a phone line or a request sent through a customer. Each channel must route to one tracked queue with a timestamp and an owner. Requests that arrive by email to an unmonitored address are a common gap an assessor will ask about.

Identity verification steps

P5.1 expects the organization to confirm that the person asking is the data subject before releasing information. Define how identity is checked for each channel, what documents or account login are accepted, and how the check is recorded. Verification that is too weak exposes other people's data, while verification that is too strict can block valid requests, so the method should be written down and applied consistently.

Support and privacy staff with access

Name the people who can search, retrieve and export personal information to fulfill a request, including support agents, engineers and privacy staff. Each role should have documented access that is limited to what the task needs, and that access should appear in the periodic access reviews. Keep a record of who handled each request and what they accessed, since those records become evidence during fieldwork.

Subservice organizations holding personal data

Cloud hosts, payment processors, email providers, analytics vendors and support tools may hold personal data on the organization's behalf. Determine which of them can be asked to return or confirm data for a request, and how that request is routed to them. Whether a subservice organization is carved out or included in the report changes what the auditor expects, so confirm that treatment with the CPA firm.

How an assessor tests data subject access

This table compares what an assessor examines for P5.1, the evidence each test relies on, and the gaps that most often appear. Read each row as a question the assessor will ask and the record you should have ready before fieldwork starts.

Test area	What the assessor does	Evidence the assessor expects	Common finding
Documented request procedure	Reads the written procedure for accepting, verifying, fulfilling and denying access requests and checks it matches stated commitments	Approved access request procedure, version history, owner and review date	Procedure exists but does not name systems or describe denial steps
Sampling requests in the period	Selects requests received during the examination period and traces each one end to end	Request log or ticket export covering the full period, with the sample population stated	Requests handled by email with no record of receipt or closure
Identity verification	Confirms the requester was identified and authenticated before any personal information was released	Verification steps taken, method used, and who approved release	No evidence of identity checks before data was sent
Response and delivery	Checks that the data provided was the stored personal information about that data subject and was delivered securely	Copy of the response, delivery method, and record of what was included	Delivery through unencrypted channels or incomplete extracts
Response timeframe	Compares receipt and response dates against the timeframe stated in the organization's own procedure	Timestamps on the request record and the response	Timeframe stated in policy is missed with no documented extension or explanation
Denials and reasons	Checks that every denied request was communicated to the data subject with the reason	Denial letters or messages, reasons recorded, and approval of the denial	No denial letters on file for requests that were refused or partly refused
Coverage across systems	Confirms the procedure reaches every system that stores personal information, including backups and third-party processors where relevant	System inventory with personal information locations, and the search steps used for each request	Access requests only search the primary application and miss other data stores

Implementing an access request process that produces evidence

This sequence turns P5.1 from a written promise into a repeatable process, where each step leaves a record an assessor can sample. It covers how requests are verified, where personal information is found, how responses and denials are written, and how the process is checked over time.

Define request intake and identity verification
Decide how data subjects submit requests, such as a web form, email address or account settings page, and what identity checks apply before any information is released. Set a written verification standard that matches the sensitivity of the data, and state when the organization will ask for more proof. The output is a documented intake channel and verification standard that the privacy owner approves. Confirm with your legal or privacy team which verification method fits your jurisdictions and data types.
Map where personal information is stored
Inventory every system that holds personal information about data subjects, including production databases, backups, object storage, logs, analytics tools, support platforms and processors that act for you. Record the owner, data elements and retrieval method for each location. The output is a data map that the access process uses as its search list, reviewed whenever a new system is added. Without this map, an assessor will ask how you know a response was complete.
Build the retrieval and export procedure
Write the steps an engineer or support analyst follows to locate a data subject's records across the mapped systems, collect them and package them in a readable format, either as a file or as a printed copy. Include how the data is transferred securely to the verified requester and how exports are kept out of shared folders. The output is a runbook with queries or scripts stored under version control, so the same method runs each time. Confirm with your platform team which export formats your self-hosted applications support.
Write response and denial templates with reasons
Prepare standard messages for four outcomes: access granted, access partly granted, access denied with the reason, and a request needing more verification. Each denial template should name the basis for refusal in plain language, such as an identity that could not be confirmed or an exemption that applies, and explain how the data subject can raise a concern. The output is an approved template set held with the policy documents. Review the wording with counsel, since denial reasons must match the obligations that apply to you.
Record each request with timestamps
Log every request in a ticketing or case system at the moment it arrives, capturing the received date, verification steps and outcome, the systems searched, the date the response was sent, and the staff member who handled it. Keep the log tamper-resistant and restrict edit rights. The output is a complete request register that can be filtered by date and status. This register is the primary evidence an assessor uses to test timeliness and consistency, so gaps in it cannot be filled in later.
Review a sample of closed requests
On a regular schedule, select a sample of closed requests and check each against the register, the verification standard, the data map and the response template. Confirm that the data released matched what the data subject was entitled to, that denials gave reasons, and that any gaps led to a corrective action. The output is a dated review record with findings, owners and remediation status. Retain these reviews as monitoring evidence, because they show the control is operating between audits.

How a data subject access request moves through your systems

A data subject access request under P5.1 passes through six stages: intake, identity verification, locating records, assembling a copy, reviewing for third-party data, and delivery with any denial and its reason. Each stage needs an owner and a record. Intake should create a ticket in the same system that holds every later step, with the date received, the channel used and the exact scope the requester asked for. Identity verification comes next. Confirm that the person is who they claim to be before any personal information leaves the organization, and record the method used, not just the outcome. Confirm with your counsel and your SOC 2 auditor which verification methods you consider sufficient for each data category you hold.

The middle stages are where most organizations lose evidence. Locating records means searching production databases, object storage, analytics warehouses, support desk tools, backups and any processor holding the data, and a search that covers only the primary application database will look complete while missing most of the data. Record which systems were queried, the search terms or keys used and the time each query ran. Assembling the copy and reviewing it for third-party data are judgment calls that often happen in email or on a shared drive, with no record of what was removed and why. Keep the working copy, the redaction decisions and the approver inside the ticket. An assessor testing P5.1 will ask for exactly this trail, and it is far easier to build as the request moves than to reconstruct afterward.

Delivery and denial close the loop. Send the copy through a channel that protects it in transit, and log the date, recipient and format. When you deny all or part of a request, the notice to the data subject must state the reason, so write the denial template with the legal grounds your organization relies on and have someone other than the handler approve it. Confirm with your privacy lead how long your organization has to respond under the laws that apply to you, because the SOC 2 criterion asks for a timely response but the deadline itself comes from your own obligations. Review a sample of closed tickets each quarter to check that every step left a record.

Evidence that passes a P5.1 test

An auditor testing P5.1 asks two things: did the organization let identified data subjects see and copy their information, and can it prove each request was handled as its own procedure says. The cards below are the records that answer those questions. Each one needs an owner and a refresh routine, because a request log that stops in the middle of an observation period is hard to defend.

Written access request procedure

This is the document the auditor reads first to understand how a data subject request moves from receipt to response. It should name the intake channels, who owns each step, the target for responding, and how requests that involve data held by a processor are routed to that processor. Between audits, review it when intake channels, ticketing tools or processors change, and record the review date and approver so the version in force on any given day can be shown.

Identity verification standard

P5.1 expects the organization to confirm that the person asking is the data subject before releasing anything. The standard should set out which identifiers are acceptable, when extra verification is required, and what happens when verification fails. Auditors look for consistency: a sample of approved requests should show the same checks were applied. Keep a list of exceptions approved by a named person, and revisit the standard whenever account login or support tooling changes.

Request log with timestamps

The request log is the population an auditor draws samples from, so it must be complete. Each entry should carry the receipt time, verification outcome, due date, the date the response left the organization and the final outcome. Gaps and backdated edits are the findings most likely to matter. Export the log on a fixed schedule into a read-only store, and reconcile it against the support inbox and ticket queue so requests received outside the tool are not missing.

Sample response copies, redacted for audit

Copies of what the data subject actually received show that access was granted in a form they could understand. Keep the outgoing package for each sampled request, with third-party personal information and security-sensitive fields redacted under a documented rule. The redaction log matters as much as the redacted file, because it shows that the exclusions were deliberate. Store the originals under restricted access and check the sample set quarterly so the review copies match what was sent.

Denial letters with stated reasons

When access is refused, P5.1 requires the organization to tell the data subject and give the reason. Denial letters are where many organizations fail, because the reason is either missing or generic. Use a short list of approved reason codes tied to the procedure, such as failed verification or an applicable legal exemption, and have legal review the wording. Keep the signed or sent letter with the request record. Review the reason list each year to confirm it still matches the exemptions the organization relies on.

Data inventory showing where personal information lives

An access response is only complete if the organization searched every system that holds personal information about the requester. The data inventory maps each system, its owner, the personal data categories it stores and any processors involved. Auditors use it to test whether the search covered the full estate. Update it when a new application, database, backup or analytics export is introduced, and tie each change to a ticket so the inventory history can be shown during the observation period.

Periodic review records

Auditors expect evidence that management checks the access process over time, not only when someone remembers. Periodic review records show who examined the request log, the sample responses and the denial reasons, what they found and which corrective actions were opened. A short, dated review note each period, with tracked follow-up, is usually enough. Ask your assessor early which review cadence they expect for your system, since the cadence must match what the organization claims in its description.

What meeting P5.1 costs in money and effort

This table breaks down the money and effort behind P5.1 data subject access by cost component, showing who is paid, whether the cost is one-time or recurring, and what pushes it up or down. Use it to structure a quote request, since no supplied figures exist for these costs and every amount depends on the organization's own data landscape and request volume.

Cost component	One-time or recurring, and who pays	What drives it up or down
Data mapping to locate personal information	One-time to build, then recurring as systems change. Paid as internal staff time or a consultant's fixed-scope work.	Number of data stores, undocumented shadow systems, and how often new products or vendors add personal data.
Engineering time for retrieval and export	One-time build, recurring maintenance. Paid as internal engineering or a partner's fixed-scope delivery.	Degree of automation, consistency of data formats across stores, and whether exports can be generated from one query path.
Case management tooling or licenses	Recurring subscription or self-hosted operating cost. Paid to a vendor or from internal infrastructure budget.	Request volume, whether the case system is open source and self-hosted, and integration effort with ticketing and identity tools.
Identity verification service	Recurring per-check or subscription fee if a third party is used. Paid to the verification provider.	Number of requests, the verification method chosen, and whether existing account authentication can serve the purpose.
Ongoing request handling staff time	Recurring. Paid as internal privacy or support staff time.	Volume of requests, complexity of each case, and how many requests are fully automated versus manually reviewed.
Review and testing of the access process	Periodic. Paid to an internal reviewer or an external tester.	Scope of testing, whether the export path is tested for unauthorized access, and how often data stores change.
Auditor sampling and evidence review	Recurring with each SOC 2 examination period. Paid to the independent CPA firm under its engagement letter.	Number of sampled requests, quality of the request log, and how easily evidence can be pulled without manual reconstruction.

Who does what for data subject access

Your organization owns the criterion. Its privacy, legal and operations leaders decide how data subjects make requests, how identity is confirmed, what personal information is released and when a request is denied. Those decisions are control design, and they must be documented, approved and carried out by your people, not delegated to a vendor or an auditor.

Request procedure: Your privacy owner writes and approves the intake channel, the response timeline and the escalation path, and assigns named staff to run each request.
Data map: Your data owners identify which systems hold personal information about data subjects and which of those systems can be searched or exported for a single person.
Verification standard: Your security and legal teams set the identity checks required before release, including what happens when a requester cannot be authenticated.
Denial decisions: Your legal reviewer makes every decision to withhold information and approves the written reason given to the data subject.
Evidence: Your compliance lead keeps the request log, verification records, responses and denial letters that the auditor will sample.

Before fieldwork, confirm that a named owner signs off each of these items and that staff can show a completed request from start to finish.

Where organizations usually fall short on P5.1

Most P5.1 failures are not about whether access is technically possible. They happen at the edges: how a request arrives, which systems hold the data, what gets left out, and whether the procedure has ever run. Each card below names one gap and the check that closes it before an examiner finds it.

No verified intake channel

Requests arrive by email, support tickets, social media or a sales contact, and nobody owns them. P5.1 expects identified and authenticated data subjects to be able to ask for their information, so the organization needs one published route with a defined owner. Check that every channel feeds the same queue, that identity verification happens before any data is released, and that staff who receive requests in other places know how to forward them.

Personal data with no inventory

Access requests fail when the team cannot say where a person's data lives. Customer records, support tools, analytics, billing, logs and data warehouses often each hold a copy. Build and maintain a data map that lists each system, the personal fields it stores and its owner, then confirm that the request procedure searches every entry on that map rather than only the primary application.

Backups and logs left out

Teams often search production databases and stop there, while personal information persists in backups, archived exports, application logs and file storage. The procedure should state which of these stores are in scope, how a data subject's records are located within them, and how the organization explains any data it cannot practically retrieve. Confirm this decision with your auditor before the observation period begins.

Denials sent without reasons

When a request is refused, for example because another person's data is mixed in or a legal hold applies, the criterion requires the organization to tell the data subject of the denial and the reason. A bare refusal or silence fails that test. Keep a short set of approved denial reasons, have a reviewer sign off on each denial, and retain the letter that was sent.

No record of closed requests

An examiner testing P5.1 will ask for a sample of requests and the evidence for each. If the team cannot show when a request arrived, how identity was checked, what was searched, what was returned and when, the control cannot be shown to operate. Use a request log with a timestamp for every step and store the response copies. Confirm how long your own policy retains these records.

Procedure never exercised

A written access procedure that no one has run is the most common finding in a Type 2 period, because the auditor needs evidence across the whole period, not a document dated before it. Run test requests on a schedule, including one that involves a backup or log store and one that ends in a denial. Record the results, fix what breaks, and treat each test as operating evidence.

Questions buyers ask about P5.1 data subject access

How much effort does P5.1 data subject access take to meet?

The effort depends on how many systems hold personal information, how well those systems are mapped, and whether a request process already exists. P5.1 asks the organization to let identified and authenticated data subjects review their stored personal information, provide copies on request, and explain any denial. Most of the work sits upfront: finding where personal data lives, building a verification step, and writing a response procedure. Recurring effort is the time spent handling real requests and keeping the procedure current as systems change. Ask any partner to estimate effort from a written inventory of your data stores and integrations, not from a generic template. The effort figures for any specific engagement should come from that written scope.

Can a small team run P5.1 data subject access without outside help?

Often yes, if the team has a clear owner, a current map of where personal information is stored, and access to the production systems that hold it. A small team usually needs three things: a documented intake channel, a repeatable identity check, and a retrieval procedure that engineering can run without improvising. The harder parts are usually data sprawl across SaaS tools and backups, and agreeing when a denial is justified and how to explain it. Outside help is most useful for building the data inventory, writing the procedure and testing it end to end before the first audit period starts. Confirm internally who will answer requests and how much time that person can give them.

How long does it take to fulfil a data subject access request?

P5.1 asks for information to be provided within a reasonable time, so the criterion itself does not set a fixed number of days. The practical timeline depends on how quickly the organization can verify the requester, locate every relevant record, and assemble an understandable copy. Requests that touch many systems or unstructured files take longer than those covered by one database. Any outer deadline set by a contract or by privacy law, such as the GDPR, may be shorter than what you would choose internally, so check those obligations separately. Confirm your own response target in writing, test it with a sample request, and record how long each step took.

Does P5.1 still apply if the privacy category is out of scope?

No. The privacy category is optional in a SOC 2, and P5.1 is one of the privacy criteria, so it is only tested when privacy is included in the examination scope. If privacy is out of scope, the common criteria CC1 to CC9 still apply, and personal information may still be handled under them through access controls and data protection. However, a customer contract, a regulation, or a privacy notice you have published may still require you to honor access requests. Those obligations stand apart from the SOC 2 examination. Confirm the scope decision with your CPA firm and check your contracts and privacy commitments before dropping the category.

How does P5.1 data subject access differ from P5.2 correction?

P5.1 covers letting a verified data subject review and obtain copies of the personal information held about them, and explaining any denial. P5.2 covers correcting, amending or appending that information based on what the data subject provides, and passing corrections to third parties as committed or required. The two often share intake, identity checks and recordkeeping, but they produce different outputs: P5.1 produces a disclosure to the individual, while P5.2 produces a change in your records. Designing one process that routes both request types, with separate steps and logs, usually reduces confusion. Your auditor will test each criterion on its own terms.

What should I ask a partner before hiring them for P5.1 work?

Start by asking what the engagement covers in writing: which systems will be inventoried, which request workflows will be built or tested, and what the partner will hand over. Ask how they will verify identity without creating new personal data exposure, and how they will handle denials and their stated reasons. Confirm that the partner prepares systems, procedures and evidence but does not issue any audit report or attestation, which only an independent CPA firm does. Ask who on your side owns the procedure after handover, and what evidence will show the criterion is operating. DeployOpen works from a fixed written scope agreed before work starts, so ask any provider for the same.

How P5.1 differs from correction and accounting

P5.1 covers the data subject's right to see what is held about them. The organization must let an identified and authenticated individual review their stored personal information and obtain copies on request, and must tell them the reason if access is denied. It does not require the organization to change anything in the record. That work belongs to P5.2 Correction of personal information, which covers amending or appending data based on what the individual provides, and passing corrections to third parties as committed or required. P6.7 Accounting of personal information and disclosures is a different obligation again: it asks the organization to give the individual an account of the personal information held and of the disclosures made of it. An auditor will test each criterion separately, so a team should confirm that its procedures and evidence can answer each one on its own terms.

The practical decision is to build one request log and reuse it across all three criteria. A single record per request can capture the request date, how the requester was identified and authenticated, the systems searched, the data returned or the reason access was denied, any correction made under P5.2, and any disclosure listed for P6.7. Each request then produces the evidence a reviewer needs for each criterion without rebuilding the trail. Teams should confirm with their privacy counsel which deadlines and response formats apply to their jurisdictions, and with their auditor how the log will be sampled, because the log itself becomes the population the auditor draws from.

How DeployOpen prepares P5.1 evidence

DeployOpen plans and builds the self-hosted open-source systems that hold personal information, then prepares the access workflow, records and documentation that show how P5.1 operates. Scope, build, handover and support are agreed in writing, and the organization keeps ownership of its controls. The independent CPA firm performing the examination decides what the evidence proves.

How we scope

Agree in writing which systems hold personal information that data subjects may request
Define how identity verification, request intake and response deadlines will be handled for each system
Confirm with your CPA firm which points of focus and evidence they expect before build starts

How we build

Configure self-hosted platforms so authenticated requesters can retrieve their stored records
Build request logging that captures receipt date, verification steps, response and any denial reason
Test retrieval and denial paths in your environment and keep the results as dated evidence

How we hand over

Deliver the access procedure, system inventory and runbook describing each step of a request
Provide sample request records and test results that the auditor can select and inspect
Document known gaps, owners and remediation dates so management can present them accurately

How we support

Review request logs periodically to confirm responses follow the documented procedure
Update the runbook and tests when systems, data stores or identity providers change
Ongoing support, upgrades and continuous testing are available as a retainer after handover