Each certificate a cloud provider shows covers a different thing, and none of them certifies your own system. This article explains the NCSA certification path, what a provider's certificate does and does not tell you, and how to write contracts while some criteria are still unpublished.
A proposal from a cloud provider lands on a procurement officer's desk. On the third page of the attachment there is a row of certificate images: ISO 27001, ISO 27017, CSA STAR, and one more that the provider recently earned. The chair of the procurement committee asks a short question. Are these enough for our system?
That question is harder to answer than it looks, because each certificate covers a different thing, and none of them certifies your own organization's system. We write this as the team that helps agencies read proposals like this, and it is not legal advice. We will explain how the National Cyber Security Agency (NCSA) framework for cloud security lays out the certification path, what a provider's certificate can and cannot tell you, and what to put in a contract while some of the criteria remain unpublished. Your agency's legal obligations should be confirmed by your legal team or whoever is responsible for security in your organization.
What we read, and how far
The main sources for this article are the NCSA's official website for its cloud security framework: the page on the certification steps for cloud service providers (CSPs), the page for cloud service customers (CSCs), and the FAQ page on certification. We read all of them on 28 October 2026, and none of the pages states a last-updated date, so the content may change.
What we have not read is the full text of the National Cyber Security Committee's announcement on the cybersecurity standard for cloud systems. A copy hosted on another agency's website would not open, because that site's bot protection redirected in a loop, and we do not work around it. So every statement about the content of the standard in this article comes from what the NCSA summarizes on its own website, not from the requirements text itself. We therefore give no fees, certificate validity periods or timelines, because those pages themselves say these are not yet set.
Three layers of provider certificates that tend to sit side by side
When a provider shows several certificates, we see three layers that answer different questions.
Company management system certificates, such as ISO/IEC 27001, say the company runs an information security management system to an international standard. The scope of each certificate may cover only some units or sites of the company.
Cloud-specific certificates, such as ISO/IEC 27017, ISO/IEC 27018 and CSA STAR, address controls specific to cloud services, or the security and privacy of data in the cloud.
Certification under the NCSA framework, which a provider applies for through a certification body (CB) registered with the NCSA, and which is an assessment of the services within a stated scope, set by the impact level of the customer's data or systems.
Providers usually obtained the first two layers from international bodies before the NCSA framework existed. For the third layer, the NCSA describes the steps this way: the provider classifies the services it wants certified and their impact level, puts technical and management controls in place to match that level, and submits an application with a scope document to a CB. The CB then assesses the architecture, the data centers and actual operations within scope, the provider fixes the findings, and it receives a certificate and is entered in the register of providers. After certification it must keep up the standard and undergo continuing surveillance for the life of the certificate.
The NCSA's FAQ states that a cloud provider must be certified to CSA STAR Level 2 (CCM) and ISO/IEC 27701 at a minimum. The same page does not list ISO/IEC 27001 or ISO/IEC 27017 in that answer, so do not conclude that an ISO 27001 certificate alone is enough.
A provider's certificate does not certify your system
This is where we see the most misunderstanding. Even if a provider is certified at every layer, the system your agency builds on that cloud remains the agency's responsibility. The NCSA has a separate page for customers (CSCs). It says that before seeking certification, a customer must classify its data or systems by impact level, low, medium or high, looking at the effect on confidentiality, integrity and availability, and that the high level covers critical information infrastructure and highly sensitive data.
According to the FAQ, a system assessed at the medium level means the customer must obtain its own certificate. A government agency that is not critical information infrastructure, and that has no statutory regulator, must have the system inspected by a certification body. A low-impact system can use self-assessment, and an agency's own internal audit cannot substitute for certification of a medium or high-impact system. The scope of certification is also set system by system, including the cloud management processes the agency applies to that system.
Our practical reading is that a provider's certificate gives an agency a base so it need not re-inspect the infrastructure, but it does not reduce the agency's own work of classifying, putting its own controls in place, and being inspected. If a proposal reads as though the provider's certificate means your system has "passed the standard," ask back which part belongs to whom.
What to check when you read a provider's certificate
When you are handed a certificate, we use five questions, whether it is an international certificate or one under the NCSA framework.
Does the scope cover the services you will use? A certificate that covers one data center or one service does not cover everything the provider sells.
At what impact level was it certified? If your system is medium or high, a certificate issued for the low level is not enough.
Who issued it? Under the NCSA framework, certificates are issued by certification bodies registered with the NCSA, not by providers assessing themselves.
Is it still in force, and is there continuing surveillance? The NCSA page says surveillance continues for the certificate's life but does not yet say for how long.
Can you check it against a register? The NCSA site mentions a register of providers, but the list pages we tried to open were not found, so we do not know whether the list is open to the public yet.
The last point matters more than it looks, because the site itself indicates the certification route is still being set up. The FAQ page says the NCSA is still drawing up the rules for certification bodies. We therefore cannot say how many certification bodies are registered today, or whether any provider has been certified under this framework.
What the NCSA has not yet published, and how to write a contract meanwhile
According to the FAQ page, the NCSA states that the cloud standard came into force officially on 10 September 2569 (10 September 2026). The items it says it is still preparing or considering include the following.
Rules for certification bodies
The attestation route through sector regulators, which the NCSA is working out with regulators in each sector
Standard criteria for self-assessment of low-impact systems (there is no template yet)
Notifications and practices to accommodate foreign providers under contracts made before the standard took effect
Guidance on how responsibility is divided when SaaS is used
Many answers on the site also give no fees, certificate validity period or renewal cycle. While the rules are unsettled, we think contracts with providers should be written flexibly enough to take on criteria that follow. This is our suggestion, not an NCSA requirement. Several things can go in: the provider states the scope and impact level it is certified for, notifies the agency if the certificate lapses or is revoked, cooperates when a certification body needs to inspect the agency's system, and says who bears the cost of changes caused by later changes in criteria. We wrote about conditions like these in our article on conditions to put in a TOR, and about account access when the development team changes in our article on cloud accounts.
What to do about foreign providers
Many agencies use large providers that are not based in Thailand. The NCSA answers that an agency using a foreign provider before the announcement took effect must review its use of that service, checking evidence of international certificates such as ISO/IEC 27001, 27017, 27018, 27701 and CSA STAR for whether they are consistent and sufficient. That text gives examples of evidence to consider. It does not say these certificates can stand in for certification under the NCSA's cloud standard, and the NCSA adds that it is considering a notification on the transition for contracts made earlier.
Where a provider should be located, and the choice of region for the data, is a separate question. We wrote about it in our article on regions and data location, and about relying on one provider or several in our article on multi-cloud. This article does not cite any data-location requirement from the standard, because we could not find a statement of it in an official source.
The limits we should state plainly
The framework is written for government agencies, critical information infrastructure organizations, and regulators that have a formal contract for cloud services. If your organization is an ordinary private company that is not in scope, chasing certificates for fear of being left behind may not be worth the time. In that case our advice is to use the framework as a reference list when you read proposals, for example asking about scope and impact level, but not to set a goal of getting your own system certified, because a certificate nobody needs becomes a continuing surveillance cost.
The other limit is that a certificate says how the system looked within scope on the day it was assessed. It does not say whether a misconfiguration exists today, and misconfiguration usually sits on the customer's side. Checking your own system's configuration and access rights remains a regular task, however many certificates the provider holds.
An objection we often hear
The objection we hear most is that the provider already has the international certificates, so why think about this further. It is a fair question, and those certificates are worth something as evidence. But under the NCSA framework they are not stated to be a substitute for certification to the standard, and they do not cover the part that is your agency's own system.
Another is to wait until the NCSA publishes all the criteria. The NCSA's answer on its site says an agency may carry out certification before or after the announcement takes effect, depending on its readiness. What you can start at once, without waiting for anyone, is classifying the impact level of the systems you already have, because that is the first step on every route.
Where to start
List the systems that run on cloud, with which provider and in what form, for example infrastructure or packaged software.
Classify the impact level of each system as low, medium or high by the effect on confidentiality, integrity and availability, and have the executive responsible for the system sign it off.
Ask each provider for its certificate documents, with the scope and impact level certified, and compare them with the level of your system.
Review contracts and SLAs against the list in the section above, especially notice when a certificate changes status.
Follow NCSA announcements on certification body rules, SaaS guidance and the transition period, and record the date you last checked in your decision document.
Summary
If you take only one thing from this article, ask every provider which services the certificate covers, at what impact level, and who issued it, then compare that with the impact level you classified yourself. A certificate that cannot answer those three questions proves nothing for you yet.
If your organization is still scoping the work and would like someone to talk through the problem first, you can reach Superdev at 088-983-9386 or [email protected]. Our office is in Bangkapi, Bangkok. There is no deadline, you do not need complete documents to start, and if it turns out the timing is not right to build a new system, we will say so plainly, because starting a project at the wrong time costs more than waiting one more quarter.
FAQ: Frequently Asked Questions about This Article
A collection of questions and answers to help you better understand the content of this article.
Tags: