Skip to main content
PDPA & Privacy

A Data Subject Request (DSR) Has Arrived: What Should You Do Within 30 Days? — Step by Step

A step-by-step operational guide to handling DSRs under the PDPA, covering all 6 types of rights, the 30-day timeline, and common mistakes to avoid.

25 Feb 20267 min
DSRPDPAdata subject requestdata subject rightsrights requestdata protection

One day, HR receives an email from a former employee asking the company to delete all of their personal data. The next day, a customer calls to ask what information the company holds about them. These situations are known as Data Subject Requests (DSRs), or requests by data subjects to exercise their rights under the PDPA—and your organization has only 30 days to act.

This article walks you through every step of handling a DSR, from the moment the request is received to closing the case.

The 6 Types of Rights You Need to Know

Sections 30–36 of the PDPA grant data subjects 6 types of rights. Each has different details and conditions.

Right of Access

This is the most frequently exercised right. A data subject may request access to the personal data your organization has collected about them, including a copy of that data. The organization must provide the information in a format that is readable and easy to understand.

Right to Rectification

Is the data inaccurate, incomplete, or misleading? The data subject has the right to request correction, and the organization must review and take appropriate action.

Right to Erasure

A data subject may request deletion or destruction of personal data when it is no longer necessary for the original purpose, or when consent has been withdrawn. However, this right has important exceptions—if the organization has another lawful basis for retaining the data, deletion may not be required.

Right to Restriction

This right applies only in certain situations, such as while the organization is verifying the accuracy of the data or considering an objection. A data subject may request a temporary suspension of processing.

Data Portability

A data subject may request their data in a machine-readable format and may also request that it be transmitted directly to another data controller. This right is being exercised more frequently.

Right to Object

A data subject may object to the collection, use, or disclosure of their personal data, particularly where processing is based on Legitimate Interest or for direct marketing. If the objection relates to Direct Marketing, the organization must stop immediately without exception.

Process Flow: How to Handle a DSR Within 30 Days

Days 1–3: Receive and Log the Request

Responsible party: Request intake team (such as Customer Service, HR, or the DPO Office)

  • Receive the request through designated channels (web form, email, letter)
  • Log it into the tracking system, including the date received, reference number, and type of right requested
  • Send an automatic acknowledgment email confirming receipt
  • Start counting the 30-day period

Important: Every request must be logged, even if it comes through an informal channel such as a phone call or message.

Days 3–7: Verify the Requester’s Identity

Responsible party: Request intake team + relevant departments

  • Verify that the requester is the actual data subject
  • Use appropriate methods such as checking an ID card, sending an OTP, or confirming against existing information
  • If the information in the request is insufficient, ask the requester for additional details (the 30-day period is temporarily paused until the information is received)

Caution: Do not request more information than necessary for identity verification, as this may constitute excessive data collection beyond the intended purpose.

Days 7–10: Assess the Request

Responsible party: DPO or Legal team

  • Identify the type of right being requested (in some cases, one request may cover multiple rights)
  • Assess whether the request can be fulfilled or whether there are legal grounds for refusal
  • Check whether any exceptions apply, such as data that must be retained under other laws
  • If the request must be denied, prepare the reason and cite the relevant legal provisions

Days 10–20: Fulfill the Request

Responsible party: IT + data-owning departments + DPO

This is usually the most time-consuming step, because you must identify which systems contain the relevant data.

  • Access / Portability: Search for and collect data from all systems, then prepare it in an appropriate format
  • Rectification: Correct the data in all relevant systems and verify that the updates are complete
  • Erasure: Delete the data from all systems, including backups, except where another legal basis justifies retention
  • Restriction: Tag the data as restricted and prevent its use until the status changes
  • Objection: Stop the disputed processing and remove the individual from direct marketing lists (if applicable)

Key point: Do not forget to notify external Data Processors that have received the data.

Days 20–25: Review and Approve

Responsible party: DPO + Legal team

  • Confirm that all required actions have been completed across all systems
  • Review the response documentation for accuracy and completeness
  • Approve the response

Days 25–30: Respond to the Data Subject

Responsible party: Request intake team

  • Send the outcome to the data subject through a secure channel
  • If the request is denied, explain the reason and inform the data subject of their right to file a complaint with the PDPC
  • Record the outcome in the tracking system
  • Close the case

Who Does What: A Simplified RACI Table

  • DPO / Privacy Office: Accountable for all stages
  • Request intake team: Responsible for request intake and responses
  • IT team: Responsible for locating data and carrying out data actions
  • Legal team: Consulted during assessment and approval
  • Management: Informed in cases involving high risk

7 Common Mistakes

1. No clear DSR submission channel — Customers cannot find a way to submit a request, so they file a complaint with the PDPC instead.

2. Starting the timeline incorrectly — The 30-day period starts on the date the request is received, not the date identity verification is completed (except where additional information is required).

  1. Not knowing where the data is because there is no Data Inventory, resulting in incomplete searches across systems and incomplete responses to the data subject.

  2. Denying a request without citing a legal exception, which is not acceptable. A DSR refusal must always be supported by a lawful basis.

5. Forgetting to notify external processors — The organization deletes data from its own systems but fails to notify vendors that also received the data.

  1. Failing to retain evidence of the actions taken. When the PDPC investigates, there are no records to show, and the organization cannot prove what it did.

7. Responding after the 30-day deadline because there is no effective tracking system, and the request gets lost in email or spreadsheets.

Manage DSRs Systematically with PrivacyHub

Managing DSRs through spreadsheets or email may be manageable when there are only a few requests. But as volume increases, so does the risk of missed requests or missed deadlines.

PrivacyHub includes a DSR Management module designed to support the entire DSR process end to end—from receiving requests through a web form, identity verification, and automatic routing to responsible parties, to real-time status tracking and response report generation. Every step is recorded as an immutable Audit Trail.

In addition, Genesis AI helps automatically classify request types, reducing the workload of the DPO team and providing early alerts when requests are approaching their deadlines—helping ensure your organization meets the PDPA’s 30-day requirement.

Learn more about PrivacyHub at enersys.co.th/en/products/privacyhub

"Empowering Innovation,
Transforming Futures."

ติดต่อเราเพื่อทำให้โปรเจกต์ของคุณเป็นจริง