The Context Gap - Part 2

In Part 1, we explored why enterprises can't answer basic questions about their own operations. The problem isn't missing data—it's missing decision traces. We've built trillion-dollar infrastructure for recording what's true now (the state clock). We've built almost nothing for recording why it became true (the event clock).

This matters for security because every control, every exception, every access right has a story. When that story disappears, we're left with fragments we can't interpret—and controls that become rituals performed for their own sake.

Part 2 is about what to do about it.

Here's the direct version for security leaders: building decision traces and context infrastructure only inside cybersecurity will not work.

The context gap spans the entire enterprise. The orphaned service account exists because organizational context was never captured, not because security failed to capture it.

If only security captures decision traces, you get:

This leads to what I call ceremonial security—activities that satisfy management, regulators, or auditors without materially reducing risk.

You've seen this before: controls that turned into rituals. We keep performing them, hoping the ceremony itself makes us safer, long after the original intent has been lost.

Every quarter, managers receive a list of access rights—often hundreds of entries with a few hours to review. Most re-certify everything because they don't know why access was originally granted, what will break if they revoke it, or whether the original justification still applies.

What gets recorded: "Manager approved continued access – Q2 2025"

What's missing: Why was this requested? Was it temporary? Which project justified it? Is that project still active?

The ritual satisfies auditors. It doesn't reduce risk.

Business leaders ask, "What do I need to sign so I can move on?" The form is signed. The decision trace disappears—what information informed the decision, what compensating controls were considered, when it expires, what assumptions were made.

Then an incident happens and the signer asks why security allowed this risk in the first place.

The framework says you need vulnerability management. You have a scanner. It runs. Reports exist. Checkbox: complete.

What you can't answer: Of the 200 unpatched critical vulnerabilities, which have exceptions? Who approved them? What was the justification? Are compensating controls in place? When do those exceptions expire?

Every vulnerability exception is a decision trace that disappears. You're left reconstructing the "why" during audits—hunting through email threads and Slack conversations, asking people who may have left the company.

Before discussing solutions, we need to be precise about what we're building toward.

Content is the state clock—immutable source documents, the evidence trail. Emails, meeting transcripts, contracts, chat messages, configuration files, tickets. Content is never edited after capture. It's the canonical record of what was observed.

Entities are what content mentions—people, organizations, systems, applications, projects. This is where identity resolution happens. "Sarah Chen" in an email, "S. Chen" in a meeting transcript, and "@sarah" in Slack are the same person. Without entity resolution, you can't reason about actors across systems.

Facts are what content asserts—temporal claims about the world. This is the event clock. Not just "the user has admin access" but "the user was granted admin access on March 15, 2024, approved by the IT manager, for the database migration project, with expected end date June 30, 2024."

Most enterprises have decent content storage—scattered across systems, but it exists. Entity resolution is partial at best. Facts as queryable data? Almost non-existent.

A properly structured fact has:

This structure captures temporal validity natively. When you query "What access did this user have when the incident occurred?", you filter facts where validAt <= incident time and invalidAt > incident time. The event clock becomes queryable data, not reconstructed reasoning.

Security is simply the first function to feel the consequences when context is missing.

Finance relies on decision traces to explain why exceptions were granted, why discounts deviated from policy, or why a risk was accepted. Without context, audits turn into archaeology exercises.

Legal depends on decision history to interpret contracts as they were understood when signed and to respond to regulators with a defensible audit trail. Missing context turns legal defense into guesswork.

Operations needs to understand why systems evolved—why configurations were changed, why dependencies exist, which business decisions justified technical trade-offs. When context is missing, recovery slows and inherited systems become brittle.

HR manages constant organizational change. Without decision context, access accumulates silently, relationships become opaque, and cleanup becomes risky.

Audit must verify not just that controls exist, but that they were applied correctly. Without captured rationale, every audit reopens old questions.

These are not separate problems. They are different expressions of the same gap. The infrastructure to solve them—identity resolution, connected relationships, time-aware state, captured rationale—is inherently enterprise-wide.

Treating context as a security-only concern guarantees fragmentation.

There's a deeper problem most organizations avoid acknowledging.

A large share of real decisions are not made in systems at all. They happen in informal meetings, hallway conversations, side calls, or through political negotiation. They are shaped by ego, power dynamics, and empire building. By the time something reaches a workflow tool, the real decision has already been made.

This matters because context infrastructure assumes decisions can be made legible. In most companies today, they are not.

Trying to force every informal decision into rigid structure will fail. It will generate resistance, workarounds, and quiet sabotage. People don't resist tooling—they resist loss of autonomy, status, and control.

The goal is not to make everything structured. It's to make decision outcomes and rationale traceable enough to be reconstructed later.

This also means accepting a hard truth: most existing processes are not AI-ready—and cannot be made so incrementally. Organizations that succeed will redesign selected processes from the ground up, asking:

Only after that groundwork exists does AI become useful—not as an oracle, but as a force multiplier that surfaces inconsistencies, expired assumptions, and hidden risk.

Given these realities—enterprise-wide scope, informal power structures, political resistance—how should security leaders approach this?

Not by building security-specific tooling. By championing shared infrastructure while navigating organizational dynamics.

The traditional CISO role is framed defensively: protect the organization, manage risk, justify spend. That posture guarantees friction. Security becomes a cost center, perpetually pushing change uphill.

Context infrastructure changes that dynamic. When the same foundation supports finance, legal, operations, and HR, security participates in a broader business conversation rather than arguing for security-specific improvements.

The fastest way to stall is framing this as a security improvement.

Lead with outcomes the business already cares about: decision trace infrastructure reduces audit preparation time, entity resolution accelerates M&A due diligence, exception management strengthens legal defensibility, structured controls reduce change-related outages.

Security risk reduction is a byproduct, not the headline.

This is not something security can - or should - drive alone. The goal is to champion shared infrastructure, not security tooling.

Natural allies emerge once the conversation shifts to decision traceability: technology leaders want coherence and reduced technical debt, finance wants lower audit friction, legal wants defensible history, risk leaders want evidence that controls actually work, operations wants to stop inheriting systems nobody understands.

Just as important are the operators living with the consequences: business leaders who can't explain past decisions, engineers blocked by unclear constraints, compliance teams buried in manual reconstruction. Different symptoms, same root cause.

At board level, never position this as a security initiative. The real issue is governance: the organization cannot reliably answer basic questions about critical processes, access, approvals, and ongoing validity of past decisions. That gap exists despite having controls, audits, and certifications.

The message: Risk persists not because controls are missing, but because context is. Until decision rationale is captured, the organization keeps re-litigating the past during audits, incidents, and regulatory scrutiny.

While organizational work proceeds, there are concrete technical steps security can take today—improving current operations while laying groundwork for context infrastructure.

Security data must be queryable by machines. Audit your critical data sources (SIEM, CMDB, IAM, vulnerability management) and stress-test their APIs under load. Establish unified data pipelines with intentional design rather than ad-hoc integration. Force structured data entry in case management—categorized root causes, tagged MITRE ATT&CK techniques, linked entities.

The test: Can a script get the data it needs nearly every time? When it can't, is that failure visible immediately?

Express security intent in machine-readable form. Firewall rules, detection logic, access conditions defined declaratively in YAML or JSON, pushed through version-controlled pipelines.

When controls live as code: rationale can be documented alongside rules, changes are versioned and attributable, temporal state is preserved by default, relationships between controls and assets become traceable.

Practical implementations: Detection-as-Code (Sigma), Infrastructure-as-Code for security configurations, Policy-as-Code (OPA, Cedar), configuration baselines with drift detection.

An AI agent cannot reason over screenshots and tribal knowledge. It can reason over structured definitions. Control-as-Code creates the substrate AI needs to understand not just that a control exists, but what it is intended to do.

Every exception should leave a trace. Capture: what was requested, who approved it, the justification, compensating controls, expiration date, and what triggers review.

Create templates requiring structured fields. Link exceptions to specific entities—not just text, but a specific system, user, vulnerability. Set mandatory expiration with required re-approval. Build review triggers for when context changes (role change, system decommission, project end).

Start with high-risk exceptions and make the process low-friction. Capture something rather than nothing.

Start small: map security identities across systems (AD → email → Slack → GitHub). Document service accounts with what you know. Create asset-to-owner mappings for critical systems.

Record when things become true and when they stop. Not just current access, but when it was granted and revoked. Your tools likely capture timestamps—the discipline is structuring queries to use that temporal data, asking "what was true at time T" rather than just "what is true now."

Context does not emerge naturally in complex organizations. It has to be designed.

Most enterprises operate on a fragile mix of formal controls and informal decision-making. The informal layer is where speed, politics, and judgment live. Ignoring it makes any context strategy naïve. Trying to eliminate it guarantees resistance.

The winning move is neither denial nor brute-force structure. It is selective redesign.

Organizations that make progress will:

Security leaders sit at a unique intersection of risk, operations, and governance. That gives CISOs a choice.

They can continue performing rituals—access reviews, risk acceptances, compliance checklists—and reconstruct context after the fact.

Or they can step into a broader leadership role: championing enterprise context infrastructure, shaping which decisions deserve structure, and helping the organization become legible to itself.

The first path preserves comfort and politics. The second creates leverage.

Context is not a security problem. It is an organizational one.

Security just happens to be where the absence hurts first.

Sources: