An assessor asks you to show that nobody used the break-glass administrator role in the last quarter. You export the cloud audit trail filtered to that role and it returns zero rows. The assessor says that is not evidence yet. What is missing, and what makes an absence into evidence?

Why zero rows proves nothing yet

An empty result has two explanations that look identical: nothing happened, or nothing was recorded. The export cannot distinguish them, because it is a query over whatever the recorder happened to capture. The assessor is not being difficult; a control whose evidence is an absence needs a separate demonstration that the recorder was running, complete and unalterable for the whole period.

The three gaps that actually occur

• The trail was off, or re-created. Someone disabled it during an incident, or deleted and recreated it with a new name in month two. Weeks one to five then return zero rows for the same reason a clean quarter does.
• Delivery stopped. The trail was enabled and the delivery to the store it is queried from failed for 11 days. Nobody noticed, because the symptom of broken log delivery is silence, which is the same shape as good news. This is the common one in production, and it survives every configuration review because the configuration was correct throughout.
• The subject of the control can edit the evidence. If the break-glass role can delete trail objects, its own absence of use is self-certified.

What turns an absence into evidence

1. Configuration history of the recorder for the period: enabled, unbroken, no gaps, no re-creation. The cloud provider's own configuration timeline is the artefact, not a screenshot of today's settings.
2. A positive heartbeat. Emit an hourly coverage record per trail with the count of events observed, even when the count is zero. An hour with a zero-count record and an hour with no record are now different facts, and the second is a detectable failure. Alert on two consecutive missing heartbeats, which is minutes of detection instead of a quarter.
3. Write-once retention in an account the subject cannot reach. Object lock or an equivalent hold for the retention period, with the role under test holding no permission in that account.
4. Integrity verification where the provider offers it: signed digest files that let the assessor confirm nothing was removed between write and read.

What to build, in order of value

The heartbeat first, because it converts the whole class of silent evidence failures into an alert, and it costs a scheduled job plus a few hundred rows a day. Then the separate retention account, which is a one-week change and removes the self-certification objection permanently. Configuration history is usually already retained by the provider and only needs exporting with the evidence pack. Choose the heartbeat over a stricter query every time, unless the control's evidence is already a positive record of each instance.

When this is the wrong answer

Controls whose evidence is a positive record have a different weak point. When every deploy produces an approval record, continuity of logging is rarely the issue; completeness of the population is - whether the list of deploys you handed over is all of them. Spending the effort on tamper-proofing a list that is missing a third of the population solves the wrong problem.

And proportionality matters. A heartbeat and a separate retention account for the role that can empty your production database are obviously worth it. The same treatment for every log in a development account is cost with no assurance attached to it.