Häufig gestellte Fragen
What is the difference between an audit trail and a normal log file?
An ordinary log file primarily serves technical troubleshooting and operations, for example to trace system crashes, performance problems or interface errors. An audit trail, by contrast, is designed for compliance and audit-proof record-keeping and captures business-relevant events together with the acting person, a timestamp and the old and new values. Tamper resistance is decisive: audit trail entries are written append-only and must not be editable unnoticed or deletable without a trace afterwards; they are often additionally secured by timestamps and cryptographic chaining. A technical log, on the other hand, can often be rotated or overwritten and generally does not meet these evidentiary requirements.
Is an audit trail legally required in Germany?
For accounting- and tax-relevant data, the obligation to keep traceable, unalterable records follows indirectly from the GoBD and from Section 146 of the German Fiscal Code (Abgabenordnung). Under these rules, postings and records must not be altered in such a way that their original content can no longer be established, and subsequent changes must remain recognisable as such. In regulated industries, further requirements apply, such as validation requirements in the pharmaceutical and medical-technology environment or for FDA-relevant processes under 21 CFR Part 11. Even though the term audit trail does not appear verbatim in the German statutes, such logging is in effect the technical prerequisite for meeting these evidentiary obligations.
How long must audit trail data be retained?
As a rule of thumb, an audit trail must be retained at least as long as the data it refers to. For tax-relevant documents in Germany, this means multi-year periods, whereby the retention period for accounting documents and invoices was, as a rule, shortened from ten to eight years by the Fourth Bureaucracy Relief Act (Viertes Bürokratieentlastungsgesetz) as of 1 January 2025, while commercial books and annual financial statements still require ten years. 21 CFR Part 11 also explicitly requires that the audit trail remain available at least for the period of the associated electronic records. For purely technical or access-related logs without a statutory period, the storage duration is instead guided by the principle of necessity for the respective purpose.
What information must a complete audit trail entry contain?
A meaningful entry answers the core questions of who triggered an action, when, what it was and ideally why. This includes a tamper-proof timestamp, the unique identifier of the acting person or technical service, the type of action — such as create, change, delete or approve — and the affected data record. In addition, the old and the new value are documented so that the specific difference can be traced, along with context information such as client (tenant), interface or transaction ID. In heavily regulated environments, for example under 21 CFR Part 11, a reason for the change is also recorded to make the justification for a correction verifiable.
How does an audit trail square with the right to erasure under the GDPR?
Two principles collide here: with its storage limitation principle, the GDPR requires personal data to be kept only as long as necessary for the purpose, while statutory retention obligations and evidentiary requirements may demand longer storage. In practice, the audit trail actually helps demonstrate compliance with the right to erasure, because it can be used to prove that and when a data record was properly deleted. The tension is resolved through a documented deletion and logging concept that defines which log data is stored, for how long and for what purpose. Log data itself is personal data and should therefore be kept purpose-bound, access-restricted and no longer than necessary.
Does an audit trail impair the performance of the ERP system?
Comprehensive logging generates additional write load and data volume, which can have a noticeable impact on performance and storage requirements when tracking is set up very broadly. In practice it is therefore advisable to log only the business- and compliance-critical tables and fields in a targeted manner rather than every event across the board. Modern ERP systems use separate log tables, asynchronous writing and archiving mechanisms for this in order to relieve ongoing transaction processing. It is also important to examine the configurable logging scope and the analysis capabilities as early as the selection process, since granularity and performance vary considerably between systems.