LGPD in Practice: What the Law Actually Requires From Your Audit Logs

The Law Is More Demanding Than Most Teams Assume

When companies assess their LGPD posture, the conversation usually focuses on privacy notices, consent flows, and data subject request handling. Those requirements matter. But there is another part of the law with equally serious operational consequences: the ability to produce trustworthy records of what happened to personal data.

Article 37 of the LGPD requires controllers and processors to maintain records of personal data processing activities. Article 38 gives the ANPD the authority to request those records.

The law does not prescribe a specific technical format. But the practical question it creates is clear: if the ANPD — or a data subject, in the context of a dispute — asks you to demonstrate that a specific processing activity occurred under the lawful basis you claim, can you actually prove it?

Showing that a record exists is not the same as showing that the record is accurate, complete, and unchanged.

When Logs Are Just Files, the Problem Begins

Most organizations store operational logs in databases, object storage, SIEM platforms, or observability tools. These systems are designed for retrieval, search, and operational visibility. They are not designed to make records tamper-evident.

In a conventional environment, someone with database administrator privileges can update or delete a log entry. That action may not trigger an alert. It may leave no evidence in the log itself. A timestamp can be edited. A user identifier can be changed. A recorded action can disappear entirely.

This is not a theoretical concern. Access to production systems is often broader than policy suggests. Incidents happen. And once a regulatory inquiry or internal investigation begins, the question of who could have modified the records quickly becomes central.

If the answer is "several people had the technical ability to do it," the credibility of the records drops immediately — even if no one actually changed them.

Three Situations Where This Turns Into a Real Problem

Healthcare Platform Under ANPD Review

A digital health company stores sensitive patient data. After a complaint from a data subject, the ANPD requests evidence of all processing activities involving that patient’s records during a specific period.

The company retrieves the logs from its database. The relevant operations appear to be there. But the ANPD asks for technical assurance that the records accurately reflect what happened and were not altered after the fact.

The company cannot provide that assurance.

The issue is no longer just whether records exist. It becomes a broader question about the company’s data governance, internal controls, and evidentiary reliability. What started as a records request becomes a larger compliance problem.

Financial Services Company Handling Sensitive Consumer Data

A credit or financial analysis company processes large volumes of personal financial information. During a security and compliance review by a potential enterprise customer, the customer asks whether access to personal data is logged in a way that supports both post-incident investigation and regulatory production.

The company explains that access events are stored in a relational database protected by role-based access controls.

The customer then asks a simpler and more important question: can those logs be altered by internal staff?

The honest answer is yes.

The deal does not move forward. The customer chooses a competitor with write-once, hash-chained, independently verifiable records.

The difference was not product capability. It was infrastructure auditability.

SaaS Company Facing a Data Subject Dispute

A B2B SaaS company receives a formal request from a data subject who claims their data was accessed for purposes beyond what had been disclosed.

The company’s logs do not show unauthorized access. But the data subject argues that those records could have been modified after the fact.

Without cryptographic proof that the logs remained unchanged from the moment they were written, the company cannot definitively refute that claim.

That does not automatically create liability. But it removes the clearest path to resolution and makes the dispute slower, more expensive, and less predictable.

What LGPD-Compatible Audit Logs Need in Practice

The LGPD does not impose a specific technical standard for log integrity. But if records must hold up under scrutiny from regulators, auditors, customers, or data subjects, certain properties become practically necessary.

First, records need to be written in a way that makes post-hoc modification detectable. That means cryptographic hashing at write time, where each event produces a fingerprint tied to its exact contents. If the event changes, the fingerprint no longer matches.

Second, records need a verifiable chain of custody. Each event should incorporate the hash of the previous one, creating an ordered sequence where silent deletion, insertion, or reordering becomes detectable.

Third, records need to be independently verifiable. A regulator, auditor, or legal representative should be able to validate a specific record using the event data and hash specification, without needing privileged access to internal systems or a reason to trust the organization’s word.

Together, these properties turn a log from a collection of internal records into a defensible evidence trail.

The Timing Problem

Many compliance teams evaluate logging infrastructure during audit preparation or after an incident. Both are the wrong time to discover that records cannot be verified.

At that point, the events already exist in their current form. You cannot retroactively add cryptographic integrity to records that were written without it. You can improve the system going forward, but the historical gap remains.

That is what makes this a timing problem.

Building tamper-evident logging early is a one-time architectural decision. Discovering during a regulatory inquiry that your historical records are not defensible is a much more expensive problem — and one without a clean fix.

Getting Ahead of the Question

The ANPD is active. Data subject complaints are increasing. Enterprise customers in regulated sectors are asking more detailed questions during due diligence. The ability to demonstrate accurate records of data processing is becoming a baseline expectation, not an advanced maturity signal.

The organizations that answer these questions well are not doing anything extraordinary. They made an early decision about how events would be recorded, stored, and verified.

That decision later shows up as faster investigations, stronger responses to data subject requests, cleaner regulatory interactions, and more confidence in enterprise security reviews.

The question is not whether this scrutiny will reach your organization.

The question is whether your infrastructure will be ready when it does.

See how ImmutableLog helps teams build audit logs that hold up under regulatory review. Talk to us →