Making it real: Bringing zero trust to life in your business

In the previous two blog posts, I’ve written about what “zero trust” means from a more prosaic perspective on the actual outcomes organizations are looking to achieve – a reduction in the impact of any compromise, and dynamic, context-based, security fit for the modern world. It’s all a bit abstract though, and perhaps still too funneled through the lens of technology. There’s no point in ivory towers; all of this stuff needs to be deliverable! So, how can organizations go about scoping, developing, and operating this more modern security philosophy?

I’m an architect, so clearly the first thing that I’m going to say is that you need to understand the context within which you are working. Why is that so important? Well, the context will identify the strategies and behaviors of the business, the elements in scope, and the stakeholders, technologies, and business processes that your delivery must support. The other obvious reason for starting with the context is that it’s much easier to get to a destination if you know where you are starting from! So, what kind of areas need exploring?

• Business context – why do your stakeholders want this change to happen? Which parts of the business are in scope? What are the overall business strategies? This latter one isn’t just the often-abstract consideration and alignment; zero trust networking can be particularly helpful in terms of accelerating mergers and acquisitions.
• Scope – are you covering the enterprise as a whole? Does that include your operational technology? Data loss protection? How about your fancy agentic AI? Does that include every geography? Any exceptions?
• Stakeholder context – do you know who the key stakeholders will be? Who will pay for the change? Who will be the executive sponsor who will enforce alignment and ensure the right behaviors throughout the organization? Who will be impacted by the changes being delivered? Who will see the change as a positive and who will see the change as a negative (either personally or organizationally)? What will your communications strategy look like?
• Technology context – can you actually do what you want to do, within the timeframe you want to do it, with what you know of the current and target technology landscapes? What is the overall technology strategy of the organization? Are you cloud-first? Are you best-of-breed or happy to go with single vendor solutions?
• Agree, and enforce, the vision. I can’t stress this one enough. Everyone needs to know the target state and why it is the target state. The vision needs to be owned and supported by someone with enough organizational heft to stop deviations from that agreed vision. You may get folks who are not 100% aligned with the rationale, approach, or vision itself – you need a suitable authority to be available to corral dissenters (alongside offering an opportunity for constructive input). How do you get to an agreed vision? Start with an established framework. I like the CISA framework for zero trust, which shows the scope of zero trust and allows you to place any ongoing initiatives within the relevant parts of the framework. Frameworks provide structure. Structure offers the opportunity to create alignment and reduce duplication.
• Agree on success criteria and the definition of done. How will you demonstrate that the initiative has successfully completed? What metrics will you use to demonstrate progress along the way? What happens next? How do you maintain ongoing alignment with evolving technology?

Okay. So let’s say that we now know who our key stakeholders are, what we want to do, and why we want to do it. We then need to do it. Some thoughts…

• Skills. Know when you need specialist support.
• Track progress. Yes, project management matters. I’m not going to pretend that this is the bit of the job that I most enjoy, but I do recognize that we need to be able to demonstrate progress to stakeholders. (Seeing milestones hit, or backlog items delivered, is also good for team morale. People like to see their efforts having an impact!) Know your critical path and dependencies, work backwards to make sure that what you want to achieve is achievable given wider constraints.
• Communicate. This ties into the above… you spent a lot of time identifying your stakeholder community, and you really need to keep in touch with them. Let them know how the initiative is proceeding. Ask them for help if you need it – senior stakeholders are often keen to help as it justifies the time they are spending meeting with you.
• Delivery methodologies. Pick the right tools for the job – whether project management, architecture frameworks, industry standards, or technology. But don’t be dogmatic and do NOT assume that everyone has the same understanding of what you may think of as standard industry terms. Establish a common taxonomy as part of agreeing on the overall methodologies.
• Respect reality. Requirements may change during the course of an initiative. You may encounter unexpected obstacles, perhaps even insurmountable obstacles, during delivery. I’m not going to go into the basics of change management here, but I do want to stress the importance of recognizing when things move from difficult to (practically) impossible. Don’t risk burning folks out trying to do the impossible.
• Prepare the organization. Look at your target operating model and any necessary changes to roles, responsibilities, and accountabilities. Train your users. You can have the best technology in the world, but if your users don’t know how to use it or, worse, don’t want to use it, then your program as a whole will be a failure. In short, make sure your organization is ready to accept and use the technology capabilities you are delivering.

Much of the above is fairly standard thinking in the transformation and delivery space. However, having spent a few days enjoying some interesting conversations at Zenith Live 2025, it seems that there are still lots of organizations out there that are struggling to get the most out of the technology capabilities that they have available to them. Some of the folks I was chatting with were still struggling to get alignment and consequently experiencing duplication across their organizations, often due to a lack of executive sponsorship. Others were still struggling to sell the benefits of moving towards modern security approaches due to lack of an overall vision. Some had more technology-focused concerns around integration, which I suspect a comprehensive architectural approach could help to address. I’d like to think that our conversations helped, and the fact that some took photos of the slides that I was chatting them through indicated at least some of them saw value in the approaches discussed above.

And this brings this short series of blogs to an end. My aim was to discuss “zero trust” in more practical, business-focused terms, and to show folks how they can do this stuff in the real world. Please do let me know whether or not I succeeded.

You can access blog one here, and blog two here.