What are Immutable Audit Logs?

Immutable Audit Logs: Definition

Immutable audit logs are records of system and operational events designed so that, once an entry has been created, it cannot be deleted or modified without leaving evidence. In practice, this means using technical and organizational controls that ensure the integrity, accountability, and verifiability of the operational history. In environments that process photos and video recordings, such logs document not the image content itself, but the actions performed on files, tasks, and system configuration.

In the context of photo and video anonymization, immutable audit logs help demonstrate who initiated the process of blurring faces or license plates, when it was initiated, on what basis, which file was processed, which version of the detection model was used, what the outcome was, and whether the operator made manual corrections. This is important for the accountability principle under Article 5(2) of the GDPR, which requires the controller to be able to demonstrate compliance with the Regulation. The GDPR itself does not prescribe a specific immutability technology, but it does require appropriate security measures, including ensuring the integrity and confidentiality of processing, as well as the resilience of systems and services-Article 5(1)(f) and Article 32 of the GDPR, Regulation (EU) 2016/679.

An immutable audit log is not the same as a standard application log. Ordinary logs can be overwritten, shortened through rotation, or deleted by an administrator. An immutable log should be resistant to such actions, for example through the use of WORM storage, cryptographic hash chains, digital signatures, qualified or other reliable timestamps, or retention controls at the file system or object-storage level.

The Role of Immutable Audit Logs in Photo and Video Anonymization

In image anonymization workflows, auditability matters not only for IT security, but also for legal compliance and operational quality. A Data Protection Officer or auditor must be able to reconstruct the course of an operation without accessing the personal data itself, unless such access is necessary.

In practice, immutable audit logs support several areas at the same time:

• accountability - demonstrating that the material was anonymized before sharing or publication,
• process integrity - confirming that the result was not altered after anonymization,
• access control - recording which user opened a task, approved a result, or made a manual edit,
• forensics - analyzing incidents, detection errors, and unauthorized actions,
• AI model management - linking the result to a specific version of the face or license plate detection model.

In a system such as Gallio PRO, the audit log should cover operations on anonymization tasks as well as system administration activities. In line with product requirements, the system should not store logs containing the face and license plate detections themselves, or other personal data, unless this is necessary for the audit purpose. This means the logging design must separate evidentiary data from content that could unnecessarily expand the scope of personal data processing.

What Events Should Be Included in an Audit Log

The scope of logging should be limited to the information necessary for auditing, security, and demonstrating compliance. In photo and video processing environments, it is best practice to log operational metadata rather than image content.

Technologies Used to Ensure Immutability

Immutability does not result from the mere fact that a log is written. It must be enforced by the system architecture. In most cases, several layers of protection are used together to make both accidental modification and intentional tampering more difficult.

• WORM - Write Once, Read Many. Once written, data cannot be changed during the retention period. This mechanism is used in optical media, storage arrays, and object storage.
• Hash chaining - each entry contains the hash of the previous entry. Changing a single record breaks the integrity chain.
• Digital signature - an entry or a batch of logs is signed with a private key, making manipulation detectable.
• Qualified or other reliable timestamp - confirms that the entry existed at a specific point in time.
• Separate audit storage - logs are sent to a repository with separate administrative permissions.

In practice, integrity verification may rely on hash functions from the SHA-2 family. FIPS 180-4, issued by NIST, defines SHA-256 and SHA-512 among the standard hash algorithms. For digital signatures and timestamps, relevant ETSI trust services documents apply, including ETSI EN 319 421 and ETSI EN 319 422, which set policies and requirements for time-stamping authorities. If logs are stored in cloud or object-storage systems, retention policies and deletion locks at the storage-medium level are also important.

Key Parameters and Metrics for Immutable Audit Logs

Assessing the quality of audit logs should not be limited to confirming that logs exist. Measurable parameters are needed so they can be verified during an audit or security test.

In regulated environments, the concepts of complete, consistent, enduring, and available, as well as attributable, legible, contemporaneous, original, and accurate-known collectively as ALCOA+-are also used. Although the term originates in regulated industries, it provides a useful framework for audit log requirements beyond those sectors as well.

Importance for AI Used to Blur Faces and License Plates

Automatic face blurring and license plate blurring rely on image detection models, typically trained using deep learning. The AI model itself does not ensure compliance or auditability. The result must be linked to a specific model version, detection-threshold configuration, and operator decisions.

The logs should record, among other things:

• the model identifier and version,
• the date the model was deployed to the production environment,
• runtime parameters, such as the confidence threshold, if configurable,
• whether the result was corrected manually,
• the checksum of the input file and output file.

Such data should not include the detection coordinates themselves if the data minimization policy excludes recording information that could be used to reconstruct the presence of specific individuals or vehicles. This is an important distinction: auditing the process does not require storing data that increases privacy risk.

Challenges and Limitations

An immutable audit log does not solve every problem. If the system records an incorrect event, the log will faithfully preserve that error. If the right event scope was not designed in advance, later analysis will be incomplete. In addition, overly broad logging may lead to excessive processing of personal data.

The most common issues include:

• lack of time synchronization between system nodes,
• log rotation without preserving the integrity chain,
• shared administrator accounts, which weaken accountability,
• logging data that does not need to be preserved from an audit perspective,
• lack of a regular procedure for verifying signatures and hashes.

Normative References and Standards

When designing and evaluating immutable audit logs, it is worth relying on primary source documents. Not all of them use the term “immutable audit logs” explicitly, but they define requirements for integrity, accountability, event logging, and log protection.

• GDPR - Regulation (EU) 2016/679, Article 5(1)(f), Article 5(2), Article 24, Article 32.
• ISO/IEC 27001:2022 - requirements for an information security management system.
• ISO/IEC 27002:2022 - security controls, including logging, monitoring, and information protection.
• NIST SP 800-92, Guide to Computer Security Log Management, 2006 - security log management.
• NIST SP 800-53 Rev. 5, 2020 - AU controls related to audit and accountability.
• FIPS PUB 180-4, NIST, 2015 - Secure Hash Standard.
• ETSI EN 319 421 and ETSI EN 319 422 - requirements for time-stamping services.