SOC 2 Data Subject Request Guide: Your Step-by-Step Guide (2026)

Data subject requests allow individuals to use privacy rights established in laws like the General Data Protection Regulation (GDPR), the California Consumer Privacy Act (CCPA) and Brazil’s Lei Geral de Proteção de Dados (LGPD). These laws give people the right to see, update, erase or transfer the personal data companies hold about them. Regulators require fast responses – 30 days under the GDPR, 45 days under the CCPA and 15 days under Brazil’s LGPD. Failing to meet these timelines or disclosing someone’s information to the wrong person can trigger fines up to €20 million or 4% of annual revenue.

The privacy criterion of SOC 2 is built on these same rights. Service providers seeking SOC 2 Type II reports must demonstrate that they collect, use, retain and disclose personal data in accordance with their commitments and relevant laws. Enterprise buyers therefore ask tough questions about how vendors manage data subject requests, document responses and protect personal data while fulfilling them. This SOC 2 Data Subject Request Guide sets out the regulatory context, explains each data subject right, shows how SOC 2 maps to those rights and provides a structured process for handling requests.

Readers will learn:

• What counts as a data subject request and why it matters for enterprise deals.
  
  
• How SOC 2’s privacy criteria match specific data subject rights.
  
  
• Regulatory requirements for response timeframes, identity verification and documentation.
  
  
• A step‑by‑step process for handling requests – from intake and verification to redaction and secure delivery.
  
  
• How to integrate security and data management to minimise risk and satisfy auditors.
  
  
• Common mistakes to avoid and the tools that can automate parts of the workflow.

What Are Data Subject Requests?

A data subject request is a formal demand from an individual to assert a privacy right. Under the GDPR, data subjects may request access to the data held about them, have incorrect data rectified, have data erased when it is no longer needed or consent is withdrawn, receive their data in a structured, machine‑readable format, or object to processing. These rights mirror the CCPA’s provisions, which allow consumers to know what personal information is collected, request deletion and opt out of sale or sharing. Similar protections exist in the LGPD and other state laws. SOC 2 ties these rights to contractual obligations: if a service provider commits to honour them, it must prove to auditors that its controls work.

Examples of Common Request Types

1. Access requests. A data subject asks for confirmation that an organisation processes their personal data and requests a copy. Under GDPR Article 15, controllers must provide categories of data, purposes of processing, recipients and storage periods. For U.S. clients, the CCPA requires disclosure of categories of personal information collected and sources.
   
   
2. Correction/rectification requests. Individuals can correct inaccurate or incomplete personal data. The GDPR requires controllers to rectify inaccuracies without undue delay.
   
   
3. Deletion or “right to be forgotten.” Data must be erased when it is no longer necessary for the purpose it was collected or when consent is withdrawn, subject to legal exceptions. In practice this means removing data from production systems and backups, or documenting the legal basis for retaining it.
   
   
4. Portability requests. Data subjects can receive their data “in a structured, commonly used, machine‑readable format”. This right enables them to transfer data to another service provider or integrate with personal services.
   
   
5. Objection and restriction. Individuals may object to processing based on legitimate interests or direct marketing. They may also request a restriction of processing when data accuracy is disputed or processing is unlawful but the data subject opposes erasure. Companies must log these objections and restrict further processing while evaluating them.

These request types often arrive through multiple channels – support tickets, email, phone or in‑app portals. Without a unified process, responses become inconsistent, deadlines slip and records are incomplete, undermining both compliance and customer trust. This SOC 2 Data Subject Request Guide treats DSRs as part of day‑to‑day operations rather than isolated legal events.

How SOC 2 Ties to Data Subject Rights

SOC 2 is an attestation framework defined by the American Institute of Certified Public Accountants (AICPA) for service organisations. It evaluates controls relevant to security, availability, processing integrity, confidentiality and privacy. The privacy criteria require organisations to demonstrate that personal information is collected and managed in accordance with commitments and public notices. A SOC 2 Type II report therefore covers not only encryption, access control and monitoring but also how personal data is obtained, used, retained, disclosed and disposed of. One of the points of focus in the AICPA privacy criteria states that entities must provide individuals with access to their personal information for review and update.

Enterprise buyers increasingly include data subject rights in vendor due‑diligence questionnaires. They want assurance that vendors can handle DSRs at scale, maintain evidence over the SOC 2 observation period (often 4–5 months) and support cross‑border obligations. In Konfirmity’s experience delivering thousands of audits, buyers often require demonstration of: (a) a defined policy for responding to data subject requests; (b) intake mechanisms that route requests to the right team; (c) identity verification procedures that are proportionate; (d) logs showing when requests were received, what systems were searched and what data was provided; (e) controls to prevent disclosure to unauthorized parties; and (f) integration with the organisation’s incident response plan to handle mis‑disclosure as a potential breach. This SOC 2 Data Subject Request Guide provides a roadmap to satisfy these demands and to bring privacy operations into harmony with broader security programmes such as ISO 27001 and HIPAA.

Core Data Subject Rights Explained

Right to Access

Under GDPR Article 15 and similar statutes, individuals have the right to know whether a controller processes their personal data and to receive a copy. To fulfil this right, organisations need inventories of where personal data resides, including databases, file stores, SaaS platforms and backups. Data maps should link unique identifiers (email, customer ID) to data repositories and classify data by sensitivity. A SOC 2 privacy programme must show that access requests are logged, assessed and fulfilled within the statutory timeframe. It should also confirm that data provided is clear and complete and that redactions protect third‑party information. SearchInform’s guidance stresses that organisations should provide requested data in a commonly used electronic format unless the data subject asks for something different.

Right to Correction/Rectification

This right allows individuals to have inaccurate personal data corrected or incomplete data completed. Processes should enable people to update their details through secure portals or by submitting a request. When a rectification request arrives, the organisation should verify identity, review the contested data, update records across systems and inform any third‑party processors. Audit trails must record the request, verification steps, systems updated and communications. Because the correction right interacts with system integrity, SOC 2 controls should include change‑management procedures and version control to ensure that changes do not compromise security or data integrity.

Right to Deletion/Erasure

The right to be forgotten requires controllers to delete personal data when it is no longer needed, consent is withdrawn or processing is unlawful. However, certain data may be retained for legal obligations (e.g., financial records, health records). In practice, deletion often involves de‑identifying data in active databases and applying retention policies to backups. Organisations should maintain deletion workflows that verify legal bases, remove or anonymise data across systems, document exceptions and communicate outcomes to the requester. They should also avoid over‑collection; the ICO and European Data Protection Board emphasise data minimisation, limiting verification to necessary information and securely disposing of any collected documents. Over-burdening verification or requesting unnecessary documents can result in fines; in 2020 the Dutch DPA fined DPG Media €525,000 for requiring identity copies from all DSARs.

Data Portability

Data portability enables individuals to obtain and reuse their personal data across services. The GDPR states that data must be provided in a structured, commonly used, machine‑readable format. SOC 2 privacy programmes should support export formats like CSV or JSON and have controls to verify the request and package data securely. Redactable’s DSAR workflow suggests using secure portals with multi‑factor authentication and expiring links. Organisations must also make sure that data exports do not include proprietary algorithms or third‑party personal information.

Restriction and Objection to Processing

Individuals may request that controllers stop processing their data under certain circumstances, such as when accuracy is contested or the individual objects to direct marketing. Organisations must log these requests, assess legal grounds and either halt processing or explain why processing continues. For SOC 2, this ties into access control and change management: systems should be able to flag records as “restricted” and ensure that downstream processes respect that status. Documentation should capture the reason for the restriction, systems affected and any communications. SearchInform highlights that organisations should keep a record of reasons for denying a request and any exemptions applied.

By mapping each right to controls, companies can consider data subject requests as a living part of their privacy management system. This SOC 2 Data Subject Request Guide emphasises that rights are not abstract legal concepts but operational obligations with measurable requirements.

Regulatory Requirements Around DSRs

This SOC 2 Data Subject Request Guide also explores regulatory requirements around data subject requests — response timeframes, proportional identity verification and documentation — because buyers and auditors expect clear evidence that your process meets legal obligations.

Response Timeframes

The GDPR requires controllers to respond to data subject requests within one month, with a possible extension of up to two months for complex or numerous requests. The CCPA gives businesses 45 days to respond to access or deletion requests, with one possible 45‑day extension if reasonable. Brazil’s LGPD sets a 15‑day limit. Redactable emphasises that these windows are critical and that DSAR volumes have surged 72% since 2021. Failing to meet deadlines can result in regulatory enforcement and lost business.

Identity Verification Expectations

Identity verification is necessary to prevent disclosure to imposters, but it must be proportionate. The ICO’s guidance notes that organisations should request additional information only if they have reasonable doubts about a requester’s identity. Verification measures should be proportionate to the sensitivity of the data and comply with data minimisation principles. The UK regulator also mandates that any identity documents collected must be securely handled and destroyed after verification. SearchInform echoes this: organisations must verify identity but should not request excessive or unnecessary information. Multi‑factor authentication, in‑account confirmation or recent transaction references can suffice for most cases. Overly burdensome verification can be unlawful; the Dutch DPA fine for DPG Media demonstrates that routine demands for ID copies violate proportionality.

Documentation and Audit Trails

Auditors expect a clear record of each request: the date received, channels used, scope, verification steps, systems searched, decisions taken, exemptions applied and communications. SearchInform advises maintaining records of DSARs to demonstrate compliance. It stresses recording the steps taken for verification, information provided and any extensions. AccountableHQ’s DSAR guide suggests creating a DSAR register with unique identifiers, stop‑clock periods, extension rationales and evidence of redactions. Detailed documentation not only supports SOC 2 audits but also allows future process improvements and readiness for regulatory inquiries. In Konfirmity’s audits we often see teams that see DSARs as legal events but lack central tracking; this makes it difficult to show consistent controls across the SOC 2 observation window. A structured register solves this problem.

Building a Repeatable DSR Process

The heart of this SOC 2 Data Subject Request Guide is a practical workflow for handling requests. While every organisation’s systems differ, the following framework reflects common patterns from 6,000+ audits and decades of hands-on experience.

Intake and Tracking

1. Centralize request channels. Accept requests through dedicated forms, customer support queues or a privacy portal. Avoid ad‑hoc emails to multiple departments, which create inconsistent handling and missed deadlines. AccountableHQ advises centralizing channels and assigning a unique identifier for each request.
   
   
2. Assign unique identifiers. Generate a reference number or ticket ID to track progress. Record the requester’s contact details, date of receipt and the right invoked (access, deletion, correction, portability or objection). For CCPA, confirm receipt within 10 business days and explain next steps.
   
   
3. Log stop‑clock periods and extensions. If the request is complex or requires additional identity verification, log the pause and document the reason. This ensures you can demonstrate compliance with statutory timeframes and justify any extensions.

Identity Verification

1. Use a layered approach. For low‑risk requests (e.g., known users logged into a portal), rely on in‑account verification or email confirmation. For medium‑risk cases, add a two‑factor challenge or request recent transaction or ticket references. For high‑risk requests or sensitive data (financial or health information), request limited‑scope identity documents such as a redacted government ID plus a selfie or live video, then delete these artifacts once verification is complete. Avoid collecting full ID copies for routine requests; regulators consider that disproportionate.
   
   
2. Explain the rationale. When asking for verification data, explain why it is needed and how it will be used. TermsFeed notes that businesses must inform requesters of verification reasons and the retention period.
   
   
3. Secure handling and disposal. Store any verification documents in encrypted systems with restricted access and delete them promptly after verification. Record the fact that verification was completed without retaining the document itself.

Scoping the Request

1. Identify systems and data. Use your data inventory or map to locate relevant personal data across systems: CRM, databases, ticketing systems, SaaS platforms, logs and backups. SearchInform emphasises the need to search all accessible media when fulfilling DSARs, and the EDPB warns that narrowing scope without justification may violate the duty to facilitate access.
   
   
2. Use tools for discovery. DSAR management platforms can scan structured and unstructured data to find personal identifiers. Redactable notes that automated data discovery can reduce search time by up to 98%. Integration with cloud storage and SaaS applications further accelerates retrieval.
   
   
3. Clarify scope with the requester. Ask the individual to confirm date ranges, products or services involved and whether they are seeking specific documents or all data. Clear communication reduces the chance of missing data and ensures that processing is proportionate.

Fulfillment Workflow

1. Extract and prepare data securely. Retrieve the relevant records, ensuring that only authorised staff can access them. Apply deduplication and relevance criteria to avoid over‑disclosing information. Use redaction tools to mask third‑party personal data, trade secrets and confidential business information.
   
   
2. Apply exemptions appropriately. Document any legal grounds for withholding data, such as attorney‑client privilege or trade secrets. Explain to the requester the nature of withheld information while protecting sensitive details.
   
   
3. Deliver data securely. Use a secure portal with multi‑factor authentication and single‑use links or send encrypted archives with passwords delivered separately. Provide machine‑readable formats like CSV or JSON and include a cover description outlining the contents and date ranges. Retain download logs and receipt confirmations for audit purposes.
   
   
4. Document everything. Record the systems searched, data provided, redactions applied and delivery method. Save evidence such as export manifests, file hashes or screenshots to demonstrate completeness.

Recordkeeping and Documentation

1. Maintain a DSAR register. AccountableHQ suggests tracking request details, scope, systems searched and decisions taken. Include the date of receipt, verification actions, extensions, data provided and communications. SearchInform emphasises maintaining records to show compliance.
   
   
2. Meet audit requirements. For SOC 2, auditors may sample requests to verify that policies were followed consistently across the observation period. Provide evidence of your register, procedures, and sample responses. Documented controls should map DSAR processes to SOC 2 privacy criteria as well as ISO 27001 Annex A controls and HIPAA requirements for Protected Health Information.
   
   
3. Review and improve. Analyse metrics such as average response time, number of extensions, and root causes for delays. Use these metrics to refine data inventory, training and automation. Regular internal audits help ensure your process remains effective and ready for external audits.

Integrating Security and Data Management

Handling data subject requests is inseparable from good security. SearchInform advises strong access controls, encryption, pseudonymisation and anonymisation to protect data during DSAR processing. Only authorised personnel should access data; logs should capture every retrieval and transfer. Encryption of stored and transmitted data prevents interception. Pseudonymisation allows internal analysis without exposing identities, and anonymisation ensures that data removed under erasure requests can't be re‑identified.

Bring DSAR workflows in line with your broader data management programme: maintain data classification schemes, define retention periods and apply secure disposal. SearchInform stresses that organisations should securely dispose of personal data obtained during DSARs once they are no longer needed. Integrate DSAR responses with incident response; any mis‑delivery or unauthorised disclosure must trigger incident procedures. Finally, ensure third‑party processors honour DSAR obligations; contracts should include clauses requiring them to assist with requests and to delete or return data when asked.

Common Mistakes and How to Avoid Them

1. Delays and missed deadlines. Teams often underestimate the work involved in locating data across systems. Centralised intake, automated discovery and clear accountability reduce delays. Track deadlines and stop‑clock periods in your DSAR register.
   
   
2. Overly burdensome verification. Asking for unnecessary identity documents or requiring all requesters to upload government ID violates data minimisation principles and can lead to fines. Use risk‑based, layered verification and delete documents after use.
   
   
3. Inconsistent handling across teams or regions. Without a unified process, different departments may interpret laws differently. Adopt standard operating procedures and train staff. Konfirmity often sees global organisations using inconsistent DSAR templates; unify them for audit readiness.
   
   
4. Poor documentation. Failure to document requests, searches, decisions and communications undermines SOC 2 evidence. Use the DSAR register and evidence file to maintain an audit trail. Incomplete documentation can lead to adverse findings and delays in enterprise sales.
   
   
5. Insecure data handling. Using unencrypted email or leaving files on shared drives exposes sensitive information. Use secure portals and encryption, and restrict access through least‑privilege permissions. Regularly test controls through internal audits and vulnerability assessments.

Tools and Automation Options

Manual DSAR handling is labour‑intensive and prone to error. Technology can streamline processes while preserving control. According to Redactable, modern DSAR platforms provide automated data discovery that reduces search time by up to 98%. They track deadlines across jurisdictions and send alerts when responses are due. They integrate with cloud services like Google Drive, Dropbox and OneDrive to retrieve data from all storage locations. Secure communication features include end‑to‑end encryption, secure portals for verification and detailed audit logs.

When selecting tools, consider: (a) support for the rights relevant to your regulatory environment (GDPR, CCPA, LGPD); (b) integration with your existing SaaS and on‑premises systems; (c) configurable workflows to reflect your policies; (d) strong identity verification options; (e) audit‑friendly reporting; and (f) dedicated support and documentation. Avoid solutions that claim to make you “compliant in two weeks.” A SOC 2 Type II examination spans months and requires continuous evidence. Tools should supplement, not replace, human oversight; Konfirmity’s managed service integrates automation with dedicated security and compliance experts who execute controls year‑round.

Conclusion

Data subject requests sit at the intersection of privacy law, security engineering and business assurance. They are not mere paperwork; they are a test of your ability to respect individuals’ rights, protect sensitive data and operate transparently. Regulatory deadlines are short, request volumes are rising and enforcement actions are growing in severity. Buyers and auditors will scrutinise how you receive, verify, fulfil and document every request. A strong DSAR programme is therefore not optional; it is a core requirement for winning and retaining enterprise business.

This SOC 2 Data Subject Request Guide has shown how to bring your DSAR process in line with SOC 2 privacy criteria, build repeatable workflows, integrate security and avoid pitfalls. Start with security and arrive at compliance: design controls inside your stack, maintain continuous evidence and empower a dedicated team to run the process. Human‑led, managed security and compliance not only speeds up audits but builds durable trust with customers, regulators and auditors. Security that reads well on paper but fails under incident pressure is a liability. Build your programme once, operate it daily and let compliance follow.

FAQ Section

1) What counts as a data subject request? 

A data subject request is any formal demand by an individual to assert a privacy right – access, correction, deletion, portability, restriction or objection. Under the GDPR, data subjects can ask controllers if personal data about them is being processed and to receive a copy. The CCPA allows consumers to request disclosure of the categories and specific pieces of personal information collected and to ask for deletion.

2) How soon must we respond to a data subject request? 

Under GDPR you generally have one month to respond, with an extra two months for complex requests. The CCPA requires a complete response within 45 days, with one 45‑day extension if reasonable. Brazil’s LGPD sets a 15‑day limit. Always document when the request was received and any extensions. Verification delays can pause the clock but must be justified.

3) Do we need different processes for GDPR and CCPA? 

The core principles – transparency, access, correction, deletion and minimisation – are similar. However, there are differences in scope and timelines. The CCPA applies to “personal information” and includes opt‑out of sale; GDPR covers “personal data” and adds rights to portability, restriction and objection. Brazil’s LGPD provides a 15‑day timeline. Rather than separate processes, build a unified DSAR workflow with configurable response templates and logging. Track deadlines and adapt content to the applicable law.

4) How do we verify someone’s identity without creating privacy risks? 

Use a risk‑based approach. Confirm identity through known account credentials or email confirmation for low‑risk requests. For medium‑risk requests, add a two‑factor challenge or request recent transaction details. For high‑risk cases, request redacted identity documents and immediately delete them after verification. The ICO and EDPB emphasise only asking for additional information when you have reasonable doubts and ensuring proportionality.

5) What should we document for SOC 2 audits? 

Maintain a DSAR register capturing the request date, rights invoked, verification steps, systems searched, data provided, redactions applied and any extensions. Keep evidence such as export manifests, logs and communications. SearchInform advises documenting reasons for denying requests and exemptions. Provide this register and supporting artifacts during audits to demonstrate control effectiveness across the observation period.