Skip to content

Common-Cause Layer Audit

Dependency audit — instantiates Layered Defense Gap Decorrelation

Hunts on paper for the shared vendor, feed, power source, or credential that secretly couples defensive layers the organization treats as independent.

Version
v1 · 2026-08-24 · History
Mechanism #
1540
Type
Dependency Audit
Form family
Assessment, Review & Assurance
Solution family
Planning & Staging
Problem family
Hazard Exposure & Uncontained Harm
Problem subfamily
Layered-Defense Gap Alignment
Origin domain
Engineering & Design
Also from
Security Studies & Intelligence Analysis
Instantiates
Layered Defense Gap Decorrelation

Layers look independent because different teams own them and different documents describe them — and that appearance is often a lie. Common-Cause Layer Audit is the analytical, documentation-based investigation that traces each defensive layer down to its underlying dependencies and asks which dependencies are shared across layers that were assumed to fail independently. It builds a common-cause link map: a cross-layer graph of the vendors, data feeds, power and network supplies, credential systems, timing windows, maintenance backlogs, staffing pools, and incentives that more than one barrier quietly rests on. Its defining move is inference from structure rather than experiment — it reads architecture diagrams, contracts, on-call rosters, and org charts to find the single point that could hole several layers at once. It does not break anything to check; it reasons its way to the coupling from what the organization already documents about who owns and supplies each barrier.

Example

A payments company believes its transaction service has three independent availability layers: a primary region, a hot-standby region, and a third-party failover gateway. A common-cause layer audit traces each to its dependencies. The primary and standby both resolve service discovery through the same internal DNS cluster. Both regions' autoscaling reads the same central configuration store. The "third-party" gateway turns out to route its own health checks through the company's primary authentication service. And all three are administered by the same small platform team using one privileged-credential system. On paper, three layers; in dependency terms, four shared roots — any one of which (a bad DNS push, a config-store outage, an auth failure, a compromised admin credential) takes down what looked like triple redundancy.

The audit's product is the link map: a diagram showing each layer's true dependencies and the four nodes where they converge, annotated with which team owns each shared node. It does not prove the coupling by inducing a failure — it exposes it by following the wiring — and it hands that map to the mechanisms that test, break, or monitor the couplings it found.

How it works

The audit's leverage is in decomposition and cross-referencing, all on paper:

  • Decompose each layer to its dependencies. For every barrier, list what it silently relies on to function — infrastructure, suppliers, people, credentials, timing.
  • Cross-reference for shared roots. Overlay the dependency lists and mark every element that appears under two or more layers; those are the candidate common causes.
  • Follow ownership to find hidden convergence. Trace who administers and supplies each barrier; shared owners and shared suppliers are among the most common invisible couplings.
  • Map, don't test. Record the coupling as a link on the map with its owner attached; proving it actually defeats multiple layers is another mechanism's job.

Tuning parameters

  • Decomposition depth — how many layers down the dependency tree you trace. Deeper finds fourth-order shared roots but costs analyst time and hits documentation limits.
  • Dependency taxonomy — which categories you hunt (technical only, or people, incentives, and timing too). Broader catches subtler couplings; narrower stays tractable.
  • Documentation trust — how much you rely on diagrams-as-written versus interviewing owners to confirm reality. Trusting stale docs is how "independent" survives on paper.
  • Shared-root threshold — how many layers a dependency must touch to be flagged. Lower surfaces more couplings and more noise.
  • Ownership resolution — team-level or individual-level attribution of shared nodes. Finer attribution finds single-person couplings but is intrusive to gather.

When it helps, and when it misleads

Its strength is catching false independence before it is proven by an outage — it turns "we have multiple layers" into a map of exactly where the layers are secretly one. This is the reliability-engineering discipline of common-cause failure analysis, where the beta-factor tradition exists precisely because supposedly redundant channels share hidden roots.[n1] Its failure mode is that it is only as good as the documentation and the analyst's imagination: an undocumented dependency, a shadow integration, or a coupling that lives in an informal practice will not appear on any diagram to be traced, so the map can look complete while missing the link that matters. The classic misuse is declaring layers independent because the audit found no shared root — treating absence of evidence as evidence of independence. The guarding discipline is to pair the audit with an empirical test of its key claims rather than trusting the paper map, and to re-audit whenever architecture, vendors, or ownership change.

How it implements the components

Common-Cause Layer Audit fills the coupling-and-ownership components:

  • common_cause_link_map — its core output: a cross-layer map of the shared dependencies through which one failure could hole several barriers at once.
  • barrier_ownership_register — it attributes each layer and each shared node to an owner, using ownership convergence as a primary clue to hidden coupling.

It does NOT empirically test whether the coupling actually defeats multiple layers (independence_assumption_test) — that is the Independent Barrier Test Drill, which breaks or stresses one layer to see if another holds. The audit infers coupling from architecture, contracts, and shared ownership; the drill proves or disproves it by acting on the system.

Editorial Notes

Form Classification

Form family: Assessment, Review & Assurance

Rationale: Hunts on paper for the shared vendor, feed, power source, or credential that secretly couples defensive layers the organization treats as independent, making its operative form a bounded evaluation of existing evidence or work that produces a finding or disposition.

Independent corroboration: The frozen evidence defines Common-Cause Layer Audit as 'Hunts on paper for the shared vendor, feed, power source, or credential that secretly couples defensive layers the organization treats as independent', so its operative form is Assessment, Review & Assurance.

Review outcome: Independent reviewer agreement; high confidence.

Origin Attribution

Primary origin: Engineering & Design

Origin pattern: Cross-disciplinary synthesis

Present-day reach: Multi-domain

Rationale: Reliability engineering made structural tracing of shared roots across nominally independent safety layers a recognizable common-cause analysis.

Related originating lineages:

Review resolution: Both reviewers agree on engineering_design as primary. Reading the source mechanism confirms that its defining operation belongs to that lineage; the final record retains security_intelligence only where it materially formed the mechanism and keeps present-day application breadth separate from provenance.

Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.

Review outcome: Reconciled after independent review; high confidence.

Notes

[n1] A common-cause failure is one where a single shared factor disables multiple components that were counted on to fail independently. Reliability engineering models it explicitly — the beta-factor approach, for instance, sets aside a fraction of failures as common-cause — because nominal redundancy collapses to a single point whenever the redundant elements share a root. This audit is the mapping step that finds those roots from structure.