Compliance Software Audit Trails: Mandatory Content 2026

Main article: Accountability (glossary) — the controller's duty to demonstrate compliance under Art. 5(2) GDPR, which an audit trail supports.

1. Mandatory content per log entry

Timestamp (UTC), user ID, action (read/write/delete), record concerned (hash), outcome (success/fail), IP address.

Each of these fields answers a question that is actually asked in a supervisory, notification or data-subject procedure: when, who, what, which record, with what outcome, from where. The greatest weight lies with the timestamp, because it is the anchor point for the statutory deadlines. The notification duties run from the moment of becoming aware — Art. 33(1) GDPR for a personal data breach, and in Germany § 32(1) BSIG for a significant security incident. The response duties run from receipt: Art. 12(3) GDPR from receipt of a data subject request, § 17(1) no. 1 HinSchG from receipt of a report. Added to this is the duty to give reasons where a deadline is exceeded under Art. 33(1) GDPR (see the deadlines table) — this too relies on logs.

For write actions, the before-and-after values of the modified field are added; without them, a change cannot be reconstructed after the event. The record concerned is logged as a hash rather than in plain text — the log thus remains attributable without duplicating the data content. The outcome field (success/fail) separates successful from blocked access and is the basis for the failed-login analysis in section 3.

2. GDPR-specific

Log access to personal data. For particularly sensitive data: an additional note on the purpose.

'Particularly sensitive' refers to the special categories under Art. 9(1) GDPR: data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs or trade union membership, as well as genetic data, biometric data for the purpose of uniquely identifying a natural person, health data and data concerning a person's sex life or sexual orientation. Processing them is prohibited in principle and permitted only via an exception under Art. 9(2) GDPR — for example explicit consent. The note on the purpose should therefore record which exception the access is based on.

Two further records belong in the same data set. First, the legal basis: processing is lawful only if at least one of the six grounds under Art. 6(1) GDPR applies (consent, contract, legal obligation, vital interests, public interest, legitimate interests). Second, consent: where processing is based on consent, the controller must be able to demonstrate that the data subject has consented (Art. 7(1) GDPR); withdrawal is possible at any time and must be as easy as giving consent (Art. 7(3) GDPR). Giving and withdrawing consent therefore each require their own time-stamped entry.

Data subject requests under Art. 15 to 22 GDPR must be answered without undue delay and in any event within one month of receipt; the period may be extended by two months where the complexity and number of requests require it, and the data subject must be informed of the extension within one month, together with the reasons (Art. 12(3) GDPR). Without a logged date of receipt, none of these periods can be evidenced.

3. NIS2-specific

Privileged access logs, configuration changes, failed login attempts. Retention of 90 days operational plus 12 months archive: a practitioner value, not a statutory period. Neither the NIS2 Directive nor the BSIG prescribes log retention periods. What the law requires is that compliance with the risk-management duty be documented (§ 30(1) sentence 3 BSIG; catalogue of measures § 30(2) nos. 1–10 BSIG, Art. 21(1) and (2) of Directive (EU) 2022/2555 — both without a retention period). A fixed cycle exists only for operators of critical installations: evidence of implementation through security audits, reviews or certifications no earlier than three years after first classification and every three years thereafter (§ 39(1) BSIG).

In substance, § 30(1) BSIG requires particularly important entities and important entities to take appropriate, proportionate and effective technical and organisational measures to avoid disruptions to the availability, integrity and confidentiality of IT systems and to keep the impact of security incidents to a minimum. The minimum catalogue in § 30(2) nos. 1 to 10 BSIG lists, among other things, risk analysis, incident handling, business continuity, supply chain security, cryptography, access control and multi-factor authentication. In practice, the three types of log named above evidence precisely these areas: privileged access logs and failed login attempts cover access control and authentication, configuration changes cover the traceability of changes to the measures themselves. What counts as a significant security incident is defined in § 2 no. 11 BSIG — the notification duty itself follows from § 32(1) BSIG: a security incident is significant if it has caused or is capable of causing severe operational disruption of services or financial loss for the entity, or has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage.

DE/AT note: the NIS2 part of this article reflects German law (BSIG 2025). In Austria, the NISG 2026 (Federal Law Gazette I no. 94/2025) takes the place of the BSIG; it applies from the start of its application on 1 October 2026: risk-management measures under § 32(1) and (4) NISG, registration with the Cybersecurity Authority (Cybersicherheitsbehörde, Austria) under § 29 NISG, notification of significant incidents under § 34 NISG (24 h / 72 h / 1 month) to the competent CSIRT. For furnishing evidence, Austria applies no three-year cycle but § 33 NISG: a structured self-declaration of the measures implemented within twelve months of the registration duty arising and — upon request — evidence from an independent body; that evidence must be provided within two years, while essential entities must evidence operational and organisational implementation within two months of the request (§ 33(1) and (2) NISG). In Austria, a cybersecurity incident is significant if it has caused or is capable of causing severe operational disruption of the services provided or severe financial loss for the entity, or has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage (§ 35(1) NISG). The NISG 2026 likewise prescribes no log retention periods.

4. HinSchG-specific

Every action in reporting-office software. Immutable. Retention for three years after the procedure is closed (§ 11(5) HinSchG).

The reason for gap-free logging is the confidentiality requirement: reporting offices must preserve the confidentiality of the identity of the reporting person, of the persons who are the subject of a report and of the other persons named in the report; the identity may be disclosed only to the persons responsible for receiving reports and taking follow-up measures and to those supporting them (§ 8(1) HinSchG). An access log is the way to evidence this restriction in the event of a dispute. Two deadlines are added that cannot be evidenced without timestamps: acknowledgement of receipt no later than seven days after receipt (§ 17(1) no. 1 HinSchG) and feedback on planned and already taken follow-up measures within three months of the acknowledgement of receipt — or, where receipt was not acknowledged, no later than three months and seven days after receipt (§ 17(2) HinSchG). In Germany, the duty to set up an internal reporting office applies to employers with, as a rule, at least 50 employees (§ 12(1) sentence 1 and (2) HinSchG). Anyone who obstructs a report, takes a reprisal or fails to preserve confidentiality commits an administrative offence — a fine of up to EUR 50,000; the absence of an internal reporting office carries a fine of up to EUR 20,000 (§ 40(2) to (6) HinSchG).

DE/AT note: in Austria the HSchG applies instead of the HinSchG: personal data must be retained for five years from the last processing or transfer operation (§ 8(11) HSchG); log data on changes, queries and transfers must be retained until three years after that retention duty ends (§ 8(12) HSchG). The internal whistleblowing system must be set up from 50 employees or public-sector staff (§ 3(1) and § 11(1) HSchG), receipt of written reports must be acknowledged in writing without undue delay and no later than seven calendar days (§ 9(1) HSchG), and no later than three months after receipt the entity must state which follow-up measures have been taken or are intended (§ 13(9) HSchG). Protection of identity is governed by § 7(1) and (2) HSchG; infringements are penalised by the district administrative authority with a fine of up to EUR 20,000, and up to EUR 40,000 in the event of repetition (§ 24 HSchG).

5. Tool options

Examples from the first version of this article (as at the first version: 2 May 2026), not a selection recommendation: Microsoft Sentinel, the ELK stack (open source), Splunk (enterprise), Datadog (mid-market).

This list deliberately contains no prices, market shares or product recommendations. Four capabilities, derived from sections 1, 3 and 6, are decisive for the selection: does the tool capture all mandatory fields, including before-and-after values? Does it write append-only or to WORM storage? Can the data set be exported without the provider's involvement? And do the data sit in a constellation that triggers processing on behalf of a controller under Art. 28 GDPR? What matters legally is not the product but the constellation. Where a provider processes personal data on your behalf, you may only work with Data Processors providing sufficient guarantees of appropriate technical and organisational measures; the cooperation must be governed by a contract setting out the subject matter and duration of the processing, its nature and purpose, the type of personal data, the categories of data subjects and the obligations and rights of the controller (Art. 28(1) and (3) GDPR). For entities within the scope of NIS2, supply chain security from the minimum catalogue is added (§ 30(2) BSIG; in Austria from 1 October 2026 § 32(4) NISG 2026) — the logging tool is itself part of that supply chain.

6. Evidentiary value: what tamper-resistant logs support in supervisory proceedings

Immutable logs (for example append-only) carry greater evidentiary value — considered here in supervisory proceedings. Hash chains plus time stamping add a further layer of integrity protection.

This article makes no statement on the law of evidence before the courts; from a supervisory perspective, however, the benefit can be described precisely. Technically, the route there runs via hash-based procedures (HMAC), append-only logs and WORM storage. Append-only means that the application has write rights only to the log store and that no account — not even an administrative one — can change or delete entries; WORM storage enforces the same restriction at storage level for the defined retention period. With hash-based procedures, each entry is secured together with the hash of its predecessor, with the HMAC key kept separately from the log system; checking the chain at a fixed interval and logging the result of that check is a practitioner recommendation. In data protection, the reference point is Art. 32 GDPR — availability, integrity and confidentiality must be ensured. For the documentation mandate in § 30(1) BSIG (section 3), a log that cannot be altered after the fact is, in our practical view, the more robust evidence — a practitioner assessment, not a statutory requirement. Integrity protection also bears on two further data protection duties: the duty to give reasons where a deadline is exceeded under Art. 33(1) GDPR (see the deadlines table) stands or falls with robust timestamps. And communication to the data subject under Art. 34(1) GDPR is not required, among other things, where appropriate technical and organisational protection measures — in particular encryption — were applied (Art. 34(3) GDPR); whether and from when they were applied is evidenced by configuration and change logs.

Timestamps as the anchor for deadlines: which clock runs when

The notification and response deadlines in this field run from one of two events: from becoming aware in the case of notification duties, and from receipt in the case of response duties. That is exactly what the audit trail is needed for. All rows of the following table are statutory deadlines; the first column names the event from which each deadline runs. The row on the NISG 2026 applies only from the start of its application on 1 October 2026; the HSchG deadlines already apply.

Retention: which period follows from which provision

The retention period follows the type of document and the provision requiring it — which is why several periods run side by side within one system. The 'Type' column states, for each row, whether it is a statutory period, a practitioner value or a figure carried over unchanged from the original version.

The three-year cycle in § 39(1) BSIG is a date for furnishing evidence, not a retention date (section 3).

Who the evidence duties apply to: thresholds in Germany and Austria

Whether the NIS2 duties described in this article and the duty to set up an internal reporting office apply is decided by the combination of type of entity and size — and the thresholds are worded differently in the two countries. In Germany, other entities of a type specified in Annex 1 BSIG qualify as a particularly important entity if they employ at least 250 staff or have annual turnover of more than EUR 50 million together with an annual balance sheet total of more than EUR 43 million. Entities of a type specified in Annex 1 or Annex 2 qualify as an important entity if they employ at least 50 staff or have annual turnover and an annual balance sheet total each exceeding EUR 10 million (§ 28(1) and (2) BSIG). Irrespective of these sizes, operators of critical installations, qualified trust service providers, top-level domain name registries, DNS service providers and certain telecommunications providers count as particularly important entities (§ 28(1) BSIG).

In Austria, from the start of the application of the NISG 2026 on 1 October 2026, an entity qualifies as a large enterprise if it employs at least 250 staff or generates annual turnover of more than EUR 50 million and its annual balance sheet total exceeds EUR 43 million; as a medium-sized enterprise if it employs at least 50 staff or generates annual turnover of more than EUR 10 million and its annual balance sheet total exceeds EUR 10 million (§ 25(2) and (3) NISG 2026). Whether this results in an essential entity or an important entity additionally depends on its allocation to a type under Annex 1 or Annex 2 (§ 24 NISG 2026). For the logs of the internal reporting office, a separate threshold of 50 employees applies (section 4). German controllers and Data Processors must designate a data protection officer, in addition to Art. 37(1) GDPR, where they as a rule permanently employ at least 20 persons in the automated processing of personal data (§ 38(1) of the German Federal Data Protection Act (BDSG)); Austria provides for no numerical designation threshold going beyond Art. 37 GDPR (§ 5 of the Austrian Data Protection Act (DSG)).

Supervision and sanctions: who requests the evidence

The evidence is requested by the national supervisory authorities — and these are different bodies in Germany and Austria. For IT security, the Federal Office for Information Security (BSI) is the central body in Germany (§ 1 BSIG); no official date for the start of supervisory and fining practice is available. The BSI points out that the statutory registration deadline has already passed; anyone who has missed registration should do so now. Irrespective of this: new entities register no later than three months after first qualifying as a particularly important entity or an important entity, and report changes without undue delay and no later than within two weeks (§ 33(1) and (5) BSIG; in Austria from 1 October 2026 registration within three months with the Cybersecurity Authority (Cybersicherheitsbehörde, Austria), changes to core data within two weeks, § 29(2) to (4) NISG 2026). From 1 October 2026, the competent authority in Austria is the Federal Office for Cybersecurity (Bundesamt für Cybersicherheit) (§ 3a NISG 2026). In data protection, the authorities competent under the law of the federal states supervise non-public bodies in Germany (§ 40(1) BDSG) and the Federal Commissioner for Data Protection (BfDI) supervises federal public bodies (§ 9(1) BDSG); in Austria, the Austrian Data Protection Authority (Datenschutzbehörde) is the national supervisory authority (§ 18(1) DSG).

The sanctions framework in both countries is tiered by class of entity. In Germany, infringements of, among other things, the risk-management and notification duties can be penalised with a fine of up to EUR 10 million for particularly important entities and up to EUR 7 million for important entities; where total turnover exceeds EUR 500 million, up to 2 % and up to 1.4 % of worldwide total turnover respectively apply instead (§ 65(5) no. 1 as well as (6) and (7) BSIG). In Austria, from the start of the application of the NISG 2026 on 1 October 2026, administrative offences under § 45(1) NISG 2026 carry up to EUR 10 million or 2 % of worldwide annual turnover for essential entities and up to EUR 7 million or 1.4 % for important entities, whichever amount is higher (§ 45(2) and (3) NISG 2026). In data protection, the framework for infringements of, among other things, Art. 25 to 39 GDPR is up to EUR 10 million or 2 % of worldwide annual turnover, and for infringements of the principles of processing, the conditions for consent (Art. 5, 6, 7, 9) and the rights of data subjects (Art. 12 to 22) up to EUR 20 million or 4 % — whichever amount is higher (Art. 83(4) and (5) GDPR).

Practitioner recommendations for day-to-day operations

Four routines keep the duties evidenced above demonstrable in daily practice: a logging concept tied to the duties, restricted access to the log systems, a fixed quarterly rhythm and an export tested in advance. They are practitioner recommendations, except where a statutory duty is expressly referenced below.

• Logging concept tied to the duties: for every logged field, note which item of evidence it provides — timestamps for the deadlines in the table above, access data for access control and confidentiality.
• Restrict and document access to the log systems themselves. For the internal reporting office, this restriction follows directly from the law (§ 8(1) HinSchG, in Austria § 7(1) and (2) HSchG); for the remaining systems it is a recommendation.
• Three stations in our annual compliance plan that draw directly on audit trails: Q1 audit preparation with an update of the record of processing activities, reconciliation of data processing agreements and the quarterly risk review, Q3 evaluation of supplier self-declarations with on-site audits of critical suppliers, Q4 management review with the management board. As standing tasks we maintain there the record of processing activities (Art. 30 GDPR) annually and whenever changes occur, as well as the review of technical and organisational measures (Art. 32 GDPR) annually and after incidents.
• Check exportability in advance: before the next supervisory request, test whether the evidence from section 3 can be extracted without the provider's involvement.