The Trust Map: Why Your Security Org Chart Is Lying to You

Customer experience teams had a quiet revolution about five years ago. They stopped measuring satisfaction through basic measures like the NPS score, a lagging indicator that tells you how someone felt after the fact and started mapping customer trust as a journey. Acquisition, onboarding, engagement, renewal: each stage with its own trust dynamics, its own failure modes, its own repair strategies. A CMSWire analysis describes the approach well: layering trust indicators such as dips in sentiment, support friction, and behavioral anomalies onto journey maps allows teams to pinpoint the exact stage where trust weakens and intervene before it collapses.

Security teams can learn a lot from this. But one of the big things holding us back as an industry is our obsession with org charts.

We obsess over who the CISO reports to, which certainly warrants its own post to dissect. But more importantly, we still function in rigid org chart structures that inhibit the complex interdependencies between security, privacy, and compliance functions from being truly effective.

We've organized ourselves around technical domains for the better part of two decades. Network security here, identity there, GRC in a different wing of the building with a different VP and a different budget cycle. The CISO Mind Map is updated annually and is an amazing tool, it gets hung on conference room walls and became a useful shorthand for the scope of the job. But scope isn't structure, and structure isn't strategy. A list of 47 things your team is responsible for doesn't tell you how those things relate to each other, where they create dependencies, who should care in the organization, or whether any of them actually serve the thing you're ultimately accountable for: being worthy of trust from the stakeholders that matter most.

That last part matters. Because somewhere along the way, we confused owning security domains with being trustworthy, and those are not the same thing.

Today we're releasing the Trust Map an interactive tool built on a different premise than the CISO Mind Map. Where the Mind Map asked what does the security team own?, the Trust Map asks what does it take to be trustworthy? It is our grounded belief around what goes into designing and operating a Trust team or function within an organization.

It's a shift from inventory to architecture. From boxes to systems.

The Org Chart Problem

Most security org charts are hierarchies pretending to be strategies. They show reporting lines, not dependencies. I first started really caring about this when I read Team Topologies for the first time. It opened my eyes to the idea of org charts having significant influence over communication flows and ultimately system architecture and technical outputs.

The story that ultimately tells is ownership doesn't necessarily drive the outcomes that are desired by senior leadership. Even though having a team hierarchy has always been part of the common body of knowledge in how to establish teams and departments.

The Trust Map is organized around twelve core domains radiating from a central Trust & Transparency Program. Some will feel familiar, coming out of the typical CISO organization: Security Operations, Application Security, Identity & Access Management. Others reflect the reality that trust in 2026 has outgrown what a traditional security team covers: AI Governance & Responsible AI, Supply Chain Transparency, Data Practices & Privacy, Business Enablement. I see and talk to more leaders who are working through the convergence of these different disciplines under their role. They are facing questions and scrutiny that spans beyond the more technical and operational cybersecurity arena.

But the domains as they are laid out are the least interesting part of this (for me anyways). The connections are where this gets useful because our org charts and our tools have reinforced siloes for year now.

Click into any domain and you'll find sub-domains broken into key practices, each mapped to its dependencies — both what it depends on and what depends on it, plus relevant compliance standards and the stakeholders who need to be (or will likely want to be) in the room. Governance & Strategy, for example, branches into Regulatory Intelligence, Governance-as-Code, Program Maturity Assessment, Security Evangelism, and more. Each with its own web of relationships.

My hope is that more people in our field can start thinking about their job in this cross-cutting way.

Here's what that looks like in practice: your Incident Response & Disclosure capability depends on Data Practices & Privacy for breach notification readiness. That depends on Governance & Strategy for regulatory intelligence. Which depends on Risk Management & Compliance for impact assessment. Pull one thread and the whole fabric moves. Your org chart won't show you this. The Trust Map will. The important thing is that the people working in enterprise security teams can begin to think in systems, to see the interconnections, and ultimately engage more holistically.

Trust as a Journey, Not a Checkbox

This is where the CX parallel earns its weight.

PwC's 2025 Customer Experience Survey — titled, tellingly, "The Loyalty Illusion" — found that nine out of ten executives believe customer loyalty has grown in recent years. Only four in ten consumers agree. That speaks to some pretty significant measurement problems...either that or straight up dellusion. Leaders think they're earning trust because they're not tracking where they're losing it. The parallel would be trying to sail a boat across the water with leaks. It probably won't go down all at once, but it will definitely drag you down over time as the leaks compound.

CX teams learned to fix this by treating trust as stage-dependent. A trust failure during onboarding like a confusing data consent flow erodes confidence before it's established. A trust failure during a mature relationship, such as discovering your data was shared with a third party you didn't expect betrays confidence that already exists (or existed). Both are trust failures. The repair strategies are completely different. The point in the journey and relationship are also completely different. You don't run the same playbook for a new user and a five-year customer.

Now apply that lens to the trust function inside your organization.

A startup building its security program for the first time has different trust vulnerabilities than a mature enterprise managing AI governance across three continents. The startup's failures look like missing access controls and no incident response plan, basically foundational gaps. That organization is going to be looking to build the basics and establish a visible external story, using artifacts like SOC2 or ISO27001 reports. The enterprise's vulnerabilities look like opacity in AI decision-making, or a fourth-party supply chain compromise nobody had visibility into, representing failures in a complex system. A SOC2 report doesn't do much to help with this, so the playbook needs to evolve.

The truth is, all the items in these mind maps and in any CISO book you might pick up are not equal and do not deserve the same level of attention. There is a lot that "depends" to inform what truly matters. Your stage of maturity, your customer spread, the industry you operate in, and more.

The interventions that matter depend on where you are in your journey.

Why "Trust Team" and the Predictable Objection

Some will read "trust team" and think this is a rebrand of the security function. It's not. And let's be direct about why the label matters.

It's not just about transparency in GRC. It's not about having a trust center and putting information out there to streamline TPRM reviews.

The modern trust function spans cybersecurity, privacy, compliance, AI governance, data ethics, and supply chain transparency. In many organizations, these capabilities still sit in separate teams with separate leadership and separate budgets. Take that a step farther, different leadership and budgets also equates to different success criteria, different metrics, different overarching mission and objectives.

We shouldn't be surprised when a data ethics question falls through the gap between the privacy team and the AI team, or when a supply chain risk gets missed because it didn't look like a traditional security vulnerability. I believe that we need to embrace that these functions share a common purpose, maintaining and deepening the organization's trustworthiness and that purpose gets lost when you optimize each function in isolation. That dynamic is exacerbated amidst organizational politics, budget pressures, multi-team cultures, tools with specific data structures and APIs, and so on.

Over the last year I have observed three forces making this convergence unavoidable.

AI governance can't be bolted on. Responsible AI touches data practices, application security, risk management, and governance simultaneously. If those functions aren't coordinated, your AI governance program is a policy document nobody reads. As security we should definitely be able to appreciate this dynamic as we've seen it play out so many times now. And given the pace at which AI capabilities are being deployed, in products, in internal tools, in your supply chain, "we'll figure out governance later" is how you end up explaining to your board why the model made a decision you can't audit or explain.

Supply chain transparency is no longer optional. Between regulatory pressure (the EU AI Act, DORA, evolving NIST frameworks) and operational reality (your software supply chain is someone else's security posture), trust now extends well beyond your own infrastructure. We made Supply Chain Transparency a first-class domain in the Trust Map because treating it as a sub-bullet under vendor management is how organizations get surprised. It's also well beyond software supply chains, vendor supply chains, or AI supply chains. There's a unique convergence of all these elements that organizations cannot escape.

Trust is becoming a market differentiator. Research from Schneider Electric found that 65% of consumers lose trust in an organization after a data breach, with nearly a third saying they'll never do business with that company again. Now, I think there's a lot of nuance in research like this, whether we're talking a B2B or B2C brand, what the breach actually was, and so on. The organizations that can demonstrate trustworthiness, not just claim it in how they handle data, deploy AI, manage incidents, and govern their supply chains will close deals that their less transparent competitors won't. CX teams figured this out about customer trust years ago. The trust function is catching up.

How to Think With This

The Trust Map is free, open, and available now at trust-map.sidekicksecurity.io.

It's not a prescriptive framework. God knows we don't need more frameworks. We built this to be a thinking tool. We also built it to communicate our own philosophy on how we see the industry evolving.

If you're building or restructuring a trust function, use the domain and sub-domain structure as a starting point and stress-test it against your actual risk profile. If you're assessing maturity, click into individual practices and be honest about where you are, the dependency mapping will show you where a gap in one area creates risk in three others. If you're making the case to leadership, the stakeholder mapping and standards connections give you the language to tie security capabilities to business outcomes.

But the real value is simpler than any of that. It's the shift from thinking about your security program as a collection of functions to thinking about it as a system that produces or fails to produce trust.

The org chart tells you who reports to whom. The dependency map tells you what breaks when something fails. The Trust Map asks whether any of it, taken together, actually makes you trustworthy.

That's the question that matters. And it's the one most security programs aren't structured to answer.