What must be true of a management-API audit record before you can tell an auditor the account's own administrators could not have altered it?

## The question behind the question An auditor asking whether the record could have been altered is really asking whether your controls survive an insider with administrative rights. Almost every part of the system is designed to be operated by those administrators; the audit record is the one part that must be designed to be operated *despite* them. That single inversion drives every decision here, and a lead who cannot state it will design a record that is perfectly reliable against accident and worthless against the case it exists for. It is worth conceding the strong version of the claim immediately, because overstating it is how the answer fails. You cannot make a record unalterable in an absolute sense. What you can do is arrange things so that any alteration requires a second party, or leaves evidence, or both — and so that the silence produced by switching the recording off is itself loud. ## The three properties **1. Separation of the copy that counts.** The record as the platform writes it is inside the account, and whoever administers the account can generally change what is captured and where it goes. So the authoritative copy is delivered continuously to a destination that is administered by someone else — a different set of permissions, held by a different group, with delete and overwrite denied to the operating team. Two supporting mechanisms matter: - a **retention lock** on the destination, so a stored object cannot be shortened or removed before its period ends, even by whoever owns the destination; - **versioning**, so an overwrite creates a new version rather than replacing the old one, and an attempt is itself visible. How this separation is arranged across an organisation's accounts — which account owns the destination and how the boundary is drawn — is a tenancy question and is answered there. The property you are asserting here is narrower and portable: *the people who could have made the change cannot remove the record of it*. **2. Continuity, and an alarm on silence.** Disabling the recording, narrowing its scope, or pointing it at a destination you control are all management calls, so each produces an event — briefly. The attacker's move is to disable and then, at leisure, address the record of having disabled it. The countermeasure is not cleverness, it is **two independent detections**: 1. a rule on the event itself — any call that changes the recording configuration alerts immediately, to somebody outside the team that operates the account; 2. a rule on the absence of events — if the expected steady trickle of entries stops arriving at the destination for longer than the normal delivery lag, that raises an alert too. The second is the one teams skip, and it is the one that matters, because the successful version of the attack produces no event at all. A monitor that only fires on events cannot fire on a stream that has stopped. **3. Survival past the discovery lag.** The window the provider keeps by default is set for operational convenience — enough to debug last week. The interval between something being done and somebody asking about it is routinely far longer: a departure, a customer complaint, a regulator's letter, a penetration test. So the exported copy's retention must be set against that discovery lag rather than against the debugging use case, and the person setting it should be able to say which of those two numbers they used. ## What you cannot promise A credible answer names its own limits, and there are four: | limit | the honest statement | |---|---| | intent | the record shows a call and an outcome, never why | | coverage | a change that did not travel through the management API leaves no entry to protect | | the gap before delivery | events accepted but not yet delivered are the one genuinely vulnerable interval | | identity, not person | the record names the credential, and tying that to a human is another system's job | The third deserves emphasis, because it is where the claim is actually weakest. Between the platform accepting a call and the entry landing in the separated destination, the evidence exists only in the provider's own store. The mitigation is that the interval is short and not under the account's control — not that it does not exist. ## How to say it The answer an auditor can use is a statement of properties with named mechanisms, not a claim of perfection: the record is written by the platform rather than by anything inside the account; it is delivered continuously to a destination the account's administrators cannot delete from or overwrite; the retention on that destination exceeds the period under review; any change to the recording configuration alerts a separate group; and the absence of expected entries alerts too. That is a control that can be tested. "We use the platform's audit logging" is not.