Personal data protection in factory IoT has long been treated as a sub-item of “security” and pushed down the priority list. In Thailand, that is no longer a safe assumption. A certification framework under the Personal Data Protection Act (PDPA) took effect in June 2026, and enforcement actions announced in August 2025 carried fines totalling roughly 14.5 million baht across 8 cases. Smartwatches, facial-recognition attendance terminals, AI visual-inspection cameras – factory IoT devices collect machine data and employees’ personal data at the same time. This article sets out the current regulatory position and the practical steps a Japanese-owned plant in Thailand can start on immediately.
Factory IoT does not only collect machine data
Factory IoT projects are usually justified by machine utilisation and quality visibility. The same sensors and cameras, however, often collect information about individual workers without anyone intending it. The four most common touchpoints are set out below.
| Touchpoint | Examples of personal data collected |
|---|---|
| Smartwatches and wearable devices | Wearer location, movement paths, biometric readings (heart rate and similar) |
| Attendance management (IC card, facial recognition) | Face images, clock-in and clock-out times, attendance patterns |
| AI visual-inspection cameras | Workers appearing in frame on the line, movement-path data |
| Sensor logs linked to worker IDs | Equipment operation records tied to an individual (who operated what, and when) |
On their own these look like machine data. The moment they are joined to something that identifies a person – a name, an employee ID, a face image – they become personal data and fall within the scope of the PDPA. Facial recognition and biometric readings from wearables are treated as sensitive personal data under Thailand’s PDPA, which as a rule requires explicit consent from the individual. More and more plants are deploying wearables and facial recognition to streamline attendance management, so the handling of personal data needs to be designed in at the point where you are still evaluating smartwatches and wearables on the factory floor or an AI visual-inspection deployment, not afterwards.
What is easy to miss is that “data for monitoring operations” and “data that constitutes personal information” sit inside the same sensors and the same log files. When an equipment engineer designs a utilisation dashboard and a worker ID is attached to the records behind it, that dashboard is already within PDPA scope. Unless you separate out – at design time, and independently of the IT department – who may access which data for what purpose, pulling the personal data back out later is difficult both technically and financially. In most plants this separation is only considered after the system has gone live, which means redoing a log design that already works.
In 2026, Thailand’s PDPA moved from “inform” to “prove”
Thailand’s PDPA was promulgated in 2019 and came into full force in June 2022 when the grace period ended. From then until around 2024 the regulator’s posture was largely educational – warnings and corrective guidance, with the emphasis on raising awareness. Across 2025 and 2026 the centre of gravity has shifted clearly from awareness to demonstration and certification.
The certification framework took effect on June 18, 2026
On June 18, 2026 the Office of the Personal Data Protection Committee (PDPC) published two notifications on PDPA certification, dated February 27, 2026, in the Government Gazette, with effect from the same day. These notifications create the first official framework in Thailand under which a third party assesses an organisation’s PDPA compliance. The assessment is built on 4 categories, 10 focus areas and 128 assessment criteria, and measures the maturity of an organisation’s privacy governance.
There are two levels of certification.
| Certification level | Score threshold (per focus area) | Requirement |
|---|---|---|
| PDPA Compliance Certificate | 80% to 89.9% | Conformity with statutory obligations |
| PDPA Certificate + Certification Mark | 90% and above | Conformity with statutory obligations and with best practice |
Certification is voluntary and valid for 3 years. Both government agencies and private companies may apply, but obtaining it presupposes that your privacy management is already at a certain level. The way your factory manages personal data collected by IoT devices naturally falls within the scope of that assessment. The granularity of 128 criteria means, in practice, that everyday accumulated evidence – whether consent records exist, what is actually written into contracts with processors – is what gets examined.
August 2025: 8 fines across 5 cases, 14.5 million baht
Alongside the framework changes, the PDPC has become markedly more willing to enforce. Administrative penalties announced in August 2025 covered 5 cases with 8 separate fines, totalling approximately 14.5 million baht. That pushed the cumulative total of fines imposed since PDPA enforcement began past 20 million baht.
| Case | Description | Fine |
|---|---|---|
| Government agency web application breach | 200,000 personal records leaked to the dark web | Agency 153,120 baht / developer 153,120 baht |
| Private hospital data leak | Inadequate handling of patient information | Hospital 1,210,000 baht / individual contractor 16,940 baht |
| Computer accessories company | Inadequate security management | 7 million baht |
| Cosmetics company | Inadequate security management | 2.5 million baht |
| Toy retailer booking system | Roughly 200,000 records leaked through a processor’s security failure | Retailer 500,000 baht / data processor 3 million baht |
The toy retailer case deserves particular attention. The retailer moved quickly to compensate affected individuals after the incident, and was still penalised – alongside its processor – because of failures in the processor’s controls. It is a concrete illustration that inadequate management at a vendor becomes your own liability, even for data you never touched directly. Factory IoT systems commonly outsource processing to cloud-based attendance services and wearable-device vendors, so this is not somebody else’s problem. Private-sector companies, including manufacturing and retail, account for the majority of the 8 fines, which shows enforcement is not confined to any one industry.
Biometric data is sensitive personal data and cannot be handled without consent
Under Thailand’s PDPA, biometric data such as facial-recognition templates, fingerprints and heart rate is classified as sensitive personal data and held to a stricter standard than ordinary personal data. As a rule it requires explicit opt-in consent from the individual, and collecting or using it without consent breaches the PDPA unless one of the limited statutory exemptions applies. When facial recognition is introduced for attendance management, many plants skip the consent process on efficiency grounds alone – a practice that carries real enforcement risk. The same analysis applies to surveillance cameras and AI visual-inspection cameras whenever the design means worker faces appear in the footage.
Sort factory IoT data into four layers
The way to stop compliance from being deferred is to stop treating factory data as one undifferentiated pool, and instead classify it by nature and design access rights accordingly. In practice, sorting it into the four layers below makes it obvious where PDPA obligations attach.
| Data layer | Examples | PDPA status | Access control guideline |
|---|---|---|---|
| Layer 1 Public data | Aggregated utilisation figures, equipment model numbers | Out of scope | No restriction needed |
| Layer 2 Machine data (not linked to individuals) | Temperature and vibration logs per machine | Out of scope | Shareable within the department |
| Layer 3 Personal data | Clock-in and clock-out times, operation logs tied to a name | Personal data | Restricted to staff with a business need |
| Layer 4 Sensitive personal data | Face images, biometric readings | Sensitive data (consent required) | Minimum number of staff, stored encrypted |
Once the layers are separated, permissions can be split at the earliest stage of system design: the utilisation dashboard is Layer 2, so it can be published company-wide, while individual attendance logs are Layer 3 and therefore accessible only to HR. The reason PDPA work ends up reactive in so many plants is that the database was designed with all four layers mixed together from day one. Writing this layer split into the requirements document you give the vendor when procuring new IoT equipment prevents the rework later.
Take a predictive-maintenance system that combines vibration sensors with inspection records made by workers. The vibration data itself is Layer 2 and carries no personal link, but the moment a record of who performed the inspection is attached, it becomes Layer 3. When both layers live in the same database, opening machine data up to the whole analytics team easily exposes personal data along with it. The risk is preventable with fairly small design changes – splitting the layers into separate tables, or keeping one table but setting different access rights on the columns that identify individuals.
PDPA compliance for factory IoT – three operational lines you cannot skip
With the regulatory picture and the four-layer classification in place, the issues that IoT and DX owners in a plant actually have to manage fall into three lines.
Line 1: Limiting the purpose of collection (scope design)
Retaining everything an IoT device produces because “it might be useful” runs against the purpose-limitation principle the PDPA is built on. Define the purpose explicitly – safety monitoring such as fall detection for a smartwatch, attendance management for a clock-in terminal – and design so that data not needed for that purpose, for example continuous location tracking logs, is either not collected at all or deleted automatically after a short period. Broadening the collection scope on the vague basis that it may be useful in future also costs you points in a certification assessment. Retention is another open area: few plants have written into internal rules how many years attendance data is kept or after how many days video is deleted automatically, so there is considerable room to get started here.
Line 2: Designing consent (opt-in and notice)
Where facial recognition or biometric data is involved, a blanket signature collected at the point of hiring is increasingly insufficient. You need to state – in a language workers actually understand, which in Thailand means Thai – what data is collected for what purpose, which roles can view it and how long it is retained, and you need a workable means for individuals to withdraw consent. In multilingual sites it is common to find that the consent document was never produced in Thai, or is written in technical language that does not match the reading level on the floor. Designing the consent process is not a legal-department task alone; it requires joint work with the engineering team that actually operates the devices. Preparing an alternative to facial recognition, such as an IC card, for employees who withdraw consent is another practical necessity.
Line 3: Vendor and processor governance
As the toy retailer case shows, where you outsource processing of personal data – to a cloud attendance service, to a wearable-device vendor – failures in the processor’s controls become the controller’s liability too. You need a data processing agreement (DPA) signed at contract stage and a routine for periodically verifying the vendor’s security posture. The vendor-management thinking covered in our practical guide to OT security transfers directly into the personal data protection context and sits naturally alongside your existing factory OT security work. Keeping audit-response records in digital form is also valuable when you have to demonstrate accountability during a certification assessment or after an incident – see digitising audit response records for how that is done in practice.
Technical measures where video data is involved
For video that may capture worker faces – AI visual-inspection cameras and surveillance cameras alike – technical measures work alongside written policy. Three are worth knowing.
- Masking or blurring faces: analyse only the inspection target (the product) and blur any person captured in frame before the image is stored. Most AI visual-inspection systems allow the region of interest (ROI) to be restricted, so setting areas where people appear outside the analysis region is also a viable operating rule
- Edge processing so raw footage is never retained: rather than sending captured video straight to the cloud, complete the analysis on an edge device inside the plant and pass only the verdict (pass or fail) to upper-level systems. Raw footage containing faces then never needs long-term storage
- Automatic retention expiry: set a retention period on video data in advance (7 days or 30 days, for example) and configure automatic deletion past that point on the camera itself or on the NVR (recording device)
None of these require a large system rebuild. In most cases they are handled through configuration changes to an existing AI visual-inspection system or camera, or a minor software addition. If you are procuring AI visual-inspection cameras now, confirming ROI restriction and edge-processing support with the vendor during initial selection removes the need to retrofit any of this later.
Where to start – a 90-day practical roadmap
Before making a large investment decision such as pursuing certification, the priority is to understand your current position and put basic controls in place. Certification is a mechanism for having a third party assess and attest to management practices you already have; it does not build those practices for you. If you complete the inventory and the policy work first, most of the documentation an assessment requires is already available when you do consider certification. A 90-day sequence looks like this.
- Day 0-30 (inventory): list the data collected by every IoT device, camera and wearable in the plant. Record what is collected, from whom and for what purpose, and map each item onto the four-layer model above
- Day 31-60 (consent and policy): for any device handling facial recognition or biometric data, check whether a consent process exists, and if not, prepare a Thai-language consent document and a withdrawal mechanism. Set internal rules for data retention periods
- Day 61-90 (vendor management): check whether data processing agreements (DPAs) are in place with wearable-device and attendance-service vendors, and sign them where they are not. At the same time, review whether access to personal data is genuinely restricted to staff with a business need
None of the three stages requires expensive system investment; each can be started by revising the operating rules around IoT systems you already run. Treating certification as the option that comes after this is the realistic order. For companies handling biometric data for large workforces across multiple sites, or reporting frequently to customer auditors and global headquarters, the output of the inventory doubles as the preparatory documentation for a certification application.
Should you certify – how to judge a voluntary scheme
PDPA certification is voluntary, not mandatory. Obtaining it costs money in assessment preparation, documentation and audit fees, while not obtaining it leaves the enforcement and fine risk in place. The decision turns on the volume of personal data you handle and the size of the associated risk.
| Decision factor | Consider pursuing certification when | Prioritise the basics first when |
|---|---|---|
| Volume of personal data | Handling biometric data for large workforces across multiple sites | A single site with small-scale attendance data only |
| Need to explain externally | Customer audits and reporting to global headquarters are frequent | Mainly internal use, few occasions to explain externally |
| Current management posture | Consent collection and purpose limitation are already operating | Consent processes and vendor management are not yet in place |
Frequently asked questions
Can we use facial-recognition cameras without consent?
As a rule, no. Facial-recognition data is classified as biometric data (sensitive personal data), and Thailand’s PDPA requires explicit consent from the individual. Unless a limited statutory exemption applies, such as a substantial public interest, deploying it without a consent process carries the risk of a PDPA breach.
Does location data from an attendance app also fall under the PDPA?
Yes. Location data linked to an employee ID or a name qualifies as personal data. Keep the purpose of collection limited to attendance management and avoid continuous location tracking that goes beyond that purpose.
If a leak originates with a vendor, is our company liable?
It can be. In the August 2025 case described above, both the controller (the retailer) and the processor (the data processing company) were fined. The responsibility for verifying a processor’s controls at contract stage and during operation rests with the controller as well.
Should we obtain the PDPA certification mark?
It is voluntary. Companies handling biometric data for large workforces across multiple sites, or facing frequent customer audits and reporting to global headquarters, have good reason to consider it – but the priority is first to establish the basics of consent collection, purpose limitation and vendor management.
Can we comply without replacing our existing IoT systems?
In most cases, yes. There is no need to replace the sensors or cameras themselves. Most of the work is changes to operating rules – setting retention periods for collected data, reviewing access rights, adding a consent process. One exception is equipment such as facial-recognition terminals, where an alternative is needed when consent is withdrawn; there you may need to consider adding a secondary clock-in method such as an IC card alongside the existing device.
Which department should lead the 90-day roadmap?
The realistic structure is for the DX or production engineering function that runs factory IoT to lead, working with legal and HR. Engineers on the floor are the ones who know the technical reality of the data, meaning which logs contain what, while the wording of consent documents and internal policies needs legal and HR expertise. Running it as joint work reduces rework. Where reporting to a Japanese parent company is required, sharing the situation early with headquarters IT and compliance functions makes the later explanation much smoother.
If personal data leaks from an IoT device, how long do we have to report it?
Under Section 37(4) of Thailand’s PDPA, a data controller must notify the PDPC of a personal data breach within 72 hours of becoming aware of it, where feasible. If notification within 72 hours is not feasible, the report must still be made within 15 days of becoming aware of the breach, together with justification for the delay. Failure to report within the 72-hour requirement can attract a fine of up to 3 million baht. Breaches occurring in wearable devices or cloud-based attendance services are equally in scope, so writing into the vendor contract how many hours the vendor has to notify you of an incident is essential to meeting the 72-hour rule.
Conclusion
Deploying factory IoT always brings a personal data dimension alongside the visibility of machine data. In Thailand the PDPA certification framework took effect in June 2026, and August 2025 saw penalties totalling 14.5 million baht, pushing the cumulative total since enforcement began past 20 million baht – the regulation now has teeth. When deploying and operating smartwatches, facial recognition and AI visual-inspection cameras, classify the data into four layers and build the three operational lines – purpose limitation, consent design, and vendor and processor governance – at the same time as the technology, not after it. Working through inventory, policy and vendor management on a 90-day sequence gets the basic controls in place without significant investment.
If you want to start with an inventory of what personal data your factory IoT devices are actually collecting, or to check where existing systems stand against the PDPA, it is worth a conversation even at an early consideration stage. TOMAS TECH supports factory IoT and OT deployments from the shop-floor perspective, balancing the use of machine data with the protection of personal data. If you have a new IoT deployment on the plan, talking it through at the selection stage makes design rework much less likely later. Contact us here.
References
- Thailand Introduces Certification Framework for Personal Data Protection Standards – Tilleke & Gibbins
- Enhancing Data Governance under Thailand’s PDPA – Nagashima Ohno & Tsunematsu
- More Than a Warning: Eight Serious Fines Imposed in Thai Data Protection Cases – Tilleke & Gibbins
- Thailand’s PDPC Signals Tougher Enforcement With Multi-Million Baht Fines – Mondaq
- Employer’s Data Obligation Under Thailand’s PDPA – Securiti
- Workplace Privacy: A Case Study on Biometric Technology for Employee Attendance Tracking – Athentic Consulting
- Thailand’s PDPC clarifies data breach notification requirements – IAPP
