If an Admin Can Edit the Log, It Isn’t Evidence: Building an Audit Trail Regulators Actually Trust

Introduction

Most organisations can produce an audit log when asked. Far fewer can answer a harder question: could someone with administrative access have quietly edited that log before producing it. If the answer is yes, even in theory, the log is not evidence. It is a document someone with the right credentials could have written to say whatever they wanted.

Regulators and auditors have started asking this question directly, because the value of an audit trail depends entirely on whether it can be trusted to reflect what actually happened rather than what an administrator would prefer it to show. A log that is technically complete but sits inside a database any admin can write to is not meaningfully different from a log with no access controls at all. This article looks at what actually makes an audit trail trustworthy as evidence, and where most organisations’ logging quietly fails that test.

• Takeaway 1: A log an administrator can edit or delete is not evidence, regardless of how detailed it is. Evidentiary value depends on whether the record could have been altered, not on how much data it contains.
• Takeaway 2: Access to the underlying log storage has to be architecturally restricted, not just policy-restricted. A rule against editing logs means nothing if the technical ability to do so still exists.
• Takeaway 3: Separation of duties matters as much as access restriction. The person who performs an action and the person who could review or control the record of it should not be the same role.
• Takeaway 4: Completeness and immediacy are part of trustworthiness, not separate from it. A log that samples under load, or delays writing entries, creates a window where events go unrecorded or could be scrubbed before capture.
• Takeaway 5: Regulators increasingly ask how a log is protected, not just what it contains. An organisation that cannot answer who could have altered a record, and how that is prevented, is not fully prepared for that question.

Executive Summary

An audit trail’s usefulness to a regulator, auditor or internal investigator depends entirely on trust in its integrity, and that trust cannot rest on policy alone. If administrative access to the underlying log storage technically allows editing or deletion, the fact that policy prohibits it is not the same as the action being impossible. For security and compliance leaders, the practical standard is architectural: can any individual, including a system administrator, actually alter the record, and if so, the log’s evidentiary value is compromised regardless of how comprehensive it otherwise looks. Building a trustworthy audit trail means designing the access model so the question “could this have been edited” has a verifiably negative answer.

Why “We Have Detailed Logs” Is the Wrong Starting Point

Most conversations about audit logging focus on coverage: which activities are captured, how much detail each entry contains, how far back the history extends. Coverage matters, but it answers the wrong first question.

Detail Without Integrity Is Just a Well-Written Story

A log with rich detail, timestamps, user attribution, IP addresses, file names, is only as trustworthy as the guarantee that nobody altered it after the fact. An administrator with database access can, in principle, edit a highly detailed log just as easily as a sparse one. Detail improves a log’s usefulness once its integrity is established. It does nothing to establish that integrity in the first place.

The Question That Actually Matters: Who Could Have Changed This

The right first question when evaluating any audit log is not what it records, but who has the technical ability to modify it after it is written. If the honest answer includes “a system administrator, given database access,” the log’s status as reliable evidence is already in question, no matter how the organisation’s policies describe acceptable admin behaviour.

What Makes Log Integrity Architectural Rather Than Procedural

A policy that says administrators must not edit logs is a procedural control. It relies on administrators choosing to follow it. An architectural control removes the technical ability to do otherwise, regardless of intent.

No Standing Access to the Underlying Log Storage

The strongest version of this control is one where neither the organisation’s own IT administrators nor the platform vendor have ordinary access to the operating system or database where logs are physically stored. Access to the application layer, to configure policies or review reports, is a different thing entirely from access to the underlying storage that could be used to rewrite history. When that underlying access simply does not exist for day-to-day administration, the “could an admin edit this” question has a structural answer, not a policy-based one.

Exceptions Have to Be the Exception, Not a Backdoor

Some systems require occasional privileged access for genuine support or diagnostic reasons. What separates a defensible exception from a backdoor is whether that access is temporary, requires explicit authorisation from more than one party, and is itself fully logged. An emergency access path that is permanent, unilateral, or unlogged is not an exception to the control. It is the absence of one.

Separation of Duties as a Second, Independent Safeguard

Restricting access to log storage closes one gap. A second, independent gap opens if the same role that can take an action is also the role that reviews or controls the evidence of that action.

The Person Who Acts Should Not Be the Person Who Audits

If a single administrative role can both perform sensitive operations and access or configure the audit and compliance reporting for those same operations, that role has an inherent conflict of interest, whether or not it is ever exploited. Genuine separation of duties assigns compliance, audit and policy functions to distinct roles from operational administration, so no single person’s account holds both the ability to act and unilateral influence over how that action is recorded or reported.

Anonymisation by Default Protects the Record From a Different Angle

A related but distinct safeguard is treating identifying details in logs as protected by default, revealed only through a deliberate, accountable step rather than freely browsable by anyone with report access. This limits who can casually correlate a log entry to a specific person, adding a further layer between routine access and the ability to selectively interpret or misuse the record.

Completeness and Timing Are Part of Trustworthiness

An audit trail with a genuinely restricted access model can still fail as evidence if it does not capture everything, or captures it too slowly to matter.

Throttled or Sampled Logging Creates Gaps an Incident Can Hide In

A logging system that drops entries under heavy load, or samples rather than capturing every event, creates exactly the kind of gap an incident, or someone trying to hide one, can fall into. A log that is architecturally tamper-resistant but incomplete because of throttling still fails the “does this reflect what actually happened” test, just through a different mechanism.

Delayed Writes Leave a Window Before the Record Exists

A log entry that is not appended immediately leaves a window, however brief, during which the event has occurred but no record of it yet exists. For most purposes this window is harmless. For evidentiary purposes, any gap between an event and its durable record is a gap in the chain of trust the log is supposed to provide.

Building the Standard Before a Regulator Asks for It

The practical test for any organisation is to ask, honestly, who could technically alter its audit logs, whether that access is an occasional, dual-authorised exception rather than routine administration, whether the roles that act and the roles that audit are genuinely separate, and whether logging is complete and immediate rather than throttled or delayed. An organisation that can answer all four with confidence has an audit trail that functions as evidence. An organisation that has to think carefully about any of them has a log that merely looks like one.

How a Data Control Plane Builds Evidentiary Integrity Into the Architecture

Meeting this standard requires the access model itself, not just policy, to remove the ability to alter records, combined with separation of duties, completeness and immediacy that hold regardless of administrative intent.

The Kiteworks Data Control Plane runs on a hardened architecture where neither Kiteworks nor the customer’s own IT administrators have ordinary access to the underlying operating system or database, including the audit log storage; any support access is temporary, dual-authorised, and itself fully logged. Dedicated Compliance, Auditor, Policy Manager, CISO and Data Leak Investigator roles separate operational administration from audit and compliance functions, so no single role both acts and controls the record of that action, and logs are anonymised by default to add a further layer of protection. Every action across every channel, including email, file sharing, APIs and AI agents, is captured completely and immediately, with entries appended in real time rather than throttled or sampled, and the resulting record feeds directly into SIEM tooling for independent analysis.

Organisations that want to test whether their current audit trail would hold up to the “could an admin have edited this” question can schedule a custom demo to see how architecturally restricted log integrity applies to their own environment.