Three of five assertions for an audit-logging control are automated — do you mark it green?
answer
- status per assertion, not per control
- green means every assertion tested
- method and freshness travel with state
- roll up to the weakest component
- self-declared gap beats a discovered one
basics
~20 sNo. Report status per assertion, not per control, and mark the control partially covered. Green on a control whose automation touches three of five assertions tells every reader that all five were tested, which is a claim your evidence does not support.
solid answer
~50 sGreen has to mean "everything this control asserts was tested and passed". If two assertions are carried by manual attestation, the control is partially covered and should say so. The model that survives an audit stores status at the **assertion** level: each assertion carries its own state, method (automated check, collected evidence, attestation, provider-satisfied), freshness and artefact, and the control's state is derived from them — three passing checks and two current attestations is *covered by mixed means*, not *green*. That distinction matters twice. Operationally, it tells you where a regression could hide: the two manual assertions are only as fresh as the last attestation cycle, so a control can be compliant in January and unverified in June while still showing green. And in an audit, declaring partial coverage yourself is far cheaper than an auditor discovering that your green meant three-fifths — the second outcome puts every other green on the board in question.
go deeper
Understand that a green control is a claim that everything the control says was tested, so a control with manually verified parts should not simply show green.
Be ready to describe assertion-level status with method and last-evaluated fields, and to explain why the control's roll-up must be derived from the weakest and stalest component.
Demonstrate that you self-declare the gap, keep staleness as a first-class state, and give the engineering team the specific uncovered assertion rather than a whole failing control.
Own the reporting contract: define what green is permitted to mean across the programme and defend it when a stakeholder wants a cleaner board before an audit.
## The problem with a boolean per control Most compliance dashboards store one state per control, because that is the granularity the framework talks in and the granularity a report is written in. But the automation happens at assertion granularity, and squeezing several assertions of differing methods and differing freshness into one boolean destroys exactly the information a reader needs. Concretely, take the audit-logging control decomposed into five assertions: 1. a log destination exists and is enabled for each production account; 2. its retention is at least 365 days; 3. delivery is still succeeding (an event newer than N hours exists at the destination); 4. records cannot be altered or deleted early; 5. the permission that would allow an early delete is held only under a break-glass process. Suppose 1, 2 and 3 are automated. Assertion 4 is set correctly on the modern platform but one legacy account predates it and is evidenced by a quarterly export. Assertion 5 lives in an approval workflow whose records a human samples. Three automated, two attested. ## Why green is the wrong word Green is read by three audiences and it lies to all three: - **An engineer** reads green as "nothing to do here" and stops looking at the legacy account. - **A control owner** reads green as "automated", and stops funding the manual cycle. - **An auditor** reads green as "tested", and will ask which test. When the answer is "three of the five things the control says", the finding is not about this control; it is about whether any green on your board means what it says. That last escalation is the reason experienced practitioners volunteer partial coverage rather than being caught at it. A self-declared partial is a managed gap. A discovered partial is a control-environment finding. ## The data model that works Store, per assertion: | field | why it exists | |---|---| | assertion text | the plain sentence pulled out of the control | | method | automated check, collected evidence, attestation, or provider-satisfied | | state | pass, fail, or stale | | last evaluated | freshness; an attestation from two quarters ago is stale, not passing | | artefact | the check result, export, or signed statement | | owner | who fixes or re-attests it | The control's roll-up is then **derived**, and it needs at least three outcomes rather than two: fully covered by automation, covered by mixed means with the manual portion named, and not covered. Some programmes add *stale* as a first-class state, which is the single highest-value addition — manual assertions do not fail loudly, they simply stop being refreshed, and a state that ages into stale is what catches that. ## Freshness is the hidden asymmetry An automated check runs continuously; its answer is minutes old. An attestation is as old as the last cycle. Rolling them into one status implicitly claims the whole control was verified at the freshness of the *best* component, which is precisely backwards. If the roll-up must be a single indicator, it should inherit the **worst** freshness and the **weakest** method among its assertions, not the strongest. ## What you tell people To the control owner: three assertions are continuously verified; two are verified quarterly by you, and here is the date of the last one and the date the next is due. To the auditor: here is the decomposition, here is which assertion each artefact answers, and here is the assertion for which the artefact is an attestation rather than a machine result. To the engineering team: this control is not done, and the open item is the legacy account, not the whole control — which is the version they can actually act on. ## The remediation path partial coverage gives you Declaring the gap also creates the backlog. Two named uncovered assertions are two tickets with owners; a green control is nothing. Over time the useful metric is not the pass rate but the drift between assertions asserted and assertions machine-verified — that number goes up when you build automation and goes down when a new control lands, and it is honest in a way a percentage of green controls never is. ## Interview signal The strong answer refuses the green, proposes assertion-level state with method and freshness, and explains the audit dynamics of self-declaring. A weak answer marks it green because "nothing is failing", or marks the whole control red, which is equally uninformative and gets the automation switched off as noise.
- Why not mark the control red instead, since it is not fully verified?Red says something is broken and demands incident-style attention, so a permanently red control that is actually compliant trains people to ignore the board. Partial coverage is a distinct and accurate state: the assertions tested are passing, and two are verified by another method on a slower cycle. The gap it names is coverage, not failure.
- How does a control show green in January and be unverified in June?Because the manual assertions age. An automated check re-runs continuously, but an attestation is only as true as its last cycle, and nothing fails loudly when a quarterly review is skipped. Treating staleness as a first-class state, with a due date per attestation, is what surfaces it before the auditor does.
- What do you hand the auditor to support a partially covered control?The decomposition itself, then one artefact per assertion mapped to the sentence it answers: check results with timestamps for the automated three, the dated export and the signed attestation for the other two, and the recorded reason those two are not automated. The mapping is what makes the evidence readable rather than a pile of files.
- What single metric best tracks progress on control coverage?The proportion of asserted facts that are machine-verified, not the proportion of controls showing green. It moves when you actually build automation, it falls honestly when new controls arrive, and it cannot be improved by widening what a green control is allowed to mean.
A recipe half-followed is not a cooked dish. Reporting green because the automated steps passed is like ticking off the whole recipe because you measured the flour.
saying these in an interview costs you the question
- Marks the control green because no check is failing
- Stores one boolean per control with no assertion detail
- Treats an attestation as equally fresh as a running check
- Marks the whole control red and creates permanent noise
- Waits for the auditor to discover the manual portion