Designing business systems to meet data-protection requirements

The Personal Data Protection Act B.E. 2562 (2019) applies to organizations that collect, use or disclose personal data of people in Thailand. It distinguishes the data controller, who decides why and how data is processed, from the data processor, who processes on the controller’s behalf, and it is overseen by the Personal Data Protection Committee (PDPC). The Act sets out lawful bases for processing, rights for data subjects, security obligations, record-keeping duties and a breach-notification requirement.

This guide is informational and is not legal advice. The Act, its subordinate regulations and PDPC guidance change over time; your data protection officer or legal counsel should confirm how they apply to your organization. What follows is the engineering view: where the law requires the organization to be able to do something, this guide describes what the system needs in order to do it.

Where consent is the basis, the system must be able to show that a specific person agreed to a specific use, in a specific wording, at a specific time, and how. Store a consent record with the data subject’s identifier, the purpose, the version of the notice or consent text they saw, the timestamp, the channel (web form, app, paper scanned, call) and any evidence such as the form ID. Keep each version of the consent text; a record that points to text that has since been rewritten proves nothing.

Withdrawal must be as easy as giving consent and must take effect in every system that acted on it. Design consent as a central state that downstream systems (a marketing platform, a newsletter sender, an analytics pipeline) check at the moment of use, rather than a flag copied once and forgotten. Our own website newsletter is a small example of the pattern: double opt-in by e-mail, an unsubscribe link in every message, and a suppression list applied before sending.

Consent is not the appropriate basis for everything. Processing an employee’s data for payroll or a customer’s data to deliver a purchase rests on contract or legal obligation; asking for consent in those cases creates a right to withdraw that the organization cannot honor. When the basis is chosen accurately, the consent records become fewer and more meaningful.

The Act requires appropriate security measures. In system terms, that begins with least privilege: role-based access in which each role sees the fields its work requires and nothing more. An Owner/Admin/Member/Viewer model is a sound foundation for a workspace; business applications usually need finer roles, so that a warehouse operator sees delivery addresses but not national ID numbers, and a support agent sees the last four digits of a card but never the full number. Field-level masking, applied in the API layer so that no client can bypass it, is worth the effort for personal and sensitive fields.

Minimization applies at collection and in every copy. Collect only the fields a purpose needs; do not copy production personal data into test and development environments, and generate or anonymize test data instead; limit exports and bulk downloads to roles that need them and log every one. Strong authentication protects all of it: single sign-on with the organization’s identity provider, two-factor authentication, passkeys where supported, and session timeouts proportionate to the sensitivity of the data.

Processors the organization relies on (hosting, e-mail, analytics, AI services) need contracts that bind them to the same standards, and the architecture should make clear which personal data flows to each.

Personal data may be kept only as long as the purpose requires, or as a law demands. Turn that into a retention schedule per data category with a period and a legal or business reason: accounting records for the period tax law requires, job applicant data for a defined time after a decision, inactive customer accounts after a defined period of inactivity, support chat transcripts after a defined time. Then automate the schedule. A retention policy that depends on someone running a script once a year is not a control.

Decide how deletion works technically. Soft deletion keeps data invisible but present; it is acceptable only as a short grace period before hard deletion or anonymization. Anonymization, which removes or irreversibly transforms identifiers while keeping statistics, allows the organization to keep business history without keeping people. Backups need the same treatment: define how long they live, confirm that they are encrypted, and ensure that restored data is subject to the deletions that took place after the backup was taken.

Data subjects can ask what the organization holds about them, request copies and corrections, ask for deletion, object to or restrict processing, and withdraw consent, and the controller must act within the period the Act and regulations set. The system requirement is a way for a trained staff member to fulfill these requests without engineering help: find every record for a person across modules, produce a readable export of their personal data, correct a field with an audit entry, and execute deletion or anonymization subject to retention rules that must be honored (an invoice cannot be deleted because the customer asked for deletion; it can be retained with a recorded legal basis).

Build a request log: who asked, when, how identity was verified, what was done and when it was completed. The log both demonstrates compliance and shows where processes are slow.

An audit log records who did what to which data and when: logins, permission changes, views and exports of personal data, edits and deletions, configuration changes. It should be written by the application at the point of action, stored separately from the business data with restricted write access, and retained for a period set deliberately. Logs that live in the same database with the same administrators offer no protection against an insider.

Make the logs useful as well as present: searchable by person and by record, reviewed on a schedule, with alerts on unusual patterns such as bulk exports or access outside working hours. Audit logs contain personal data themselves and belong in the retention schedule.

The Act requires controllers to notify the PDPC of a personal data breach without undue delay and, where feasible, within 72 hours of becoming aware of it, unless the breach is unlikely to pose a risk to rights and freedoms; where the risk is high, affected data subjects must be informed as well. Seventy-two hours passes quickly. The system side of readiness is detection, meaning logging and monitoring that would reveal unauthorized access, together with the ability to establish quickly what data was affected, about whom, over what period.

The organizational side is a written incident process: who is told first, who assesses risk, who drafts the notification, who speaks to customers, and templates prepared in advance in each language the organization works in. Run a tabletop exercise annually with a realistic scenario, so that the first use of the runbook does not take place during a breach.