ISO 27701:2025 is the privacy management system standard that, in its new edition, stands on its own without ISO 27001 as a prerequisite, and much existing PDPA work already counts as evidence for it. This article is for Thai DPOs and PDPA teams asked about ISO 27701: it maps which records carry over, what is still missing, and which Thai duties the standard never covers.
- ISO/IEC 27701:2025 is the second edition. It replaces the 2019 version and was redrafted to stand alone, so ISO 27001 is no longer a prerequisite.
- A s.39 records register, s.30 rejection records, a s.37(4) breach log and s.40 processor agreements are exactly what an ISO 27701 auditor samples.
- PDPA work does not build the management system: scope, policy, objectives, SoA, internal audit and management review are extra work.
- ISO 27701 sets no 72-hour, 30-day or 15-day limit and no age-10 consent rule. Those numbers come only from Thai law.
- Your PDPA role, controller or processor, decides which of the 78 Annex A controls apply.
More and more Thai companies get the same question from foreign customers or a large partner's procurement team: do you have ISO 27701? The answer usually heard internally is that ISO 27001 has to be finished first. That was true of the 2019 edition. It is no longer true of the 2025 one.
This article does not summarise the whole standard. It takes the duties in Thailand's Personal Data Protection Act B.E. 2562 (2019), the PDPA, one at a time and sets each against what an ISO 27701 auditor will want to see. The aim is to show how far existing work carries over, what the ISO side still needs, and what the standard will never give you because it is specific to Thai law.
What changed between ISO 27701:2019 and ISO 27701:2025?
The starting point changed. The 2019 edition was built as an extension of ISO/IEC 27001, so an organisation needed an information security management system first and layered privacy on top. The second edition, published in October 2025, cancels and replaces the first, and its foreword states that the main change is a redraft as a stand-alone management system standard.
In practice, ISO 27701:2025 carries the full set of management system requirements in its own clauses 4 to 10: context, leadership, planning, support, operation, performance evaluation and improvement. If you already hold ISO 27001 you can still integrate the two systems. It is simply no longer a condition of entry.
What you still cannot skip is an information security programme. Clause 6.1.3 asks you to identify and document one, covering a minimum list of topics such as access control, supplier management, incident management, continuity and cryptography. It may be based on ISO 27001 or be a set of controls you design yourself. The ITGP 2025 pocket guide (summarised in an AIPDPA team note) observes that the split should make leadership, planning and continual improvement for personal data get proper attention at audit, an area it says was often overlooked before.
Which PDPA records will an ISO 27701 auditor ask to see?
Almost every record the PDPA already demands can serve as evidence for an Annex A control: the records register, the rights-request log, the breach register and processor agreements in particular. The condition is that they are live documents with dates and traces of use, not policy files nobody opens.
The table below is our own mapping. The standard itself maps its controls to ISO/IEC 29100 and to the EU GDPR, but not to the PDPA, so read this as a pointer to where the evidence lives rather than as legal advice.
| PDPA duty | Provision | Related part of ISO 27701 | What auditors typically sample | Common gap |
|---|---|---|---|---|
| Records of processing (RoPA) | s.39 (controller) · s.40(3) (processor) | B.1.2.9 records of processing · B.2.2.7 processor side | A register with a named owner accountable for accuracy, lawful basis per activity | No named owner, no date of last review |
| Answering data subject requests | s.30–s.36 (s.30: within 30 days) | B.1.3 obligations to PII principals · B.1.3.10 handling requests | A written procedure, real request logs with received and answered dates, rejections with reasons | An intake form exists, but no record of when each request was answered |
| Breach notification | s.37(4) · 2022 breach notification | B.3.11–B.3.12 incident preparation and response | Response plan, a log of every incident including those assessed as not notifiable, proof of notices sent | Only notified incidents are logged; no reasons kept for the ones not notified |
| Processor agreements | s.40 paragraph three · clause 8 of the breach notification | B.1.2.7 contracts with processors · A.2/B.2 processor controls · B.3.10 supplier agreements | Contracts or DPAs stating controls and breach-notice duties, a list of sub-processors | Older contracts with no 72-hour breach clause |
| Security measures | s.37(1) · s.40(2) | 6.1.3 security programme · A.3/B.3 | Access reviews, logs, backup restore tests, reviews of the measures | Measures exist, but nothing shows when they were last reviewed |
| Impact assessment (DPIA) | No section mandates it directly · good practice alongside s.37(1) | B.1.2.6 privacy impact assessment · 6.1.2 risk assessment | Written triggers for when a DPIA is needed, reports for high-risk activities | Done once at project start, never repeated when the system changes |
| Consent and privacy notices | s.19 · s.20 · s.23 | B.1.2.4–B.1.2.5 consent · B.1.3.3–B.1.3.4 informing principals | Per-person consent records, dated versions of the notice actually shown | Consent is stored, but nobody can say which notice version the user saw |
Records of processing: what Section 39 already demands
The Data Controller shall maintain, at least, the following records in order to enable the data subject and the Office to check upon, which can be either in a written or electronic form
A records register that fully meets Section 39 already looks much like the processing inventory ISO 27701 describes in guidance B.1.2.9: categories of data, purposes, and a description of security measures under item (8). The ISO questions that go further are whether the register has an owner who answers for its accuracy and completeness, and whether the lawful basis is recorded per activity.
Watch the last paragraph of Section 39, which lets small organisations be exempted from some items under rules set by the Committee. ISO has no equivalent. Whatever activities you put inside the management system scope, plan to keep complete records for them on your own terms. For a practical way to collect the entries from each department, see the RoPA guide.
Rights requests: ISO lets you set the deadline, the PDPA already has
Guidance B.1.3.10 in ISO 27701 only says requests should be answered within response times the organisation defines, and that those times belong in the privacy policy. The actual number therefore has to come from the law. For access and copy requests, Section 30 paragraph four of the PDPA reads:
the Data Controller shall fulfill the request without delay, but shall not exceed thirty days from the date of receiving such request.
In the case that the Data Controller rejects the requests in paragraph one, the Data Controller shall record its rejection together with supporting reasons in the record as prescribed in section 39.
Paragraph three is a gift at audit time, because it ties every refused request back to the records register. If the auditor samples a few requests, an organisation that follows Section 30 can show the date received, the date answered and, for refusals, the reason, with little extra preparation. For running requests inside 30 days, see our article on data subject requests.
Breaches: log the ones you notify and the ones you do not
notify the Office of any Personal Data breach without delay and, where feasible, within 72 hours after having become aware of it, unless such Personal Data breach is unlikely to result in a risk to the rights and freedoms of the Persons.
ISO 27701 guidance B.3.12 has every incident involving personal data reviewed to decide whether it is a breach that needs a response, and asks for records detailed enough to support a report to a regulator: time period, consequences, who reported it, and the steps taken. It does not set a number of hours. The 72-hour window from awareness comes from Section 37(4) of the PDPA.
The exception at the end of Section 37(4) covers breaches with no risk to people's rights and freedoms. Clause 9 of the 2022 breach notification puts the burden of proving that on the controller, who must supply supporting evidence. So a decision not to notify needs a written reason, which is the same record an ISO auditor asks for. For the first steps after an incident, see the first 72 hours after a breach.
Processors: one contract has to satisfy both sides
the Data Controller shall prepare an agreement between the parties to control the activities carried out by the Data Processor to be in accordance with the Data Processor's obligations for compliance with this Act.
the data controller must stipulate in the agreement or in the relevant contract that the data processor has a duty to notify a personal data breach to the data controller without delay and within seventy-two hours from the time the data processor becomes aware of it, so far as it is able to do so.
On the ISO side, guidance B.1.2.7 wants processor contracts to cover the controls in Table A.2, assuming by default that all of them are relevant and requiring a justification for any you leave out. The processor guidance in B.3.12 also suggests the contract should set breach notification response times. A contract that writes in the 72 hours from clause 8 closes both points in one clause. For a full clause list, see processor agreement clauses.
Security measures: show that they are actually reviewed
provide appropriate security measures for preventing the unauthorized or unlawful loss, access to, use, alteration, correction or disclosure of Personal Data, and such measures must be reviewed when it is necessary, or when the technology has changed
The duty to review in Section 37(1) is exactly what an ISO auditor looks for: proof that controls are not a one-off. Periodic access reviews and recorded backup restore tests are typical examples. This set of measures is the core of the security programme that clause 6.1.3 asks you to document.
Section 37(1) also requires the measures to follow the minimum standard announced by the Committee, which is a purely Thai requirement. A security programme designed around ISO should be checked against that notification as a separate layer. See the minimum security standard checklist.
DPIA: not mandated by name in the PDPA, but ISO will ask
The PDPA has no section that orders a DPIA in so many words. ISO 27701 guidance B.1.2.6 asks the organisation to consider whether an impact assessment is needed whenever new processing or a change to existing processing is planned, and gives example triggers: automated decisions with legal effects, large-scale processing of sensitive categories, and large-scale monitoring of publicly accessible areas.
Teams that already run DPIAs as good practice start ahead. What to add is a written rule for when one is required, and a record of why activities that were screened did not need a full assessment. For getting both the register and DPIAs finished, see this article.
In AIPDPA, all 78 ISO 27701 controls sit on the same evidence board as the PDPA, ISO 27001 (93), ISO 42001 (38), NIST AI RMF (72) and PDPC guidance, so a records entry or a handled request done once counts wherever it is relevant. Status is calculated live each time the board opens; every night the system flags evidence expiring within 30 days and records a daily readiness score; and a customer's own claim alone never rises above partial. The board starts at the GROWTH plan.
What does PDPA work not give you for ISO 27701?
Almost everyone is missing the management system itself. The PDPA orders individual tasks; it does not order a cycle of planning, checking and improving the whole. That cycle is half of ISO 27701, and it is the part most PDPA teams have no documents for at all.
| ISO 27701 clause | What it requires | Does PDPA work help? |
|---|---|---|
| 4.2 Interested parties | Identify relevant parties and their requirements, explicitly including the individuals whose data you process | Partly, if the records register already lists the groups of data subjects |
| 4.3 Scope | A documented scope that includes the processing of personal data | No. The PDPA applies to everything, so you never had to draw a boundary |
| 5.2 Privacy policy | An organisation-level policy from top management, committing to meet requirements and to improve continually | Usually only a customer-facing privacy notice exists, which is a different document |
| 6.1.2–6.1.3 Risk and SoA | Assess risks to the organisation and to individuals, choose controls, then a Statement of Applicability: which controls are needed, whether they are in place, and why any Annex A control is excluded | DPIAs help a little, but they are not an SoA |
| 6.2 Privacy objectives | Objectives consistent with the policy, measurable where practicable, with owners and target dates | No |
| 9.2 Internal audit | A planned audit programme, impartial auditors, results reported to the relevant managers | No |
| 9.3 Management review | Reviews at planned intervals covering the minimum inputs in 9.3.2, such as open actions, audit results, nonconformities and corrective actions, with recorded decisions | No |
| 10.2 Nonconformity and corrective action | Record the nature of each nonconformity, its causes, the action taken and its results | Partly, if the breach register records the fixes |
This whole group is covered in the AIPDPA ENTERPRISE plan: a 5×5 risk register, objectives, a risk-based internal audit plan, a management review agenda built on the inputs in clause 9.3.2, an SoA exported to Word, and a two-stage mock audit. The system prepares the evidence; certification itself still goes through a certification body of your choice. For preparation steps, see the ISO audit readiness guide.
Which Thai legal duties does ISO 27701 not cover?
ISO is written for use anywhere, so it only says that some jurisdictions may set their own conditions. Thai numbers and conditions have to be taken from the PDPA and its notifications. An organisation that passes an ISO 27701 audit still needs to check these points separately.
ISO expects a notification procedure and records but names no hours. The breach log must record when you became aware, or the Thai deadline cannot be counted.
You may ask the Office to waive liability for lateness, explaining the necessity, and must notify within 15 days of awareness. ISO has no such mechanism.
ISO suggests the contract set a time frame. The Thai notification already fixes 72 hours and tells the controller to write it into the contract.
ISO only notes that children may be subject to extra requirements. Section 20 sets out when a parent's consent is needed and the rule for minors aged ten or under.
ISO lets you define response times. The ceiling of 30 days from receipt comes from the PDPA.
Measures must follow the minimum standard announced by the Committee, so an ISO-style programme needs checking against that notification too.
(2) Where the minor is not over ten years of age, the consent shall be obtained from the person exercising parental power who has the authority to act on behalf of the minor.
The standard contains no age threshold like this. A consent system that passes an ISO audit may still never ask a user's age or separate children from adults, even though the last paragraph of Section 20 applies the same rule to withdrawing consent and exercising rights. See children's data and parental consent.
must notify the Office as soon as possible and in any event not later than fifteen days from becoming aware of it.
Clause 7 is a Thai-only mechanism. A breach register designed purely around ISO rarely has a field for the reason a notice was late. Add one from day one, because during a real incident nobody has time to redesign the form.
Controller or processor: which Annex A controls apply to you?
Your role under the PDPA decides the control set. ISO 27701 splits Annex A into three groups: controls for PII controllers, controls for PII processors, and security controls that apply to both. One company can hold both roles for different activities, for example as controller of its own staff data and processor of data its clients send in.
| Group | Applies to | Controls | Comparable PDPA duties |
|---|---|---|---|
| A.1 (guidance B.1) | Controllers | 31 | Lawful basis s.24, s.26 · consent s.19 · rights s.30–s.36 · records s.39 · transfers abroad s.28–s.29 |
| A.2 (guidance B.2) | Processors | 18 | Processor duties s.40 |
| A.3 (guidance B.3) | Both roles | 29 | Security s.37(1), s.40(2) · breaches s.37(4) |
The Data Processor, who fails to comply with (1) for the collection, use, or disclosure of the Personal Data, shall be regarded as the Data Controller for the collection, use, or disclosure of such Personal Data.
This matters for service providers such as cloud hosts, call centres and software houses. Use client data outside the instructions and Thai law treats you as the controller for that use. It lines up with the ISO processor controls, which limit processing to the purposes in the customer's documented instructions and bar marketing use without the individual's prior consent.
A company that is only ever a controller still has to manage its own processors through contracts under guidance B.1.2.7 and Section 40 paragraph three. For joint controllers, guidance B.1.2.8 asks for the split of responsibilities to be documented, including who notifies when a breach occurs.
Where should a PDPA team start with ISO 27701?
- Write down where the organisation is a controller, a processor or both, activity by activity, using the records register as the base.
- Draw the scope under clause 4.3. It can be the whole company or only the service customers are asking about, but it must include the processing of personal data.
- Walk through the evidence map above and mark what exists and is in use versus what exists with no dated trail.
- Assess risks to the organisation and to individuals, then write the SoA with reasons for every exclusion.
- Set three to five measurable privacy objectives, such as the share of requests answered on time or the number of processor contracts with a breach clause.
- Run one internal audit and take the results to a management review before you call a certification body.
Steps one to three reuse what the PDPA team already has. The real effort is in steps four to six, the management system work, which is why a company with solid PDPA compliance still should not expect ISO 27701 in a month. For an overview of the standard, see the ISO 27701 guide.
Frequently asked questions
Does ISO 27701:2025 require ISO 27001 first?
No. The 2025 edition was redrafted as a stand-alone management system standard. You still need a documented information security programme under clause 6.1.3, which can be based on ISO 27001 or designed yourself.
If we are certified to ISO 27701, are we PDPA compliant?
Not automatically. ISO is not Thai law and does not set the 72-hour window in s.37(4), the 30-day limit in s.30 or the minors rules in s.20. A certificate shows a working management system; PDPA duties still need checking on their own.
Can our Section 39 records register be used as ISO 27701 evidence as it is?
Mostly. Add a named owner accountable for accuracy, the lawful basis per activity and the date of the last review.
Does the PDPA require a DPIA?
No section orders a DPIA by name, but ISO 27701 asks you to consider one whenever processing is new or changes. Running DPIAs for high-risk activities is good practice that serves both.
Which Annex A controls does a data processing service provider need?
At least the processor group A.2 and the shared group A.3. If you also decide purposes for some data, such as your own staff records, the controller group A.1 applies as well.
Why does this article not quote ISO text?
The ISO standard is copyrighted and sold by ISO, so we describe it in our own words and give clause numbers for you to check. Only Thai legal provisions are quoted word for word.
Law and sources
- ISO/IEC 27701:2025 Privacy information management systems, second edition · international standard, not Thai law · described in our own words, not quoted — Foreword · 0.1 · 4.2–4.3 · 5.2 · 6.1.3 · 6.2 · 9.2–9.3 · 10.2 · B.1.2.6–B.1.2.9 · B.1.3.10 · B.2.2.3–B.2.2.4 · B.3.12
- AIPDPA team note on ISO/IEC 27701:2025 An introduction to privacy information management systems (ITGP 2025) · not law
- Personal Data Protection Act B.E. 2562 (2019) — Section 20 · Section 30 · Section 37 (1) (4) · Section 39 · Section 40
- PDPC Notification on Criteria and Methods for Personal Data Breach Notification B.E. 2565 (2022) — Clause 7 · Clause 8 · Clause 9
Text in the "The text" boxes is copied word for word from AIPDPA's legal knowledge base, transcribed from the Royal Gazette and official documents; every edit is checked by the system against that base, character by character. English wording is an unofficial translation; the Thai text prevails. This article is general information, not legal advice for a particular case.
Do it in the system
Who stands behind this guide?
Written by the AIPDPA legal team · Content owner: Phuwara Krobtaku, Attorney-at-law · Thai Barrister-at-Law · technology & intellectual property counsel
Lawyer's licence no. 477/2558 · Thai Barrister-at-Law · LL.M. in Intellectual Property & IT Law (Gold Medal)