Zero Trust Architecture: Where to Start

When I started learning about Zero Trust Architecture, the concept made sense in theory, but it felt distant. Verify everything and trust nothing by default. Cool, but what does that actually look like when you're evaluating a real environment?

After wrapping up the SQL injection project on my bookshop application, I took the same environment and ran a Zero Trust gap analysis to see where trust was assumed instead of earned. It gave me a chance to study the system’s design with fresh eyes and pinpoint the places where access flowed a little too freely.

Why Gap Analysis is Where You Start

Zero Trust is built on the idea that nothing gets trusted by default. Every identity, device, and connection has something to prove before gaining access. That sounds straightforward, but then you need to apply it to an actual environment and know where your current trust assumptions are located.

That's what gap analysis does. It forces you to examine your environment and identify where you're trusting things without verifying them. You begin to consider the flows where identities are getting access they shouldn't have. Then you move on to find the devices that connect without proving they're secure and what applications are running with excessive permissions. There are a number of questions you can come up with when scrutinizing the lax trust that exists in your environment.

When I analyzed my bookshop environment, I started finding gaps immediately. For example, the network had no segmentation, meaning that everything could talk to everything else. Because controls and policies were missing, BYOD devices could access company resources without any compliance checks. And if you’ve read the article, SQL Injection: What’s On Top and Under the Hood, you must know that the database service account had way more permissions than it needed.

Each of these gaps represents a place where the environment trusts something by default instead of verifying it first. That's what you're looking for when you’re doing a gap analysis; your focus is to find the difference between Zero Trust principles and your current environment’s reality, then bridge the gap.

What You're Actually Analyzing

A proper gap analysis looks at several key areas, including identity and access management, network architecture, endpoint security, etc.

Application security is quite critical here as well. You should know how your applications authenticate users and what permissions they require to run. The bookshop app had SQL injection vulnerabilities, but beyond that, it also had application accounts with excessive database permissions and no input validation anywhere.

Data protection is another important area to analyze. For example, how is sensitive information stored? How does it move through the environment? Who can access it? What prevents unauthorized access or exfiltration? In my analysis of the environment, I found that payment card data was stored unencrypted with CVV numbers that should never be kept. Also, user passwords were stored in the database without hashing algorithms applied.

Where Compliance Frameworks Come In

What really tied everything together for me was mapping these gaps to actual compliance frameworks. When I started connecting findings to ISO 27001 controls, PCI DSS requirements, and NIST guidelines, the gaps became concrete business risks with regulatory implications.

For example, that unencrypted payment card data is a direct PCI DSS violation. Another compliance mapping was network segmentation which is required by ISO 27001. There were many other violations found, but these are just a few.

The theoretical understanding I had started connecting with this practical experience. Compliance frameworks provide structure for evaluating what's actually wrong and why it matters from a business perspective. It's not just "this seems like bad security practice." It's actually more like, "this violates specific requirements and creates quantifiable risk."

When you document findings this way, you can tie them to potential consequences like data breaches, regulatory fines, incident response costs, and reputation damage. This also helps you prioritize gaps to find which ones create the most significant business risk. And when you generate a report for stakeholders with findings linked to compliance frameworks, reducing or eliminating these gaps increases in importance.

Revelations About Starting Zero Trust

Running this gap analysis taught me that Zero Trust implementation is a complex and focused principle that starts with understanding where your environment trusts things it shouldn't.

My bookshop environment had gaps across every category I analyzed. That was expected because the environment was made intentionally vulnerable, however, certain gaps could’ve been easily tied to real companies.

Starting with a gap analysis allows you to be more strategic about where to focus your efforts. Finding which gaps pose the highest risk, which violate compliance requirements, and which would be easiest to remediate versus the ones requiring significant architectural changes gives you a clear hierarchy for mitigation efforts.

In my environment, the missing database permissions and lack of input validation were high-priority because they directly enabled SQL injection attacks that I could easily exploit. The missing network segmentation was critical because it would allow lateral movement after any compromise, and the unencrypted payment data was urgent due to PCI DSS violations.

That prioritization comes from the gap analysis process. You can't start implementing Zero Trust effectively if you don't know where your most detrimental trust assumptions exist. The analysis gives you a roadmap that points out where your gaps are, the risks they create, the business impact, and the frameworks they violate. These revelations will help you define objectives and identify an appropriate starting point on the path to designing a zero trust architecture.

If you're trying to understand Zero Trust Architecture for career purposes or as a learning experience, start by analyzing an environment (a test environment is okay) to see where the gaps are. It makes a lot more sense once you've identified real trust relationships and mapped them to consequences.