Control Decomposition

## Two different kinds of statement A **control** is a sentence in an audit framework or an internal policy. It is deliberately written in intent language so that it survives changes in technology: it says what must be true, not how you prove it. A **check** is the opposite: a small program that reads a specific field of a specific system and returns pass or fail with an identifier for the thing it examined. Compliance-as-code lives in the gap between those two, and **control decomposition** is the act of crossing it. The reason interviewers open here is that most candidates skip the step. Handed a control, they immediately start writing a rule, and the rule ends up testing the one fact that was easiest to query rather than the assertions the sentence actually makes. ## Worked example: audit-log retention Take a control that reads, in full: *"Audit logging is enabled for every production account and the records are retained for at least 365 days in a form that cannot be altered."* Read it as a list of assertions rather than as a sentence: 1. **A log destination exists and is switched on** for each account in scope. 2. **Its configured retention is at least 365 days** — a number comparison, not a boolean. 3. **The records cannot be altered or deleted early** — an immutability or integrity-validation setting, plus the permissions that would allow an early delete. 4. **Delivery is still succeeding** — the configuration can be perfect while the destination has become unwritable, in which case nothing has been retained since it broke. Four assertions, four independent failure modes, four different fields on (probably) three different objects. Notice how uneven they are: (2) is a trivially machine-readable integer; (4) is a liveness property that needs a freshness query — "an event newer than N hours exists at the destination" — not a configuration read; (3) is partly a setting and partly a statement about who holds a permission. ## Why one control is rarely one check Three structural reasons: - **Conjunctions.** Control sentences are full of *and*, *including*, and *in a form that*. Every conjunction is usually a separate assertion, and a compound check that ANDs them together loses the ability to tell you which half failed — which is exactly what the person remediating needs. - **Different surfaces.** The assertions of one control frequently land on different systems: a cloud configuration export, an identity-provider export, a ticket record, an HR system. There is no single query that spans them. - **Configuration versus behaviour.** "Enabled" is a configuration fact; "retained" is an outcome that only holds if the pipeline kept working. Static configuration checks are cheap and behavioural checks are not, so teams write the cheap one and quietly claim the expensive one. ## The three honest outcomes of a decomposition When you finish listing the assertions, each one lands in one of three buckets, and saying which is part of the deliverable: - **Machine-checkable now** — there is a field you can read and a rule you can write. - **Evidence only** — you cannot decide pass or fail automatically, but you can collect a dated record that a human judges. Approval trails and training completion records look like this. - **Not yours to check** — the assertion is satisfied by a provider under a shared-responsibility split, and the correct artefact is a citation to that boundary rather than a rule you invent. A control can also decompose to **zero** machine checks. That is a legitimate result, not a failure of imagination. ## Arguing about what the sentence says Decomposition is a conversation with the control owner, not a solo reading exercise. Words like *production*, *appropriate*, *timely* and *privileged* are load-bearing and undefined; someone has to pin them down before a rule can exist, and the pinned-down version has to be written next to the control so the auditor sees the same interpretation you encoded. "Production" meaning "anything tagged env=prod" is a decision with consequences, and it belongs in the record. ## How this is graded in an interview A strong answer names assertions rather than tools, distinguishes configuration from behaviour, and admits which assertions the check does not cover. A weak answer describes a single rule and calls the control covered. The tell is whether the candidate can say what their check would still pass through.