Why Audit Logs Are Not Enough for Compliance

Every compliance framework in existence relies on audit logs as a primary source of evidence. SOC 2, ISO 27001, HIPAA, PCI DSS, GDPR, DORA, NIST CSF, CMMC, FedRAMP, and dozens of industry-specific regulations all require organizations to maintain logs that demonstrate compliance with their respective requirements. Auditors review these logs as proof that controls are operating effectively. Regulators request these logs as evidence of compliance. Legal teams cite these logs in litigation. The entire compliance evidence chain is built on audit logs.

And audit logs are not enough. They have never been enough. The compliance industry has known this for decades but has continued to rely on logs because there was no better alternative. Now there is a better alternative, and the gap between what logs provide and what compliance actually requires has become too significant to ignore.

This article examines exactly why audit logs fall short as compliance evidence, what organizations and regulators actually need, and how cryptographic attestation bridges the gap between recorded events and provable facts.

What Audit Logs Actually Prove

To understand why audit logs are insufficient, it is important to be precise about what they do and do not prove. An audit log is a record of events that were captured by a logging system. When a user logs in, the authentication system writes a log entry. When a database query is executed, the database writes a log entry. When a file is accessed, the operating system writes a log entry. When a network connection is established, the firewall writes a log entry.

Each log entry typically contains a timestamp, an identifier for the actor, a description of the action, and a result code indicating success or failure. The log entries are stored in a file, a database, or a centralized logging service. They are retained for a period specified by the compliance framework, typically one to seven years. During an audit, the auditor reviews a sample of log entries to assess whether the controls are operating as designed.

This is what audit logs prove: that the logging system recorded specific events at specific times. They do not prove that the events actually occurred as described. They do not prove that no other events occurred that were not logged. They do not prove that the log entries were not modified after they were created. They do not prove that the logging system was functioning correctly during the period in question. And they do not prove that the logging system captured all relevant events.

The distinction between "the logging system recorded this event" and "this event actually occurred as recorded" may seem pedantic. It is not. It is the gap through which breaches, fraud, and compliance failures flow.

The Five Fundamental Weaknesses of Audit Logs

Audit logs have five fundamental weaknesses that make them insufficient as the sole basis for compliance evidence. Each weakness has been demonstrated repeatedly in real-world incidents, and each represents a gap between what logs provide and what compliance actually requires.

Weakness One: Logs Can Be Modified

The most fundamental weakness of audit logs is that they can be modified by anyone with sufficient access to the system that stores them. An administrator with root access can edit, delete, or backdate log entries. An attacker who compromises the logging system can modify the logs to cover their tracks. A malicious insider can alter logs to create a false record of events.

Compliance frameworks attempt to address this weakness through access controls on log storage, separation of duties for log management, and integrity monitoring for log files. These measures reduce the risk of log modification but do not eliminate it. An administrator who manages the logging infrastructure has, by definition, the ability to modify the logs. No amount of access control policy can prevent someone from exercising access that they legitimately possess.

Some organizations use centralized logging services or SIEM platforms that are managed separately from the systems that generate the logs. This adds a layer of protection, but the logs must still traverse a network from the source system to the logging service, and there is a window of time between event generation and log collection during which the log entry can be intercepted, modified, or deleted. Write-once storage and log integrity hashing add additional layers, but each layer adds complexity and each has known limitations.

Weakness Two: Logs Can Be Incomplete

Audit logs only capture events that the logging system is configured to record. If a relevant event type is not included in the logging configuration, it will not appear in the logs. If the logging system has a bug that prevents certain events from being recorded, those events will not appear. If the system generates events faster than the logging infrastructure can process them, events may be dropped without any indication in the log.

This is a particularly insidious weakness because the absence of a log entry is ambiguous. It may mean the event did not occur. It may mean the event occurred but was not logged. It may mean the event was logged but the log entry was subsequently deleted. Without additional evidence, there is no way to distinguish between these possibilities. Auditors and investigators must interpret the absence of evidence, which is a fundamentally unreliable basis for conclusions.

Weakness Three: Logs Prove Recording, Not Occurrence

A log entry is a record created by a software system. It reflects what the software was programmed to record, which may or may not accurately represent the event that triggered the log entry. A log entry showing a successful authentication does not prove that the person who authenticated was actually the person identified in the log. A log entry showing an access control decision does not prove that the access control policy was correctly implemented. A log entry showing a successful backup does not prove that the backup data is complete and recoverable.

Each log entry is a statement by a software system about what it observed. The accuracy of that statement depends on the correctness of the software, the accuracy of the system clock, the integrity of the input data, and the absence of interference. Each of these dependencies introduces uncertainty. The log entry is an assertion, not a proof.

Weakness Four: Logs Are Retrospective Evidence

Audit logs are reviewed after the fact. An auditor reviews logs during an annual audit, which may be months after the events were recorded. A forensic investigator reviews logs during an incident investigation, which may be weeks after the incident occurred. A regulator reviews logs during an examination, which may be years after the compliance period in question.

During the interval between event occurrence and log review, the logs exist without verification. No one confirms that the log entries are accurate when they are created. No one verifies the integrity of the log chain in real time. The logs accumulate, and their integrity is assumed until someone reviews them. This retrospective approach means that problems with the logs, whether modifications, gaps, or inaccuracies, are not detected until long after they occur, if they are detected at all.

Weakness Five: Logs Are Not Independently Verifiable

Audit logs are generated and stored by the organization that is being audited. The organization controls the logging system, the log storage, and the access to the logs. When the organization presents logs to an auditor, the auditor must trust that the logs are authentic and complete. The auditor can apply professional skepticism and perform tests of controls, but ultimately, the evidence originates from the entity being examined.

This creates a fundamental limitation in the evidentiary value of audit logs. The party that has the most to gain from favorable evidence is the party that controls the evidence. Compliance frameworks address this through auditor independence, sampling methodologies, and corroborating evidence. But the foundational evidence remains under the control of the audited entity, which is an inherent limitation that no amount of methodology can fully overcome.

Cryptographic Attestation: A Different Kind of Evidence

Cryptographic attestation addresses each of these five weaknesses by producing compliance evidence that is fundamentally different from audit logs. Instead of a software system recording an event and writing a log entry, cryptographic attestation produces a mathematical proof that an event occurred, that it occurred at a specific time, and that it is linked to the previous event in a tamper-evident chain.

Each attestation in the H33-74 system is a 74-byte cryptographic receipt that contains a commitment to the event, a timestamp, and a chain link. The attestation is signed with post-quantum signatures using three independent hardness assumptions: one from lattice-based cryptography, one from hash-based cryptography, and one from a structured lattice distinct from the first. Tampering with an attestation requires simultaneously breaking all three mathematical problems, which is computationally infeasible with any known or foreseeable technology, including quantum computers.

This approach addresses each of the five weaknesses of audit logs directly.

First, attestations cannot be modified without detection. Each attestation is cryptographically signed and chained to the previous attestation. Modifying any attestation in the chain invalidates the signature on that attestation and breaks the chain link, making the modification immediately detectable. This is not a policy control that can be bypassed by a sufficiently privileged administrator. It is a mathematical property of the cryptographic construction.

Second, attestation chains are verifiably complete. Because each attestation is chained to the previous one, any gap in the chain is immediately apparent. You cannot delete an attestation from the middle of the chain without breaking the chain. The completeness of the chain is a verifiable property, not an assumption.

Third, attestations prove occurrence, not just recording. The cryptographic construction binds the proof to the event itself. The attestation contains a commitment to the specific computation or verification that was performed. It is not a statement about the event; it is a cryptographic artifact of the event. The distinction is significant: a log entry is a description of an event, while an attestation is a mathematical consequence of the event.

Fourth, attestations provide real-time verification. Each attestation is independently verifiable at the moment it is created. There is no delay between event occurrence and evidence verification. The attestation chain can be verified continuously, not just during periodic audits. Problems are detectable immediately, not months later during an annual review.

Fifth, attestations are independently verifiable by any party. Any entity with access to the public verification key can confirm that each attestation is authentic and that the chain is intact. The audited organization does not need to be trusted because the evidence is self-proving. The auditor, regulator, or insurer can verify the evidence directly, without relying on the organization's representations.

Practical Applications in Compliance Frameworks

The transition from audit logs to cryptographic attestation has practical implications for every major compliance framework.

In SOC 2 engagements, auditors test the operating effectiveness of controls by examining evidence that the controls operated as designed throughout the audit period. With cryptographic attestation, the evidence is a verifiable chain of proofs rather than a sample of log entries. The auditor can verify the complete chain rather than sampling, which provides higher assurance with potentially less effort. The attestation chain also addresses the common SOC 2 finding of "gaps in logging" because the chain makes any gaps immediately visible.

In PCI DSS assessments, organizations must demonstrate that they protect cardholder data through specific security controls. Cryptographic attestation can provide continuous evidence that encryption controls are operating, that access controls are enforced, that monitoring is active, and that configuration standards are maintained. The assessor can verify this evidence independently rather than relying on the organization's representations and sample testing.

In HIPAA compliance, covered entities must demonstrate that they protect the confidentiality, integrity, and availability of protected health information. Cryptographic attestation provides continuous, verifiable evidence that security controls are in place and functioning. This is particularly valuable for Business Associate agreements, where covered entities must demonstrate that their business associates are complying with HIPAA requirements. Attestation data provides objective evidence of compliance that does not depend on the business associate's self-reporting.

In DORA compliance, financial entities in the European Union must demonstrate operational resilience through specific security and incident management controls. The continuous nature of cryptographic attestation aligns well with DORA's emphasis on ongoing operational resilience rather than point-in-time compliance. The tamper-evident attestation chain also addresses DORA's requirements for incident reporting and evidence preservation.

The Archival Dimension

Compliance evidence must be retained for years, sometimes decades. This creates a long-term integrity challenge that audit logs handle poorly. Log files can become corrupted over time. Storage media can degrade. Log formats can become obsolete. Organizations can migrate logging platforms, introducing the risk of data loss or modification during migration. Over a period of years, the integrity of audit logs degrades in ways that may not be detectable.

ArchiveSign, H33's long-term document attestation service, addresses this challenge by applying the same H33-74 cryptographic attestation to archived compliance evidence. Each piece of archived evidence receives a post-quantum attestation that remains verifiable regardless of how long it is stored. The attestation does not degrade over time. It does not depend on the integrity of the storage medium. It does not become obsolete as technology changes. The mathematical proof is permanent.

This is particularly important for post-quantum security. Compliance evidence that is archived today and signed with classical cryptographic algorithms may become vulnerable to quantum attacks in the future. If a quantum computer can forge the signatures on archived evidence, the evidentiary value of that evidence is destroyed. H33-74's three-family post-quantum signatures ensure that archived evidence remains verifiable and tamper-evident in a post-quantum environment. This is not a theoretical concern for evidence with retention periods measured in decades.

The Transition Path

The transition from audit logs to cryptographic attestation does not require organizations to abandon their existing logging infrastructure. Audit logs continue to serve valuable purposes: they provide human-readable records of events, they support operational troubleshooting, and they provide context that supplements the cryptographic evidence. The transition adds a layer of cryptographic attestation on top of existing logging, providing mathematical proof where logs currently provide only records.

Organizations can begin by attesting their most critical compliance controls: authentication events, access control decisions, encryption operations, and configuration changes. Over time, they can extend attestation to additional controls as their processes and tools mature. The H33-74 attestation system is designed to operate alongside existing logging infrastructure, not to replace it.

For auditors and regulators, the transition requires developing new verification procedures that incorporate cryptographic attestation evidence. This is a simpler task than it may appear, because the verification of an attestation chain is a deterministic process: either the chain is valid or it is not. There is no judgment involved in verifying a cryptographic proof, which actually simplifies the auditor's task compared to interpreting ambiguous log entries.

The compliance industry is at an inflection point. The limitations of audit logs have been known for decades, but there was no practical alternative. Cryptographic attestation provides that alternative. Organizations that adopt it gain compliance evidence that is tamper-evident, independently verifiable, continuously generated, and resistant to both current and future cryptographic attacks. Organizations that continue to rely solely on audit logs will find their compliance evidence increasingly inadequate as regulators, auditors, and insurers come to expect cryptographic proof.

The standard of evidence for compliance is rising. Logs were the best we had. Now we have proof. The question for every organization is whether they will adopt proof before their auditors, regulators, and insurers require it, or after.