How to Handle DSARs with OneTrust: Access, Correction, and Erasure

OneTrust Privacy Rights Automation is built to run data subject (or consumer) requests end to end: intake, identity verification, discovery, rectification or deletion actions, redaction, and secure response. This guide focuses on three request types Indian and multi-jurisdiction teams handle most often: access, correction (rectification), and erasure (deletion).

Product names and screens change across OneTrust releases. Treat the steps below as a working pattern grounded in OneTrust public documentation for Privacy Rights Automation, web forms, workflows, Targeted Data Discovery (TDD), and the DSR Automation APIs. Confirm labels in your tenant before you go live.

Map request types to laws before you configure OneTrust

OneTrust can host many request types in one module. Your workflow logic still has to match the law that applies to each requester.

• Access: GDPR Article 15; DPDP Act Section 11 (summary of data and activities, plus sharing details where that section applies).
• Correction / rectification: GDPR Article 16; DPDP Act Section 12(2) (correct, complete, update).
• Erasure / deletion: GDPR Article 17; DPDP Act Section 12(3) (erase unless retention is needed for the specified purpose or for law).

For India, remember the commencement schedule: Sections 11 to 17 of the DPDP Act become operative on 13 May 2027 under MeitY G.S.R. 843(E) (13 November 2025). You can still configure OneTrust now and align India-specific response templates before that date.

Core OneTrust building blocks

OneTrust public materials describe Privacy Rights Automation as covering intake, identity verification, data discovery, deletion, data redaction, and secure response. The main objects you will configure are:

• Web forms: branded intake forms linked from your privacy policy.
• Workflows: stages and subtasks that move a request from unverified to complete.
• Identity verification: email, phone, account authentication, or other methods you enable.
• Privacy Portal / secure messaging: where the requester reads responses and uploads proof.
• Targeted Data Discovery (TDD): system subtasks that fetch or delete data in connected systems.
• Resolution codes and audit history: how you close requests and prove what changed.

Step 1: Publish intake that matches your privacy notice

Link the form from the privacy policy

OneTrust best-practice guidance expects data subjects to create requests through a branded web form linked from your privacy policy page. Put the same link on cookie and rights pages so support teams are not the only intake path.

Configure the web form fields

Collect only what you need to identify the person and route the request:

• Name and contact email (required for portal access in typical setups).
• Request type: access, correction, erasure (and others you support).
• Country or state of residence (for regulatory routing).
• Account or customer identifier if you publish that requirement (useful for DPDP Rule 14 identifiers).
• Free-text description (for correction: what is wrong and what it should be).

Enable CAPTCHA and attachment upload when your OneTrust web form settings allow it, especially if you will ask for identity documents later.

Assign a workflow to the form

Each form should point at an active workflow. OneTrust documentation states that default workflows cannot be edited in place. Create a new workflow from a default or existing template, customise stages and subtasks, then activate it. If you edit a workflow already tied to a form, reactivate it so new submissions use the published version.

Step 2: Verify identity before you disclose or delete

OneTrust workflows commonly start in an Unverified stage. Best-practice articles describe validating identity and, in some cases, residency before fulfilment.

Practical verification pattern

1. Prefer proving control of the account email or phone already on file.
2. For password-protected accounts, use your existing login or OTP flow when OneTrust verification settings support it.
3. Escalate to document upload through the secure portal only when risk is high (for example, erasure of payment or identity data).
4. Refuse or pause fulfilment when you cannot verify, and record the reason in the request history.

Under GDPR and many US state laws, authentication before disclosure, correction, or deletion is expected. Under the DPDP Act, Section 15 also requires principals to furnish verifiably authentic information for correction or erasure requests. Keep checks proportionate.

Step 3: Access requests (DSAR know / access)

Workflow stages

A workable access workflow looks like this:

1. Unverified: identity check subtasks.
2. New / intake review: confirm request type, residency, and systems in scope.
3. Discovery: run TDD system subtasks and manual data discovery for offline or unconnected stores.
4. Review and redact: remove other people’s data, secrets, and privileged material before release.
5. Respond: publish the package to the Privacy Portal.
6. Complete: apply a resolution code and close.

OneTrust documentation notes that Unverified, New, and Complete stages cannot be deleted when you customise workflows. Add middle stages as needed.

Discovery tips

• Use TDD subtasks with integration workflows (API triggers and actions) so connected apps return data into the request.
• Add manual discovery entries for paper files, local drives, or systems without connectors.
• For DPDP Section 11, prepare a summary of processing activities and a list of fiduciaries or processors with whom data was shared, not only a raw file dump.
• For GDPR Article 15, include the Article 15 information set (purposes, categories, recipients, retention, rights, and related items) in your response template.

Secure delivery

Send the response through OneTrust’s secure messaging or Privacy Portal path rather than open email attachments when the package contains personal data. OneTrust materials describe a portal where the subject can read responses, reply, and upload verification documents after public comments or responses are posted.

Step 4: Correction (rectification) requests

Correction requests need a clear “current value” and “requested value”. Capture both on the web form.

Fulfilment pattern in OneTrust

1. Verify identity.
2. Confirm the field and system of record (CRM, billing, identity provider).
3. Create subtasks for each system owner who must update data.
4. Where TDD or integrations support rectify actions, use them; otherwise complete manual subtasks and attach evidence (screenshot or ticket ID).
5. Push the same correction to processors under contract so stale copies do not overwrite your fix.
6. Notify the requester through the portal that the correction is done, or explain why you cannot change a field (for example, a legal record that must stay accurate historically).
7. Close with a resolution code that distinguishes “corrected”, “partially corrected”, and “denied”.

Align outcomes to GDPR Article 16 and DPDP Section 12(2). If you deny a change, say why in plain language and keep the audit trail.

Step 5: Erasure (deletion) requests

Decide retain vs delete before you press delete

Build a retention decision table outside OneTrust, then encode it as workflow guidance text and subtasks:

• Delete marketing profiles and non-essential analytics identifiers when no legal hold applies.
• Retain invoices, KYC, or dispute records when law or the specified purpose still requires them (DPDP Section 12(3); GDPR Article 17(3) exceptions).
• Document partial erasure: what was deleted, what was kept, and the legal basis for keeping it.

OneTrust deletion flow

1. Verify identity at a higher bar than for a simple marketing preference change.
2. Run discovery so you know every store that holds the person.
3. Trigger TDD or integration delete actions for connected systems.
4. Assign manual delete subtasks for backups, logs, and offline stores, with clear “deleted / anonymised / retained” outcomes.
5. Instruct processors (ticket or contract workflow) so they erase or return data you made available for processing.
6. Redact residual files if you must share confirmation packs that still contain third-party data.
7. Message the outcome in the portal and close with a resolution code.

OneTrust describes the ability to discover, delete, rectify, or otherwise action a requestor’s data across relevant systems, including through system subtasks. Use that automation where connectors exist; do not pretend a green subtask means backups and cold storage are clean unless your runbooks say so.

Step 6: Subtasks, assignees, and SLAs

OneTrust workflows use subtasks (user or system) that can be required before a stage advances. Practical setup:

• Auto-assign privacy analysts for intake and portal messaging.
• Auto-assign system owners for CRM, support, and product databases.
• Mark legal review as required for erasure with active disputes or regulatory inquiries.
• Use automated public comments when moving stages so the requester sees progress.

Set internal clocks tighter than the legal outer limit. Example: acknowledge in two business days; complete standard access in 30 days for GDPR-style programs; for DPDP grievances, Rule 14(3) requires you to publish a response period not exceeding ninety days.

Step 7: Resolution codes and audit history

OneTrust DSR Automation APIs expose resolution codes and request audit history. The Get Request Audit History API returns field updates, old and new values, timestamps, and user details for a request queue reference ID. Use that history when auditors ask who approved an erasure or changed a stage.

Create resolution codes that match your legal outcomes, for example:

• Completed – full access provided
• Completed – correction applied
• Completed – erasure applied
• Completed – partial erasure (retention applied)
• Rejected – identity not verified
• Rejected – request frivolous or not personal data
• Closed – withdrawn by requester

Create resolutions through the product UI or the Create Resolution API documented on the OneTrust developer portal, then train staff to pick the right code every time.

Step 8: India-ready configuration notes

1. Publish on your site the means to exercise rights and the identifiers you need (DPDP Rule 14(1)), and point that page to the OneTrust form.
2. Add an India or DPDP request type or workflow variant with Section 11 summary fields and Section 12 erasure retention reasons.
3. Store grievance response targets in guidance text (at most 90 days under Rule 14(3)).
4. Plan a nomination intake path for Section 14 once legal approves how nominees prove authority; OneTrust forms can collect nominee details even if fulfilment stays manual at first.
5. Keep cookie and consent tooling separate from DSAR fulfilment, but link both from the same privacy hub.

Operational pitfalls to avoid

• Leaving the default workflow on the form after you customised a copy and forgot to activate it.
• Sending personal data packs over plain email instead of the secure portal.
• Marking erasure complete when only the CRM row was deleted and the ESP or data warehouse still holds the profile.
• Skipping redaction so one person’s access pack reveals another customer’s data.
• No resolution codes, which makes reporting and Board or DPA inquiries harder.

Related in this series: OneTrust DSAR Automation: Setup and Best Practices, DPDP Act User Rights: A Practical Guide for Indian Websites, and GDPR vs DPDP: User Rights and Consent Compared.

Sources

• OneTrust, Privacy Rights Automation Overview: MyOneTrust article.
• OneTrust, Best Practices: Managing Data Subject Rights and Requests: MyOneTrust article.
• OneTrust, Customizing a Workflow; Adding and Deleting Workflows (Setup > Workflows; Unverified, New, Complete stages retained).
• OneTrust developer portal, Privacy Automation DSR APIs (request audit history, resolutions): Get Request Audit History.
• Digital Personal Data Protection Act, 2023, Sections 11 to 15; MeitY G.S.R. 843(E) commencement; DPDP Rules, 2025, Rule 14.
• Regulation (EU) 2016/679, Articles 15 to 17: EUR-Lex.

Disclaimer

This article was prepared using publicly available information. It is for general education only and is not legal advice. Do not rely on it alone when implementing cookie compliance, DSAR handling, consent flows, privacy policies, or other privacy and data-protection controls. Consult your own legal counsel for advice that fits your business, jurisdictions, and systems.

Last updated on 20 September 2026