Moving to the cloud: who Thailand's 2024 cloud security standard binds

Many Thai agencies moved workloads to public cloud under the Cloud First policy. The security rules written specifically for cloud only became binding last month: the Notification of the National Cybersecurity Committee re: Cloud System Cybersecurity Standard, B.E. 2567 (2024), issued under section 9(4) of the Cybersecurity Act B.E. 2562 (2019).

It was published in the Government Gazette on 10 September 2024 with a two-year runway, so it took effect on 11 September 2026. If your team filed it under "later", later has arrived.

This piece reads the standard together with the NCSA Office notification on using public cloud services with a primary data centre in Thailand (2024), which answers the question IT teams ask most: do we have to host in Thailand? It ends with a contract checklist drawn from the standard itself.

Who does the 2024 NCSA cloud standard apply to?

Three groups defined by the Cybersecurity Act: government agencies, regulatory or supervisory agencies, and critical information infrastructure (CII) organisations, plus the cloud providers that serve them. Clause 3 of the notification calls the three groups together an "agency".

For providers, the scope is narrower than many assume. Annex 2 covers public cloud providers only insofar as they serve those three groups, on the basis of a contract. A provider that sells only to private-sector customers is not directly bound by this standard.

What impact level must personal data in the cloud get?

At least medium for confidentiality. Clause 5 says so expressly and ties it to the 2023 NCSC standard on cybersecurity characteristics, which grades impact as low, medium or high.

In practice, a system holding customer, patient or staff records can no longer be graded low. Where one system holds several data categories, the 2023 standard takes the highest level of any category for each security objective.

That level decides which controls apply and what kind of certification is needed. The table below follows the table in clause 4 of the annex; the last column comes from the NCSA Office notification on Thai data centres.

How is responsibility shared between the cloud customer and the provider?

Every requirement in the annex has two columns: the left one for the cloud service customer (CSC), the right one for the cloud service provider (CSP). Annex 1.7 explains why: the risk comes from both sides.

Where the line falls depends on the service model. Rent bare infrastructure (IaaS) and the agency still runs the operating system and the application; buy finished software (SaaS) and most of the work sits with the provider. Clause 5.1.1(d) therefore requires the contract to draw that line by service type.

Note the reference to sub-contractors. Many SaaS vendors run on someone else's cloud. A sound contract tells you whose hands the agency's data passes through and who answers for which layer.

Do we have to use a cloud with a data centre in Thailand?

Yes, if the assessment comes out high. The NCSA Office notification on public cloud with a primary data centre in Thailand, in force since 26 December 2024, sets the condition in clause 4, paragraph one.

"Including Singapore and the Hong Kong Special Administrative Region" widens the area for the backup site; it is not a closed list of two. Hong Kong is not in Southeast Asia, which is why the text has to name it.

The exception that matters in practice is paragraph two. A system rated high overall because of financial or reputational impact, but only low or medium on state security, does not have to move its primary data centre to Thailand.

What should a cloud contract spell out?

Annex 5.2.9.2 requires the customer to confirm the security roles and responsibilities described in the service agreement, and requires the provider to state its own measures in that agreement to avoid misunderstandings. The contract is the first document an auditor will ask for.

The standard lists 12 example processes. We have turned them into questions you should be able to answer from the contract or its schedules. If you cannot, ask the provider in writing before you sign.

1. Malware protection and vulnerability management: who scans, who patches, at which layer?
2. Data backup: where, how often, and who tests restores?
3. Cryptographic controls: is data encrypted at rest and in transit, and who holds the keys?
4. Incident management: what will the provider report, within what target time, through which channel? (Read with 5.2.10.1(b).)
5. Auditing and security testing: can the agency see audit reports or run its own tests?
6. Evidence and logs: how long are logs and audit trails kept, and how do you get copies?
7. Protection of data at termination: in what format is data returned, when is it deleted, and how is deletion confirmed?
8. Authentication, access control and identity management: whose administrator accounts can reach the data?

One item teams often miss is the provider's home law. Clause 5.1.3.1 tells the customer to allow for the laws of the jurisdiction governing the provider, and the provider must disclose the legal jurisdiction that governs the service.

In what order should an agency do the work?

The sequence below is taken from the three notifications. Step 1 comes first because everything after it depends on the impact level.

1. Step 1
   Grade impact per data category and per objective (confidentiality, integrity, availability). Personal data is at least medium on confidentiality.Cloud standard cl. 5 · 2023 standard cl. 10
2. Step 2
   Map the level to the minimum-requirements table to see which Part 1 and Part 2 controls apply.Annex cl. 4
3. Step 3
   Choose a provider, check its certifications for that level, and check primary and backup data centre locations if the system is high.Annex 1.8.2 · Office notification cl. 4
4. Step 4
   Write the contract: split duties by service model, cover the 5.2.9.2 processes and the incident reporting mechanism.Annex 5.1.1(d) · 5.2.9.2 · 5.2.10
5. Step 5
   Self-assess or get certified for the level (medium and high run on a 3-year cycle).Annex 1.8
6. Within 30 days of completion
   Send the summary report to the NCSA. If the agency cannot comply, notify the NCSA in writing so the matter goes to the Committee.Cloud standard cl. 6 · Office notification cl. 6

Should a private company that is not CII care about this standard?

The 2024 cloud standard does not bind ordinary private companies. The Personal Data Protection Act B.E. 2562 (2019) still does. A cloud provider that stores data for you is usually your data processor, and section 40, paragraph three, requires an agreement between you.

The PDPA does not list what that agreement must cover. The 12-process checklist from annex 5.2.9.2 is a sensible model for private companies too. It is not mandatory for them, but it makes the contract answer the questions that matter when something goes wrong. See the processor agreement guide.

If the provider's data centre is abroad, there is a second question the cyber standard does not answer: is it a transfer abroad under PDPA section 28? That depends on who can access the data. Read When data leaves Thailand, and if the recipient is a group company, BCR versus standard contract clauses.

For agencies inside the scope, AIPDPA provides security controls mapped to the PDPC, ETDA and NCSA standards, and a processing register that records which system runs on which cloud. For the wider picture, see the public cloud in Thailand guide.

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)