PDPA Compliance & Data Protection Counsel in Thailand

Data mapping and the record of processing activities (ROPA)

The most essential opening step is walking through what data the organisation actually holds, where each item comes from, how long it is kept, and who it is passed to, from a website sign-up form and office CCTV to the payroll system HR touches daily. Many organisations discover data sitting in places no one had thought to check, such as attachments in old emails or a spreadsheet a staff member kept for personal convenience.

The findings feed into the record of processing activities the law requires every data controller to maintain. That record must state the purpose of each collection, the legal basis relied on, the retention period, and the security measures applied to each data set. It is not a document written once and filed away; it needs updating whenever a new system or new collection channel appears.

In practice we give each department a short questionnaire paired with an interview of the process owner, because existing policy documents rarely match what happens on the ground. The result is an organisation-wide data map that underpins every later task, from drafting the privacy notice to assessing risk when a breach occurs.

Lawful basis and a privacy notice a reader can actually understand

Each data set needs a lawful basis for its collection and use, whether consent, contractual necessity, legal obligation, legitimate interest, or another basis appropriate to the data. The most common mistake is defaulting to consent for every case, when in some situations consent is not a suitable basis at all because the customer has no genuine choice to refuse while still receiving the service.

A good privacy notice genuinely informs the data subject what is collected, why, who it is shared with, and what rights they hold, written in language an ordinary reader understands without needing a law degree. We avoid lifting a translated foreign template, because the collection context differs by business: a retail shop and a hospital hold entirely different sensitive touchpoints.

Sensitive data such as health, religious or criminal record information carries stricter conditions than ordinary data, requiring explicit consent or a specific statutory exception. We therefore isolate this category for special review from the mapping stage onward, rather than letting it blend into a general form alongside ordinary fields.

Data processing agreements (DPA) and appointing a data protection officer (DPO)

When an organisation sends data to an outside vendor for processing, whether a cloud provider, an email marketing platform, or an outsourced call centre, the law requires a data processing agreement specifying the scope of processing, security measures, and the duty to report incidents back to the controller. We review every existing contract, because standard service agreements rarely cover these terms in full.

Appointing a data protection officer is mandatory for certain types of businesses, particularly those processing sensitive data at scale or routinely monitoring individuals' behaviour. Even for businesses outside the mandatory threshold, having someone clearly responsible makes handling data-subject requests and liaising with the regulator far more orderly. We help define the role's scope so it does not simply overlap with existing legal or IT duties.

For corporate groups with several affiliated entities, a common question is whether one officer can cover the whole group and how an intra-group data-sharing agreement should be worded. We design the document structure to match how the group actually operates, rather than forcing everything into a single template that does not reflect real practice.

Consent management and handling data-subject rights

A consent request must sit separately from other terms of service; the data subject needs to understand exactly what they are agreeing to, and withdrawal must be as easy as giving consent in the first place. A checkbox buried at the end of a long document, or a default set to opt-in, are both high-risk practices under scrutiny.

Data subjects hold several rights: to access their data, to have it corrected, to have it erased or destroyed, and to object to processing in certain cases. The organisation needs a clear intake channel and an internal process assigning responsibility and a response timeframe. We design the request form and internal workflow so that frontline staff know exactly who to escalate a request to and within what number of days it must be answered.

Cross-border transfer to overseas service providers

Many Thai businesses use software and cloud services hosted overseas, which legally counts as a cross-border transfer. The destination country must offer an adequate standard of data protection, or, failing that, the transfer must rely on an alternative safeguard such as a contract with data-protection clauses recognised by the regulator or an approved set of intra-group binding rules.

Our work is to check which category the overseas provider a business already uses falls into, and to prepare the necessary substitute documentation where the destination country has not been declared adequate. Many cases involve negotiating with large providers to accept added clauses within their own standard contracts, which requires understanding both Thai law and the frameworks those providers are already used to working with.

Organisations with an overseas parent or branch often face the same recurring question of whether to centralise employee and customer data at the foreign head office. We help structure the transfer correctly from the outset, rather than allowing the transfer to happen first and fixing it retroactively, which carries far higher cost and risk.

Responding to a data breach within the 72-hour window

When a breach occurs that risks the rights and freedoms of data subjects, the law requires the controller to notify the PDPC office without delay and, where feasible, within 72 hours of becoming aware. That window is extremely short against how complex it can be to establish what actually happened, so an organisation needs a written response plan in place beforehand, not one improvised as the incident unfolds.

A workable plan names who holds decision authority, sets out the initial technical containment steps, provides a fact-logging form to be completed immediately, and gives criteria for deciding whether affected data subjects must also be notified directly. We help run a simulated exercise with the IT and management teams before a real incident, because even a single rehearsal usually exposes gaps in the process that the written plan alone never revealed.

After the incident, the step most often overlooked is recording lessons learned and updating safeguards to prevent recurrence. The regulator typically weighs whether reasonable safeguards were already in place alongside how promptly the incident was reported. An organisation with a documented history of post-incident improvement stands in a far better position than one that never reviewed anything at all.

Internal audits and preparing to face a PDPC complaint

A data subject dissatisfied with how an organisation has treated their data may file a complaint directly with the PDPC office. When a request for information arrives from the office, an organisation with a maintained record of processing activities, written policies and complete consent evidence can respond quickly and credibly, unlike one scrambling to reconstruct documentation under time pressure.

We recommend a periodic internal audit, at least annually or whenever a major system changes, to confirm that actual practice still matches written policy. This covers both the documentary side, such as whether the privacy notice is still current, and the technical side, such as whether database access rights are genuinely limited to those who need them.

When facing a complaint or an inquiry from the office, a cooperative and directly responsive stance tends to produce a better outcome than denial or delay. We help organisations prepare responses grounded in genuine internal documents, showing an ongoing system of data governance rather than paperwork assembled only after the complaint arrived.

When to act, and when waiting is fine

• Start immediately if the organisation has never built a record of processing activities

  This is the foundation every later task references; the longer it waits, the more new collection points accumulate that later need chasing down.

• Prioritise sensitive data ahead of ordinary data

  Health data and other sensitive categories carry stricter legal conditions and are typically the first point a data subject complains about.

• No need for a full-time data protection officer yet if the business is small and outside the mandatory threshold

  Assigning a clear internal owner is enough for the early stage; reassess once the business grows or begins processing more sensitive data.

• Once an anomaly is spotted in a system, follow the response plan immediately without waiting for a complete investigation

  The 72-hour clock, where feasible, runs from becoming aware of the incident, not from the day the full investigation concludes.