Audit evidence on AWS: logs are not proof

The sentence comes up in nearly every kickoff: "We log everything." It is usually true. CloudTrail is on, the application writes to CloudWatch, the database has its audit log. And the real work starts exactly there, because an auditor does not check whether data exists. They check whether it qualifies as evidence.

Three properties evidence needs

A log line becomes proof only when three things hold:

1. Completeness. The period has no gaps, and nobody can create one without it being visible.
2. Integrity. The content cannot be altered after the fact, and that claim is technically verifiable rather than organisationally promised.
3. Retention. The data survives the required period, even if someone with broad permissions would prefer otherwise.

A CloudWatch log whose retention is a number that a handful of people can change at any time fails points two and three. It stays valuable for operations. As evidence it is contestable, and that is precisely what audit questions aim at.

One place for evidence, not many

The first architectural decision is therefore organisational rather than technical: there is exactly one place where evidence lives. A separate S3 bucket whose only job is storing audit artifacts, with its own access rules and no other use.

Immutability comes from S3 Object Lock. Worth knowing while planning: Object Lock requires bucket versioning, and this decision is best made early rather than retrofitted into a structure that has already grown.

Governance or Compliance, and why it is not a formality

Object Lock has two modes, and choosing between them is the most interesting decision in the whole setup.

In Compliance mode nobody can delete an object before its retention expires. Not even the root account. It is the strongest assurance AWS offers technically, and at the same time a promise you cannot take back.

In Governance mode there is an emergency exit: anyone holding the s3:BypassGovernanceRetention permission can override the lock. That sounds like a watered-down version, but it is more practical than it looks. What matters is the consequence: the bypass is an explicit, narrowly granted permission, and every use produces a CloudTrail event of its own. A silent deletion becomes a documented action with a name and a timestamp.

For an environment approaching its first certification audit, Governance is usually the right starting point. Compliance is the stronger mode, but it forgives no misconfiguration of the retention period. Enter ten years by accident and you live with it for ten years.

CloudTrail: the difference between a log and proof

CloudTrail records who made which API call. Without log file validation enabled, however, the result is a text file in a bucket, and a text file proves nothing about itself.

With validation on, CloudTrail also produces digest files: hashes over the delivered log files, signed and chained together. That makes it possible to verify later whether a file was modified or removed from the chain. This is the point where a log turns into evidence, and it is a checkbox that is missing surprisingly often.

The gap that usually stays open

Up to here the infrastructure layer is covered. The database is not.

The audit log of a managed MariaDB instance lands in CloudWatch Logs. That is a fine home for operations and troubleshooting, but it is again subject to a retention setting rather than a real lock, and it sits outside the evidence store. In an audit this creates an awkward situation: complete, verifiable proof for the infrastructure, and a log with softer guarantees for access to the actual data.

Closing that gap takes little code. A Lambda function running on a schedule pulls the audit entries out of CloudWatch and writes them into the same evidence bucket, under the same Object Lock rule. The effort is modest, the effect in the audit is not: all evidence sits in one place under one set of rules, regardless of which layer produced the event.

Where to start

Moving an existing environment in this direction goes fastest in this order:

• Check CloudTrail before building anything new. Is there an organisation-wide trail? Is log file validation on? Two settings, and the largest single gain available.
• Set up the evidence bucket separately, with versioning and Object Lock in Governance mode, and bind the bypass permission to exactly one role.
• Agree retention periods with the business, do not estimate them. Too short shows up in the audit; too long costs money indefinitely and cannot be corrected in Compliance mode.
• Only then close the gaps, meaning database audit logs and anything else still sitting outside the evidence store.

The real payoff does not show on audit day but in the weeks before it: once evidence sits in one place and its integrity is technically verifiable, preparation turns into an export instead of a search.