Thailand PDPA for Small Businesses: A Practical Checklist

A ten-person company can still hold a surprisingly rich picture of an individual. A customer phone number, a staff passport copy, a lead's email address, an online identifier or security footage showing an identifiable person can all fall within the PDPA. Information about a juristic person as such is different, but the named director, signatory or employee behind that record is still a person.

The first distinction is operational, not academic. The party that decides why personal data is used and sets the essential means of that use is acting as the controller. A payroll bureau, hosting provider or other supplier may process data on instructions, but not every vendor is automatically a processor. A bank, regulated professional or platform may be an independent controller for parts of what it does, so the role has to be tested against the actual activity.

Small businesses also underestimate how many places data travels through. A sales enquiry starts on a web form, moves into LINE or WhatsApp, is copied into a spreadsheet or CRM, and later reaches an accountant. Add employee files, visitor logs, Wi-Fi credentials, CCTV, marketing lists and outsourced cloud tools, and the privacy footprint is no longer a website problem. It is an operating model.

Build a simple data map before buying templates. For each meaningful flow, record the data and source, purpose, legal basis, system, recipients, overseas access or storage, retention period and internal owner. This is the fastest way to expose the awkward gaps: a vendor with access nobody remembered granting, a customer list kept forever, or personal data collected at reception with no notice at the point of collection.

Being an SME does not create a blanket PDPA exemption. Specific duties can have their own exemptions or thresholds under current PDPC notifications, so those need to be checked separately against what the business actually does. An exemption from one record-keeping duty does not erase the wider obligations around lawful processing, security, rights handling or breach response.

The most common design mistake is to treat consent as the default answer to every privacy question. Thailand's PDPA provides several possible legal bases for ordinary personal data, including contract, legal obligation and legitimate interests where the balancing test is satisfied. Consent remains important, but it is not a universal switch that makes any later use lawful. The purpose comes first; the legal basis follows that purpose.

Consider a service business. A person sends details because they want a quotation and may enter into a contract. Payroll processing may be tied to statutory employer duties. Building access controls may sometimes be justified by legitimate interests if the aim is clear and the intrusion is proportionate. A separate marketing use, however, needs its own analysis. A customer contract should not become a catch-all explanation for every future use of the customer's data.

A privacy notice should be written for the person whose information is being collected. It should identify the controller, the data involved, the purposes, the relevant legal basis, recipients or recipient categories, retention, rights and a contact route. The collection point matters just as much as the wording: a website notice will not cover a receptionist taking visitor details, an HR onboarding pack, or a CCTV entrance if those are separate data flows.

Sensitive personal data under Section 26 needs a higher level of care. Health information, certain criminal-record information, genetic data and biometric data sit in a different category from ordinary contact details. Video that happens to show a face should not automatically be described as biometric processing; facial recognition or other technical identification can change the analysis substantially.

A single consent form is therefore a poor substitute for a processing model. The correct basis and notice content depend on the real purpose, the data category and the current PDPC rules at the time the process is implemented. Where the answer is genuinely unclear, document the facts first and have the specific use case reviewed rather than forcing it into a generic template.

Sending personal data to an accountant, marketing agency or cloud platform does not make the privacy responsibility disappear. It also does not turn every supplier into a processor. The classification follows the activity: who decides the purpose, who sets the essential means, and who is acting on whose instructions. A payroll provider may be processing on behalf of an employer, while a bank or regulated professional may have independent duties for part of the same relationship.

Where a vendor is genuinely processing on instructions, the paperwork should describe that reality. The arrangement should cover processing instructions, confidentiality, security, subprocessors, assistance with data-subject requests, incident escalation, and what happens to the data when the service ends. A supplier's security page or certification badge may be useful evidence, but it does not replace the allocation of duties between the parties.

Maintain a vendor register that a non-lawyer can actually read. Record what data each supplier can access, through which system, where storage or remote access may occur, whether other providers sit underneath the service, and how deletion or export works on termination. This often exposes recipients that never made it into the privacy notice, such as backup providers, outsourced support teams or a separate email-marketing platform.

Using an overseas SaaS provider is not automatically unlawful. It does, however, raise a cross-border question that needs to be checked against the applicable PDPC mechanism and the current transfer rules. A Thai SME may have an entirely local customer base while its CRM, Microsoft or Google environment, payroll service or analytics platform moves or exposes data across borders. Geography inside the technology stack still matters to the legal analysis. The practical aim is not to force every supplier into the same contract. It is to know which role each party plays, what access exists, what protections apply and where an overseas transfer has to be addressed. Without that map, a business can have a polished customer notice while its most important privacy risks sit quietly in vendor accounts.

Rights requests are often an ownership problem before they become a legal problem. A customer asks for access or deletion, and the message bounces between sales, finance and an IT vendor because nobody is responsible for assembling the answer. A small business is usually better served by one clear intake channel and one internal owner who can verify identity proportionately, identify the relevant right and exceptions, gather information from the right systems and keep a record of the outcome.

The PDPA provides rights that include access, correction, erasure in applicable circumstances, restriction, objection, portability where the conditions are met, and withdrawal of consent. None of this means that every deletion request requires the company to erase every record immediately. Legal retention duties, contractual needs or the establishment or defence of legal claims can justify keeping specific information even when other data should be removed.

Retention works best when it is tied to purpose. A job application, CCTV clip, customer contract and accounting record should not inherit one arbitrary retention period merely because they sit in the same company. When the purpose has ended and no lawful reason remains, the business needs a real deletion, destruction or anonymisation process rather than a policy sentence that nobody can execute.

CCTV needs the same discipline. Define why the camera exists, give people an appropriate notice, restrict who can view or export footage, and retain recordings for a period that can be justified by the actual security purpose and legal context. There is no sensible universal number for every business. A request for footage may also involve other identifiable people in the frame, so disclosure can require careful selection or masking.

Not every company needs a CCTV sub-process. If there are no cameras, do not invent one. If a landlord or building operator controls the cameras independently, the tenant business may have a different role altogether; the correct answer follows the real arrangement, not a copied policy.

A personal data breach is not limited to a hacker stealing a database. An email attachment sent to the wrong recipient, a public cloud link, a lost laptop, misconfigured permissions, ransomware at a vendor or accidental destruction of records can all be relevant. The first question is what happened to the confidentiality, integrity or availability of personal data, not whether the incident looks dramatic enough to call a cyberattack. The first hours should establish facts and reduce harm. Record when the business became aware of the event, contain access where possible, preserve logs and other evidence, identify the affected data and people, and bring in the relevant IT or vendor contact. That factual picture is what allows the controller to assess the risk to individuals and decide whether notification duties are engaged.

Under the PDPA breach framework, the controller notifies the PDPC without undue delay and, where feasible, within 72 hours after becoming aware of the breach when the notification threshold is met. A breach that poses no risk to the rights and freedoms of individuals can fall within the exception from notification to the Office. Where the risk is high, affected individuals may also need to be told without undue delay, together with useful information about mitigation.

The 72-hour window is therefore not permission to wait for a perfect forensic report. The assessment starts as soon as the business has credible information that a breach may have occurred. Current PDPC rules should be checked for the notification method, staged information and any justification for delay in the particular case.

Vendor escalation can make or break that timetable. If a processor operates the system, the contract needs a fast route for reporting a breach to the controller and supplying enough detail to assess it. A small company does not need an enterprise incident centre, but it does need a named person who receives the alert, a technical contact who can contain the event and a clear route for the legal notification decision.

A DPO is not mandatory simply because a company is incorporated in Thailand, employs staff or falls within the PDPA. Section 41 ties the requirement to defined circumstances, including specified public authorities, regular monitoring linked to large-scale personal data, and core activities involving sensitive data. The current PDPC notifications add detail to the large-scale and monitoring tests, so headcount alone is not a reliable answer.

A small business may therefore fall outside the mandatory DPO criteria, but it still has to look at what it actually does. The nature of the core activity, the volume and duration of processing, systematic monitoring and the use of Section 26 data matter more than the size of the sign above the office door. A company whose service depends on monitoring large numbers of users is not in the same position as a small restaurant holding a modest customer list.

The absence of a formal DPO should not mean the absence of an owner. Someone needs to keep notices current, maintain the vendor register, route rights requests, enforce retention, understand the CCTV setup and coordinate the first response to an incident. Otherwise privacy becomes an organisation-wide responsibility that belongs to nobody when a real request arrives.

The useful end state is deliberately modest: a data map, legal bases for the main purposes, notices at collection points, a consent inventory, vendor records and processor terms where relevant, a rights workflow, retention rules, CCTV controls, a breach playbook and a documented DPO check. That is not a promise of instant full compliance. It is a working operating layer that a small business can maintain and improve.

Review it on a calendar, but also when the business changes. A new cloud platform, payroll provider, analytics tool, facial-recognition feature or major marketing flow can change the privacy analysis long before the next annual review date. Event-driven review is what keeps the paperwork connected to the real business. This is an operational guide, not a legal opinion on a particular company; disputed legal bases, sensitive-data uses, cross-border transfers and mandatory-DPO questions should be confirmed against the current rules and the actual processing.