Employee Benefits and the Personal Data of Family Members

Employee benefit programs frequently require employers to process personal data not only of their employees, but also of their employees’ spouses, children, parents, or other family members. Typical examples include medical benefits, insurance coverage, educational allowances, travel benefits, and other welfare programs. While such processing is routine from an HR perspective, it raises an important question under the Personal Data Protection Act B.E. 2562 (2019) (PDPA): can an employer rely on the same lawful basis for the employee and the employee’s family members?

This issue was addressed by the Office of the Personal Data Protection Committee (PDPC Office) in Consultation No. 10/2568 concerning a bank’s processing of personal data of employees and their family members for employee benefits. The consultation is particularly useful because it illustrates a point that is sometimes overlooked in HR privacy compliance: identifying a legitimate business purpose is not enough. The data controller must identify the appropriate lawful basis in relation to each data subject whose personal data is being processed. The consultation also refers to the PDPA provisions concerning minors and purpose limitation, making the issue especially relevant where employee benefits extend to children.

The Employee and the Family Member Are Different Data Subjects:

For the employee, the analysis is relatively straightforward. Where benefits form part of the employee’s employment package, the employer may need to process the employee’s personal data to administer those benefits. Section 24 of the PDPA permits processing without consent in several circumstances, including where processing is necessary for the performance of a contract to which the data subject is a party, compliance with a legal obligation, or legitimate interests, subject to the applicable conditions.

Accordingly, where a benefit arises from the employment relationship, the contractual basis may potentially support processing of the employee’s personal data if that processing is objectively necessary to perform the employer’s obligations under the employment arrangement. Other benefits may instead be supported by a legal obligation or legitimate interests, depending on their nature and purpose.

The position becomes more complicated when the same benefit requires information about the employee’s spouse, child, parent, or other family member. Those individuals are separate data subjects. More importantly, they will ordinarily not be parties to the employment contract between the employer and the employee. The fact that processing their data enables the employer to provide a contractual benefit to the employee does not automatically make the family member a party to that contract.

This distinction matters because the contractual basis under the PDPA focuses on a contract to which the data subject is a party. Employers should therefore be cautious about treating the employment contract as a blanket lawful basis covering everyone whose information happens to be required for HR administration.

What Lawful Basis Can Apply to Family Members?

The appropriate basis must instead be considered according to the particular processing activity. Depending on the circumstances, an employer may be able to rely on legitimate interests, provided that the processing is necessary for a legitimate purpose and the employer has appropriately considered the rights and interests of the affected family members. Consent may be relevant where no other lawful basis is available, although it should not automatically be treated as the default solution merely because the individual is not an employee.

This distinction becomes even more important where benefits involve sensitive personal data under Section 26, particularly health information. Medical reimbursement and health insurance schemes, for example, may require medical certificates, diagnoses, treatment information, disability information, or other health data concerning an employee or family member. A lawful basis for ordinary personal data under Section 24 does not by itself resolve the processing of sensitive personal data. The employer must separately determine whether one of the conditions under Section 26 applies or whether explicit consent is required.

Children introduce an additional layer of compliance. If an employee submits personal data concerning a child for educational, medical, insurance, or other benefits, the employer must consider the PDPA requirements applicable to minors, including the rules governing consent where consent is the basis relied upon. Consultation No. 10/2568 expressly refers to Section 20 of the PDPA, which contains the statutory framework governing consent involving minors.

Do Not Forget the Privacy Notice:

Another practical issue is transparency. Section 21 requires personal data to be collected, used, and disclosed consistently with the purposes communicated to the data subject, subject to the statutory exceptions. Employers therefore need to consider not only whether they have a lawful basis, but also whether the relevant family members have been properly informed about the processing of their data.

An employee privacy notice that describes how the employer processes employee information does not necessarily solve this problem. The spouse, child, or parent remains a separate data subject. In many organizations, however, the employer obtains the family member’s information indirectly through the employee rather than directly from that family member.

HR teams should therefore review how their privacy notices deal with this situation. Depending on the circumstances, organizations may consider a separate notice for family members and beneficiaries, or incorporate appropriately drafted provisions into the HR privacy framework together with a mechanism for ensuring that the relevant information reaches those individuals. The notice should explain, among other matters, the purposes of processing, categories of information involved, applicable lawful bases, disclosures to insurers or other benefit providers, retention arrangements, and data subject rights.

Practical Implications for Employers:

Consultation No. 10/2568 is a useful reminder that an HR database should not be analyzed simply as a database containing “employee information.” A single employee record may contain personal data belonging to several legally distinct data subjects, and the lawful basis may differ among them.

Employers should therefore map benefit-related processing at the data-subject level. For each benefit, HR and privacy teams should identify whose information is collected, why it is required, whether ordinary or sensitive personal data is involved, the lawful basis applicable to each category of data subject, how the required privacy information is provided, and whether information is transferred to insurers, hospitals, benefit administrators, payroll providers, or other third parties.

This approach is particularly important because many HR processes were designed long before privacy compliance became a formal legal requirement. Forms asking employees to provide the names, identification numbers, dates of birth, relationship information, bank details, or medical information of family members may have existed for years. Their operational familiarity does not remove the need to identify a lawful basis and comply with the PDPA’s transparency, data minimization, security, and retention requirements.

Key Takeaways:

• Do not automatically extend the employee’s lawful basis to family members. The employee and each family member are separate data subjects.
• Contractual necessity requires particular attention. A spouse, child, or parent will ordinarily not be a party to the employment contract merely because the employee receives a benefit relating to that person.
• Consider legitimate interests or another appropriate lawful basis for family-member data rather than treating consent as the automatic solution.
• Analyze sensitive personal data separately. Health and similar information requires a basis permitted under Section 26 in addition to the analysis applicable to ordinary personal data.
• Children require additional consideration, particularly where processing relies on consent.
• Review privacy notices and indirect collection procedures. An employee privacy notice should not automatically be assumed to satisfy transparency obligations toward family members.
• Audit existing benefit forms and HR systems. Employers should identify exactly what family-member information they collect and whether each data field remains necessary for administering the relevant benefit.

Author: Panisa Suwanmatajarn, Managing Partner.

Related Articles in the “PDPA Insights: Building Effective Privacy Governance” Series

• Competition: New Mandatory Credit Terms for Payments to SMEs
• Digital Trust in Action: ETDA’s Key Priorities for 2027
• New Electronic Transactions Bill: Major Changes for Digital Contracts, E-Signatures and Trust Services
• Cannabis Control Bill Moves Forward: Medical Use Takes Center Stage
• Cabinet Extends Skills Development Programs to 2031 to Strengthen Industry-Ready Skills
• Thailand Seeks U.S. Investment in AI and Digital Infrastructure

PDPA: New Section 30 Access Rules Put Data Subject Access Request Operations on a Compliance Clock

The Personal Data Protection Committee (PDPC) has issued a binding notification setting out detailed rules for data subjects exercising the right of access under section 30 of the Personal Data Protection Act B.E. 2562 (2019) (PDPA).

Published in the Royal Gazette on 16 July 2026, the Notification will take effect after the expiration of 60 days from publication. It should therefore be treated as an immediate implementation project rather than simply a regulatory development to monitor.

The importance of the Notification lies in its operational detail. Section 30 already gives data subjects the right to access and obtain copies of personal data concerning them that is under a controller’s responsibility, as well as to request disclosure of the source from which personal data was obtained without their consent. The new rules now specify how requests must be received, verified, assessed, fulfilled, refused, charged for, and recorded.

For controllers, this moves data subject access requests (DSARs) firmly from privacy-notice language into operational compliance.

Controllers Must Make Relevant Information Accessible:

The Notification requires controllers to make available information that enables data subjects to exercise the section 30 right. This includes personal data collected directly from the data subject, personal data collected from other sources, and information concerning the source or acquisition of personal data obtained without the data subject’s consent.

The controller must also make accessible relevant information that it is required to provide under section 23 of the PDPA and relevant items contained in the controller’s records of processing under section 39 that the data subject is entitled to access.

This requirement makes data inventory and data mapping particularly important. A controller cannot respond effectively to an access request if it does not know where an individual’s data is stored, how it was obtained, and which systems or service providers hold it.

Mandatory Request Channels:

The Notification does not leave request channels entirely to the controller’s discretion.

At a minimum, controllers must permit requests to be submitted:

• in person at the controller’s place of business or another contact location notified to data subjects under section 23; and
• by registered mail sent to that location.

Controllers may provide additional electronic or other channels. A data subject may exercise the right personally or through an authorized representative.

This is a significant implementation point. An organization that currently accepts DSARs only by email or through an online privacy portal should review whether its procedure accommodates the channels expressly required by the Notification.

Controllers should also determine how requests received at reception desks, branch offices, HR functions, customer-service centers, or by post will be recognized as section 30 requests and routed immediately to the responsible team.

Requests Must Contain Prescribed Information:

A request must be made in writing or electronically and must contain specified information and supporting evidence.

Among other things, the request must identify the data subject, specify the requested access or copy and, where relevant, disclosure of the source of personal data obtained without consent, provide sufficient details of the data requested, and carry the signature or electronic signature of the data subject or authorized representative.

The Notification also sets out identity-verification requirements.

Where a data subject submits a request in person, official identification may be required. Where a request is made by registered mail, certified copies of relevant identification documents may be required. The controller may use alternative verification methods, but those methods must not create an unreasonable obstacle to the exercise of the right. Controllers may also request additional information where necessary to establish identity, verify the request, or communicate with the data subject, including identifiers and contact information already known to the data subject.

The practical challenge is to strike the correct balance. Insufficient authentication can result in disclosure of personal data to the wrong person, while excessive authentication requirements may improperly obstruct the exercise of the right.

Representatives Require Proper Authority:

The Notification expressly addresses requests submitted through representatives. An authorized representative must provide a power of attorney identifying the matter for which authority has been given, with the required stamp duty and signatures, together with appropriate identification documentation for the relevant parties. Alternative verification methods may again be used, provided they do not create an unreasonable obstacle.

Controllers should therefore review their procedures for requests submitted by lawyers, family members, guardians, employee representatives, and other authorized persons. A generic assumption that an email from a representative is sufficient may no longer be appropriate.

A 15-Day Initial Review Stage:

One of the most important procedural features of the Notification is an initial review stage.

After receiving a request, the controller must examine the request details, supporting documents, and whether the requester is the data subject or a genuinely authorized representative. This review must be completed without delay and no later than 15 days from receipt of the request. If the request or supporting documents are incorrect or incomplete, or if the controller cannot verify the requester, the controller must notify the requester to correct the request or provide additional documents.

The controller must provide a period of not less than 10 days for the requester to correct the deficiency. For purposes of the subsequent process, the request is treated as received when the corrected request or complete supporting documentation has been received. If the requester does not correct the deficiency within the specified period, the request is treated as abandoned. The controller must notify the requester accordingly, although the data subject remains entitled to submit a new request.

This makes DSAR intake more than a logging exercise. Controllers should be able to distinguish between receipt of an initial request, completion of the verification process, requests for additional information, and the point from which the substantive response period runs.

The Substantive Response Period Is 30 Days:

Where the request is complete, the requester has been verified, and no ground for refusal applies, the controller must fulfill the request without delay and no later than 30 days from receipt of the request. The Notification allows an extension where the request concerns a large volume of information or where another necessity prevents the controller from completing the request within the ordinary period.

Importantly, the permitted extension is no more than an additional 30 days. The controller must inform the data subject or authorized representative of the necessity for the extension and the relevant details. This corrects an important point appearing in some descriptions of the new regime: the official Notification does not provide for a further 60-day extension. For implementation purposes, organizations should therefore build their DSAR workflow around a 30-day substantive response period, with only a limited additional 30-day period where the conditions for extension are satisfied.

How Access Can Be Provided:

The Notification permits several methods of fulfilling a request.

A controller may:

• allow the data subject to inspect relevant personal data;
• prepare and provide copies of documents containing the relevant personal data; or
• provide access, copies, or source information electronically or in another format agreed between the controller and the data subject.

Where the data subject submits the request electronically and does not request another format, the controller must provide the response electronically where this can reasonably be done. Controllers should therefore consider not only whether data can be found, but also whether it can be extracted into a format that can safely and intelligibly be provided to the requester.

Refusal Grounds Are Now More Operationally Defined:

The Notification provides greater detail concerning circumstances in which a controller may refuse to comply with a request.

A request may be refused where compliance would be contrary to law or a court order. Refusal may also be permitted where compliance would adversely affect the legally protected rights and freedoms of another person. The Notification expressly refers to matters including another person’s personal data, official secrets, trade secrets, copyright, and other intellectual property rights.

A controller may also refuse a request that is manifestly unfounded or that would impose an unreasonable burden on the controller. However, third-party information does not automatically justify refusing the entire request.

Where disclosure would affect another person’s rights and freedoms, the controller must comply with the request to the extent reasonably possible after balancing the relevant rights and interests. The Notification expressly contemplates deletion, redaction, or other measures that prevent disclosure of information that would adversely affect the third party. This makes document review and redaction a core part of DSAR compliance.

Employee DSARs May Become Particularly Significant:

For HR functions, the new rules could have substantial practical consequences.

Employee personal data is rarely located in a single personnel file. It may be distributed across HR information systems, payroll platforms, performance evaluations, email, internal messaging systems, access-control records, CCTV, workplace monitoring tools, expense systems, disciplinary records, and documents held by external service providers.

A section 30 request may therefore require coordination between HR, legal, IT, information security, facilities, and other business functions. The 30-day substantive response period means that organizations should establish internal search and escalation procedures before requests are received, rather than attempting to construct the process after the clock has started.

AI Systems Should Be Included in DSAR Readiness Testing:

Organizations deploying AI should also consider whether personal data contained in or processed through AI systems can actually be identified and retrieved when a section 30 request is received.

Depending on the architecture, relevant personal data may exist in prompts, uploaded documents, user profiles, interaction histories, logs, retrieved contextual information, generated outputs linked to identifiable individuals, or data stores supporting an AI application.

The Notification does not create separate rules for AI. The practical point is that the same access obligation applies where relevant personal data is held within an AI-enabled environment. Accordingly, it is not sufficient for a privacy notice simply to state that data-subject rights are available. The technical architecture must allow the organization to operationalize those rights within the applicable timetable.

Processor and Vendor Cooperation Should Be Tested:

The Notification places the legal obligation to respond on the controller, but much of the relevant personal data may be held by processors or other service providers.

Controllers should therefore review processor and vendor agreements to determine whether they contain adequate obligations concerning:

• assistance with data-subject requests;
• data searches and retrieval;
• response times;
• provision of copies in usable formats;
• identification of relevant systems and repositories;
• preservation of data during the request process; and
• assistance with deletion, redaction, or other measures needed to protect third-party information.

A processor that is contractually permitted to take several weeks simply to begin searching for data may make it difficult for the controller to comply with its own regulatory timetable.

Fees Are Permitted Only in Defined Circumstances

The Notification also contains detailed rules on fees.

Where access is provided electronically and the controller does not need to prepare data in a special medium or incur direct delivery costs, the controller must not charge a fee. Fees may be charged in other cases, but they must be reasonable and must not exceed actual costs. Certain copying charges are also subject to maximum rates specified in the annex to the Notification.

Where requests are repetitive, involve large volumes of information, or impose a greater-than-normal burden, the controller may charge a reasonable fee having regard to its costs. The controller may also limit the scope or method of compliance to the extent necessary, taking into account both the data subject’s rights and the burden involved.

The Notification further permits controllers to waive or reduce fees for low-income data subjects or in other appropriate circumstances. If a fee will be charged, the controller must notify the data subject before or when exercising the right to charge it. Controllers should therefore avoid adopting a standard DSAR fee without first determining whether charging is permitted in the particular circumstances.

Record-keeping Is Mandatory:

Controllers must maintain records of requests, supporting documentation, and the action taken or refusal to act on each request for at least two years for verification and evidentiary purposes. Those records may be kept electronically.

Where a request is refused, the controller must notify the data subject or representative of the refusal and the reasons, and the refusal and its basis must also be recorded in the controller’s records maintained under section 39 of the PDPA.

This makes a DSAR register or case-management system increasingly important. The record should allow the controller to reconstruct the lifecycle of the request, including receipt, identity verification, deficiencies, internal searches, processor involvement, redactions, extensions, fees, disclosure, refusal, and final closure.

What Controllers Should Do Before the Notification Takes Effect:

Controllers should use the remaining implementation period to test whether their existing DSAR procedure can comply with the new rules in practice.

Priority areas include:

• request channels — ensuring that in-person and registered-mail requests can be received, recognized, and logged, in addition to any electronic channels;
• identity verification — establishing proportionate procedures for verifying data subjects and representatives;
• initial review — implementing the 15-day assessment process and procedures for curing incomplete requests;
• internal routing — identifying responsible contacts in HR, IT, marketing, customer service, security, legal, and other relevant functions;
• data discovery — determining how personal data can be located across email, HR, CRM, cloud services, CCTV, monitoring systems, archives, and other repositories;
• processor cooperation — testing whether processors and vendors can retrieve relevant information quickly enough;
• third-party information — establishing review and redaction procedures;
• deadline controls — monitoring the 30-day response period and any justified additional 30-day extension;
• response formats — determining how inspection, copies, and electronic access will be provided;
• fees — ensuring that charges are imposed only where permitted and within the applicable limits;
• refusals — developing a documented process for assessing refusal grounds and issuing required explanations; and
• records — maintaining evidence of requests and their handling for at least two years.

A practical way to test readiness is to run a mock DSAR involving an employee or customer whose information is spread across several systems and at least one external processor. That exercise is likely to identify operational weaknesses more effectively than simply reviewing the wording of the organization’s privacy notice.

Key Takeaways:

The new Notification materially changes the operational expectations surrounding section 30 access requests.

Controllers will need more than a general statement in their privacy notices that data subjects have a right of access. They need an end-to-end process capable of receiving requests through the required channels, verifying identity and authority, identifying deficiencies within the initial review period, locating data across internal and external systems, protecting third-party rights, producing the requested information, managing statutory deadlines, documenting refusals, applying fee rules correctly, and preserving evidence of compliance.

Two timing points deserve particular attention: the controller must conduct the initial review without delay and within 15 days, while a valid request that proceeds to fulfillment must generally be completed within 30 days, subject to a justified extension of no more than an additional 30 days.

For organizations with mature DSAR procedures, the immediate task should be a gap analysis against the Notification. For organizations that have treated access rights primarily as privacy-notice language, a more substantial operational implementation project is required. The key compliance question is now straightforward: if a real section 30 request arrived today, could the organization authenticate the requester, find the relevant personal data across all relevant systems and processors, review it for third-party information, provide it in the required manner, and demonstrate that every step was completed within the prescribed timetable?

Author: Panisa Suwanmatajarn, Managing Partner.

Related Articles in the “PDPA Insights: Building Effective Privacy Governance” Series

• Competition: New Mandatory Credit Terms for Payments to SMEs
• Digital Trust in Action: ETDA’s Key Priorities for 2027
• New Electronic Transactions Bill: Major Changes for Digital Contracts, E-Signatures and Trust Services
• Cannabis Control Bill Moves Forward: Medical Use Takes Center Stage
• Cabinet Extends Skills Development Programs to 2031 to Strengthen Industry-Ready Skills
• Thailand Seeks U.S. Investment in AI and Digital Infrastructure