Subject Rights Requests: What They Are and How to Process Them

The terminology problem

Privacy teams, legal departments, and software vendors all use different names for the same thing. This creates confusion — especially for organisations operating under multiple regulations or evaluating compliance tools. The underlying right is the same: an individual asks an organisation to tell them what personal data it holds, and the organisation must respond within a statutory deadline.

Term	Full name	Origin	Used by
DSAR	Data Subject Access Request	GDPR / UK GDPR	UK and EU privacy teams, ICO, most European vendors
SRR	Subject Rights Request	Industry term	Microsoft Priva, OneTrust, ServiceNow, enterprise platforms
SAR	Subject Access Request	UK Data Protection Act	UK legal profession, older compliance documentation
VCR	Verifiable Consumer Request	CCPA	California-specific compliance, CPPA guidance
IRR	Individual Rights Request	Industry term	DataGrail, some US enterprise privacy teams
DSR	Data Subject Request	Industry term	BigID, Securiti, some GRC platforms
Consumer request	Consumer privacy request	US state laws	CCPA text, state AG guidance, US legal profession

Types of subject rights requests

An SRR is not limited to access requests. Privacy regulations grant individuals multiple rights, and a single request may invoke more than one. Understanding the full set of rights helps teams build processes that handle all request types efficiently rather than treating each as a one-off.

Access (right to know)

The most common type. The individual asks for a copy of the personal data the organisation holds about them. Under GDPR, this is the Article 15 right. Under CCPA, it is the "right to know" under Section 1798.100. The response must include not just the raw data but also supplementary information — the purposes of processing, categories of recipients, retention periods, and the source of the data. This is the request type that requires document redaction, because the response typically includes documents (emails, HR records, chat logs) that contain third-party personal data.

Deletion (right to erasure)

The individual requests that the organisation delete their personal data. Under GDPR, this is the Article 17 "right to be forgotten." Under CCPA, it is the "right to delete" under Section 1798.105. Deletion requests are operationally complex because data may exist across dozens of systems, backups, and third-party services. Exceptions apply — organisations can retain data needed for legal compliance, contract fulfillment, or defense of legal claims. Deletion requests do not typically require redaction, but they do require comprehensive data discovery.

Correction (right to rectification)

The individual requests correction of inaccurate personal data. Under GDPR, this is the Article 16 right. Under CCPA (as amended by CPRA), it is the "right to correct" under Section 1798.106. The organisation must make "commercially reasonable efforts" to correct the data as directed. Correction requests are usually straightforward but require coordination across systems where the incorrect data may be replicated.

Opt-out

The individual requests that the organisation stop selling, sharing, or using their personal data for targeted advertising or profiling. This right exists under CCPA Section 1798.120 and most US state privacy laws. Under GDPR, the right to object (Article 21) serves a similar function. Opt-out requests are typically handled through consent management platforms and do not require document redaction.

Portability

The individual requests their personal data in a structured, commonly used, machine-readable format. Under GDPR, this is the Article 20 right. The data must be provided in a format that allows transmission to another controller. CCPA requires data to be delivered in a "readily useable format." Portability requests overlap with access requests but emphasise the format requirement — CSV, JSON, or structured exports rather than document copies.

The SRR processing workflow

Regardless of terminology or jurisdiction, every subject rights request follows the same five-stage workflow. The details vary by regulation, but the structure is universal.

Stage 1: Intake and logging

Requests can arrive through any channel — email, web form, phone, letter, chat, social media, or in conversation. Under CCPA, businesses must provide at least two designated methods for submitting requests. The request does not need to cite a specific law or use legal terminology. Any clear expression of intent to access personal data counts. Log the date of receipt immediately — this starts the statutory clock. Under GDPR the deadline is 30 days; under CCPA and most US state laws it is 45 days.

Stage 2: Identity verification

Before disclosing personal data, verify that the requester is who they claim to be. The level of verification should be proportionate to the sensitivity of the data. CCPA takes a tiered approach: requests for data categories require matching at least two data points; requests for specific personal data require three data points plus a signed declaration under penalty of perjury. GDPR requires "reasonable measures" without specifying a threshold. Do not collect more information than necessary for verification — excessive requirements can be treated as obstruction.

Stage 3: Data discovery and collection

Search every system where the individual's data might reside. For an employee SRR, this typically means email, HR platforms, payroll, CRM, file storage, chat platforms, databases, and backup systems. For a customer SRR, the scope depends on the nature of the relationship. Use data inventory or data mapping documentation to ensure no system is missed. Microsoft Purview eDiscovery is the standard tool for searching across Microsoft 365; Google Vault serves the same function for Google Workspace. Document which systems were searched and when — this forms part of the audit trail.

Stage 4: Review, exemptions, and redaction

This is the most time-consuming stage and the one where compliance risk is highest. Review the collected data for exemptions — legal professional privilege, management forecasting, crime prevention, and other jurisdiction-specific carve-outs. Then redact all third-party personal data from documents that will be included in the response. Names, email addresses, phone numbers, physical addresses, employee IDs, national insurance or social security numbers, and any other identifiers belonging to individuals other than the requester must be permanently removed. Redaction must be permanent — drawing black boxes over text in a PDF does not constitute redaction if the underlying data can be recovered. For large data exports containing thousands of files, manual redaction is impractical. SafeRedact Enterprise automates bulk redaction with selective PII preservation: name the data subject, upload the files, and the system redacts all third-party data while preserving the subject's information.

Stage 5: Response and documentation

Compile the response package: the personal data in a commonly used format, plus supplementary information required by the relevant regulation. GDPR requires information about processing purposes, categories, recipients, retention periods, data source, and automated decision-making. CCPA requires disclosure of categories collected, sources, business purposes, and third-party sharing. Deliver the response securely — never via unencrypted email. Use a secure portal, encrypted file transfer, or password-protected archive. Maintain a complete audit trail of every step: receipt date, verification method, systems searched, exemptions applied, redactions performed, delivery method, and completion date.

SRR deadlines by regulation

The statutory clock starts when the request is received. If clarification is needed to scope the request, the clock pauses until the individual responds (GDPR) or continues running (CCPA).

Regulation	Initial deadline	Extension	Total max
EU GDPR	30 days	+60 days	90 days
UK GDPR	30 days	+60 days	90 days
CCPA / CPRA	45 days	+45 days	90 days
US state laws (typical)	45 days	+45 days	90 days
Iowa (ICDPA)	90 days	None	90 days
LGPD (Brazil)	15 days	None	15 days
PIPEDA (Canada)	30 days	None	30 days

SRR management platforms

Enterprise organisations typically use a privacy management platform to orchestrate subject rights requests. These platforms handle intake, routing, workflow management, and response tracking — but most do not perform the actual document redaction step. Understanding the platform landscape helps teams identify where automation tools like SafeRedact fit into existing workflows.

Microsoft Priva Subject Rights Requests

Built into the Microsoft 365 compliance centre. Uses the term "subject rights request" natively. Integrates with Exchange, SharePoint, OneDrive, and Teams to discover data. Automates data collection and provides a review interface. Does not perform AI-powered redaction of third-party PII — the review and redaction step is manual within Priva. Organisations processing large SRRs through Priva typically export the collected data and use a dedicated redaction tool for the third-party PII removal step before assembling the final response.

OneTrust Privacy Rights Automation

The largest standalone privacy management platform. Handles SRR intake, identity verification, workflow routing, and response delivery across multiple regulations. Connects to 200+ data systems for automated discovery. Uses "subject rights request" in its interface. Like Priva, OneTrust manages the orchestration but relies on manual processes or third-party tools for document-level redaction.

DataGrail

Focuses on automated data discovery and deletion across SaaS systems. Uses "individual rights request" (IRR) as its primary term. Strong integration coverage for SaaS-heavy organisations. The platform automates data retrieval and deletion but does not provide document-level PII redaction for access request responses.

Where SafeRedact fits

SafeRedact is not an SRR orchestration platform — it does not handle intake, routing, or workflow management. It handles the document redaction step that orchestration platforms cannot do well. In a typical enterprise workflow, the orchestration platform (Priva, OneTrust, DataGrail) collects the data, and SafeRedact processes the collected documents for third-party PII removal. The integration is straightforward: export from the orchestration platform, upload to SafeRedact, process, and import the redacted output back for delivery. For organisations without an orchestration platform, SafeRedact's enterprise product handles the full redaction workflow including batch upload, DSAR-mode subject preservation, review, and export.

The redaction step: why it is the bottleneck

Across all SRR types, access requests are the most operationally expensive. The data discovery step can be largely automated by platforms like Priva or OneTrust. Identity verification is a straightforward process. But the redaction step — reviewing every document in the response for third-party PII and permanently removing it — remains the bottleneck.

A typical employee access request generates thousands of documents: emails, attachments, HR records, chat transcripts, performance reviews, and meeting notes. Each document must be reviewed for personal data belonging to individuals other than the requester. Names, email addresses, phone numbers, and other identifiers must be permanently removed while preserving the requester's own data. This is the step that consumes 60-80% of the total SRR processing time.

Manual redaction at this scale is unsustainable. A single complex SRR can consume 40+ hours of skilled labour. At $1,524 average cost per request and rising volumes (72% increase since 2021), the economics push organisations toward automation. SafeRedact reduces the redaction step from hours to minutes by automating PII detection across all common file types — PDF, DOCX, XLSX, EML, MSG, HTML, TXT, CSV — while preserving the data subject's information throughout.

Multi-jurisdiction SRR challenges

Organisations operating across multiple jurisdictions face additional complexity in SRR processing. The same individual may have rights under multiple regulations simultaneously — a California resident working for a UK-based company has rights under both CCPA and UK GDPR.

The practical approach is to fulfil the request to the highest standard across all applicable regulations. GDPR requires the most comprehensive supplementary information (processing purposes, recipients, retention periods, automated decision-making). CCPA requires disclosure of commercial purposes and third-party sharing categories. By building the response to include all elements required by any applicable regulation, you satisfy all of them in a single response. The redaction requirement is identical across every jurisdiction: third-party personal data must be permanently removed.

For a detailed comparison of US state-level requirements, see our US State Privacy Laws comparison. For UK/EU-specific DSAR processing, see our enterprise DSAR guide.

Frequently asked questions

What is a subject rights request?

A subject rights request (SRR) is any request from an individual to exercise their data privacy rights — including access, deletion, correction, and opt-out. The term is used broadly across privacy regulations including GDPR, CCPA, and US state privacy laws. Different laws and platforms use different names (DSAR, SAR, VCR, IRR) but the underlying process is the same.

What is the difference between a DSAR and an SRR?

A DSAR (Data Subject Access Request) specifically refers to a request to access personal data, originating from GDPR terminology. An SRR (Subject Rights Request) is a broader term that covers all data subject rights — access, deletion, correction, opt-out, and portability. Microsoft, OneTrust, and ServiceNow use SRR in their platforms. In practice, the terms are often used interchangeably.

Why is redaction required when fulfilling a subject rights request?

When providing a copy of personal data in response to an access request, you must not disclose the personal data of other individuals. This means all third-party PII in the response documents must be permanently redacted — names, emails, phone numbers, addresses, and identification numbers of anyone other than the requester. This obligation exists under GDPR, CCPA, and every US state privacy law.

What platforms use the term "subject rights request"?

Microsoft Priva uses "subject rights request" as its primary term. OneTrust and ServiceNow use SRR in their privacy management modules. DataGrail uses "individual rights request" (IRR). BigID and Securiti use "data subject request" (DSR). The terminology often depends on which platform an organisation uses for privacy management, which is why this guide covers all variants.