NCSA Cloud Security Standard B.E. 2567 (2024)
A source-based guide to the National Cyber Security Committee Notification on Cybersecurity Standards for Cloud Systems B.E. 2567 (Thailand National Cloud Security Framework), separating scope, customer/provider responsibilities, and implementation evidence.
- Target Audience
- Government agencies, regulators, Critical Information Infrastructure (CII) entities, and cloud providers serving those agencies
- Mandatory Frequency
- Low-impact CSCs self-assess at least annually. Medium and high impact use 3-year attestation or certification under annex 1.8
- Required Scope
- Public IaaS, PaaS, and SaaS services, CSC/CSP role split, and vulnerability management defined in the agreement
- Non-Compliance Risk
- Non-compliance with the NCSA Cloud Standard B.E. 2567 according to the system's impact level
Applicability and effective date
The standard is officially in effect as of 10 September 2026, establishing mandatory duties for agencies using public cloud services under the National Cloud Security Framework.
Determine scope and impact before selecting safeguards and evidence.
- In-scope agency — Confirm the entity and cloud-service context
- Systems and data — Identify cloud workloads and information
- Impact level — Assess criticality and sensitivity
- Service model — Identify IaaS, PaaS, SaaS, or combined services
- Requirements and evidence — Select relevant safeguards, contracts, and evidence
- “Agency” covers government agencies, supervisory or regulatory agencies, and critical information infrastructure organizations under Thailand's Cybersecurity Act B.E. 2562 (2019).
- The notification covers IaaS, PaaS, SaaS, and combined services, establishing distinct security domains for Cloud Service Customers (CSCs) and Cloud Service Providers (CSPs).
- Implementation must consider the impact level of the data or information system. Personal data must have, at minimum, a medium confidentiality impact level.
Shared accountability, SLAs, and legal jurisdiction
The standard requires cloud customers and providers to agree and record appropriate information-security roles, duties, and binding responsibilities.
“The provider handles it” is not a responsibility agreement. Record owners, evidence to exchange, and incident coordination in the contract and SLA.
- Cloud customer (CSC) — Sets requirements and governs service use
- Shared responsibility — Agrees roles, evidence, and incident coordination
- Cloud provider (CSP) — Provides service information and agreed safeguards
Cloud Security Policy
Agencies must formally issue written information security policies for cloud processing and deliver specialized cloud risk training for executive and business management.
Service Level Agreements and Roles
Formally document the Shared Responsibility Matrix within contracts, covering malware defense, backup, cryptography, vulnerability management, incident response, and access controls.
Legal Jurisdiction and Data Localization
Identify data center regions, potential storage jurisdictions, and evaluate cross-border legal conflicts to safeguard digital sovereignty.
Provider Evidence Verification
Customers must obtain audit evidence of provider compliance with relevant laws and standards (such as ISO/IEC 27001, SOC 2) or validated self-assessments.
Technical control areas to plan jointly
The annex addresses customer operational processes and technical capabilities that cloud providers must support under Clause 5.2.
Cloud safeguards connect the CSC, CSP, contracts, operations, and evidence.
- Governance and people — Define policy, roles, and competence
- Identity, data, and cryptography — Control access and protect information
- Infrastructure and operations — Configure, segment, back up, and log
- Systems and suppliers — Govern lifecycle, contracts, and suppliers
- Incidents and evidence — Coordinate response, assurance, and records
Asset inventory and user lifecycle
Maintain an inventory of cloud assets across regions/zones, enforce data classification tagging on VMs, buckets, and containers, alongside secure user registration and deregistration.
Authentication and privilege management
Mandate Multi-Factor Authentication (MFA) for privileged admins, enforce least privilege access, govern privileged utilities (Cloud CLI, Terraform, API keys), and secure log-on procedures.
Data cryptography and key management lifecycle
Implement cryptographic controls for data at rest and in transit using proven standards, maintain KMS procedures, and enforce contractual prohibitions against default provider key access (BYOK, HYOK, Cloud HSM).
Virtual network security and tenant isolation
Enforce data localization, segment virtual networks (VPC, subnets, Security Groups, NACLs, WAF), and verify tenant isolation controls in shared multi-tenant environments.
Operations security and centralized logging
Establish change management, backup and recovery verification, event logging, personal data masking within logs, automated retention lifecycle rules, privileged audit logs, and NTP clock synchronization.
Technical vulnerability management
Customers must obtain provider information on vulnerabilities that may affect the cloud service, identify which weaknesses the customer owns, and define the management process.
Security in supplier agreements
The service agreement must record security roles and responsibilities and may include security testing, vulnerability management, and compliance checks. It does not set a universal annual pentest cadence.
Incident management and breach response
Coordinate joint incident handling procedures with the provider, execute personal data breach assessments, and maintain formal notification pathways to NCSA.
Evidence and reporting
Turn the requirements into auditable evidence from service selection through contract review and operation.
Start with each system’s impact level. Link assessment results to evidence that can be checked, then obtain management review before submitting through the official channel.
- Classify impact — Set criteria for each system
- Assess implementation — Record status in the assessment
- Assemble evidence — Policies, contracts, records, and test results
- Management review — Approve the agency’s assessment
- Report to NCSA — Submit through the official channel
- Keep impact classification, selected requirements, contracts, responsibility allocation, provider evidence, and review results together.
- The notification requires an agency to submit a summary implementation report to NCSA within 30 days after completion, utilizing the official CSC Self-Assessment framework (version 1.0).
- Access official publications, the 2026-2030 integration plan, and self-assessment templates on NCSA's dedicated portal at cloudsecurity.ncsa.or.th.
Requirements and Testing Scope Matrix
Summary of the referenced clauses, the testing scope they cover, and the expected evaluation cycle.
This is an illustrative division of work, not a fixed owner for every control. Adapt it to the service model and the actual agreement.
- Governance — Requirements | Roles and SLA | Service terms
- Controls — Configuration | Incident coordination | Platform safeguards
- Evidence — Assessment records | Joint review | Service evidence
| Reference | Mandate Title | Scope Required | Testing Cycle |
|---|---|---|---|
| Clause 5.1 (5.1.1 and 5.1.2) | Cloud Security Governance, Policies, and Service Level Agreements (SLA & Jurisdiction) | Cloud information security policies, risk assessments, cloud service contracts across IaaS, PaaS, SaaS, SLA definitions, and evaluations of cross-border legal jurisdictions and data storage locations | Follow policy and service-agreement terms; cited clauses do not specify an annual interval |
| Clauses 5.2.2 and 5.2.3.2 | Cloud Asset Inventory, Information Labelling, and User Lifecycle Management | Cloud asset inventory maintenance across regions and zones, data classification labelling and tagging on VMs, storage buckets, and containers, alongside secure user registration and deregistration | Maintain inventory and labels as assets are used; no annual interval specified |
| Clause 5.2.3 (5.2.3.1 to 5.2.3.6) | Advanced Authentication, Least Privilege, and Privileged Utility Tool Controls | User registration and deregistration, access-right management, secure log-on, and control of privileged utility programs | Follow access policy and permission changes; no annual interval specified |
| Clause 5.2.4 (5.2.4.1 and 5.2.4.2) | Data Cryptography and Cryptographic Key Management Lifecycle | Data-at-rest and data-in-transit encryption standards, Key Management Service (KMS) lifecycle controls, BYOK, HYOK, or Cloud HSM architectures, and cryptographic audit logging | Follow cryptographic policy and the key lifecycle; no annual interval specified |
| Clauses 5.2.5 and 5.2.7 | Virtual Network Security, Perimeter Defense, and Multi-Tenant Isolation | Virtual network segmentation (VPC, subnets, peering), Security Groups, Network ACLs, Web Application Firewalls (WAF), and multi-tenant boundary controls preventing cross-tenant access | During network design and change; no annual interval specified |
| Clause 5.2.6 (5.2.6.1 to 5.2.6.7) | Operations Security, Backup & Disaster Recovery, and Centralized Event Logging | Cloud change management, automated backup and recovery verification, centralized event logging, personal data masking within logs, and network time protocol (NTP) clock synchronization | Follow operating procedures and service agreements; no annual interval specified |
| Clauses 5.2.6.8 and 5.2.9.2 | Technical vulnerability management and security-testing roles in the contract | Obtain provider vulnerability information, assign CSC and CSP duties, and record security-testing roles in the service agreement | As defined in the agreement, not a universal annual pentest cadence |
| Clauses 5.2.9.1, 5.2.10, and 6 | Supplier security roles, incident handling, and implementation reporting | Treat the provider as a third party in policy, define incident roles, and submit a summary implementation report to NCSA under Clause 6 | Incident reporting per the agreement, and an implementation summary within 30 days after completion |
STH CLOUD SECURITY TESTING
Cloud Vulnerability Assessment and Penetration Testing Implementation (Clauses 5.2.6.8 & 5.2.9.2)
Annex Clause 5.2.6.8 requires customers to obtain vulnerability-management information from the provider and assign ownership. Clause 5.2.9.2 requires the contract to record security roles and may include security testing. It does not set a universal annual pentest cadence.
Before testing, establish who may do what. Obtain vulnerability information from the provider and agree responsibilities. Use the cadence and scope applicable to that service agreement.
- Agree the scope — Record roles and limits in the contract
- Obtain CSP information — Vulnerabilities, affected services, and evidence
- Assess and test — Work within agreed duties and authorization
- Close and review — Document findings, fixes, and evidence
Obtain vulnerability information
Identify which weaknesses the customer owns and define the process.
Roles in the service agreement
Testing frequency and scope follow the contract, not a fixed annual rule.
Network Tenant isolation
A network-segregation duty, not a pentest Rules-of-Engagement clause.
Report within 30 days
Submit a summary implementation report to NCSA after completion.
Technical Vulnerability Management & Assessment
Clause 5.2.6.8 requires the customer to obtain vulnerability-management information from the provider, identify which weaknesses it owns, and define the process. It does not prescribe monthly scans or fixed patch SLAs.
Obtain vulnerability information from the provider
Clause 5.2.6.8Customers must request information from the provider on technical vulnerability management that may affect the cloud service in use.
Split vulnerability-management duties
CSC / CSPThe customer must specify which technical weaknesses it owns and define the process for managing them.
Provider disclosure duty
CSP DutyThe provider must give the customer information on technical vulnerability management that may affect the cloud service.
Separate test environments (Clause 5.2.6.9)
Data ProtectionIf personal data cannot be avoided in testing, the parties must assess the risk and apply technical and organisational measures to reduce it.
Cloud Penetration Testing & Rules of Engagement
Clause 5.2.9.2 is a supplier-agreement duty to record security roles and responsibilities. Security testing may be one of the processes listed in the contract. It is not a universal annual pentest mandate.
Record roles in the service agreement
Clause 5.2.9.2Customers must confirm information-security roles and responsibilities related to the cloud service in the service agreement.
Topics the contract may cover
Contract TopicsClause 5.2.9.2 lists processes that may appear in the agreement, including malware protection, backup, vulnerability management, incident handling, technical compliance, and security testing.
Tenant isolation under Clause 5.2.7.2
Multi-Tenant IsolationCustomers must set network-segregation requirements so Tenant isolation holds in shared multi-tenant environments. That is a network control, not a pentest Rules-of-Engagement clause.
Testing frequency
By AgreementSecurity-testing frequency and scope follow what the parties agree in the contract, not an annex-wide annual figure for every agency.
Auditable Evidence and Reporting for NCSA Form CSC v1.0
Assessment results must be compiled into traceable, verifiable evidence ready for regulatory submission in accordance with NCSA requirements.
Executive Summary Report
Synthesizes high-level cloud risk posture, regulatory impact, and business context tailored for CISOs and board members.
Technical Pentest & VA Report
Comprehensive technical dossier detailing vulnerabilities, CVSS scores, CVE/CWE tags, reproducible PoCs, and remediation guidance.
Retest Verification Report
Official retest report validating remediated status across all identified findings without residual risk.
Form CSC v1.0 Submission
Directly references testing artifacts within Chapter 5 of NCSA Self-Assessment Form CSC v1.0, submitted within 30 days.
Referenced from the annex to the National Cyber Security Committee Notification on Cybersecurity Standards for Cloud Systems B.E. 2567: Clause 5.2.6.8 technical vulnerability management, Clause 5.2.6.9 test-environment separation, Clause 5.2.7.2 network segregation, and Clause 5.2.9.2 security in supplier agreements.
Talk to STH about Cloud VA and Penetration Testing for NCSA Standard
Compliance Readiness Self-Assessment
Select items your organization has completed to evaluate your readiness score.
Frequently Asked Questions (FAQ)
Key answers and practical guidance addressing common compliance questions.
Who must comply with the NCSA Cloud Security Standard 2024?
It applies to government agencies, regulators, and Critical Information Infrastructure entities under the Cybersecurity Act B.E. 2562, plus cloud providers that serve those agencies. It takes effect on 10 September 2026.
What security testing is required for government cloud deployments?
Clause 5.2.6.8 requires the customer to obtain vulnerability-management information from the provider, identify which weaknesses it owns, and define the process. Clause 5.2.9.2 requires the contract to record security roles and may include security testing. It does not impose a universal annual pentest.
What specific rules govern cloud penetration testing under the NCSA standard?
Testing frequency and scope follow the service agreement under Clause 5.2.9.2. Tenant isolation in Clause 5.2.7.2 is a network-segregation duty, not a pentest Rules-of-Engagement clause. Clause 6 requires a summary implementation report to NCSA within 30 days after completion.
