Thailand’s PDPA treats consent as a valid lawful basis only when people understand what they are agreeing to and can choose purpose by purpose. That reduces hidden reuse of data, prevents broad blanket authorisations, and forces controllers to align processing with the purpose originally disclosed. If a new purpose emerges, fresh consent is generally needed unless another legal basis applies.
What “informed” and “specific” consent mean under Thailand’s PDPA
Under Thailand’s PDPA, consent is not a generic opt-in. It has to be understandable, tied to a clear disclosure, and narrow enough that the person can tell what processing they are authorising. That matters because consent is the lawful basis only when the controller can show the person knew the scope of use, not just that they clicked agree.
“Informed” means the notice or request should explain the controller’s identity, the purpose, and the consequences in plain terms, so consent is not obtained through ambiguity. “Specific” means each purpose should be separated enough that the person can accept one use and decline another. That is why a single blanket statement usually fails where multiple processing purposes are involved.
For practical compliance, the test is whether a reasonable person could distinguish one purpose from another without needing to infer hidden reuse. If the wording is broad enough to cover future reuse, profiling, marketing, sharing, or other distinct uses, the consent may stop being purpose-specific and become too open-ended to support valid reliance on consent.
Why separate purposes matter for lawful processing
Separate purposes are not a formality, they are what keeps consent aligned with the principle of purpose limitation. When a controller merges several uses into one request, the person cannot make a real choice about each use, and the controller gains room to repurpose data later in ways the person never actually approved. That is exactly the control failure PDPA tries to prevent.
Separate consent also improves accountability. It forces the controller to document which processing activity depends on which lawful basis, which is useful when a team later wants to add a new campaign, share data with another party, or reuse the same dataset for analytics. If the new use is materially different, the original consent should not be stretched to cover it.
Thailand’s EU General Data Protection Regulation (GDPR) is a useful comparison point because it reflects the same compliance logic: consent must be tied to a specific, disclosed purpose rather than used as a blanket authorisation. That makes purpose separation a design requirement, not just a notice-writing exercise.
How controllers should structure consent flows in practice
The cleanest pattern is to map each processing purpose to its own consent decision and to keep that mapping visible in the user flow and records. If a purpose is optional, it should be optional on its own. If another purpose is needed to perform the service, the controller should not bundle it with marketing or other secondary uses just to raise opt-in rates.
Where a new purpose appears later, the controller should treat it as a new decision point unless another lawful basis clearly applies. That means checking whether the new processing is genuinely within the original disclosure, whether the original language was narrow enough, and whether the person was given a real ability to refuse the extra use without losing unrelated functionality.
The practical discipline here is similar to what privacy engineers aim for in any purpose-limited design: collect only what is needed, separate what is optional from what is essential, and keep consent records aligned to the actual processing activity. The Identity Data Privacy and Consent Guide is relevant here because it shows how consent, minimisation, and retention controls reinforce one another when personal data is being used across more than one purpose.
Risk and Threat Considerations
When consent is broad or bundled, the main risk is not just non-compliance, it is hidden reuse of data under an apparently valid lawful basis. That weakens user trust, increases the chance of downstream complaints or regulator scrutiny, and makes it harder to prove that a later processing activity was actually authorised.
Failure mechanism: A controller presents several distinct purposes as one choice, or reuses a prior consent for a new purpose, so the person never had a meaningful opportunity to agree purpose by purpose. In practice, that creates a control gap between the stated purpose and the actual processing.
Impact: The organisation may have to suspend the new processing, rebuild its notices and consent logs, and re-collect valid consent or move the activity to another lawful basis. The same weakness can also expose the organisation to complaints if data is shared or repurposed beyond what was originally disclosed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while GDPR and ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| GDPR | Art. 5 — Principles relating to processing of personal data | Purpose limitation and fairness directly mirror the consent specificity issue. |
| Art. 7 — Conditions for consent | Sets the bar for freely given, informed, and unambiguous consent. | |
| Art. 25 — Data protection by design and by default | Supports building separate-purpose consent into the processing design. | |
| Recommendation — Align each consent request to one disclosed purpose and avoid blanket reuse. Document consent so it can be withdrawn and proven for each separate purpose. Design collection flows so optional uses are separated from required processing. | ||
| ISO/IEC 27001:2022 | A.5.34 — Privacy and protection of PII | Privacy controls require lawful, purpose-limited handling of personal data. |
| Recommendation — Set governance so each processing purpose is traceable to an approved legal basis. | ||
| NIST SP 800-53 Rev 5 | AP-1 — Privacy Program Plan | A privacy program needs documented purpose and consent handling rules. |
| Recommendation — Define privacy procedures that separate lawful bases by processing purpose. | ||
Practitioner Guidance
What to verify: Check that each consent request names one processing purpose in language a non-specialist can understand, and that the person can accept or decline that purpose without ambiguity. If the page or form mixes essential service processing with optional reuse, split them before launch.
Decision rule: If the new processing changes the purpose, recipient, or downstream use of the data, treat it as a fresh consent decision unless you can point to a different lawful basis with confidence. Do not rely on a broad “future use” clause to cover a materially different activity.
Practitioner takeaway: Valid consent under PDPA is a purpose-control mechanism, not a general permission slip, so the quality of your purpose separation is what determines whether the consent can actually be relied on later.
Related resources from NHI Mgmt Group
- Why do misleading consent statements present significant risks?
- Why do direct marketing campaigns into the EU require more specific consent under GDPR?
- What is the difference between consent-based processing and the PDPA exemptions for employee data?
- Why does Quebec guidance require consent to be granular and specific for personal data use?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
