Zero Trust Architecture: What CISM Holders Need to Know About Governance

What Zero Trust Actually Means (and Why Governance Owns It)

The term "zero trust" is older than most of its current marketing, tracing back to Forrester's early research on de-perimeterization and formalized by NIST in Special Publication 800-207, Zero Trust Architecture. The core idea is simple to state and hard to operationalize: no user, device, or workload should be trusted by default based on network location alone. Every access request is evaluated on its own merits, continuously, using identity, device posture, and context.

CISA's Zero Trust Maturity Model breaks the concept into five pillars: Identity, Devices, Networks, Applications and Workloads, and Data, cutting across cross-pillar capabilities like visibility and automation. That framing matters for security managers because it makes an important point explicit: zero trust is not a single product category. It is an operating model that touches identity governance, device management, network segmentation, application access, and data classification simultaneously.

That breadth is exactly why governance has to own it. A vendor can sell you a zero trust network access (ZTNA) appliance, but no vendor can tell your organization what "least privilege" should mean for a third-party contractor accessing a finance system, or how long a session should remain authenticated before re-verification is required. Those are policy decisions, and policy decisions are governance work.

From NIST 800-207 to Board Policy: The Governance Translation Layer

NIST 800-207 is written for architects. A CISM-minded security manager's job is to translate it into something a policy committee and a board can actually approve. That translation layer typically has three parts:

1. Policy, not architecture diagrams

The architecture (policy decision points, policy enforcement points, continuous diagnostics) belongs to engineering. The policy itself, who can access what, under what conditions, with what level of assurance, belongs to governance. A zero trust initiative that starts in the network team and never produces an access policy document has built infrastructure without governance.

2. A phased roadmap tied to risk, not a product list

CISA's maturity model defines stages from Traditional through Initial, Advanced, and Optimal. Mapping your organization's current state against those stages, by pillar, gives the board a defensible, risk-based roadmap instead of a shopping list. This is the same governance discipline CISM candidates study under COBIT and NIST CSF: pick the framework, map current state, prioritize gaps by risk, fund accordingly.

3. Explicit ownership

Zero trust initiatives routinely stall because no single role owns the cross-pillar decisions. Identity governance may sit with IAM, device posture with endpoint engineering, network segmentation with infrastructure, and data classification with the data governance function. Without a named accountable owner, usually the CISO or a delegated security governance committee, these teams optimize locally and the organization never gets a coherent trust model.

Where Zero Trust Shows Up Across the CISM Domains

Zero trust is not a named topic in any single CISM domain, but its underlying concepts appear throughout the current CISM Body of Knowledge, and increasingly in the AI governance content ISACA added in its November 2026 update, since AI agents and automated workflows are themselves identities that need zero trust treatment. See our CISM AI governance update guide for how that overlaps.

Candidates preparing for the exam should not expect a question that says "zero trust" verbatim. They should expect scenario questions about access control philosophy, segmentation, and risk-based authentication, where the "ISACA preferred answer" rewards governance-first thinking over a purely technical fix.

Building the Governance Structure Around a Zero Trust Program

A zero trust initiative needs the same governance scaffolding as any other major security program: a charter, a sponsor, and a decision-making body. If your organization already runs a security governance committee (see our guide on structuring a security governance committee), zero trust should be a standing agenda item, not a separate shadow structure.

Practically, that means:

• A written access philosophy approved at the steering committee level, stating that access is granted based on verified identity and context, not network location, and defining the conditions under which exceptions are permitted.
• A RACI for the five pillars (identity, devices, network, applications, data) so that when a cross-pillar decision is needed, such as how long a privileged session can stay authenticated, there is a clear accountable owner rather than an informal negotiation between teams.
• A phased funding model tied to the CISA maturity stages, so the board approves a multi-year roadmap rather than a single large capital request with no interim milestones.
• Change management built in from day one. Zero trust increases authentication friction for end users almost by design. A governance body that doesn't plan for help desk volume and user communication will see shadow IT and workaround behavior spike.

Risk Management Implications: Revisiting Risk Appetite Under Zero Trust

Removing implicit trust changes the organization's actual risk posture, which means the risk register and risk appetite statement need to be revisited, not just the control set. If your organization has a formal risk appetite statement, a zero trust rollout is a reasonable trigger for a scheduled review: continuous verification may justify a higher appetite for remote and contractor access that was previously restricted purely because the network perimeter couldn't support it safely.

The same logic applies to key risk indicators. Metrics that made sense under a perimeter model, like VPN concurrent session counts or firewall rule counts, stop being meaningful risk signals. CISM-minded risk functions should retire those and introduce indicators that actually reflect zero trust maturity, such as the percentage of access decisions made with device posture context, or the percentage of privileged sessions subject to continuous re-authentication. Our Key Risk Indicators guide covers how to select and threshold indicators like these so they drive escalation rather than just populating a dashboard.

Zero Trust and Third-Party Risk

Third parties are usually the weakest link in a traditional trust model, since they often receive broad network access for convenience. Zero trust principles apply with particular force here: a contractor or SaaS integration should receive access scoped to a specific application and function, time-bound, and continuously verified, never a flat VPN tunnel into the corporate network.

This is squarely Domain 2 and Domain 3 territory, and it intersects directly with vendor risk management practice. If your organization already runs a mature third-party risk program, extending zero trust principles into vendor access reviews, contract language around access scope, and ongoing monitoring is a natural next step. See our third-party and vendor risk management guide for the full lifecycle this fits into.

Metrics and Reporting: Proving Zero Trust Governance to the Board

Boards fund what they can see progress on. A multi-year zero trust program needs a small set of metrics that show movement without drowning executives in architecture detail. Based on the CISA maturity model and common practice among governance-mature programs, useful board-level metrics include:

• Maturity stage by pillar (Traditional, Initial, Advanced, Optimal), tracked quarterly against the approved roadmap.
• Percentage of applications behind identity-aware access controls versus still relying on network-level trust.
• Mean time to revoke access for a departed employee or contractor, a number that should shrink meaningfully as identity governance matures.
• Reduction in lateral movement paths, often demonstrated through periodic segmentation testing rather than a single number.

Avoid reporting raw technical counts (number of policies written, number of devices onboarded to an MDM) as if they were outcomes. They are activity metrics, not risk metrics, and a board that has seen a security dashboard before will notice the difference. Our security metrics dashboard guide covers this distinction in more depth.

Common Governance Pitfalls to Avoid

1. Letting the initiative live entirely in IT infrastructure. Without a governance sponsor, zero trust becomes a never-ending engineering project with no business risk narrative attached, and it is usually the first thing cut in a budget tightening cycle.
2. Treating it as a single project with an end date. Zero trust is an operating model, not a deliverable. Governance structures should plan for it as a permanent capability with ongoing investment, similar to how vulnerability management or security awareness training is funded.
3. Skipping the risk appetite conversation. Teams sometimes implement stricter controls everywhere, assuming "more zero trust" is always better, without checking whether the business is willing to accept the added friction in lower-risk areas. Governance should calibrate control intensity to actual risk, not apply it uniformly.
4. No plan for legacy systems that cannot support modern authentication. Nearly every organization has some set of systems too old to support continuous verification. Governance needs to formally accept, document, and compensate for that residual risk rather than letting it sit undocumented.

Frequently Asked Questions

Is zero trust a CISM exam topic?

There is no dedicated zero trust domain or objective in the current CISM Body of Knowledge, but its underlying concepts, access control philosophy, least privilege, segmentation, and continuous risk-based authentication, appear throughout Domains 1 through 4. Scenario questions about access control decisions reward governance-first thinking consistent with zero trust principles.

Who should own a zero trust program: security or IT?

Architecture and implementation are typically IT and engineering responsibilities, but policy ownership, the decisions about who gets access to what under which conditions, belongs to security governance, usually the CISO or a delegated security steering committee. Programs that let IT own both architecture and policy tend to optimize for operational convenience over risk management.

How long does a zero trust rollout take?

Most organizations should plan in years, not months. CISA's maturity model assumes a multi-stage progression (Traditional to Initial to Advanced to Optimal) across five pillars, and few organizations move every pillar at the same pace. A realistic governance roadmap phases investment over 3 to 5 years, prioritized by where the organization's actual risk is highest.

Does zero trust eliminate the need for a traditional risk register?

No. Zero trust changes what belongs on the risk register and how some existing risks should be scored, since removing implicit network trust reduces certain lateral movement and credential-theft risks. It does not eliminate the need for a risk register, a risk appetite statement, or ongoing key risk indicator monitoring; it changes their inputs.

What's the single biggest governance mistake organizations make with zero trust?

Scoping it down to a network access technology swap and declaring it done. Genuine zero trust governance requires decisions across identity, device trust, application access, and data classification, and a security manager who lets the conversation stop at "we bought ZTNA" has left most of the actual risk reduction on the table.

Related Guides