Most security leaders can describe their stack. Email, web, endpoint, network, cloud, identity, DLP, SIEM, EDR, IPS, vulnerability management, all in place. Controls mapped. Dashboards live. Architecture diagrams complete. Renewal dates tracked. Risk committees updated.
On paper, that picture looks strong.
But there is a harder question underneath it: not how the stack was designed, sold, or written into the original business case, but how it is actually working in production, across the real complexity of the organisation.
That is usually a different picture.
The gap between the boardroom view and operational reality
In large organisations, the senior view of the stack is necessarily simplified. Leaders need concise reporting: what capabilities exist, where major risks are managed, whether the organisation is broadly covered. That view matters, but it hides the operational detail that determines whether a control is genuinely effective.
I have seen this repeatedly on security transformation projects with large, global organisations. The opening conversations with senior stakeholders sounded reassuring. Tooling in place. Major control areas covered. Everything feeding central platforms. A strong position.
Then the conversations moved closer to the ground.
Engineers, administrators, SOC analysts, platform owners and architects told a more complicated story. They knew the exceptions, the workarounds, the compromised deployments, the integrations that never quite worked, and the projects that ran out of time before the hard problems were solved.
In one organisation, leadership understood that IPS was in place. The capability existed and the control was considered covered. The team running it saw it differently. The implementation had been cut short. Instead of running inline, the IPS was taking a feed from a TAP port, and it was only connected to one side of a load-balanced environment. The control leadership believed was actively protecting the environment was not inline and was seeing a fraction of the traffic.
That is not a small operational detail. It is the difference between believing a control exists and knowing whether it works.
In another organisation, the web proxy team had a different problem. Policies had become hard to manage. Legal advice had taken large categories of traffic out of interception. Some systems could not support custom certificates, so the team based SSL interception on the user agent string. That meant anyone could open Chrome Developer Tools, change their user agent, and bypass SSL interception, DLP, download controls and packet capture in one move.
From the top, the organisation had web controls, DLP, SSL inspection and monitoring. On the ground, the team running the platform knew there were serious gaps.
These stories are not unusual. Every large organisation has them. They come from legacy decisions, acquisitions, regional differences, urgent exceptions, budget pressure, vendor limitations and projects that had to move on before everything was fixed.
The result is hidden risk.
Hidden risk is usually already known
Hidden risk rarely means unknown risk. In most cases someone inside the organisation already knows about it. Their knowledge is just trapped where it cannot influence decisions.
The SOC analyst knows the logs are too weak to support a proper investigation. The engineer knows only part of the estate has been onboarded. The platform owner knows the tool works well, but only because several risky exclusions were made. The architect remembers why two overlapping technologies were both kept. The product owner knows a renewal is approaching, but has no clear evidence of whether the organisation is getting full value.
This is tribal knowledge. In security, it is not operational trivia. It is risk context, investment context and decision context. It explains how technology is actually used, where controls are fragile, which teams are frustrated, which capabilities are underused, and where the organisation is carrying unnecessary cost or exposure.
Most organisations have no scalable way to capture that knowledge, structure it, and use it at the moments where decisions get made.
Why existing approaches fall short
Organisations usually reach for one of three solutions.
The first is tooling. Another platform, scanner, dashboard or integration. These can be valuable, showing assets, vulnerabilities, alerts, configurations and control coverage. But they rarely capture the human and operational story behind a technology. They will not tell you the SOC dislikes a mail security product because the logs are not good enough to investigate with. They will not tell you engineering disabled a feature because it broke a business process. They will not tell you a tool was bought for one control requirement that another product in the stack could now deliver.
The second is governance. Registers, control mappings, risk acceptances, architecture reviews, design documents, spreadsheets. Useful, but often static, incomplete or out of date, and dependent on busy people knowing what to document before anyone has asked them the right questions.
The third is consultancy. External consultants interview stakeholders, run workshops, gather evidence and produce a report. This surfaces important findings, but it is expensive, time-bound and limited in scope. It gives the organisation a snapshot. Then the consultants leave, the stack changes, the organisation changes, and the knowledge drifts again.
The underlying problem stays the same. The most important context about the stack is scattered across people, teams and systems. It is rarely captured continuously, rarely connected back to specific products and controls, and rarely available at the point of renewal, rationalisation, replacement planning, incident review or strategic decision-making.
From assertions to Tribal Layer
At ESProfiler, we started on part of this problem with assertions. Assertions gave us a way to understand which features within a product were actually being used, asking consistent questions across stakeholders to answer one important question: how much of the capability already purchased is the organisation really using?
That was valuable. But working with customers showed us that feature usage is only part of the picture. A feature being switched on does not mean it is effective. A product supporting a control does not mean the control operates properly. A team owning a tool does not mean every stakeholder is getting what they need from it.
The real questions are deeper. How has the technology been implemented? Where is it excluded? Who depends on it? What does each stakeholder need from it? Where is it creating friction? Where is it creating risk? Where is it duplicating something else? Where is there untapped value? And who inside the organisation already knows the answer?
That is the shift from assertions to Tribal Layer. Tribal Layer captures the human context behind the stack and turns it into structured intelligence.
What Tribal Layer does
Tribal Layer uses AI agents that understand the organisation, the security stack and the directive they are working towards. That directive might be a renewal decision, rationalisation, replacement planning, gap analysis, control mapping or post-incident improvement.
The agent does not run a generic list of questions. It establishes who it is speaking to and adapts the conversation to that role. A SOC analyst is not interviewed like a platform owner. An engineer is not interviewed like a procurement lead. A security architect is not interviewed like a tool administrator. Each person sees a different part of the truth.
Take mail security. The mail team may say the product works well: mail flows, users are not complaining, administration is manageable. The SOC may say the alerting is useful but the logs are weak and investigations take too long. Security engineering may say integrations are limited and automation is difficult. Compliance may need clearer evidence for policy enforcement and reporting. Procurement may be three months from a renewal, asking whether to keep, replace or consolidate.
All of these perspectives matter. None is complete on its own. The value comes from stitching them together. Tribal Layer captures those conversations, documents the findings, and links them back to the relevant technologies in the customer's stack, where they become intelligence the platform can use.
Turning tribal knowledge into risk and opportunity signals
Once captured, tribal knowledge becomes structured findings.
Some become risk signals. A control believed to be in place is only deployed across part of the estate. A product is missing the logs required for effective investigation. A key integration is broken. A policy contains risky exclusions. A tool does not support a required workflow.
Others become opportunity signals. Two products deliver overlapping capabilities. A feature already licensed removes the need for another tool. A renewal can be challenged with evidence. A replacement project can be shaped around real stakeholder requirements rather than generic market assumptions.
This changes the quality of stack decisions. Product comparison becomes grounded in what the organisation actually needs. Rationalisation runs on evidence rather than opinion. Gap analysis reflects implementation reality, not just vendor capability. Control mapping shows whether a control is operating, not just whether a product claims to support it. Procurement conversations get stronger because the organisation understands value, risk and duplication before entering a negotiation. Post-incident improvement gets sharper because the organisation can see the context behind the failure, not just the technical symptom.
Why this matters
Security stacks are often treated as lists of products. In reality they are living systems. Tools, people, processes, integrations, exceptions, requirements, history, politics, budget, incidents and operational reality all interact.
Look only at the tools and you miss the system. Look only at the system from the top and you miss the truth on the ground.
Tribal Layer closes that gap. It gives security leaders a clearer view of what is really running, not what the diagram says is running. It gives operational teams a way to have their knowledge heard, structured and acted on. It gives procurement, architecture and risk teams evidence at the moments where decisions are made. And it helps organisations stop rediscovering the same hidden risks only after something has gone wrong.
Introducing Tribal Layer
Tribal Layer supersedes our existing assertion system and takes security stack intelligence to a new level. It captures and documents tribal knowledge at scale across the organisation, surfacing the risks, opportunities, integrations, requirements and context that traditional stack analysis cannot see.
It moves you from static documentation to living intelligence. From generic product analysis to organisation-specific context. From scattered tribal knowledge to decisions grounded in reality.
So the next time someone says "we have that control covered," the follow-up should not be whether the product exists or the feature is switched on. The better question is whether you know how it is actually working. That is the question Tribal Layer answers.
See Tribal Layer in action. Book a demo and we will walk through how it captures the human context behind your stack and turns it into decisions you can act on.