Zero Trust Foundations: Running AAVI Through the Data Pillar

Why data has to hold veto power over every trust decision, even when identity, device, network, and application have all already said yes.

Summary: This week we bring the final pillar into our transaction flows and Zero Trust policy statements: Data. Identity told us who is asking. Device told us what they are asking from. Network told us how far the request should travel. Application told us whether the application itself is behaving as expected. Data asks the question that overrides all of them if the answer is wrong: given what this data actually is, should this action be allowed to happen at all, regardless of how clean everything else looked.

Grab a fresh cup of coffee, because this is the pillar that gets the final word. Last time, we ran AAVI through the Application and Workloads pillar and asked whether an application does what we actually expect, not just what it is technically capable of. This week we close out the Five Pillars with Data, and it is worth saying plainly why this one goes last in the walkthrough but first in authority. Every other pillar can look perfect and still be wrong if the data itself says no.

Here is why that matters right now, not as a theoretical closing argument. In 2025 and 2026, healthcare and health adjacent breaches kept following the same pattern. Cegedim Sante exposed 15.8 million patient records. DentaQuest and other health organizations landed on breach lists for similar reasons. IBM's own research found that 97 percent of organizations experiencing an AI related breach lacked proper access controls around the data itself, not around identity or network. In nearly every one of those cases, somebody authenticated correctly, connected from a reasonably normal device, traveled an expected network path, and used the application the way it was designed to be used. The transaction looked fine right up until sensitive data moved somewhere it should never have been allowed to go. That is not an identity, device, network, or application failure. That is a Data pillar failure, and it is exactly the gap this post is here to close.

Data Needs Veto Power, Not Just a Seat at the Table

Here is the idea that makes this pillar different from the other four. Identity, Device, Network, and Application all contribute signals to a trust decision, and each one matters. But none of them, even all four working together, can fully answer whether an action should happen if they do not know what the data actually is. A finance user, on a managed laptop, on an approved network path, using the export function exactly as designed, should still be stopped cold if that export happens to include a field of regulated health data that function was never supposed to touch.

That is what veto power means in practice. Data does not just add another vote to the decision. Data gets to override the other four when what it discovers changes the risk enough to matter. An approved user attempting an approved action through an approved path can still get a no, a challenge, or a restriction, if the data itself is more sensitive than the rest of the transaction accounted for. Zero Trust without a data veto is four pillars agreeing with each other while nobody actually looked at what was leaving the building.

Our Model Protect Surface, Continued

Back to our familiar messy hybrid application: on premises core, legacy database, corporate identity platform, SaaS analytics export, cloud file storage, internal admin tools, and vendor support access. Now we ask the Data question about the same transactions. When the finance user exports a report, does the export actually check what fields are in that report, or does it simply trust that the export function was scoped correctly and never look again. When the service account moves data to SaaS analytics, does anything inspect what is actually in that data stream, or does the pipeline just move whatever the source system hands it. When a file gets copied to cloud storage for collaboration, does anything notice if that file happens to contain something that should never leave a managed environment.

This is where the whole series comes together. Identity, Device, Network, and Application can all report a clean bill of health on a transaction, and Data can still be the pillar that catches the one thing that actually matters: what is this, and does it change the answer.

AAVI Through the Data Pillar

Assess: What Data Actually Exists, and What Does It Deserve

Assess for this pillar means finding out what data actually lives in the protect surface, not what the documentation says should be there. That includes classifying data by sensitivity, understanding where regulated or high value data sits, tracing where it flows once a transaction touches it, and being honest about how much of that classification exists on paper versus how much actually gets checked at the moment of the transaction.

For our protect surface, assessment likely shows customer records mixed with less sensitive operational data in the same tables, an export function that returns whatever the query asks for without checking field level sensitivity, a SaaS analytics pipeline that moves data without inspecting its contents, and a cloud storage habit that has probably picked up at least one file nobody meant to put there. None of that is unusual. It is exactly what shows up in nearly every honest assessment, which is precisely why this pillar cannot be skipped or treated as a formality.

Adapt: Give Data the Authority to Stop Things

Adapt is where classification stops being a spreadsheet exercise and starts actually influencing what happens. That might mean tagging sensitive fields so the export function can check them before returning results, applying data loss prevention controls that inspect what is actually leaving through the SaaS pipeline, and adding automated scanning to cloud storage so a sensitive file lands somewhere restricted instead of somewhere convenient.

The important shift here is architectural, not just procedural. Data classification has to be wired into the decision point itself, not published as a policy and hoped for. If the export function cannot check field sensitivity in real time, classification is not actually protecting anything, no matter how well documented the classification scheme is on paper.

Verify: Prove Data Actually Changed an Outcome

Verify asks the question that separates real Data pillar maturity from a compliance checkbox. Can we show a specific instance where a transaction was blocked, limited, or challenged because of what the data actually was, not because of who was asking or what device they used. If sensitive data has never once stopped a transaction that would have otherwise gone through cleanly, that is not evidence the data is safe. That is evidence the veto has never actually been tested.

If data cannot be shown to have overridden a decision at least once, we CANNOT count the Data pillar as functional yet.

That is a harder bar than the verification standard for the other four pillars, and it should be. Identity, Device, Network, and Application prove themselves by consistently doing what is expected. Data proves itself by occasionally doing the opposite of what everything else already agreed to.

Iterate: Keep Tightening What Data Is Allowed to Reveal

Iteration here usually starts with the highest sensitivity data and works outward. The first pass might add field level checks to the export function. The next might add real content inspection to the SaaS pipeline. The next might extend scanning to cloud storage and shared drives. The next might apply the same veto logic to whatever the AI agents from the Application pillar are allowed to retrieve and summarize, since an AI assistant that can read sensitive records needs the same data level check a human export function would need. Each pass reduces how much sensitive data can move purely because everything upstream of it looked fine.

Cross Functions Keep Data Honest

Visibility and Analytics need to show not just that data moved, but what that data actually was, at the moment it moved, and whether its sensitivity matched what the transaction expected. A log that says "export completed successfully" without saying what was in the export is not decision grade evidence.

Automation and Orchestration should apply data classification and inspection consistently, rather than depending on a person remembering to check. Sensitive fields should be flagged automatically, DLP rules should trigger without manual review, and AI agents pulling from sensitive sources should have those checks applied every time, not just when someone thought to configure it.

Governance should own how classification schemes get set, reviewed, and enforced, and should require evidence that the veto has actually been exercised, not just that a policy exists describing when it should be.

The Five Pillars, Working Together

With Data in place, we have now walked all five pillars through AAVI against the same protect surface. Identity told us who. Device told us from what. Network told us how far. Application told us whether the behavior matched expectation. Data told us whether any of that should matter once we actually looked at what was at stake. None of these pillars work in isolation, and none of them should be treated as a finish line on their own. A functional Zero Trust architecture is what happens when all five keep talking to each other, continuously, on every transaction, with the Data pillar holding the authority to say no even when everyone else already said yes.

Before the Next Cup

Here is your homework before the next cup of coffee: pick one transaction from your protect surface and ask honestly whether the data involved has ever actually stopped, limited, or challenged that transaction. If the answer is no, ask why. Is it because the data has never been sensitive enough to matter, or because nothing was ever built to check.

Call to action: This week, do four small things. First, pick one export, transfer, or data movement in a real transaction and confirm whether field level sensitivity is actually checked before it happens. Second, find one place where data leaves your environment (a SaaS export, a cloud storage upload, an AI agent's retrieval) and ask whether anything inspects what is actually leaving, not just whether the transfer was authorized. Third, look for one instance, real or simulated, where the data veto actually worked, and if you cannot find one, treat that as your next priority. Fourth, ask whether your classification scheme is wired into an actual decision point, or whether it is a document that describes intentions nobody enforces.

Remember, this series is the lighter, consolidated version of the process I walk through in full in Zero Trust Foundations Volume I: Building Zero Trust with the Tools You Already Have. The book is available now through cletustaylor.com while I work through relaunching it across additional distribution channels, so if you would rather order it directly, that is the place to do it right now. There is also Protect Surface Walkthrough, the companion volume to Volume I, which walks through example protect surface evaluations and realistic outcomes for readers who learn best by seeing the process applied to real scenarios. Both books are meant to go deeper than this blog series can, and 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 have some news I am genuinely excited about. A Student of Truth, my Finding Truths book, is now live on Amazon and available immediately. For the first 90 days, the ebook is on sale for $2.99 and the paperback is priced at $15. If you have been waiting to pick up a copy, or if you know someone who could use a clearer way to think through misinformation, outrage, and AI, now is the time. You can find it directly on Amazon or through the link at cletustaylor.com.

Next time, we step back from the individual pillars and put the full picture together, running our model protect surface through all five pillars at once, and starting the conversation about how to keep a young Zero Trust architecture from quietly drifting back into implicit trust once the initial excitement wears off. As always, I would love to hear your thoughts, questions, pushback, and real world examples. Where has your data ever actually stopped a transaction that everything else had already approved? Send your comments and ideas to hello@cletustaylor.com, or leave a comment wherever you are reading this. I'll have the coffee ready, and I promise not to make you classify every field in the database before the first sip, unless one of them happens to be somebody's medical record.

#ZeroTrust #Cybersecurity #DataSecurity #DataClassification #DLP #AIsecurity #SecurityArchitecture #ZeroTrustArchitecture #CyberSecurityAwareness