Blog Series: Zero Trust — From Concept to Board Room
Post 4 of 4
A Practical Guide for InfoSec Professionals, Aspiring CISOs, and New Security Leaders
We have covered a lot of ground in this series. We started with the business case and the executive conversation. We went deep on the five pillars and what each one actually demands from your architecture. And in the last post we worked through how to use CISA’s maturity model to assess your current state honestly, identify your most consequential gaps, and define a target state that reflects your organization’s actual risk profile.
Now we build the roadmap. And we execute it.
This is where the work becomes real. Everything in the first three posts was preparation for this moment — the moment you have to translate a framework, an assessment, and a set of targets into a concrete plan with timelines, owners, dependencies, milestones, and a narrative that leadership will fund and support over a multi-year horizon. That translation is harder than most security leaders expect, and it is where more zero trust programs stall than at any earlier stage.
I am going to walk you through how to build a zero trust roadmap that is credible, executable, and sustainable — one that your team can actually deliver and your leadership will actually support. And I will share the execution discipline that separates programs that move from programs that drift.
ABOUT THIS SERIES
- Post 1: Zero Trust 101 — What It Is, Why It Matters, and How to Win Executive Support
- Post 2: The Five Pillars — Identity, Devices, Networks, Applications, and Data
- Post 3: The Maturity Model — Assessing Where You Are and Planning Where You Need to Go
- Post 4: Building and Executing Your Zero Trust Roadmap (you’re here)
What a Zero Trust Roadmap Actually Is
Let me start by being clear about what a zero trust roadmap is not. It is not a list of tools you plan to buy. It is not a vendor evaluation schedule. It is not a Gantt chart of infrastructure projects. And it is not a compliance checklist with target completion dates. I have seen all of those documents labeled as zero trust roadmaps, and none of them produced the outcomes organizations were hoping for.
A zero trust roadmap is a sequenced plan for moving your organization from its current maturity state to a defined target state across the five pillars and three cross-cutting capabilities — organized by risk priority, constrained by operational and financial reality, and expressed in terms that connect security outcomes to business objectives. It answers four questions: Where are we now? Where do we need to be? How do we get there in what sequence? And how will we know when we have arrived?
The roadmap needs to be realistic enough to actually execute, ambitious enough to materially reduce risk, and flexible enough to adapt as the environment changes. Those are difficult things to balance, and getting the balance right requires discipline in both the planning and the execution phases. The sections that follow walk through how to achieve that balance in practice.
Step One: Prioritize Your Gaps by Risk
Your maturity assessment gave you a complete picture of where each pillar and each cross-cutting capability stands today. You likely identified a significant number of gaps between your current state and your target state. The roadmap cannot address all of them simultaneously — and even if it could, doing so would be the wrong approach. The first step in building the roadmap is deciding which gaps to close first, and that decision has to be driven by risk.
Not every gap is created equal. A gap in phishing-resistant MFA adoption across privileged accounts represents a materially higher risk exposure than a gap in cryptographic agility for internal traffic. A flat network architecture that enables unrestricted lateral movement between your most sensitive workloads is a different order of severity than incomplete device compliance monitoring for conference room endpoints. The gaps that belong at the top of your roadmap are the ones that, if exploited, would cause the most significant harm to the organization — and that are most likely to be exploited given your specific threat environment.
I use a simple but effective prioritization framework when building roadmaps. For each gap, I evaluate three dimensions: the risk impact if the gap is exploited, the likelihood of exploitation given current threat intelligence, and the feasibility of closing the gap within a reasonable timeframe given available resources. Gaps that score high on all three dimensions are your immediate priorities. High-impact, high-likelihood gaps that are complex to close still need to be in your near-term roadmap even if they require more extended timelines — but they cannot wait for the complex ones to be sequenced later. High-feasibility, lower-impact gaps should not be prioritized over higher-impact work just because they are easier to accomplish.
One additional prioritization consideration that is specific to zero trust: the dependency structure of the architecture. Some capabilities are foundational to others in a way that makes sequencing non-negotiable. You cannot implement meaningful device-context-aware access decisions without a solid identity foundation. You cannot enforce micro-segmentation policies based on application profiles without first building those profiles. You cannot operate effective data loss prevention without data classification. These dependencies define a logical sequence that your risk prioritization has to respect even when it is tempting to jump ahead to more visible or more interesting work.
Step Two: Structure the Roadmap into Phases
A zero trust roadmap that attempts to do everything at once does nothing well. The work needs to be organized into phases that are cohesive, achievable, and that build meaningfully on one another. Three phases over a three-year horizon is the structure I find most effective for most organizations, though the specific timing and scope of each phase should reflect your starting maturity and available resources.
Phase One: Foundation (Months 1–12)
The first phase is about closing your most critical gaps and establishing the foundational capabilities that everything else depends on. For most organizations, this means deploying phishing-resistant MFA across all users and privileged accounts, establishing a comprehensive and continuously updated device inventory, initiating network segmentation for your highest-risk workloads, and launching data discovery and classification for your most sensitive data categories. It also means standing up the Visibility and Analytics infrastructure — the centralized log aggregation, correlation, and monitoring capabilities that will produce the signals every other pillar needs to function.
The goal of Phase One is not to reach Advanced maturity in any pillar. It is to move every pillar from Traditional to Initial, close the gaps that represent your most immediate risk exposure, and build the foundational infrastructure that Advanced and Optimal capabilities will depend on. Phase One should produce measurable, defensible risk reduction that you can demonstrate to leadership — not just a list of completed projects, but a documented comparison of your before-and-after exposure in the areas you addressed.
Phase One is also when you establish the governance structures, program management cadences, and cross-functional working relationships that will sustain the program over the full three-year horizon. Zero trust is not a security team project. It requires active participation from identity and access management, networking, application development, data governance, and operations. Building those working relationships and governance structures in Phase One prevents the collaboration breakdowns that typically cause programs to stall in Phase Two.
Phase Two: Integration (Months 13–24)
Phase Two is where zero trust starts to function as an architecture rather than a collection of individual controls. The investments from Phase One are now producing data and signals. Phase Two is about connecting those signals — building the cross-pillar integrations that allow identity risk scores to inform device access decisions, device compliance status to inform application access policies, and network anomalies to trigger automated response workflows. This is the phase where the cross-cutting capabilities — Visibility and Analytics, Automation and Orchestration, and Governance — begin to operate at meaningful scale.
Specific workstreams in Phase Two typically include expanding micro-segmentation from critical workloads to broader network architecture, deploying automated device compliance enforcement across the full device fleet, integrating application access controls with identity and device context, expanding data access controls from your highest-sensitivity data to a broader classification tier, and building the automated orchestration workflows that remove manual intervention from routine security operations. You are moving from Initial toward Advanced across multiple pillars simultaneously.
Phase Two is also when the organizational friction tends to peak. The controls you are deploying are more disruptive to existing workflows than Phase One controls. Users notice micro-segmentation when it breaks an application they depend on. Developers notice access controls when they prevent them from doing something they have always been able to do. Operations teams notice automated remediation when it isolates a device they were actively working on. Managing this friction requires proactive communication, transparent change management, and a feedback loop that allows issues to surface and be resolved quickly without derailing the program.
Phase Three: Optimization (Months 25–36)
Phase Three is about pushing the architecture toward the Advanced maturity target you defined in your assessment, hardening the integrations built in Phase Two, and building the continuous improvement mechanisms that will sustain and evolve the program beyond the initial three-year horizon. This phase typically includes completing enterprise-wide deployment of capabilities that were partially deployed in earlier phases, implementing advanced analytics and behavioral detection capabilities in the Visibility and Analytics function, hardening automated orchestration to handle a broader range of threat scenarios without human intervention, and establishing the ongoing governance and policy review cadences that prevent the architecture from drifting back toward implicit trust through organizational entropy.
By the end of Phase Three, you should have a zero trust architecture that is demonstrably more mature than where you started, with documented, measurable improvements in risk posture across the pillars and cross-cutting capabilities. You should also have the program management infrastructure, the cross-functional working relationships, and the executive reporting cadence in place to sustain progress into a second roadmap cycle that targets further maturity advancement.
Step Three: Define Milestones and Metrics
A roadmap without milestones is a wish list. A roadmap without metrics is a narrative. You need both to manage execution and to demonstrate progress to leadership. Building them into the roadmap from the start — not adding them after the fact — is what separates programs that can account for their progress from programs that cannot.
Milestones should be specific, binary, and time-bound. Not “improve MFA adoption” but “phishing-resistant MFA deployed to 100% of privileged accounts by end of Q2.” Not “advance network segmentation” but “micro-segmentation perimeters implemented for all Tier 1 workloads by end of Q3.” The more specific the milestone, the easier it is to determine whether it has been achieved and to diagnose why it has not been achieved when execution falls behind. Vague milestones produce vague accountability, which produces drift.
Metrics should measure outcomes, not activities. The number of MFA deployments completed is an activity metric. The percentage of authentication events using phishing-resistant MFA is an outcome metric. The number of network segmentation projects initiated is an activity metric. The percentage of east-west traffic subject to explicit policy enforcement is an outcome metric. Outcome metrics are harder to game and more directly connected to the security posture improvements your roadmap is designed to achieve. When you report to leadership, lead with outcome metrics. Activity metrics belong in program management dashboards, not executive presentations.
Step Four: Secure the Investment
The most technically sound roadmap in the world is worthless if it is not funded. Securing the investment is not a one-time event at the start of the program. It is an ongoing responsibility that requires sustained executive engagement, consistent progress reporting, and a narrative that keeps the business case alive and compelling throughout the multi-year execution horizon.
When you bring the roadmap to leadership for initial funding approval, organize the investment ask around risk reduction outcomes rather than technology categories. Do not ask for a budget for “identity and access management improvements” and “network segmentation projects.” Ask for a budget to reduce your organization’s exposure to credential-based attacks by a defined percentage, to eliminate lateral movement capability from your most sensitive workload environments, and to achieve compliance with specific regulatory requirements that currently represent audit findings. Connect every dollar to a risk outcome that leadership cares about.
Phasing the investment request also matters. A multi-year program with a single large upfront ask is a harder conversation than a phased program where Phase One delivers measurable risk reduction and uses that demonstrated value to justify Phase Two funding. When you structure the ask this way, you are also building accountability into the investment model: leadership funds Phase One, Phase One delivers results, and those results justify Phase Two. Each phase has to earn the next phase. That structure disciplines execution and builds executive confidence in the program’s ability to deliver.
Step Five: Execute with Discipline
This is the part that most roadmap guides skip over, and it is the part that matters most. Building a great roadmap is a planning exercise. Executing it is a management challenge that requires sustained attention to a set of disciplines that do not come naturally to most security teams.
Assign Clear Ownership
Every initiative in your roadmap needs a named owner who is accountable for delivering it. Not a team, not a department — a specific individual who will stand up in your program review meeting and account for progress. Ownership without accountability produces the same outcome as no ownership at all. The program manager can track status, but the initiative owner has to be responsible for driving execution, removing blockers, and escalating when something is preventing progress. This is especially important for initiatives that span multiple teams, because without a named owner, cross-functional work defaults to the slowest stakeholder.
Maintain a Regular Program Cadence
Zero trust programs that do not have a structured review cadence lose momentum. What gets scheduled gets done. What does not get scheduled gets deferred indefinitely when competing priorities arrive — and competing priorities always arrive. Build a monthly program review into the calendar from day one. Review milestone status, escalate blockers, adjust timelines when necessary with documented rationale, and update the risk-reduction metrics that demonstrate progress. Quarterly, present a condensed version of that progress to your executive sponsor. Annually, update the full maturity assessment and use it to refine the roadmap for the coming year.
Manage Scope Ruthlessly
Zero trust programs attract scope creep the way any high-visibility security initiative does. Every new threat, every audit finding, every vendor briefing produces a suggestion that “we should add this to the zero trust program.” Some of those suggestions are legitimate. Most are distractions. The program manager and the CISO need to actively protect the roadmap from additions that dilute focus without meaningfully advancing the program’s objectives. When a proposed addition does not directly advance maturity in one of the five pillars or three cross-cutting capabilities, it belongs in a separate workstream — not in the zero trust roadmap.
Adapt Without Drifting
Roadmaps are not contracts. The threat landscape changes. Technology evolves. Organizational priorities shift. A roadmap that cannot adapt is a roadmap that will eventually be abandoned when reality diverges too far from the plan. Build explicit review points into your roadmap — at least annually — where you formally assess whether the priorities, sequencing, and targets still reflect the current environment. When you make changes, document them with the rationale. What you want to avoid is the quiet drift where the roadmap is technically still the plan but nobody is actually following it because informal workarounds have accumulated to the point where the formal document is no longer meaningful.
The Board Room Conversation at the End of Year One
This series started with the executive conversation — how to get leadership to understand zero trust and commit to funding it. I want to end with a different executive conversation: the one you will have twelve months into execution, when your board or your CEO asks whether the investment is paying off.
That conversation will go one of two ways. If you built your roadmap with outcome metrics and documented your baseline before you started, you will walk into the room with a clear before-and-after story: the specific risks that existed twelve months ago that no longer exist today, the maturity improvements across each pillar, the incidents that your controls detected or prevented, and the regulatory requirements you are now positioned to meet. That is a conversation that justifies continued investment and builds executive confidence in the program.
If you built your roadmap as a project list and measured your progress in activities completed, you will walk into the room with a status report. Projects completed, budget spent, next phase beginning. That conversation produces a different kind of question: what exactly did we get for this investment? And that is a question that is very hard to answer well after the fact.
The difference between those two conversations is not the quality of the technical work. It is the quality of the planning and measurement discipline that surrounded the technical work. Zero trust is a significant, multi-year investment. The organizations that sustain that investment and drive it to meaningful completion are the ones that treat the program management and executive communication with the same rigor they bring to the architecture itself.
You now have the framework, the assessment methodology, the architectural understanding, and the roadmap structure to do exactly that. The rest is execution.
I have watched organizations spend years talking about zero trust and organizations that spent those same years actually building it. The difference was rarely resources, and it was almost never technical capability. It was commitment — the organizational will to treat this as a strategic program rather than a security project, to sustain the investment through the friction and the setbacks and the competing priorities that every multi-year program encounters, and to hold themselves accountable to outcomes rather than activities. Zero trust is not a destination you arrive at and declare victory. It is a continuously advancing security posture that requires ongoing investment, ongoing adaptation, and ongoing leadership attention. But the organizations that build it — that actually put in the work across all five pillars and all three cross-cutting capabilities — end up with something that perimeter-centric security can never deliver: a posture that assumes breach, limits blast radius, and continuously verifies every access decision against the full context of the environment. That is worth building. Get started.
You have reached the end of the Zero Trust — From Concept to Board Room series. To revisit any post, use the links below.
→ Post 1: Zero Trust 101 — What It Is, Why It Matters, and How to Win Executive Support
→ Post 2: The Five Pillars — Identity, Devices, Networks, Applications, and Data
→ Post 3: The Maturity Model — Assessing Where You Are and Planning Where You Need to Go
→ Post 4: Building and Executing Your Zero Trust Roadmap (you’re here)