Consent Withdrawal in Thailand: How Fast, How Easy

Open your own company's app and count. When it asks for consent to marketing messages or to sharing data with partners, how many taps does the customer need? Usually one. Now look for the way to withdraw that same consent. Many companies send the customer to a call centre, a form, or an email to the DPO. Some do have a switch in the app, with small print saying the system will update within several days. Until then the promotional messages keep going out.

Company Z, a regulated electronic money (e-money) provider, had the same problem and asked the Office of the Personal Data Protection Committee (the PDPC Office). If withdrawal in the app cannot take effect immediately because the system needs processing time, may the company add a note stating how long it takes, and how many days would be reasonable? This article reports that answer, sets it beside the opinions given to two banks, and turns all three into checks a product team can run on its own app today.

What does Section 19 say about withdrawing consent?

Section 19, paragraph five of the Personal Data Protection Act B.E. 2562 (PDPA) lets the data subject withdraw at any time and sets the standard for the withdrawal channel in the same breath. The Act does not merely require that a way to withdraw exists. It requires that the way out be as easy as the way in.

The same paragraph adds that withdrawal does not affect collection, use or disclosure lawfully carried out before it. Nothing a company did before the withdrawal turns unlawful in hindsight. The exposure lies in what its systems keep doing after the customer has tapped.

What did the PDPC tell Company Z about "as easy"?

The PDPC advisory opinion on Company Z's query about customers withdrawing consent in an application system begins by confirming that Company Z is a data controller bound by Section 19, paragraphs four and five. The sub-committee that answers such queries then turns to the consent guidance issued by the Personal Data Protection Committee under Section 16(3) to explain what "as easy" is measured against.

• Visible from the moment you ask. The method, conditions or form for withdrawal must be displayed prominently, in a clearly visible place, in the consent request itself, on paper or on screen.
• Same kind of action in, same kind out. If consent was given electronically, by a click, a swipe or a drawn key stroke, withdrawal must be possible by the same method or one of the same level, or by another route that is just as accessible.
• No heavier burden than giving. Withdrawal must not impose more burden, cost or steps on the data subject than giving consent did.
• No worse service afterwards. The opinion states that withdrawal must not make the service perform worse.

The reasoning deserves a second read by anyone on the board. The rule exists to stop controllers building barriers that make withdrawal harder than consent. The sub-committee regards such barriers as an inappropriate burden on the data subject, and adds that they may reveal a controller's intention not to let people withdraw at all. That would contradict the duty to take utmost account of freely given consent, and the PDPC treats the right to withdraw as part of that freedom.

How fast must you stop once the customer withdraws?

Without undue delay, or as soon as technically and practically possible. The PDPC told Company Z that once a data subject has withdrawn consent through the app, by a method as easy as giving it, the company must stop collecting, using or disclosing that data. The opinion itself glosses the Thai phrase with the English words without undue delay.

The sub-committee then makes an observation that many request-handling procedures overlook. Acting on a withdrawal is different from responding to other data subject rights. The right of access under Section 30 and the right to erasure under Section 33 come with response frames of 30 days or more. Stopping the collection, use or disclosure after a withdrawal is expected to happen considerably faster.

The reason is brief and heavy. After withdrawal the controller no longer has a lawful basis to collect, use or disclose that data, and it has a duty to erase or destroy the data for which consent was withdrawn, unless an exception in the PDPA applies. Every hour in which the system still sends a message or still shares the record with a partner is use of personal data with no basis under it.

The system the PDPC wants to see

For withdrawals through a digital channel such as an app, the PDPC considers that the system should be designed to change how data is collected, used or disclosed according to the user's consent status, automatically and at once. Company Z should therefore do three things: make withdrawal take effect automatically when the user presses the button; have the system update the status and stop the related collection, use or disclosure immediately where it can; and confirm the withdrawal so the data subject knows it is complete.

If immediate effect really is impossible

The PDPC leaves a door open, but a narrow one. The cause must be a technical or practical reason that cannot be avoided, and the company should then do the following. The third item is the sharpest because it can be measured: if consent takes effect seconds after the tap, it will be hard to explain why withdrawal needs days.

1. Tell the data subject, clearly and in the withdrawal step itself, the conditions and the appropriate time needed until the withdrawal takes effect. Not in some other document.
2. Set that time with fairness and transparency in mind.
3. The time should not be longer than the process the company uses to make consent take effect.
4. State the time in outline in the privacy notice under Section 23, and when stating purposes in the consent request under Section 19, paragraph three, because it may matter to a person's decision to consent or to exercise other rights.
5. Derive the time from the actual processes of the systems involved, state when the withdrawal is expected to be complete, and optionally give the fastest and slowest possible times.
6. Whatever time is stated must reflect action without undue delay and reasonable speed.

Company Z asked directly how many days would be reasonable. The PDPC gave no number. It gave the principles from which a company must work out its own. Anyone hoping for a ceiling such as 7 or 15 days to paste into a footnote will not find one in this opinion, and with no common figure, the burden of showing that your time is not undue delay stays with you.

What has to happen, in order, after the tap?

The sequence below combines the PDPC's answers to Company Z and to Bank Khor with the text of the PDPA. One step is AIPDPA's own good practice rather than the regulator's words, and is marked as such.

1. Before the customer confirms
   The withdrawal screen states the consequences the customer will face and, if the withdrawal cannot take effect at once, the conditions and the time.s.19 para. six · Company Z opinion
2. At the tap
   The system changes the consent status and automatically stops the collection, use and disclosure that relied on it.Company Z opinion
3. Straight after
   Confirm the withdrawal, show the current status to the customer, and keep a traceable record of who withdrew what and when.Company Z opinion · Bank Khor opinion
4. Within the time you stated
   Where instant effect is impossible, the withdrawal is fully effective within the time the customer was told, which should not exceed the time consent took to become effective.Company Z opinion
5. In the same window
   Push the new status to every system that uses the data: email and SMS tools, in-app notifications, lists already sent to partners or vendors (AIPDPA good practice).Good practice
6. Once use has stopped
   Erase or destroy the data collected on that consent unless another basis or an exception allows you to keep it, and record the reason.s.33(2) · s.37(3)

Does an existing "do not consent" button count as withdrawal?

Yes, if the company has told customers so clearly. A bank the PDPC calls Bank Khor asked whether a customer who changes the setting from consent to no consent, unaided, on a Virtual Teller Machine or in mobile banking has withdrawn consent, or whether a separate revocation menu is needed. No separate menu is needed, on one condition: the privacy notice must state clearly that pressing "do not consent" after having consented is treated as withdrawal.

Good news for developers: the same toggle can serve for giving and for withdrawing. But the PDPC's answer has a second half that many banks and fintechs have not yet built.

The two opinions meet at one point: the customer must know the withdrawal worked. Bank Khor was advised to show the status. Company Z was advised to send a confirmation. A switch that slides off while the back end keeps no timestamp and the customer hears nothing falls short of both.

When must you tell the customer the consequences, and what do you say?

Whenever withdrawal will affect the customer. The duty sits in Section 19, paragraph six, and unlike several other parts of that section it has a fine attached to it by name.

Picture this: a wallet-app customer withdraws consent to the use of spending history for personalised offers. One consequence may be that discounts matched to the shops they use will no longer appear. The withdrawal screen should say so before the customer confirms. Say only what is true, and do not frighten people into staying, because the Company Z opinion says withdrawal must not degrade the service.

Section 82 also refers to Section 23, and Section 23(6) requires the privacy notice to state the data subject's right under Section 19, paragraph five. A notice that never mentions that consent can be withdrawn, or how, is exposed to the same ceiling: an administrative fine of up to THB 1 million.

After withdrawal, what must stop and what may you keep?

Everything that rested on that consent must stop. Processing that had a different basis from the start is untouched. A company that cannot say which dataset runs on which basis cannot answer this question at all, and will stop either too much or too little.

Section 37(3) adds a standing duty: the controller must have a system for checking and erasing or destroying personal data when the data subject withdraws consent, with exceptions such as retention for the establishment of legal claims or for compliance with the law. The Company Z opinion says the same thing in its own words: there is a duty to erase or destroy, unless the PDPA provides an exception.

Can you switch to legitimate interests after the customer withdraws?

The opinion given to a bank the PDPC calls Bank Jor concerns customers who refused consent in the first place, not customers who withdrew. But it sets out a principle marketing teams should know. Once the bank has chosen consent as the basis for an activity and the customer does not consent, the bank can no longer fall back on legitimate interests under Section 24(5) for that same activity.

Applying that principle to withdrawal is this article's reading, not the PDPC's wording. It does point the same way as the Company Z opinion, which says that after withdrawal no lawful basis remains. Where an activity ran on legitimate interests from the start, the customer's route is the right to object under Section 32 instead. That route is covered in marketing to existing customers: when you need consent.

Does your app pass? How to audit it yourself

Have two team members time themselves and count taps. One gives a consent; the other withdraws the same consent. Then fill in this table. The last column is the test drawn from the Company Z opinion. If the withdrawal column is worse than the giving column on even one row, there is work to do.

What does the Act say you risk by leaving it as it is?

None of the three opinions discusses penalties. This part reads the PDPA's penalty provisions against each kind of conduct. Our corpus holds no ruling or judgment confirming the outcome in any row, so treat the table as a risk map, not a prediction of how a case would end.

The last row is the most interesting. The administrative penalty provisions in Sections 82 to 84 do not name Section 19, paragraph five. That does not make a difficult withdrawal route safe. A hard route makes withdrawal happen late, and during the delay the system goes on using the data, which leads back to Section 27 and Section 83 by another road. The final paragraph of Section 19 also provides that a consent request which does not comply with the chapter does not bind the data subject, which gives a customer's lawyer room to argue that the whole batch of consents was never valid.

Civil liability under Section 77 arises whether or not the company acted intentionally or negligently. The explanation that the system had not finished updating is not among the defences Section 77 lists, which are force majeure, the data subject's own act or omission, and compliance with an order of an official acting under the law. Among the circumstances a court weighs for punitive damages under Section 78 is the benefit the controller obtained.

Where directors and managers come in

The criminal offence in Section 79 applies to breaches of Section 27 involving sensitive data under Section 26, committed in a manner likely to cause another person damage, loss of reputation, scorn, hatred or humiliation, or in order to obtain an unlawful benefit. Apps that ask consent for biometric or health data therefore need more care than most. Where the offender is a juristic person, Section 81 extends the punishment to a director, manager or responsible person whose instruction or act caused the offence, or who had a duty to instruct or act and failed to.

In fairness, Section 90 allows the expert committee to order rectification or issue a warning first where it sees fit, and requires it to weigh the severity of the conduct and the size of the business when setting a fine. The figures in the table are ceilings, not fixed rates. For the full picture of sanctions, see the guide to PDPA penalties.

Five mistakes, set against the words of the law

1. "as easy as … giving consent", yet consent is given in the app and withdrawn by phone or at a branch.
2. "at any time", yet withdrawals are accepted only in office hours, or batched once a month.
3. "shall inform the data subject of such consequences", yet the withdrawal screen has only a confirm button and says nothing about what changes.
4. "has no legal ground for such collection, use, or disclosure", yet the data collected on consent still sits in every table and nobody checks which part must be erased.
5. "without the consent of the data subject", yet lists already passed to a vendor or an advertising platform are never updated, so the downstream system carries on.

If the user is a minor, who withdraws consent?

The same conditions apply as for giving consent. The PDPC told Company Z that Section 20, paragraph four applies the conditions for obtaining a minor's consent to the withdrawal of consent, mutatis mutandis. Whoever has the power to give it has the power to take it back.

According to the opinion, where the user is a minor who has not become sui juris, Company Z must first consider whether the matter is one in which a minor may consent alone under the provisions of the Civil and Commercial Code that Section 20 refers to. If not, consent of the person exercising parental power is also required, and for a minor not over 10 years of age consent must come from that person instead, under Section 20, paragraph one of the PDPA. The Civil and Commercial Code is not in our corpus, so this article goes no further than what the opinion mentions.

The PDPC adds that the controller should consider the minor's maturity in making decisions about the product or service, together with the consequences of the decision, and handle both the request for and the withdrawal of consent from the person exercising parental power appropriately. An app with young users therefore needs a parent's route out designed alongside the parent's route in. More on this in children's data and parental consent.

How do the three opinions differ?

All three are answers to the organisation that asked, on the facts it described. They are not legislation and not penalty decisions. Other companies can use them as the weightiest guidance available, provided they check that their own facts match the question that was asked.

A five-question self-test, and a seven-day fix

Answer these five from evidence, not from memory. A single "no" or "not sure" means the company is exposed today.

1. Can a customer withdraw consent in the same channel where it was given, in no more taps than giving took?
2. After the tap, does every system that uses that data stop by itself, without waiting for a member of staff to change something by hand?
3. Does the withdrawal screen state the real consequences, and the time to take effect if it is not instant?
4. Does the customer receive a confirmation and see the status afterwards, and can the company trace who withdrew what, on which date and at what time?
5. Does the company know which data must be erased after withdrawal, which may be kept and on what basis, and who is responsible for erasing it?

The seven-day plan

1. Day 1. List every consent the app and website ask for, and note for each how it is given and how it is withdrawn.
2. Day 2. Fill in the give-versus-withdraw table above, timing and counting taps on a real test device.
3. Day 3. Trace where consent status travels: internal systems, vendors, partners. Measure how far behind the tap each destination stops using the data.
4. Day 4. Fix the withdrawal screen: add the consequences required by Section 19, paragraph six, and the time to take effect where it is not yet instant.
5. Day 5. Add the confirmation, the visible status and a traceable record, as the PDPC advised Bank Khor.
6. Day 6. Amend the privacy notice and the consent wording: how to withdraw, that switching off counts as withdrawal, and the time in outline.
7. Day 7. Assign responsibility for erasure after withdrawal under Section 37(3), record the exceptions relied on to retain data, and schedule development work for destinations that still stop late.

If the team is not yet sure its consent wording is valid at all, start with the guide to consent that actually holds up, because a good way out cannot repair a consent that was collected wrongly. For more regulator answers to everyday business questions, read The PDPC Has Answered: 8 Real PDPA Questions.

Who stands behind this guide?

Written by the AIPDPA legal team · Content owner: Phuwara Krobtaku, Attorney-at-law · Thai Barrister-at-Law · technology & intellectual property counsel

Lawyer's licence no. 477/2558 · Thai Barrister-at-Law · LL.M. in Intellectual Property & IT Law (Gold Medal)