A PDPA checklist for a LINE Official Account connected to your systems

A LINE Official Account that only sends promotions has little to worry about under PDPA. The moment it is connected to membership, booking or a CRM, a customer’s LINE account becomes tied to their name, phone number and purchase history. From then on, your LINE OA is one more place your organisation collects personal data, and it is covered by Thailand’s Personal Data Protection Act B.E. 2562 (PDPA) like any other.

The risk no longer sits only with the company that owns the data. In 2025 Thailand’s Personal Data Protection Committee began fining developers and data processors, not only the companies whose data it was (Tilleke & Gibbins).

This is the checklist we run on every LINE OA project with a backend behind it. It is practical guidance, not legal advice.

1 Points 1–3 and 5: at sign-up Know what you receive, watch for sensitive data, say why you collect it, and ask for marketing consent separately.
2 Point 4: at linking A one-time code to the phone or email already on file, before any account is linked.
3 Points 6 and 8: inside Chats kept like a database; each role sees only what it needs, and every view is logged.
4 Point 7: outside An agreement with every processor: the builder, the chatbot, the AI service.
5 Points 9 and 10: over time A breach plan, people's rights, and deletion on schedule.

Fig. 1 Once LINE is connected to your backend, personal data passes five places. Every point on the checklist belongs to one of them.

1. Know what you receive

When someone adds your OA as a friend, your backend receives a user ID and can read their profile, such as display name and picture. With LINE Login, you can ask for an email address only if LINE has granted you that permission and the user agrees. Add everything your own forms ask for: phone, member number, address. Write the list down; every point below starts from it.

2. Tell people before you collect

Section 23 of the PDPA requires you to tell people why and how you collect their data before or at the time you collect it. On LINE, the right place is the first screen of your LIFF app or the sign-up form, not a link buried in the rich menu.

If you will send marketing, ask for that consent separately from your terms of service. Section 19 requires a request for consent to be clearly separated from other matters. A pre-ticked box, or one “Agree” button for everything, doesn’t pass.

4. Verify before linking accounts

The riskiest step is linking a LINE account to an existing member record. If typing a phone number is enough to link, anyone can link to someone else’s record. Send a one-time code to the phone or email already on file first, every time.

1 Phone number only Anyone who knows a member's number can link their own LINE to that record, and see the name, phone and purchase history in it.
2 A code to the number on file Sent to the phone or email already in your records, not to whoever typed the number in.
3 Link only when the code comes back No code, no link. Every time an account is linked, not only at sign-up.

Fig. 2 The same member record, linked two ways. Only one of them checks that the person linking is the member.

5. Watch for sensitive data

Health, religion, biometrics and criminal records are sensitive data under section 26 and need explicit consent. Clinics and hospitals using LINE for appointments need extra care: even “appointment with a dermatologist” can reveal something about health.

6. Treat chats like a database

What customers type to your admins is personal data too. Decide which staff can see chats and how long they are kept. Never ask customers to send a photo of their ID card in chat; if you need to verify identity, do it on a secure web page instead.

7. Sign an agreement with every processor

The vendor that builds the system, the chatbot provider and any AI service that answers chats are all data processors. Section 40 requires an agreement between the data controller and each processor. If data is processed on servers outside Thailand, check the cross-border transfer conditions in section 28 as well.

8. Limit access and keep an audit log

The admin console should give each role only what it needs, and record who viewed or changed whose data. When someone leaves, remove their access to both the backend and LINE OA Manager on the same day.

9. Have a breach plan before you need it

Section 37(4) requires you to notify the regulator within 72 hours of learning of a breach, unless it is unlikely to put people’s rights at risk, and to tell the people affected when the risk is high. Seventy-two hours pass quickly when nobody knows who calls whom. Write the plan now.

1 Who calls whom Without a plan, most of the 72 hours goes on finding out.
2 Assess the risk Is it likely to affect people's rights? If the risk is high, tell them too.
3 Notify the regulator Within 72 hours of learning of the breach, under section 37(4).

Fig. 3 The clock starts when you learn of the breach, not when you've worked out what to do. With a written plan, the 72 hours go on the breach itself.

10. Honour people’s rights, and delete when you’re done

Customers can ask to see, correct or delete their data. Your system should be able to do this without a developer editing the database by hand. Decide, too, what happens to linked data when someone blocks your OA (your backend receives an unfollow event). Set a retention period, and actually delete on schedule.

If your LINE OA is about to be connected to your systems, or already is and has never been checked against this list, every point above is part of our Blueprint, before any code is written.