PDPA Encryption & Access Control: Thailand Compliance Standards

"Appropriate" is doing a lot of work in Section 37 of Thailand's Personal Data Protection Act. The law says data controllers must arrange "appropriate security measures" for personal data. It does not say which ones. That gap is where most Thai companies get PDPA compliance wrong: they buy a compliance checklist template, fill it in, and still fail an actual inspection because nobody translated "appropriate" into database settings, firewall rules, and access groups.

Data Encryption Standards for PDPA Compliance

The Notification of the Personal Data Protection Committee on Security Measures of the Data Controller B.E. 2565 (2022) fills in some of what Section 37 leaves vague. It still doesn't name AES-256 or TLS 1.3 — Thai regulation states outcomes, not products. After ten years of audits across manufacturing, healthcare, and logistics clients here, these are the controls that satisfy both a PDPC inspector and a competent penetration tester:

• TLS 1.2 minimum on any web form, customer portal, or API that touches personal data. TLS 1.3 where your infrastructure allows it — most cloud providers support it by default now.
• AES-256 for data at rest: database files, backups, exported spreadsheets sitting on a shared drive.
• Field-level encryption for Section 26 sensitive categories — health records, religion, criminal history, biometric data, and national ID numbers used as record identifiers.
• Key storage separate from the encrypted data. If the encryption key sits in the same database as the encrypted column, you haven't actually encrypted anything.
• Encrypted backups, not just an encrypted production server. A hospital group we audited in Chonburi had full-disk encryption on their patient management server and an unencrypted nightly backup sitting on a NAS drive in the server room. That NAS drive, not the server, was the real exposure — 40,000 patient records, no encryption, accessible to anyone who walked into the room.

Encryption buys you very little if the access controls around it are loose — and for a five-person trading company running one shared customer spreadsheet, full field-level encryption is often more engineering effort than the actual risk justifies. Loose access control, not weak encryption, is the failure we see most often.

Access Control and Authentication Mechanisms

Most PDPA incidents we've reviewed in Thailand didn't start with a hacker. They started with an ex-employee's login still active six months after they left, or a shared password taped to a monitor. Access control is cheaper to fix than encryption and gets ignored more often.

• Apply least privilege by role. Sales staff don't need HR records. HR doesn't need the general ledger. Set this in groups, not by trusting people not to click around.
• Named accounts only. No "warehouse1" login shared by four staff on rotating shifts. You cannot produce an audit trail for a password everyone knows.
• Multi-factor authentication on anything that touches personal data, not just the admin account.
• Review access rights quarterly, and immediately whenever someone changes role or leaves. This sounds obvious. It is also the single control we find missing most often in year-two audits.

If you're running Odoo 18, released October 2024, you have native passkey and WebAuthn login built into Community edition — no paid module required. That's a real improvement over Odoo 17 and earlier versions, which are limited to password plus optional TOTP two-factor. If you're still on Odoo 17, TOTP is not optional in any environment holding personal data; treat it as mandatory for every user with database access, not just admins.

Audit Logging and Monitoring Requirements

Section 37(4) requires notifying the Office of the PDPC within 72 hours of becoming aware of a data breach, in most cases. You cannot do that if you don't know what happened. Logging is not a nice-to-have here; it's the mechanism that makes the 72-hour clock survivable.

At minimum, log:

• Who accessed a personal data record, and when.
• What action they took — view, edit, export, delete.
• The record affected and the IP address the action came from.
• Failed login attempts, especially repeated ones against the same account.

Two practical notes from projects that went wrong. First, logs need to be tamper-resistant — a log an admin can quietly edit is not evidence of anything in front of a regulator. Second, don't log forever without a plan; unmanaged logs become their own personal-data liability, since access logs often contain personal data too. A mid-size logistics firm in Rayong we worked with kept five years of raw access logs with no retention policy — that dataset became a bigger PDPA exposure than the system it was meant to protect. For companies without budget for a SIEM platform, a monthly manual review of access logs against an approved-user list catches most of what matters. It's not elegant, but it works.

Data Retention and Secure Deletion Techniques

PDPA's purpose limitation principle, tied to Sections 22 and 23, means you can't keep personal data indefinitely just because deleting it is inconvenient. Section 33 gives data subjects the right to request erasure. If your systems can't actually delete a record on request, you have a compliance gap that no amount of encryption fixes.

• Write a retention schedule per data category — customer records, job applicant CVs, CCTV footage, marketing consent records — with a stated period and the legal basis for that period.
• Distinguish soft delete from secure delete. Flagging a record `active = False` in a database is not deletion. It's still there, still exportable, still a liability if that database leaks.
• Plan for backups. If you delete a customer record from production but it survives in eleven months of backup snapshots, you have not fulfilled an erasure request. Most companies discover this the first time a data subject actually asks.
• For unstructured data — scanned ID cards, PDFs, photos — secure deletion usually means file shredding utilities or full disk wipe on decommissioned hardware, not the Recycle Bin.

Configuring Odoo for PDPA-Required Security Controls

If Odoo is your ERP, most of the technical controls above map to specific settings rather than custom development, which is one reason we recommend it for SME clients trying to hit PDPA requirements on a real budget.

• Access rights and groups: Under Settings → Users & Companies, assign users to functional groups rather than granting broad "Settings" or "Administration" access by default. Odoo's group-based model, documented at odoo.com/documentation/18.0/applications/general/users/access_rights.html, lets you restrict a sales rep to their own leads and orders rather than the whole customer database.
• Record rules: Beyond groups, record rules restrict which rows a user can see even within a model they have access to — useful for multi-branch operations where a Chiang Mai store manager shouldn't see Bangkok customer data. Layer more than a handful of record rules on one model, though, and debugging why a specific user can or can't see a specific record turns into its own small project. Test with a real user account, not the admin login, before you trust the result.
• Two-factor and passkeys: Enable this per-user or enforce it company-wide from the Users settings screen. On Odoo 18, encourage passkey enrollment for anyone handling customer or employee records — it removes the phishing risk that comes with SMS or app-based TOTP codes. Budget for the rollout cost too: enforcing two-factor across a workforce that has never used it generates a real spike in support tickets — locked-out warehouse staff, lost phones, forgotten backup codes — and that cost lands worse if you flip the switch on a payday morning instead of a quiet Tuesday.
• Field-level restriction: Sensitive fields — national ID, salary, health notes on an HR record — can be hidden from groups that don't need them using field-level security on the underlying model, generally set up through Studio or a small customization rather than a base setting. Studio isn't included in Community edition; it requires an Enterprise subscription, so this particular control has a recurring cost attached, not just configuration time.
• Data export controls: Odoo logs export actions on most models by default, but review who has export rights specifically. Export rights are where a well-controlled system quietly leaks a full customer list into someone's personal spreadsheet.

None of this replaces a written retention policy or a breach response plan. Odoo gives you the mechanism; the policy still has to come from your side.

Testing and Validating Technical Compliance

A control you haven't tested is a control you're guessing about. Before an actual PDPC inspection finds the gap, run these yourself:

• Access review audit: pull the full user-permission list quarterly and confirm every access grant maps to a current role. Anything that doesn't, revoke it that day.
• Deletion test: submit an internal erasure request and trace it through production, backups, and any connected third-party systems (email marketing tools, payment processors). If it doesn't disappear everywhere, your process is incomplete, not your intention.
• Breach tabletop exercise: simulate a breach discovery and time how long it takes your team to identify scope, notify the DPO, and draft the PDPC notification. If that process takes longer than 72 hours to even start, fix the process before you need it for real.
• Penetration test: an external test against anything customer-facing, at minimum annually, specifically checking the encryption and access controls listed above rather than a generic scan.
• Log spot-check: pick a random week and verify the logs actually captured what you'd need to reconstruct an incident. Gaps here usually mean a misconfigured logging module, not a lack of activity.

Compliance isn't a document you file once. It's a system you can still explain, under pressure, eighteen months from now when someone asks what happened to their data.