# NCSA Zero Trust Guidelines

Locale: `en`

Source: `/en/compliance/ncsa-zero-trust-guidelines/`

Summary: NCSA Zero Trust Guidelines v1.0: moving from perimeter security to risk-based continuous verification.

On this page

1. [Overview](/en/compliance/ncsa-zero-trust-guidelines/#topic-overview)
2. [Zero Trust principles and adoption scope](/en/compliance/ncsa-zero-trust-guidelines/#zero-trust-principles)
3. [Architecture and policy decision points](/en/compliance/ncsa-zero-trust-guidelines/#zero-trust-architecture)
4. [A five-step risk-based transition](/en/compliance/ncsa-zero-trust-guidelines/#five-step-migration)
5. [Gap analysis, maturity, and continuous operations](/en/compliance/ncsa-zero-trust-guidelines/#gap-analysis-and-maturity)
6. [Requirements Matrix](/en/compliance/ncsa-zero-trust-guidelines/#compliance-matrix)
7. [Readiness Assessment](/en/compliance/ncsa-zero-trust-guidelines/#compliance-readiness-checklist)
8. [Frequently Asked Questions](/en/compliance/ncsa-zero-trust-guidelines/#compliance-faq)
9. [Related Frameworks](/en/compliance/ncsa-zero-trust-guidelines/#related-compliance-frameworks)

# NCSA Zero Trust Guidelines

A source-based guide to NCSA's Zero Trust Guidelines, published as version 1.0, for executives, policy owners, technical teams, system administrators, and security engineers planning a risk-based transition from perimeter security to continuous verification.

Executive Summary and Mandate Overview

Target Audience

Executives, policy owners, technical teams, and security engineers planning a move away from perimeter-based security

Mandatory Frequency

Review protect surfaces, policy, and maturity under the guidance; not an annual pentest mandate

Required Scope

Identity, devices, networks, applications and workloads, and data under the Zero Trust Maturity Model

Non-Compliance Risk

Lateral movement when the internal network is still trusted by default

## Zero Trust principles and adoption scope

The guidance shifts the assumption from trusting an internal network to verifying every access request against identity, device posture, and session context.

[![Zero Trust principles for every access request: Resources are services, Authorize per session, Use contextual policy, No trust from location, Check asset posture, Secure communications, Improve with telemetry](/assets/compliance/guide-ncsa-zero-trust-guidelines-zero-trust-principles-en-v1.webp)](/assets/compliance/guide-ncsa-zero-trust-guidelines-zero-trust-principles-en-v1.webp)

**Zero Trust principles for every access request**

Every request receives a contextual decision and least-privilege enforcement.

- **Resources are services** — Protect data, applications, assets, and services
- **Authorize per session** — Grant only the access needed for the request
- **Use contextual policy** — Evaluate identity, device, location, and behavior
- **No trust from location** — Internal network position does not establish trust
- **Check asset posture** — Continuously assess devices and systems
- **Secure communications** — Authenticate and protect every path
- **Improve with telemetry** — Feed events back into policy decisions

- All resources, including data, applications, services, and devices, should be treated as assets that need protection regardless of where they reside.
- Access should be granted per session and adjusted to risk using relevant evidence such as identity, device posture, location, and behavior.
- The seven Zero Trust principles emphasize strict authentication and authorization, continuous security monitoring of assets, and using collected information to improve controls.

## Architecture and policy decision points

The document explains that requesters and their devices pass through policy decision points before they can reach a resource, separating decision, session-management, and enforcement responsibilities.

[![Zero Trust: decide, then enforce: Requester and device, Policy Engine (PE), Policy Administrator (PA), Enforcement point (PEP), Resource](/assets/compliance/zero-trust-policy-en-v1.webp)](/assets/compliance/zero-trust-policy-en-v1.webp)

**Zero Trust: decide, then enforce**

The PE evaluates the request; the PA creates or ends the session. Resource traffic passes through the PEP. Test both the decision and its enforcement.

- **Requester and device** — Send the request with context
- **Policy Engine (PE)** — Evaluates policy and trust signals
- **Policy Administrator (PA)** — Creates or ends the session
- **Enforcement point (PEP)** — Opens, monitors, or ends the connection
- **Resource** — Allows only authorized access

- The Policy Engine evaluates policy and supporting information to decide whether access is permitted.
- The Policy Administrator establishes or terminates communication paths and manages session credentials according to that decision.
- The Policy Enforcement Point opens, monitors, or terminates connections and should draw on identity, device, security telemetry, and other relevant information sources.

## A five-step risk-based transition

The guidance starts with a defined protect surface and expands incrementally instead of changing every system at once.

[![Five steps to transition to Zero Trust: Define the Protect Surface → Map transaction flows → Design the architecture → Define 5W1H policy → Monitor and maintain](/assets/compliance/guide-ncsa-zero-trust-guidelines-five-step-migration-en-v1.webp)](/assets/compliance/guide-ncsa-zero-trust-guidelines-five-step-migration-en-v1.webp)

**Five steps to transition to Zero Trust**

Begin with the protect surface and real flows before selecting technology.

1. **Define the Protect Surface** — Identify data, applications, assets, and services
2. **Map transaction flows** — Understand communications and dependencies
3. **Design the architecture** — Select approaches for context and risk
4. **Define 5W1H policy** — Specify who, what, when, where, why, and how
5. **Monitor and maintain** — Use logs, alerts, and feedback to improve policy

- Define the Protect Surface and a risk-based strategy, then map Transaction Flows to understand the relationship among data, applications, assets, and services.
- Design the Zero Trust architecture for that surface, considering identity, segmentation, microsegmentation, cloud, or hybrid approaches according to context and risk.
- Define policy through the 5W1H framework: Who, What, When, Where, Why, and How. Then monitor, log, alert, and continually review protect surfaces and policy.

## Gap analysis, maturity, and continuous operations

Gap analysis needs to cover strategy, governance, data, assets, operations, and control effectiveness rather than comparing tool inventories alone.

[![Measure Zero Trust readiness across five pillars: Identity, Devices, Networks, Applications and workloads, Data](/assets/compliance/guide-ncsa-zero-trust-guidelines-gap-analysis-and-maturity-en-v1.webp)](/assets/compliance/guide-ncsa-zero-trust-guidelines-gap-analysis-and-maturity-en-v1.webp)

**Measure Zero Trust readiness across five pillars**

Assess each pillar separately across Traditional, Initial, Advanced, and Optimal maturity, then define targets and improvements.

- **Identity** — Assess authentication, privileges, and identity risk
- **Devices** — Assess device posture and trust signals
- **Networks** — Assess segmentation, connections, and telemetry
- **Applications and workloads** — Assess access and workload protection
- **Data** — Assess classification, access, and protection

- Use the Risk Management Framework to structure the gap analysis across preparation, categorization, control selection, assessment, authorization, and monitoring.
- Use the Zero Trust Maturity Model to assess the five pillars of identity, devices, networks, applications and workloads, and data, with connected risk indicators.
- Establish roles, accountability, communication, training, and feedback loops so policy can adapt to incidents and changing environments.

## Requirements and Testing Scope Matrix

Summary of the referenced clauses, the testing scope they cover, and the expected evaluation cycle.

| Reference | Mandate Title | Scope Required | Testing Cycle |
| --- | --- | --- | --- |
| **Seven tenets (NIST SP 800-207 as cited by NCSA)** | Verify every access request against identity, device posture, and session context | Policy Engine, Policy Administrator, and Policy Enforcement Point | Per-session verification under the guidance, not an annual pentest cadence |
| **Five pillars (CISA ZTMM as cited by NCSA)** | Assess maturity of identity, devices, networks, applications and workloads, and data | Protect surface, transaction flows, and 5W1H policy | Assessed in context and expanded incrementally |

### Compliance Readiness Self-Assessment

Select items your organization has completed to evaluate your readiness score.

0%

Protect surface defined and transaction flows mapped for data, applications, assets, and services
          
          
            
            Policy Engine, Policy Administrator, and Policy Enforcement Point roles separated
          
          
            
            Maturity assessed across identity, devices, networks, applications and workloads, and data
          
          
            
            Policy written with the 5W1H framework and reviewed when the environment or incidents change

Assessment Status

Check items above to view assessment result.

[Request Pentest Quote](/en/#contact)

## Frequently Asked Questions (FAQ)

Key answers and practical guidance addressing common compliance questions.

### How does Zero Trust Architecture (ZTA) differ from traditional perimeter-based security?

Traditional security relies on perimeter firewalls, whereas Zero Trust operates on the principle of Never Trust, Always Verify, requiring explicit authentication and authorization for every request regardless of origin.

### Where should an organization begin when adopting Zero Trust Guidelines?

The guidance starts with a defined protect surface and a risk-based strategy, then maps transaction flows, designs the architecture, and writes policy with the 5W1H framework before expanding incrementally rather than changing every system at once.

## Related Compliance Frameworks and Security Standards

- [
                NCSA Cloud Security Standard B.E. 2567 (2024)
                
              ](/en/compliance/ncsa-cloud-security-standard/)
- [
                Does ISO/IEC 27001:2022 require penetration testing?
                
              ](/en/compliance/iso-27001/)
- [
                Thailand Cybersecurity Act 2019 and penetration testing
                
              ](/en/compliance/cybersecurity-act/)
- [
                NCSA Guidelines for Post-Quantum Readiness
                
              ](/en/compliance/ncsa-post-quantum-readiness/)

Open full-size image to zoom

## Official source documents

Original files from the regulating authorities, hosted on sth.sh for convenience. Always defer to the latest version at the source link.

[
            
              
              
              ![First-page preview of NCSA Zero Trust Guidelines](/assets/process/compliance-sources/sth-source-ncsa-zero-trust-guidelines-2569.webp)
            
          ](/assets/documents/sth-source-ncsa-zero-trust-guidelines-2569.pdf)

### NCSA Zero Trust Guidelines

By NCSA

[Open document (PDF) ](/assets/documents/sth-source-ncsa-zero-trust-guidelines-2569.pdf)
              [Download ](/assets/documents/sth-source-ncsa-zero-trust-guidelines-2569.pdf)
              
              [Source ](https://www.ncsa.or.th/standards)

## Need a pentest that satisfies these requirements?

Tell us about your systems and the requirements you must meet. The STH team will assess the approach and prepare a quotation.

[Request a Pentest quote](/en/#contact)

## PDF document

[Open in new tab ](/en/compliance/ncsa-zero-trust-guidelines/)
              [Download](/en/compliance/ncsa-zero-trust-guidelines/)

Last updated 16 October 2026