Feb 26, 2026
Audit logs: What it is, how it works & key requirements
Audit logs are one of those subjects that sit at the intersection of legal obligation, technical infrastructure, and organisational culture. They are easy to dismiss as an IT concern until they become a boardroom crisis. And in the EU, where the regulatory landscape has never been more demanding, organisations that have not taken audit logging seriously are finding themselves increasingly exposed.
This guide is for the people who want to get this right. Whether you are a compliance lead trying to understand your obligations, a technical team building or reviewing your logging infrastructure, or a business owner who has heard the words "audit trail" and wants to understand what they actually mean in practice, this is a comprehensive, plain-language resource grounded entirely in factual regulatory requirements.
What Is an Audit Log?
An audit log, sometimes called an audit trail, is a chronological, tamper-evident record of events that have occurred within a system, application, or organisation. Think of it as a detailed, automatic diary that your systems maintain without being asked: who did what, to which data, at what time, and from where.
An audit log entry typically captures:
Who took the action (user ID, role, or system process)
What action was performed (login, data access, modification, deletion)
When it happened (timestamp, ideally with timezone)
Where it happened (IP address, device, system module)
Why, where technically feasible (purpose of access, especially relevant under GDPR)
Audit logs exist at multiple levels. System logs record infrastructure events like server restarts and network connections. Application logs track actions within software, such as who opened a file or changed a record. Security logs capture authentication events, access attempts, and policy changes. Each of these levels serves a different purpose, and a mature audit log programme will cover all three in a coordinated, consistent way.
The key distinction between a regular system log and an audit log is intentionality and integrity. An audit log is designed to be a reliable, unalterable record for accountability purposes. It should not be something that can be quietly edited or deleted by the same people it monitors. That integrity is what makes it useful, both for internal governance and for demonstrating compliance to an external authority.
What Are Audit Logs Used For?
Audit logs serve several overlapping purposes, and understanding each one helps you design your logging approach more intelligently.
Regulatory compliance is the most obvious driver in regulated industries. Supervisory authorities in the EU, from data protection authorities under GDPR to national cybersecurity bodies under NIS2, can request audit logs to verify that your organisation is behaving as it claims. Logs are how you demonstrate accountability rather than merely assert it.
Security incident investigation is another critical use case. When a breach occurs, audit logs let you reconstruct exactly what happened: which account was compromised, which data was accessed, and how far the attacker moved through your systems. Without logs, you are guessing. And guessing costs you both in fines and in the trust of the customers, partners, and regulators you work with.
Internal accountability matters too. Audit logs help organisations detect insider threats, enforce access policies, and ensure that sensitive data is only touched by people with a legitimate reason to touch it. They create a culture of accountability without requiring constant manual supervision. Knowing that actions are logged changes behaviour, and in regulated environments, that change in behaviour is genuinely valuable.
Data subject rights fulfilment under GDPR is increasingly important. When an EU data subject submits a Subject Access Request under Article 15 of the GDPR, your logs should be able to show what data you hold about them, when it was accessed, and by whom. Without a reliable audit trail, responding accurately and within the statutory one-month deadline becomes extremely difficult.
Operational continuity and system health monitoring is a less-discussed benefit but a real one. Logs that capture system behaviour over time help you identify performance degradation, identify misconfigured systems, and detect patterns that predict failure before it happens. In that sense, audit logs are not just a compliance asset; they are an operational one.
How Does an Audit Log Work?
Understanding the mechanics helps you make better decisions about what to log and how to store it.
When a user or system performs an action, say, an employee opens a customer record in your CRM, the application generates a log entry automatically. This entry is written to a secure, append-only log store. Append-only is important: in a properly designed audit log system, you can add new entries but you cannot edit or delete existing ones without generating an alert. This tamper-evidence is what makes audit logs trustworthy as evidence.
In practice, most organisations route logs to a centralised log management platform, sometimes called a SIEM (Security Information and Event Management) system. This aggregates logs from multiple sources, making it easier to search, correlate events, and alert on suspicious activity in real time.
Log data is typically structured using a standard format such as JSON or syslog so that entries from different systems can be compared and analysed consistently. Structured logging matters more than people realise: unstructured logs that require manual interpretation slow down incident response and make regulatory reporting significantly harder.
The lifecycle of a well-designed audit log looks like this:
Event occurs — a user action, system change, or access attempt happens
Log entry generated — the system automatically creates a structured record
Entry written to secure storage — encrypted, access-controlled, and timestamped
Real-time monitoring — security teams or automated tools watch for anomalies
Retention and archiving — logs are kept for the required period, which varies by regulation
Secure deletion — logs are disposed of properly once retention periods expire
That last step, deletion, is one many organisations miss entirely. Under GDPR's data minimisation principle, keeping logs indefinitely is itself a compliance risk. More on this below.
What Makes an Audit Log Legally Defensible?
This is a question that does not get asked enough, and it matters enormously. There is a meaningful difference between having logs and having logs that will hold up when scrutinised by a regulator, an auditor, or in a legal proceeding.
A legally defensible audit log needs to satisfy several conditions simultaneously. First, it must be complete: critical events cannot be missing. If your logs capture logins but not data access events, or capture modifications but not deletions, then significant accountability gaps exist. Regulators and auditors are trained to notice what is absent, not just what is present.
Second, the log must be authentic. Authenticity means you can demonstrate that the log accurately reflects what occurred, that entries have not been altered after the fact, and that timestamps are reliable. Reliable timestamps require synchronisation with a trusted time source, such as an NTP server. Logs with inconsistent or incorrect timestamps are a credibility problem in any formal proceeding.
Third, the log must be attributable. Every entry should tie back to a specific identity, whether that is a named user account, a service account, or a system process. Anonymous or pseudonymous entries that cannot be linked to an individual or system offer limited accountability value and may not satisfy GDPR's accountability requirements under Article 5(2).
Fourth, the log must be accessible in a usable format. Logs stored in proprietary formats that require specialist tools to read, or buried in systems that take days to query, are a practical problem even if they technically exist. Regulatory requests often come with short deadlines. NIS2 incident reporting timelines, for example, begin at 24 hours for an early warning notification. If extracting relevant log data takes longer than that, your logs are not operationally useful.
Key Requirements for Audit Logs Under EU Regulations
Here is where things get specific, and where many regulated businesses in the EU have genuine gaps. Three major regulatory frameworks impose direct or indirect audit log requirements: GDPR, the NIS2 Directive, and the EU AI Act.
1. GDPR: Records of Processing Activities and Access Logging
GDPR does not use the term "audit log" explicitly, but the requirements are clear. Article 30 of the GDPR requires both data controllers and processors to maintain comprehensive records of processing activities. These records must document the purposes of processing, categories of data and data subjects, recipients, retention periods, and security measures.
Beyond Article 30, Article 32 requires organisations to implement appropriate technical and organisational measures to ensure data security. Logging is a core part of this. Specifically, you need to be able to log and track:
Every instance of access to personal data including who accessed it, when, and for what purpose
Modifications to personal data including what changed, who changed it, and when
GDPR-specific activities including consent obtained, data subject requests received and actioned, and Data Protection Impact Assessments conducted
Article 28 also requires processors to make all information necessary to demonstrate compliance available to controllers, including through audits. This means your processors, cloud providers, SaaS vendors, and anyone handling personal data on your behalf, need to maintain their own audit logs and give you access to them.
On retention periods: GDPR does not specify a fixed log retention period, but it does require that personal data not be kept longer than necessary. France's data protection authority CNIL recommends that active logs containing personal data be retained for no more than 6 months, after which they should be archived with restricted access or anonymised. Germany's BSI and other national authorities have their own guidance that may differ. The practical takeaway is to document your retention rationale, define it explicitly in your retention policy, and automate deletion.
Critical GDPR nuance on logs as personal data: Logs themselves frequently contain personal data, including IP addresses, user IDs, email addresses, and timestamps linked to individuals. The European Court of Justice has confirmed that dynamic IP addresses can constitute personal data. This means your audit logs are not just tools for compliance, they are also subjects of compliance. They must be encrypted at rest and in transit, access-controlled, and subject to the same data minimisation principles as any other personal data you hold.
Potential fines for non-compliance: GDPR violations can result in fines of up to €20 million or 4% of global annual turnover, whichever is higher.
2. NIS2 Directive: Logging as Cybersecurity Infrastructure
The NIS2 Directive came into force on 18 October 2024, replacing the original NIS Directive and significantly expanding both scope and enforcement. NIS2 applies to medium and large organisations with 50 or more employees or turnover of €10 million or more, in sectors including energy, healthcare, banking, transport, digital infrastructure, and more.
Where NIS2 directly touches audit logging is through its risk management and incident response obligations. Under Article 21, in-scope organisations must implement security measures covering:
Incident detection and response which requires event logging and monitoring capabilities
Access control and asset management meaning logs of who has access to what
Supply chain security extending logging obligations to third-party risk monitoring
NIS2 gives national supervisory authorities the power to conduct targeted audits, security inspections, and on-site checks, and to request logs as evidence of compliance. Essential entities in sectors of highest criticality are subject to proactive, regular supervision, while important entities are supervised reactively when issues are flagged.
Enforcement is serious. Essential entities face fines of up to €10 million or 2% of global annual turnover. Important entities face up to €7 million or 1.4% of global annual turnover. Crucially, NIS2 also introduces personal liability for senior management. Executives can be temporarily banned from leadership roles following significant cybersecurity failures.
Most EU Member States were required to transpose NIS2 into national law by October 17, 2024. As of early 2026, implementation varies: Belgium, Italy, Hungary, and others have enacted national legislation, while Germany, France, Spain, and Ireland are still in various stages of progression. Even where national law is not yet finalised, the EU-level obligations apply, and enforcement is beginning across the bloc.
3. EU AI Act: Automatic Logging for High-Risk AI Systems
The EU AI Act (Regulation (EU) 2024/1689) introduces specific and binding audit log requirements for high-risk AI systems. Article 12 is the key provision.
What counts as "high-risk"? Under the AI Act's Annex III, high-risk use cases include AI systems used in hiring and HR decisions, access to education, credit scoring and lending, health and safety, law enforcement, migration control, and the administration of justice. If your AI system affects any of these areas, Article 12 applies.
Article 12 requires that high-risk AI systems technically allow for the automatic recording of events over the lifetime of the system. These logs must enable:
Identification of situations that may result in the AI system presenting a risk
Post-market monitoring of system behaviour after deployment
Monitoring of the system's operation by deployers
For AI systems used in remote biometric identification, logs must additionally capture the precise start and end times of each use, the database against which input data was checked, the input data that led to a match, and the identities of the natural persons who verified results.
Article 19 specifies that providers must retain automatically generated logs for at least 6 months, or longer where required by other applicable law.
The Five Core Requirements for Effective Audit Logs
Across GDPR, NIS2, and the AI Act, a consistent set of principles emerges. Your audit logs should satisfy all five to be considered compliance-grade.
1. Completeness: log the right events. Not every system event needs to be an audit log entry, but every access to personal data, every privileged action, every configuration change, and every security event should be. Define your event taxonomy clearly and document it.
2. Integrity: logs must be tamper-evident. A log that can be quietly altered by the same administrator it monitors is not an audit log, it is a liability. Use append-only storage, cryptographic hashing, or dedicated log management platforms to ensure integrity. This is especially important under NIS2, where logs are potential evidence in enforcement proceedings.
3. Security: encrypt and control access. Logs containing personal data must be encrypted at rest and in transit. Access to logs should be role-based and itself logged. The irony of logs that are not themselves logged is not lost on auditors.
4. Retention with defined expiry. Define a retention period for each log type, document the justification, and automate deletion. Logs kept indefinitely are a GDPR liability. Logs deleted too soon make incident investigation and regulatory response impossible. The right balance depends on your sector, the type of data, and applicable national guidance.
5. Accessibility and searchability. Logs are only useful if you can find what you need quickly. A regulator requesting evidence of a specific access event from 90 days ago should not take your team days to fulfil. Centralised log management with robust search and export capability is not a luxury; it is a compliance requirement in practice.
What Good Audit Log Governance Actually Looks Like
Many organisations have the technical infrastructure in place but lack the governance framework to make that infrastructure meaningful. Audit log governance means defining, documenting, and regularly reviewing the policies and procedures that surround your logging capability.
A mature governance framework includes a log inventory: a documented register of all systems that generate logs, what events each system captures, where logs are stored, who has access, and what the retention period is. Without this inventory, you cannot demonstrate control over your logging estate, and you will struggle to answer even basic regulatory questions accurately.
It also includes a regular review cycle. Logs should be reviewed not just when an incident occurs but as a routine operational practice. Many regulated organisations are now scheduling periodic log reviews as part of their internal audit programmes, ensuring that logging configurations remain appropriate as systems evolve.
Finally, good governance includes testing. Just as you would test your backups to confirm they actually restore, you should periodically test your log extraction and reporting capability to confirm that you can retrieve the data you need, in the format you need it, within a timeframe that meets regulatory deadlines.
Common Audit Log Failures in Regulated Industries
These are the gaps seen most frequently in organisations that believe they are compliant but are not.
Logs exist but are never reviewed. Having logs is not the same as having a monitoring programme. NIS2 in particular requires that organisations actively monitor and respond to incidents. Passive log storage is insufficient.
Logs contain too much personal data. System logs that capture full email addresses, unredacted health data, or complete financial records need to be treated as personal data under GDPR. Many organisations have not audited their log content at this level of detail.
No defined retention policy. Logs sitting in storage with no end date are a ticking compliance risk. GDPR's storage limitation principle (Article 5(1)(e)) applies to logs just as it applies to customer databases.
Third-party logs not covered. If you use cloud services, SaaS platforms, or AI tools, your suppliers' logs are relevant to your compliance picture. Article 28 of GDPR requires processors to support audits. Make sure your contracts reflect this and that you actually exercise this right.
Logs not encrypted or access-controlled. A log file sitting in an accessible network share is not a secure audit trail. Encryption and access control are not optional extras.
No documented log governance policy. Having logs but no written policy governing who can access them, how long they are kept, and what constitutes a reviewable event is itself a compliance gap under GDPR's accountability principle.
About SpeedyDD
At SpeedyDD, we work with complex and regulated businesses across the EU that cannot afford to be caught off guard by an audit. Our mission is simple: to make audit-readiness the default state of your organisation, not a scramble that happens every time a regulator calls.
We understand the pressure that comes with operating in regulated environments where GDPR, NIS2, the EU AI Act, and sector-specific frameworks all overlap, and where the cost of non-compliance is measured not just in fines but in trust, reputation, and operational disruption. We help businesses build the logging infrastructure, documentation frameworks, and monitoring processes that turn compliance from a burden into a business asset.
If you are unsure whether your current audit log practices would hold up to scrutiny, the honest answer is: find out now, not when you are asked to prove it.
Frequently Asked Questions
Q: Do small businesses need audit logs under GDPR? A: Yes. GDPR applies to any organisation that processes personal data of EU individuals, regardless of size. The record-keeping obligation under Article 30 has a limited exemption for organisations with fewer than 250 employees, but only where processing is not a risk to individuals' rights, is not carried out regularly, or does not involve sensitive categories of data. In practice, most businesses processing personal data regularly fall outside this exemption. When in doubt, maintain records.
Q: How long should audit logs be retained in the EU? A: There is no single EU-wide answer. GDPR requires that personal data including logs not be kept longer than necessary for its stated purpose. France's CNIL recommends a maximum of 6 months for active logs containing personal data. The EU AI Act requires that AI system logs be kept for at least 6 months. NIS2 does not specify a retention period for security logs but requires that organisations be able to demonstrate incident response capability, implying logs must be retained long enough to support investigations. Sector-specific regulation such as DORA for financial services may impose longer retention. The right approach is to define a documented retention policy per log type, with a clear legal basis for the period chosen.
Q: What is the difference between an audit log and a system log? A: All audit logs are a type of system log, but not all system logs are audit logs. A system log captures technical events for operational purposes such as errors, performance metrics, and system health. An audit log is a specifically structured, tamper-evident record designed for accountability and regulatory purposes. It is focused on who did what to which data and when, and it is maintained with integrity protections that operational logs often lack.
Q: Can we use cloud provider logs to satisfy our GDPR and NIS2 obligations? A: Partially. Cloud providers such as AWS, Azure, and Google Cloud generate their own logs for infrastructure-level events, and these can form part of your compliance picture. However, application-level audit logs capturing what users do within your systems and with personal data are your responsibility. Under Article 28 of GDPR, processors must support your audit rights, so ensure your cloud contracts include appropriate provisions. You cannot fully outsource audit log compliance to a vendor.
Q: Does the EU AI Act apply if we only use a third-party AI tool, not build our own? A: Yes, in some cases. The EU AI Act distinguishes between providers who develop and deploy AI systems and deployers who use AI systems in a professional context. Deployers of high-risk AI systems have obligations under the Act, including monitoring the system's operation and retaining automatically generated logs for at least 6 months under Article 26(6). If your AI vendor does not provide logs that meet Article 12 requirements, this is a contractual and compliance risk you need to address.
Q: What happens if our audit logs are found to be inadequate during an inspection? A: Consequences vary by regulation. Under GDPR, inadequate logging that contributes to a data breach or inability to demonstrate accountability can result in fines of up to €20 million or 4% of global turnover. Under NIS2, essential entities face fines of up to €10 million or 2% of global revenue, and senior management may face personal liability. Under the EU AI Act, market surveillance authorities can require corrective actions, impose fines, and in serious cases withdraw a product from the EU market. Beyond financial penalties, the reputational impact of a public enforcement decision can be significant.
Q: Are audit logs required for data subject requests (DSARs)? A: Audit logs are essential infrastructure for responding to Data Subject Access Requests under Article 15 of GDPR. When an individual requests to know what data you hold about them and how it has been used, your logs should be able to provide a record of access and processing history. They are also critical for responding to erasure requests under the right to be forgotten in Article 17, where you need to confirm that data has actually been deleted across all systems.
Q: What is the NIS2 incident reporting requirement and how do audit logs support it? A: Under NIS2, in-scope organisations must report significant cybersecurity incidents to their national supervisory authority within 24 hours as an early warning and submit a full report within one month. Audit logs are critical to this process: they allow you to reconstruct the incident timeline, determine what data was affected, identify the initial vector of compromise, and demonstrate to regulators what your detection and response looked like. Without adequate logs, incident reporting becomes guesswork, which regulators notice.
Q: Do audit logs need to be stored within the EU? A: GDPR's data transfer rules apply to logs that contain personal data. Transferring log data to a third country outside the EU or EEA requires an appropriate legal mechanism, such as an adequacy decision, Standard Contractual Clauses, or another approved safeguard under Chapter V of GDPR. Many regulated organisations choose EU-based log storage to avoid this complexity entirely.
Q: What does "tamper-evident" mean in practice for audit logs? A: Tamper-evidence means that any alteration to a log entry can be detected. In practice, this is commonly achieved through cryptographic hashing where each log entry includes a hash of the previous entry creating a chain, write-once storage where logs can be added to but not edited or deleted, or third-party log management platforms that enforce these controls. Tamper-evidence is particularly important under NIS2 and in any situation where logs may be used as legal evidence.
Q: What is the difference between logging and monitoring, and do we need both? A: Logging and monitoring are related but distinct. Logging is the act of recording events as they occur. Monitoring is the active process of reviewing those records to detect anomalies, threats, or policy violations in real or near-real time. You need both. Logs without monitoring are a historical archive you only consult after something has gone wrong. Monitoring without logs has no reliable data to work from. NIS2 in particular requires organisations to have incident detection capability, which means active monitoring, not just passive log collection.
Q: How does DORA affect audit log requirements for financial services firms in the EU? A: The Digital Operational Resilience Act (DORA), which applies to financial entities including banks, insurance companies, investment firms, and their critical ICT service providers, requires comprehensive logging as part of ICT risk management under Article 9. Financial entities must maintain logs of ICT-related incidents, user access events, and system changes. DORA generally requires that logs be retained for longer than GDPR's default guidance, and the European Supervisory Authorities have issued regulatory technical standards that include specific logging requirements. If you are in financial services, DORA operates alongside GDPR and NIS2 rather than replacing them, and the most stringent applicable requirement on any given point will generally be the one you need to meet.
This article was last reviewed in February 2026 and reflects requirements under GDPR (Regulation (EU) 2016/679), the NIS2 Directive (Directive (EU) 2022/2555), and the EU AI Act (Regulation (EU) 2024/1689). Regulatory guidance evolves; always verify current requirements with your legal or compliance advisors and consult relevant supervisory authority guidance for your sector and member state.