Organisations should separate consent from contracts and service terms, use clear opt-in mechanisms, and make refusal genuinely possible without pressure or deception. The request should stand on its own, describe the purpose of processing, and avoid preselected boxes or bundled permissions. Consent is only valid when the individual can decide independently and voluntarily, with no coercion or hidden conditions attached.
What “freely given” consent means in practice under Thailand’s PDPA
“Freely given” is not just a formality. Under Thailand’s PDPA, consent has to be a real choice, which means the person must be able to say no without losing access to a separate service or being pushed toward the decision by design, wording, or default settings. The collection flow should make the purpose of processing obvious before any acceptance is requested.
That means the consent request should be separated from terms that govern a contract, marketing preference, or account creation. If the request is bundled with unrelated permissions, the individual cannot meaningfully choose each purpose on its own, and the organisation weakens the legal quality of the consent it records.
How to design a valid consent flow
A compliant flow should be narrow, explicit, and purpose-specific. The individual should see what data will be processed, why it is needed, and what happens if they decline. Separate toggles or checkboxes are better than broad statements because they let the user agree to one purpose while refusing another.
Clear presentation matters as much as the form control itself. Preselected boxes, implied consent, silence-as-acceptance, or opt-out wording do not produce the same evidential value as an active opt-in. If the organisation needs to demonstrate valid consent later, it should be able to show exactly what was shown, when the person chose it, and what each choice covered.
Good practice is to use plain language, avoid conditional pressure, and make the refusal path equally visible. If refusal is hidden behind extra clicks, confusing phrasing, or a degraded user experience that is unrelated to the core service, the organisation risks turning a supposedly voluntary choice into a compelled one. For a practical privacy baseline, align the consent flow with the data-minimisation and transparency expectations reflected in the EU General Data Protection Regulation (GDPR) and the implementation guidance in Identity Data Privacy and Consent Guide.
When consent stops being freely given
Consent stops being dependable when the organisation creates an imbalance of power or removes genuine choice. Common failure patterns include bundling consent with contract acceptance, making access conditional on unrelated marketing consent, and using wording that suggests the person must comply to proceed even when the processing is optional.
The problem is not only legal wording. Poor user interface design can also invalidate the practical choice. If the default path nudges everyone into agreement, if the decline option is harder to reach, or if different purposes are presented as one combined permission, the organisation may collect a record of “consent” that does not reflect a voluntary decision.
Failure mechanism: The individual is steered into agreement through bundling, defaults, or pressure, so the record captures acceptance rather than a genuinely independent choice.
Impact: The organisation may lose a lawful basis for the processing, expose itself to complaint or enforcement, and be forced to redesign or withdraw the consent-based activity.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
GDPR and ISO/IEC 27001:2022 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| GDPR | Art.7 — Conditions for Consent | Consent validity and voluntariness are central to this consent-flow question. |
| Art.5 — Principles relating to processing of personal data | Purpose limitation and transparency shape how consent must be presented. | |
| Art.25 — Data protection by design and by default | Consent UX and defaults are part of privacy-by-design implementation. | |
| Recommendation — Separate consent from bundled terms and keep every purpose opt-in, specific, and withdrawable. Present the purpose clearly before acceptance and avoid hidden or combined processing purposes. Design the consent flow so refusal remains genuinely available without pressure or deceptive defaults. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Consent collection interfaces govern who is allowed to grant or refuse processing permissions. |
| A.5.31 — Legal, statutory, regulatory and contractual requirements | PDPA-driven consent handling is a compliance obligation that must be built into governance. | |
| Recommendation — Implement consent workflows with clear approval boundaries and traceable decision records. Map PDPA consent requirements into documented control ownership and review evidence. | ||
Practitioner Guidance
What to verify: Check that each purpose has its own consent action and that the individual can refuse one purpose without blocking unrelated service access. If the business process cannot survive that separation, it is probably not a good candidate for consent as the basis of processing.
Decision rule: Use consent only where the person can make a real, unpressured choice. If the activity is essential to deliver the service, consider whether another lawful basis is more appropriate, because forcing consent into an essential flow usually produces weak evidence and higher challenge risk.
What practitioners underestimate: The weakest point is often not the legal text but the journey design. A consent statement can look compliant on paper while the interface, defaults, or dependency structure quietly removes the freedom that the rule is trying to protect.
Practitioner takeaway: Treat freely given consent as a user-choice problem first and a form-design problem second, because the law will follow the actual power balance and interaction design, not the label on the checkbox.
Related resources from NHI Mgmt Group
- How should organisations implement consent flows so they are freely given and unambiguous under the GDPR?
- How should organisations implement verifiable parental consent for children’s data under COPPA?
- How should organisations implement PIPEDA compliance across collection, consent, retention, and access rights?
- How should employers handle employee data collection under Thailand’s PDPA?
