Tamper-Evident Security Logs under NIS2 and DORA: Using Qualified Timestamps as Independent Evidence

When a security incident is investigated, by an internal team, an auditor, a supervisory authority or a court, the logs are usually the primary evidence. They show who accessed what, when an attack started, when it was detected and what was done about it. Their value depends entirely on one assumption: that they have not been changed since they were written.

Both NIS2 and DORA now make that assumption an explicit obligation. Logs must be protected against unauthorised modification, and entities must be able to show that they are. This article looks at what the two frameworks actually require, what a qualified timestamp can and cannot prove about a log, and how to build log integrity into a logging pipeline in a way that holds up under scrutiny.

It is written for CISOs, security architects, SOC and SIEM teams, managed security service providers and compliance officers at entities in scope of NIS2 or DORA.

What NIS2 requires

Directive (EU) 2022/2555 (NIS2) requires essential and important entities to take appropriate and proportionate technical, operational and organisational measures to manage cybersecurity risks (Article 21(1)). The minimum set of measures in Article 21(2) includes, among others, incident handling (point b) and policies and procedures regarding the use of cryptography and, where appropriate, encryption (point h). Article 20 makes the management bodies responsible for approving these measures and overseeing their implementation.

Article 23 sets strict reporting deadlines for significant incidents: an early warning within 24 hours of becoming aware of the incident, an incident notification within 72 hours, and a final report within one month. Meeting these deadlines, and later demonstrating that they were met, depends on a reliable record of what happened and when.

Commission Implementing Regulation (EU) 2024/2690 sets out the technical and methodological requirements of Article 21 in detail for a defined group of entities: DNS service providers, TLD name registries, cloud computing service providers, data centre service providers, content delivery network providers, managed service providers, managed security service providers, online marketplaces, online search engines, social networking platforms and trust service providers. Point 3.2 of its Annex, on monitoring and logging, is specific:

• Logs must be maintained, documented and reviewed, covering events such as network traffic, authentication, privileged access, configuration changes and the activity of security tools (point 3.2.3).
• “The relevant entities shall maintain and back up logs for a predefined period and shall protect them from unauthorised access or changes” (point 3.2.5).
• “To the extent feasible, the relevant entities shall ensure that all systems have synchronised time sources”, so that logs can be correlated between systems for event assessment (point 3.2.6).

Entities outside the scope of the Implementing Regulation are subject to the national transposition of Article 21, but the Regulation is widely used as a reference for what good logging practice looks like under NIS2.

What DORA requires

Regulation (EU) 2022/2554 (DORA) has applied to financial entities since 17 January 2025. It requires an ICT risk management framework, an ICT-related incident management process that records all ICT-related incidents (Article 17), and the reporting of major ICT-related incidents to the competent authority (Article 19).

Commission Delegated Regulation (EU) 2024/1774, the regulatory technical standard on the ICT risk management framework, addresses logging directly in Article 12. Financial entities must have logging procedures that include, among other elements:

• “measures to protect logging systems and log information against tampering, deletion, and unauthorised access”, at rest, in transit and, where relevant, in use;
• measures to detect a failure of logging systems;
• a defined retention period for logs;
• the synchronisation of the clocks of the entity’s ICT systems with a documented reliable reference time source.

What the regulations do not say

Neither NIS2 nor DORA prescribes a specific technology for log integrity. They do not require qualified timestamps, and they do not require any single product. They require an outcome: logs that are protected against unauthorised change, and an organisation that can demonstrate this protection to an auditor or a supervisor.

Common measures include access control on log stores, separation of duties between administrators and log reviewers, write-once (WORM) storage and centralised forwarding to a SIEM. These are valuable, but they share a limitation: they are all controls operated by the entity itself, or by its service providers. When the integrity of the logs is challenged, for instance in an investigation involving a privileged insider or a compromised administrator account, the entity has to prove that its own controls were not bypassed.

This is where an independent, cryptographic proof becomes useful.

What a qualified timestamp proves, and what it does not

A qualified electronic timestamp, issued by a Qualified Trust Service Provider under the eIDAS Regulation (EU) No 910/2014, binds the hash of a piece of data to a date and time certified by an independent authority. Under Article 41(2) of eIDAS, it enjoys a legal presumption of the accuracy of the date and time it indicates and of the integrity of the data to which they are bound, recognised in every Member State.

Applied to logs, this gives two precise guarantees:

• Integrity: the timestamped log segment has not been changed since the moment of the timestamp. Any modification, however small, changes its hash and no longer matches the token.
• Time: the segment existed, in exactly that form, no later than the certified time. It cannot have been created or rewritten afterwards.

It is equally important to be clear about the limits:

• A timestamp does not prove that the log content was accurate when it was written. If a system was already compromised and wrote false entries, the timestamp will faithfully preserve those false entries.
• A timestamp protects data from the moment it is applied. The shorter the interval between writing a log entry and timestamping it, the smaller the window in which it could be altered undetected.
• A timestamp does not replace access control, monitoring or backups. It makes tampering detectable and provable; it does not prevent it.

Used within these limits, qualified timestamps turn “our controls show the logs were not changed” into “an independent qualified authority certified this exact data at this exact time”, which is a considerably stronger position in an audit or a dispute.

A practical design: hash-chained, timestamped log segments

The most common pattern combines hash chaining with periodic qualified timestamps:

1. Segment the log stream by time (for example every 1, 5 or 15 minutes) or by size, per log source or per tenant.
2. Hash each segment with a strong algorithm such as SHA-256, including the hash of the previous segment, a sequence number and the source identifier. This chains the segments together, so that deleting, inserting or reordering a segment also becomes detectable.
3. Request a qualified timestamp for each segment hash over RFC 3161. Only the hash is sent; the log content never leaves your infrastructure.
4. Store the token next to the segment, and ideally also in a separate store with different administrative access.
5. Verify continuously. A scheduled job recomputes the hashes, checks the chain and validates the tokens. A verification failure or a missing timestamp is itself a security event and should raise an alert, which also supports the DORA requirement to detect failures of logging systems.

Because log data often contains personal data such as IP addresses and user identifiers, sending only hashes to the timestamping authority also keeps the design simple from a GDPR perspective.

The qualified timestamp also provides an independent, UTC-traceable time reference for each segment. It does not synchronise your systems’ clocks, but it makes significant clock drift or manipulation on a log source visible when log times are compared with the certified times.

Beyond logs: other records worth timestamping

The same mechanism applies to other records that NIS2 and DORA expect entities to keep and, if needed, to justify:

• Incident timelines. The moment an incident was detected, classified as significant or major, and escalated determines the reporting deadlines. Timestamping these decisions creates an independent record of when the entity became aware of the incident and how it acted.
• Incident reports as submitted, so the exact version sent to the authority can be demonstrated later.
• Forensic evidence. Disk images, memory dumps and exported log sets can be hashed and timestamped at acquisition, supporting the chain of custody.
• Policies and approvals. Security policies, risk assessments and management body approvals can be timestamped to show which version was in force at a given date.
• Configuration baselines. Snapshots of critical configurations, timestamped periodically, help demonstrate when an unauthorised change occurred.

Planning the volume

Timestamp consumption depends on the number of independent log streams and on the segment interval. One timestamp per segment per stream gives:

Shorter intervals reduce the window in which data could be altered before being timestamped. Separate streams per system, per environment or, for managed security service providers, per customer keep the evidence independent, so that one customer’s or system’s logs can be disclosed and verified without exposing any other. Entities with very large numbers of sources can also aggregate segment hashes into a hash tree and timestamp the root, trading some independence of evidence for lower volume. The right balance is a risk-based decision that should be documented as part of the logging procedure.

What to require from a timestamping provider

• Qualified status in the EU Trusted Lists, with a timestamping service listed as qualified and granted. Only qualified timestamps carry the presumption of Article 41(2) eIDAS.
• High availability. Logging never stops. The pipeline should queue segments during an outage and timestamp them as soon as the service is reachable, but every outage widens the unprotected window.
• No quotas or throttling, since a constant stream of requests from many sources is the normal mode of operation.
• Standard RFC 3161, so the integration works with any SIEM, log pipeline or scripting environment.
• Hash-only requests, so log content and personal data never leave your infrastructure.
• Pricing suited to continuous use, with volume packages that match a steady, high request rate.

How qtsa.eu supports security logging

qtsa.eu provides qualified electronic timestamps issued by AlfaTrust Certification S.A., a Qualified Trust Service Provider supervised under eIDAS and listed in the EU Trusted Lists for the issuance of qualified electronic timestamps. The service is suited to continuous, automated use in logging and evidence pipelines:

• eIDAS qualified and listed in the EU Trusted Lists. Every timestamp carries the legal presumption of Article 41(2) and is recognised in all EU Member States.
• Uptime above 99.9%. A highly available service, to keep the unprotected window of your log pipeline as small as possible.
• Simple to use, without restrictions. A standard RFC 3161 endpoint that integrates with log pipelines, SIEM tooling and scripts. No daily or monthly quotas and no throttling.
• 24-month validity. Every prepaid package can be used over 24 months from the date of purchase.
• Volume packages up to 1.200.000 timestamps, with tailored offers for SOCs, managed security service providers and entities with many log sources.
• Hash-only requests. Log content and personal data never leave your infrastructure.
• No VAT for EU businesses. Companies registered in another EU Member State with a valid VAT number are invoiced under the reverse charge mechanism.

Test it on your log pipeline

Request 50 free qualified timestamps and timestamp a few log segments from a test source. Our integration guides show how to request and verify RFC 3161 timestamps with OpenSSL, PowerShell, Python, Java, C# and PHP, which is all you need to build a proof of concept in an afternoon.

Get 50 free eIDAS qualified timestamps → | See volume packages →

Frequently asked questions