Five pillars on four foundations, jointed like a timber house.

A pillar is a durable resource domain: it exists regardless of what you're building on it. There are five.

Identities — who or what is acting. Compute — where workloads run. Networking — how anything reaches anything else. Software — what delivers the function. Data — the reason the other four exist.

The first draft had a sixth: AI. It was a category error, and the fix came from a better instinct — AI is humanised compute. An android is a body and a person. Pull AI apart the same way: the model, the weights, the inference runtime are the body — a workload on Compute. The agent that authenticates, holds privileges and acts on your behalf is the person — a non-human Identity. The governance it needs — evals, guardrails, model risk — rides through as a tie-beam, exactly like Security. Nothing floats, and nothing needs its own post.

The core of how I think: every component is a configuration item, and the moment it exists it must link to at least one other. But a CI on a whiteboard and a CI in the rack are two different animals, and pretending otherwise is where CMDBs go to die.

The theoretical CI is the idealised node — clean, single-purpose, fully linked. The real CI is messy, multi-role, half-documented, and drifting. So the graph is a desired state; the estate is the observed state; the gap between them is drift — and drift is the thing you actually manage. That's not a new discipline to invent: it's the same reconciliation loop as infrastructure-as-code, pointed at the CI graph instead of the servers.

Which is why a self-maintaining CMDB is a north star you earn, not a switch you flip. You can only auto-discover CIs through the pillars — the IdP is the source of truth for identities, IPAM for addressing, the hypervisor API for compute. The CMDB isn't a system bolted on the side; it's the emergent join of each pillar reporting itself. You earn automation one authoritative source at a time.

And the links aren't just nouns touching nouns. A CI event fires procedures across pillars and foundations. Provisioning one server looks like this:

A pillar isn't bought in one go — it's raised module by module, where a module is the smallest thing you can fund and deploy on its own. Each module carries a cost that lands in a finance quarter and an impact score that lands in a matrix cell. Maturity is just the running sum.

Take a single access switch. It doesn't arrive “mature” — it earns maturity in steps, and a second control laid over it doesn't just add, it amplifies:

The overlap is the whole point of defence-in-depth, finally made countable: NAC over a segmented switch isn't 35 + 20 = 55. It's 35 + 20 + 6 = 61, because identity-aware segmentation is worth more than the static kind. Formally: M = Σ base(module) + Σ amp(overlap), where the amplification factor is a dial you calibrate and keep consistent — not a law of physics. Set it once, apply it the same way everywhere, and the number stays honest.

The tipping point, worked

A flat access layer with no segmentation carries an expected loss on the order of €18k a year from lateral movement — likelihood × impact, priced in money (an expected value, really a range, and one that grows the longer the gap stays open). The base-segmentation module costs €4k once plus ~€1k/year to run, adds +15 maturity, and pulls that exposure hard toward the origin — the hit lands less often and smaller, cutting the expected loss by roughly €12k a year. What it removes dwarfs what it costs, so it crosses the line and goes into Q2. That's the tipping point: the moment risk justifies adding the cost to the budget to buy the points down.

Do that for every candidate module and the rule is simple: rank by exposure-retired ÷ cost, fund down the list until the quarter's budget runs out, repeat next quarter. The estate matures on the cheapest path available, and you can prove it.

Price the risk, don't colour it

All of it turns on one move: state exposure in money, not red-amber-green. A colour is nothing you can budget against; a euro range is — and the evidence sits on that side (Cox's 2008 proof that a typical risk matrix can unambiguously rank fewer than one pair of risks in ten, and the FAIR standard's loss-exceedance curve). Two caveats keep the numbers honest. A breach is a lumpy one-off, not an annuity, so any single figure is a first cut, best read as a range. And the risk compounds — the longer a gap stays open, the closer to certain the, by then larger, hit becomes. So a control is never a line item that "saves €X a year." It shifts your whole loss curve down and to the left: less likely, and smaller when it lands.

NIS2 and the frameworks like it don't want a snapshot that says “we're secure.” They want evidence of a plan — a current posture, a roadmap, money behind each step, and the risk each step retires. The two-curve model is exactly that, in a form a partner, a customer or an auditor can read in one page.

Wrapping all of it is the same closed loop every framework runs: Design → Evaluate & Adopt → Operate → Audit, then feed what you learned back into the next design. Not a waterfall — a loop, and each turn is tighter than the last. The modules are how a turn of that loop gets funded and scored.