Can You Prove That Control?
Cyber insurance renewals and compliance reports ask yes-or-no questions about your security controls. Most firms answer from memory. Chronolith grades every answer by the evidence behind it — and will not let itself claim more than it can show.
In short
- Controls are graded, not ticked. Every control is shown as observed, corroborated or declared, with the live measurement that justifies it.
- A claim cannot exceed its evidence. Each control has a ceiling set by what the telemetry actually supports, enforced in code.
- Ceilings fall as well as rise. If a feed stops, the claim drops with it — a stale claim is worse than a modest one.
- What you see is what downloads. The dashboard and the report share one calculation, so they cannot disagree.
- It caught us once. The mechanism found Chronolith itself overstating a control, in the document an underwriter reads.
Why a tick box is a risk you cannot see
“Do you enforce multi-factor authentication?” is asked as a yes-or-no question. It is answered by a person, often under time pressure, often from memory — and submitted as a statement about the firm.
Meanwhile the tooling that could actually answer it reports in a different vocabulary: counts, charts, alert volumes. Somebody has to translate, and the translation is where overstatement creeps in — in the comfortable direction rather than the true one.
Chronolith does not present controls as met or unmet. It presents them at one of three evidence levels, with the measurement that justifies the level beside it — so the difference between “we have it” and “we can show you we have it” is on the page, not left to the reader.
Three levels of evidence
A claim can never exceed its evidence
Every control carries a ceiling: the highest level the available telemetry supports. The presented level can never go above it — enforced when a level is set, and again every time the posture is read.
A ceiling rises when a connector lands — backups graduate the moment the backup product's inventory is readable. It falls again if that feed stops, and the presented level drops with it.
A control genuinely observed six months ago, whose feed has since broken, would otherwise keep presenting as observed.
The time it caught us
The safeguard's first real catch was in Chronolith itself.
The MFA control reported corroborated unconditionally, and the figure beside it was calculated from a Windows event that records running a process as another user.
That has nothing to do with a second factor. So the one control that is a headline question on essentially every cyber policy was presented above what any evidence supported, with a number that counted something else — in the document an underwriter reads.
MFA now sits at declared until a genuine multi-factor sign-in feed exists, and says so plainly: “no multi-factor sign-in records are reaching Chronolith”. It will rise on its own when a feed lands, and fall again if that feed stops.
There is a state beneath declared: the measurement could not be taken at all. That reports as “metric unavailable” and is explicitly not read as “no MFA telemetry exists”. A failed check and an absent control are different findings, and collapsing them makes a product confidently wrong in one direction or the other.
What you see is what downloads
A dashboard that summarises and a report that recalculates are two implementations of the same claim, and they drift. When they drift, the firm finds out from whoever read the report rather than from the product.
Here the on-screen preview calls the same calculation the report generator calls. There is no second path. Before anything goes to a broker or an auditor, you can see exactly what the download will contain. Every level change is recorded with who changed it and when, and posture is snapshotted over time, so a claim made at renewal can be reconstructed later.
Alert queues get cleared in bulk, and that is a reasonable thing to do — one misconfigured account can generate hundreds of identical failures. But a batch action stamps one timestamp across every alert it touches, so counting them would report the moment somebody clicked a button as your incident response time.
Bulk-cleared alerts are excluded from the response-time figures, and the report says how many were excluded, with high and critical broken out. Excluding them quietly would show a fast, clean response with nothing to indicate part of the queue was cleared categorically — which is the same thing the evidence ceiling exists to prevent, in a different place.
What Chronolith proves, and what you still have to state
The rule for every control is a question about the customer, not the engineering: can we work this out ourselves? If yes, we derive it and never ask. If only a skilled installer could answer, it ships with a working default. If nobody could answer it and it is not essential, it does not ship — an unanswerable question becomes the configuration permanently, because nobody answers it.
| Control | Ceiling today | What stands behind it |
|---|---|---|
| EDR coverage | Observed | Endpoint protection activity, counted by machine over 30 days |
| Backups | Observed | Backup inventory: protected machines, stale or missing restore points. Falls back if the feed stops. |
| MFA enforcement | Declared | No multi-factor sign-in feed yet. Rises automatically when one exists. |
| Incident response plan | Declared | An attestation. No telemetry can observe a plan. |
| Penetration test | Declared | An attested date. Correctly a human statement. |
Alongside these sit the carrier control confirmations an administrator ticks. Two things were wrong with treating those as a plain checklist:
- Asking someone to attest to what the product can prove. Five of the eleven duplicated a control Chronolith already measures — including EDR, which is observed. The product asked for a tick, then printed “not confirmed” when nobody supplied one. Evidence is now shown alongside, so the tick confirms scope rather than existence.
- Counting an inapplicable control as a gap. Cloud security is not a missing control for a firm with no cloud — and on-premises is the majority case here. An unticked box reads to an underwriter as a deficiency rather than as not applicable, which made a perfect score unreachable by design.
Five remain correctly human-attested: privileged access management, vulnerability scanning, network segmentation, business continuity planning, and security awareness training.
Common questions
Will this make our renewal answers look worse?
Sometimes, and that is the point. It frequently makes a firm look more modest than a checklist would have. What it buys is that every claim submitted is one you can stand behind, with the measurement supporting it attached. An answer you cannot evidence is an exposure that has nothing to do with your actual security posture.
Does it fill in the insurance questionnaire for us?
No. It produces the evidence and the current level for each control, in a form you or your broker can work from. The submission remains the firm's, and the attested controls remain statements a person makes.
How do we move a control from declared to observed?
Connect the relevant source. The ceilings are visible precisely so the gap becomes a concrete work list — “backups are corroborated and could be observed if the backup connector were configured” is actionable in a way a red cross on a checklist is not.
Can we override a level if we know a control is in place?
You can lower any level at any time. You cannot raise one above what the evidence supports — that is the safeguard, and it is not configurable. Where a control is genuinely in place but unobservable, the honest presentation is declared, which is a legitimate answer rather than a failure.
Does this replace an audit?
No. It gives an auditor evidence that is graded and dated rather than asserted, and it gives you a continuous view between audits. The judgement remains the auditor's.