Visit almost any website and you will see a popup asking for cookie consent. Many organizations assume that this alone means they have fully addressed consent under PDPA. In reality, that is far from the truth. A cookie banner is only the tip of the iceberg. Proper PDPA-compliant consent management covers far more than that.
This article takes a deeper look at consent management beyond cookie popups—from core concepts and the full consent lifecycle to all 6 legal bases, as well as how to track and retain evidence in a way the PDPC will accept.
Why a Cookie Banner Is Not Enough
A cookie banner only manages consent for website cookie usage. But organizations collect personal data through many other channels as well.
- Registration forms — collect names, email addresses, and phone numbers
- Job application forms — collect education history and work experience
- CRM systems — collect customer data from multiple channels
- CCTV — captures images of individuals entering premises
- HR systems — collect employee data, health information, and financial data
- Applications — collect usage behavior and location data
Every point at which personal data is collected must have a valid legal basis. And if consent is used as that basis, it must be managed systematically.
The 6 Legal Bases Under PDPA
Before discussing consent, it is important to understand that consent is only 1 of the 6 legal bases defined by PDPA. Choosing the appropriate legal basis is the most important starting point.
Consent — Section 19
This is the legal basis most people are familiar with. The data subject gives consent clearly, freely, specifically, and based on sufficient information provided in advance. It should be used only when no other legal basis is more appropriate, such as for sending marketing communications or collecting data beyond what is necessary for a contract.
Contract — Section 24(3)
This basis applies when processing is necessary for the performance of a contract to which the data subject is a party. Examples include collecting a shipping address for an order or processing employee data under an employment contract. In such cases, consent is not required, but a privacy notice must still be provided.
Legal Obligation — Section 24(6)
When another law requires data to be processed, this basis may be used directly. Examples include collecting employee data under labor law, submitting information to regulators, or reporting transactions under anti-money laundering laws.
Vital Interest — Section 24(1)
This basis has a very limited scope. It can only be used when necessary to prevent or suppress danger to a person’s life, body, or health. A classic example is disclosing health information to doctors when a patient is unconscious.
Public Task — Section 24(4)
This basis is mainly intended for public authorities. It applies when processing is necessary for performing duties carried out in the public interest or exercising official authority. Private-sector organizations rarely use this basis.
Legitimate Interest — Section 24(5)
This basis is highly flexible but also the most complex. It applies when processing is necessary for the legitimate interests of the data controller, provided those interests do not override the rights of the data subject. Examples include fraud prevention and network security. However, a Legitimate Interest Assessment (LIA) must always be conducted before using this basis.
The most common mistake: using consent as the legal basis for everything, even when another basis would be more appropriate. The problem is that if the data subject withdraws consent, the organization may be left without a legal basis for necessary processing.
The Consent Lifecycle
Consent is not just a one-time request. It has a lifecycle that must be managed continuously.
1. Giving Consent
- It must involve an explicit action, not a pre-ticked checkbox
- It must be freely given, without coercion or bundling with unrelated services
- It must be specific and separated by purpose
- It must be informed, with sufficient information provided in advance
2. Renewal
- If the purpose changes, new consent must be obtained
- If a new purpose is added, additional consent must be obtained
- Consent should be reviewed and renewed periodically, especially for sensitive data
3. Withdrawal
- Data subjects have the right to withdraw consent at any time
- Withdrawal must be as easy as giving consent (if consent is given via the web, it should also be withdrawable via the web)
- Once consent is withdrawn, processing for that purpose must stop immediately
- Withdrawal does not affect processing that occurred before the withdrawal
4. Expiration
- Consent should not last forever; it should have an appropriate validity period
- Once consent expires, it must be obtained again if processing is still required
- Sensitive data should generally have a shorter consent duration than general personal data
How to Track Consent Properly
What Must Be Recorded
For every consent collected, at least 7 items should be recorded:
- Who — the identity of the data subject who gave consent
- When — the date and time consent was given (timestamp)
- How — the channel and method used (web form, paper, app)
- For what purpose — the specific purpose for which consent was given
- What data — the categories of data covered
- What was shown — the content of the consent notice the data subject saw at that time
- Version — the version of the privacy policy/consent notice used
Immutable Audit Trail: Why It Matters
The most important principle of consent management is the ability to prove it retrospectively. If the PDPC investigates, the organization must be able to demonstrate when consent was given, for what purpose, and what wording the data subject saw.
A Consent Log should be append-only, meaning new entries can be added but old entries cannot be modified or deleted. When consent is withdrawn, a new entry stating "consent withdrawn" should be added rather than deleting the original record.
Why must it be immutable?
- Legal evidence — proves to the PDPC that valid consent actually existed
- Prevents backdated edits — no one can alter consent history afterward
- Supports auditability — external auditors can verify its integrity
- Reduces disputes — if a data subject claims they never gave consent, the record can be checked immediately
7 Common Consent Mistakes
Pre-ticked Checkbox
This is the clearest violation, yet it is still seen frequently. Using a checkbox that is already ticked and requiring users to untick it if they do not agree violates the PDPA principle that consent must result from an explicit action.
Bundled Consent
Another common issue is combining multiple purposes into a single consent option, such as "I consent to data collection for service provision and marketing communications." Legally, consent must be separated by purpose.
Making Withdrawal Harder Than Giving Consent
Giving consent is easy—just one click—but withdrawing it requires calling a contact center or sending a letter. This conflicts with the principle that withdrawal must be as easy as giving consent.
Not Keeping Versions of the Consent Notice
Organizations change the wording of their consent notice but do not retain previous versions. As a result, they cannot prove what wording the data subject saw at the time consent was given. This may seem minor, but it is a point the PDPC tends to scrutinize closely.
Consent With No Expiration
Keeping consent forever without review is problematic, especially for sensitive data, where consent should be refreshed periodically.
Making Consent a Mandatory Condition
Statements such as "You must consent to receive marketing communications before registering" are invalid because they force consent as a condition of using the service, even though marketing consent is not necessary for the core service.
Storing Consent Logs in a Spreadsheet
Using Excel or Google Sheets to store Consent Logs is risky because records can be edited easily, there is no audit trail, and it is impossible to prove that no retrospective changes were made. The PDPC is unlikely to accept this as reliable evidence.
From Cookie Banner to Consent Governance
Proper PDPA-compliant consent management is not just a technology issue—it is a matter of process and governance. It requires clear policies, systematic procedures, and tools that support the full consent lifecycle.
What organizations should have for complete consent management includes:
- A Consent Center where data subjects can manage their own consent
- An append-only Consent Log system that cannot be altered
- Integration with downstream systems to enforce consent across all processing points
- Version management for every consent notice
- A dashboard showing real-time consent status
- An alerting system when consent is nearing expiration
Manage Consent Professionally with PrivacyHub
PrivacyHub includes a Consent Management module designed for end-to-end consent governance—not just a cookie banner.
The PrivacyHub Consent Module provides:
- Consent Lifecycle Management — manage consent throughout its full lifecycle, from giving and renewal to withdrawal and expiration
- Immutable Consent Log — append-only records that cannot be altered, aligned with the PDPA accountability principle
- Multi-channel Support — supports consent from all channels, including web, app, paper, and offline
- Version Control — automatically stores every version of each consent notice
- Zero PII Storage — no actual personal data is stored; only metadata and pointers are retained, while the real data remains in the customer’s source systems
- Genesis AI — helps analyze which legal basis should be used for each activity and detects potentially problematic consent setups
Good consent management is not only about legal compliance—it is also about building trust with customers and employees. When data subjects know that an organization handles their data transparently and respects their rights, long-term relationships become stronger.
Start managing consent the right way today at enersys.co.th/en/products/privacyhub
