Zero Trust Foundations: Using AAVI to Build Functional Zero Trust in Existing Environments

How Assess, Adapt, Verify, and Iterate help turn one messy protect surface into practical, cooperative, real-time Zero Trust.

Summary: This week introduces the AAVI model: Assess, Adapt, Verify, and Iterate. We will use it to move existing environments toward functional Zero Trust one protect surface at a time. The first passes will be messy, and that is normal. The goal is not perfection. The goal is to learn, prove, improve, and keep reducing implied trust with every iteration.

Grab a fresh cup of coffee and let’s keep moving. This is where the series shifts from concepts to operating discipline. Over the last few posts, we picked a realistic protect surface, looked at the Five Pillars, and then talked about the cross functions that keep those pillars visible, consistent, and governed. Now we need a repeatable way to turn all of that into practical work.

The model I use is AAVI: Assess, Adapt, Verify, and Iterate. It is not a magic formula, and it is not a vendor roadmap. It is a disciplined way to examine how trust is granted today, modify what we can, prove the changes work, and then keep improving one protect surface at a time.

That matters because most organizations are not starting from a clean sheet of paper. We are adapting environments that already exist. We have legacy applications, inherited network paths, old permission models, service accounts, partial telemetry, manual processes, and business workflows that were not designed with Zero Trust in mind. AAVI gives us a way to make progress without pretending the mess does not exist.

In practical terms, implementation happens inside Adapt and Verify. We adapt the environment by making prudent changes, then verify those changes with evidence. Iterate keeps implementation from becoming a one-time project. It reminds us that every improvement becomes the starting point for the next pass.

AAVI at a Glance

Step	Purpose	Practical output
Assess	Understand the protect surface, capabilities, dependencies, and normal behavior.	Inventory, transaction list, ownership map, behavior baseline, and known assumptions.
Adapt	Modify existing practices and controls to make trust more specific.	Policy changes, narrowed access, improved logging, reduced standing privilege, and documented exceptions.
Verify	Prove the changes work consistently and continue to work over time.	Repeatable metrics, reports, scans, test results, alert validation, and drift monitoring.
Iterate	Use what was learned to keep reducing implied trust across this and future protect surfaces.	Next-priority backlog, lessons learned, improved patterns, and faster future evaluations.

Use this table as the quick map. The rest of the post slows each step down and applies it to our model protect surface.

Our Model Protect Surface

For this walkthrough, we will continue using the messy hybrid business application we selected earlier in the series. Think of a departmental business application used by finance, operations, and customer support. The core application still runs on-premises and uses a legacy database in the data center. Users authenticate through the corporate identity platform, but the application still carries older permission models. Reports are exported to a SaaS analytics platform. Files are occasionally dropped into cloud storage for collaboration. A small set of administrators manage the application through internal tools, while a vendor occasionally needs access for support.

That protect surface is messy on purpose. It has users, service accounts, administrators, vendor access, on-premises infrastructure, SaaS integration, exported data, legacy assumptions, and operational dependencies. It is not the worst system in the company, but it is not clean either. That is what makes it useful. It gives us enough complexity to examine multiple Zero Trust capabilities without trying to redesign the entire enterprise at once.

Start With the Transactions

Before we change controls, we need to define the transactions that matter to this protect surface. A transaction is any meaningful action or communication that touches the application, the data, or the services that support them. For this example, the initial list might include users signing in, users viewing records, users exporting reports, service accounts moving data between the application and the SaaS analytics platform, administrators changing configuration, vendors connecting for support, and files being copied to cloud storage for collaboration.

Each transaction needs to be evaluated across every Zero Trust pillar and every cross function. Identity, Device, Network, Application, and Data each tell part of the story. Visibility and Analytics, Automation and Orchestration, and Governance help us prove, implement, and sustain the decision. The point is not to ask whether each pillar has a tool. The point is to ask how each pillar and cross function contributes to the trust decision both individually and collectively.

For example, a user exporting a report is not only an identity question. Identity tells us who the user is and whether the role allows the export. Device tells us whether the request is coming from a managed and healthy endpoint. Network tells us whether the path is expected and constrained. Application tells us whether export is a normal action for that user and workflow. Data tells us whether the report contains sensitive information that should limit or change the action. Visibility proves the decision happened. Automation helps implement the control consistently. Governance decides whether the policy still matches the business risk.

That is the cooperative nature of Zero Trust. No pillar wins alone. No cross function saves the day by itself. The architecture becomes useful when these signals and controls work together in real time and adapt as circumstances change.

Transaction	Primary risk	Pillars involved	Verification evidence
User exports a report	Sensitive data leaves the application without enough context or control.	Identity, Device, Network, Application, Data	Export logs, policy decision records, device posture, data label, approval or challenge result.
Vendor connects for support	Third-party access becomes broader or longer-lived than needed.	Identity, Device, Network, Application	Named account, time-bound access, session logs, approved path, ticket or change record.
Service account moves data to SaaS analytics	Non-human identity has excessive permissions or unmonitored data movement.	Identity, Network, Application, Data	Service account owner, scoped permissions, transfer logs, destination validation, anomaly monitoring.
Administrator changes configuration	Privileged action occurs without strong proof, approval, or accountability.	Identity, Device, Network, Application	Privileged access record, MFA or step-up result, admin workstation posture, change log, rollback evidence.

The table is not meant to be complete. It is meant to show the kind of thinking we want before we start changing controls: define the action, name the risk, involve the pillars, and decide what evidence would prove the decision worked.

AAVI Step One: Assess

Assess is where we inventory resources, capabilities, dependencies, behaviors, and assumptions. We identify the data, applications, assets, services, identities, devices, workloads, network paths, integrations, administrative tools, vendor processes, logs, policies, and owners that support the protect surface.

Assessment is also where we determine what normal looks like. Who normally uses the application? Which devices are expected? What reports are commonly exported? Which service accounts move data? When do administrators make changes? How often does the vendor connect? Where should files be stored? What behaviors are expected, and what behaviors are unusual enough to deserve a different decision?

This part can feel slow, but it is where the real Zero Trust work begins. If we do not understand the protect surface, we cannot define good trust decisions. If we do not know what normal looks like, we cannot recognize abnormal. If we do not know which controls already exist, we cannot decide whether to adapt, replace, or add anything.

AAVI Step Two: Adapt

Adapt is where we modify and repurpose what we learned during assessment. We use the tools, processes, policies, and capabilities already available to make the trust decision more specific. That may mean tightening access groups, requiring stronger authentication for high-impact actions, narrowing network paths, improving logging, reducing standing administrative access, changing export behavior, adding expiration to exceptions, or documenting ownership where it was missing.

This is also where we need to be careful about complexity. Adding new capabilities can be the right decision, but it also adds complexity at the exact moment we are trying to simplify and understand the environment. I am not saying do not implement new tools. That decision belongs to you and your organization. I am saying that if you do, do it with open eyes. New tools may solve real gaps, but they also add integrations, ownership questions, training needs, configuration risk, operational dependencies, and new telemetry to validate.

Adaptation should be prudent. Use what you have first where it makes sense. Change the controls closest to the transaction. Make one decision better, then the next, then the next. The goal is not the most impressive architecture diagram. The goal is to reduce implied trust around the protect surface in ways the organization can operate and prove.

AAVI Step Three: Verify

Verify is probably the most important part of AAVI. This is where we prove that the changes we made actually work and that they work consistently. It is not enough to say the policy exists. It is not enough to say the control was enabled. We need repeatable evidence that the intended decision is being made and enforced.

If we cannot prove it, we CANNOT rely on it.

That proof can take many forms: metrics, reports, configuration scans, access reviews, policy evaluation logs, test transactions, alert validation, tabletop exercises, red team findings, control drift reports, and operational dashboards. Wherever possible, verification should run continuously. A one-time test tells us what was true at the moment of the test. Continuous verification helps us identify drift before drift becomes the new normal.

For our protect surface, verification might prove that privileged access expires, that vendor connections are logged and limited, that sensitive exports trigger the expected policy, that unmanaged devices cannot reach the same functions as managed devices, that service accounts are scoped and monitored, and that exceptions have owners and expiration dates. If we cannot prove the control works, we should not count it as part of the architecture yet.

AAVI Step Four: Iterate

Iteration is where Zero Trust implementations live. Zero Trust is never done. As soon as we make one improvement, we start looking for the next one, and then the next. That is not a flaw in the model. That is the model.

Each iteration should make the infrastructure more resilient and better able to respond to modern attack techniques. Maybe the first pass removes broad vendor access. The next pass improves service account governance. The next pass tightens data exports. The next pass improves device posture enforcement. The next pass moves a manual control into a repeatable pipeline. Each improvement reduces the amount of trust we are giving away for free.

The good news is that each protect surface gets easier and faster. Not easy, but easier. We will have already identified and fixed many common issues along the way. We will have better questions, better patterns, better measurements, and better habits. More importantly, the organization will become better at looking at systems through a Zero Trust lens.

The First Few Protect Surfaces Will Be Ugly

Let me say this clearly: the first few protect surfaces will probably be ugly. You are going to find implicit trust in places nobody expected. You are going to find broad access, weak assumptions, shared accounts, old rules, missing logs, unowned exceptions, forgotten service accounts, incomplete inventories, and business processes that depend on trust nobody wants to admit is still there.

You will also find things you cannot fix immediately. Sometimes the technology is not capable of enforcing the decision we want. Sometimes the application is too old. Sometimes the business process is too fragile. Sometimes the control exists, but implementing it immediately would create too much disruption. Sometimes there are simply too many things to change at once.

That is normal. It is expected. Do not become discouraged, and do not give up. The ugliness is evidence, not failure. Finding implicit trust means the process is working. Zero Trust is a marathon, not a sprint. The value is not limited to the controls you fix on day one. The value also comes from seeing the environment honestly, documenting the risk, setting priorities, adding compensating controls where needed, and building a repeatable path for improvement.

Every honest assessment makes the next decision better. Every verified control makes the next protect surface easier. Every piece of implied trust we remove makes the organization more resilient. This is how existing environments become functionally Zero Trust: not by pretending they are clean, but by adapting them deliberately, proving the improvements, and repeating the process.

What We Are Really Building

AAVI is not just an assessment cycle. It is an operating discipline. Assess helps us understand what exists and how it behaves. Adapt helps us make the current environment safer and more specific. Verify proves that the change works and continues to work. Iterate keeps us from treating Zero Trust like a project with a finish line.

Zero Trust is cooperative, real-time, and adaptive to changing circumstances. Cooperative means the pillars and cross functions work together. Real-time means trust decisions respond to what is happening now, not only what was approved months ago. Adaptive means the system can tighten, challenge, limit, or change behavior as risk changes.

That is the practical goal: not perfect Zero Trust, but functional Zero Trust. A functional system understands the protect surface, defines meaningful transactions, uses the pillars and cross functions collectively, proves what it enforces, and keeps improving.

Before the Next Cup

Here is your homework before the next cup of coffee: take the protect surface you have been thinking about and list five transactions that matter. Do not try to solve them yet. Just write them down. Who or what acts? What action happens? What data, application, asset, or service is involved? Which team owns it? What would you need to know before deciding whether that action should be allowed?

Call to action: This week, choose one transaction and run a light AAVI pass. Assess what you know. Adapt one thing you can improve with existing capabilities. Verify that the improvement actually works. Then write down the next iteration. Keep it small, keep it honest, and keep moving.

Remember, this blog series is the consolidated, lighter version of the full process I walk through in ZT Foundations: Building Zero Trust with the Tools You Already Have. In the book, I go deeper into the methodology, the questions, the assessment process, the operating model, and the practical ways to use existing tools before turning Zero Trust into a shopping list.

There is also a companion volume, ZT Foundations: Protect Surface Walkthroughs, that provides example protect surface evaluations, realistic outcomes, and practical expectations. If you are the kind of reader who learns best by seeing the process applied to real-world-style scenarios, that companion book is built for exactly that.

Both books are available through cletustaylor.com and through major distributors. If your team is trying to make Zero Trust practical instead of theoretical, I would be grateful if you picked up a copy, shared it with your team, or pointed someone toward the series.

On a personal note, I also write on civic topics. I am currently looking for ARC reviewers for my new Finding Truths book, A Student of Truth. If you would like to sign up to be a reviewer, you can do that at cletustaylor.com.

As always, I would love to hear your thoughts, questions, pushback, and real-world examples. Where have you found implicit trust hiding in your environment? Which part of AAVI feels most useful, and which part feels hardest to put into practice? Send your comments and ideas to hello@cletustaylor.com, or leave a comment wherever you are reading this. Dialogue makes this work better.

Next week, we roll up our sleeves and run through our model protect surface, starting with the Identity pillar. We will identify the human and non-human identities involved, map how they participate in the transactions, look for inherited trust, and write the first draft of an identity-focused Zero Trust policy statement. I’ll have the coffee ready.