In defense in depth, what makes two controls count as two layers rather than one?

## The claim being tested "We have four layers here, so we are fine" is one of the most common sentences in an architecture review, and it is usually said about a diagram with four boxes in it. The question behind it is not how many controls exist but how many *independent things* an actor has to obtain. That number is often smaller than the box count, and occasionally it is one. ## Preconditions, not boxes Every control is a conditional: it permits an action when some fact about that action holds, and blocks it otherwise. Call that fact the control's **precondition**. - A permitted-tool list permits an action when the invoked tool appears on the list. - An egress restriction permits an action when the destination appears on the list. - An identity gate permits an action when the caller holds a particular approved identity. - A change review permits a change when someone entitled to approve it has approved it. Once each control is written this way, layering has a precise meaning. Two controls are two layers when their preconditions are **independent**: obtaining the first gives you no help at all in obtaining the second. They are one layer when a single fact satisfies both, because then the cost of the pair is just the cost of that fact. ## Why the distinction decides everything The whole appeal of depth is compounding. If an actor needs precondition A and precondition B, and neither can be derived from the other, the effort is roughly the effort of A plus the effort of B, and the chance of holding both is much lower than the chance of holding either. That is real and it is why layering is worth building. But compounding is a property of independence, not of quantity. Where two controls are conditioned on the same fact, the second contributes no new obstacle. In the worst version, the shared fact is something an insider or a contributor holds **legitimately and for free** — a standing right to start a build, an approved service identity, membership of a repository role. Their cost to obtain it is zero, so the cost of every control conditioned on it is also zero, however many of them there are. ## The proxies that do not work Three things get mistaken for independence, and all three are about implementation rather than logic: 1. **Different products or suppliers.** Two independently written checks can still both accept 'the job runs under the approved identity'. Diversity of supplier protects against a bug or an outage in one product; it does not add a precondition. 2. **Different positions in the stack.** A check in the network path and a check on the host feel independent because they are far apart, but if both consult the same permitted list, or both trust the same session, they are one condition expressed twice. 3. **Different owning teams.** Separate ownership limits the damage one person's mistake or one person's misuse can do, which is worth having. It does not change what each control actually verifies. ## What independence looks like when it is real Independence is created by anchoring a control on a precondition the other controls cannot inherit — most reliably, on a **different principal**. A step that requires an approval recorded out of band by a named human who is not, and cannot be, the running job is independent of every control conditioned on the job's identity: holding that identity does not produce the approval. That is the shape to look for, and it is why 'add another check' and 'add another layer' are not the same proposal. ## How to answer in an interview Say that you would list the controls, write beside each one the single fact it has to be satisfied about, and then group by fact. The number of distinct facts is the true layer count. If four controls collapse to one fact, say so plainly — and say which one you would re-anchor to make the count two.