Zero Trust Isn't Something You Buy: What to Fund First, and How to Report It to the Board

When the security team brings a Zero Trust budget to the board, the first questions are usually what the organization has to buy and how many years it will take. A better first question is what the organization trusts today without checking. If one contractor's account were stolen tonight, which systems could that account reach?

The answer to that question sets the whole investment sequence.

This article is written for the CTO, CIO or CISO who has to approve the budget and then report progress to the board. We will cover why the old security model no longer holds up to enterprise-level risk, the order we would invest in, and how to measure progress so the board can see that risk has actually gone down.

The old model trusts network location, not identity

The security architecture many organizations still run was designed around a single line: inside the network or outside it. Anyone who gets past the firewall or connects through the VPN is treated as an insider, and usually ends up with far broader access than their job requires.

That assumption was workable when staff sat in the office and every system lived in the organization's own server room. Today core systems are spread across several cloud providers, people work from outside the office, and a number of contractors hold accounts on internal systems. The line that used to decide who is trustworthy no longer matches reality.

Public data points the same way. Verizon's 2026 Data Breach Investigations Report (DBIR), released on 19 May 2026, found that breaches involving a third party made up 48% of the total, a 60% increase on the previous year's report. That is a global figure; it is not broken out for Thailand.

On cost, the Cost of a Data Breach Report 2026 from IBM and the Ponemon Institute puts the average cost of a breach in ASEAN at USD 4.12 million, up from USD 3.67 million in the previous report. That regional sample groups Thailand with Singapore, Indonesia, the Philippines, Malaysia and Vietnam, covers breaches from March 2025 to February 2026, and does not publish a separate figure for Thailand.

Globally, the same report found that breaches which began with the abuse of valid accounts cost an average of USD 5.07 million. These attackers do not break the door down. They use keys the organization issued itself: employee accounts, service accounts and contractor accounts.

Once inside, the old model lets them walk a long way.

Zero Trust changes the question from "are you inside?" to "should this request go through?"

NIST SP 800-207, published in August 2020 and the main reference document on the subject, describes Zero Trust as moving defenses away from static, network-based perimeters and toward users, assets and resources. Where a request comes from on the network is no longer a reason to trust it.

In practice, every access request passes through a decision point that asks who is making the request, whether the device is in an acceptable state, and whether the access being asked for goes beyond what the task needs. NIST calls the component that decides the policy decision point and the component that enforces the result the policy enforcement point. Access is granted per session, and passing the check for one resource does not automatically open any other.

What an executive should take from this is that Zero Trust is not only about making accounts harder to steal. It limits how much damage an account can do once it has been stolen. We have written about the same principle in a narrower case, preparing systems before an AI agent is given access to production. This article applies it to the whole organization.

The point that matters most for budgeting is that Zero Trust is a way of designing, not a product. There is nothing you can buy that turns an organization into a Zero Trust organization on delivery. Vendor tools can help with parts of it, but the order of investment has to come from the organization's own map of risk.

Use CISA's five pillars as the shared planning language

The framework we use for planning is CISA's Zero Trust Maturity Model, Version 2.0, published by the US Cybersecurity and Infrastructure Security Agency in April 2023. It splits the work into five pillars: Identity, Devices, Networks, Applications and Workloads, and Data. Three cross-cutting capabilities run across all of them: Visibility and Analytics, Automation and Orchestration, and Governance.

Each pillar has four maturity stages: Traditional, Initial, Advanced and Optimal. That structure replaces a question nobody can answer ("have we done Zero Trust yet?") with one that can be answered and audited: which stage is each pillar at, and which stage will it reach this year?

The model was written for US federal agencies working toward the goals in OMB memorandum M-22-09, which set a deadline of the end of US fiscal year 2024. That deadline has passed, and Thai organizations were never bound by it. Even so, the pillars and stages work well as a common language between the technical team and the board.

The investment sequence we recommend

CISA does not say which pillar to start with. The order below is our own view, and it rests on one criterion: start where a stolen account could do the most damage.

First, Identity. Every account needs an owner who can be named by role: employee accounts, administrator accounts, service accounts and contractor accounts. High-privilege accounts should use phishing-resistant MFA, and accounts held by outsiders should expire in line with their contracts. This stage usually costs little in tooling and a lot in people's time, because someone has to track down the owners of accounts nobody remembers creating.

The accounts most often left out of the plan are the ones that are not people: service accounts that systems use to call each other, API keys embedded in scripts, and the accounts behind automation tools. These accounts never resign, so they are never closed by the HR cycle. If the organization starts deploying AI agents, this group will grow faster still. Every one of them needs a human owner and a review cycle, the same as an employee account.

Second, Applications and Workloads, plus the most important Data. Pick a small number of systems where a leak or an unauthorized change would hurt the organization most, and route access to those systems through per-request policy checks before anything else. Keeping the scope narrow is what lets results show up within the first budget year.

Third, Devices. Make access to critical systems conditional on the device meeting a baseline, such as an up-to-date operating system and being managed by the organization. This gets considerably harder if staff are allowed to work on personal devices.

Fourth, Networks. Segment the network so that one compromised system does not lead easily to the next. Many organizations want to start here because their teams know network work well. But if identity is still messy, the segments can be crossed with any account that has broad privileges.

Visibility and Analytics has to start in the first stage, not wait until the end. Access logs are the evidence that shows whether each control is actually working.

Legacy systems that cannot support SSO or MFA usually get stuck at the second stage. If the organization is already weighing whether to modernize or replace those systems, this constraint belongs in the rewrite-versus-refactor decision as well.

Report to the board in maturity stages, not a list of tools

The most common progress report is a list of tools purchased and their deployment percentages. That tells the board how much budget has been spent. It does not tell them whether risk has gone down.

The format we recommend is a one-page table with one row per pillar and four columns: the current stage as CISA defines it, this year's target stage, the metric that proves the stage has moved, and the role that owns the pillar.

The metrics should be countable from real systems: the share of high-privilege accounts using phishing-resistant MFA, the number of service accounts with no owner, contractor accounts still active after their contracts ended, and the time it takes to remove access when an employee leaves.

These metrics have one more advantage: the first round of numbers is rarely flattering. A board that sees contractor accounts still open after the contract ended will grasp the reason for the budget faster than it would from an explanation of architecture.

What Zero Trust does not fix

Zero Trust does not close every gap. The same 2026 DBIR found that exploitation of software vulnerabilities has become the most common way in, at 31% of breaches where the initial access vector was known, while the use of stolen credentials, the previous leader, fell to 13%. Verizon says this is the first time in the report's 19 years that the two have swapped places. If an internet-facing system has an unpatched vulnerability, no amount of identity checking closes that hole.

Zero Trust helps with the next step: limiting how far an attacker can move once one system has been breached. So the Zero Trust budget should not be taken from patching and vulnerability management. The two have to run together.

The downside we have to state plainly is that Zero Trust adds friction for users and the IT team in the early period. People authenticate more often, access requests need a justification, and shared accounts have to be split up. If your organization has a small headcount, runs mostly on SaaS and holds no sensitive data, a full Zero Trust program may not be worth it. Our advice in that case is to do the first stage only: give every account an owner, turn on MFA, and set expiry dates for outsiders' accounts. Then expand as the systems grow.

The objection we hear most: "We already have a firewall and a VPN"

There is truth in this. Firewalls and VPNs still do a job, and the organization should not remove them just because a Zero Trust program has started. The team that runs the network every day knows better than anyone what those controls actually stop.

The problem is what happens after someone gets through. A VPN decides once whether someone may join the network, and then usually allows broad access. A contractor account that connects over VPN to maintain one system may be able to see several others. Zero Trust does not replace the existing gate. It adds a check on each individual request, so that an account's access stops at the systems its work requires.

Write the conditions into the TOR from the first new system

A system procured this year will stay with the organization for many years. If identity requirements are not written into the TOR from the start, that system becomes remediation work in next year's Zero Trust plan.

At a minimum, the TOR should require that the system supports the organization's SSO and MFA, can export its access logs for the organization to keep, and that developer accounts are ones the organization creates and can revoke itself. The broader principle, that cloud accounts must stay in the organization's hands, applies to every procurement, not just security ones.

What this article does not cover

This article is about planning and architecture, not legal advice. If your organization is critical information infrastructure, or falls under a sector regulator, the question of whether you have Zero Trust obligations should go directly to the NCSA (Thailand's National Cyber Security Agency) or your regulator. The NCSA published its Zero Trust Guidelines in early February 2026, and the original document is worth reading alongside any plan.

Summary

If you take one thing from this article, ask your team two questions: how many accounts in the organization have no owner today, and how many contractor accounts are still open after their contracts ended? Those two numbers are the starting point of a Zero Trust plan the board can follow, and both can be answered before any tool is bought.

If your organization is planning next year's security work and would like someone to walk through the five pillars against your actual systems, you can read how we work with organizations on our enterprise services page. We are glad to talk, with no deadline attached and no need to decide quickly.

To discuss a project in detail, call us on 088-983-9386 or email [email protected]. Our office is in Bangkapi, Bangkok. If your organization is still drafting the scope of work, we are happy to meet and understand the problem first, without a complete set of documents. And if the conversation shows it is not yet time to build a new system, we will say so plainly, because starting a project at the wrong moment costs more than waiting another quarter.