NIS2 and DORA: the audit log they expect

Two European laws now decide what “we keep an audit log” has to mean for a lot of organisations. NIS2 covers essential and important entities across eighteen sectors, from energy and health to digital providers and the companies that supply them. DORA covers the financial sector and the ICT providers it depends on. Both are in force: DORA has applied since January 2025, Germany’s NIS2 law since December 2025 and the Dutch one since August 2026.

Neither text contains a log schema. People looking for a list of fields come away disappointed, and vendors fill the gap with claims that their product is “NIS2 compliant”, which is not a property a product can have. What the two laws do contain is more useful: a description of what a log has to be able to do, especially in the hours after something goes wrong. This article sets that out, and then shows how Sapherbox’s audit log answers each point, including where it does not yet.

What NIS2 asks

The directive itself, in Article 21, lists the measures every covered entity must take. Incident handling is one of them, and so are policies on access control, cryptography and the security of the supply chain. Logging is not named as a measure of its own. It appears where it belongs, as the thing incident handling runs on.

The detail is in the implementing regulation the Commission adopted for digital providers in October 2024, which the national authorities also treat as the reference for everyone else. Under incident handling it asks entities to monitor and log activity on their systems in order to detect events that could be incidents, and it says what the log should cover where appropriate: creation, modification and deletion of users, authentication events, every privileged access, and access to or changes of critical configuration and backups. Logs are to be kept for a predefined period and protected against unauthorised access and change. Clocks are to be synchronised so that logs from different systems can be correlated. And the logging system itself is to be monitored, so that its failure is noticed.

Then there is the clock. Article 23 gives a covered entity 24 hours from becoming aware of a significant incident to send an early warning, 72 hours for a notification that includes an initial assessment of severity and impact, and one month for a final report with a root cause and the measures taken. Whatever a log is, it has to make those three documents possible.

What DORA asks

DORA is a regulation, so it applies directly, and it is more explicit about logs. Article 10 requires mechanisms to detect anomalous activity promptly. Article 17 requires that all ICT-related incidents are recorded, not only the major ones. The technical standard that fills in the risk management framework has an article headed simply “Logging”. It asks financial entities to decide which events are logged and for how long, to protect logging systems and the logs themselves against tampering, deletion and unauthorised access, to detect failures of the logging system, and to synchronise clocks against a documented reference. Retention is not a fixed number. It is to be set from the purpose of the log and the entity’s own risk assessment, and written down.

DORA’s incident clock is tighter than NIS2’s. An initial notification of a major incident is due within four hours of classifying it as major and no later than 24 hours after becoming aware of it. An intermediate report follows within 72 hours of the initial notification, and a final report one month after the last intermediate one. Four hours is not long enough to start assembling evidence. It is only long enough to look it up.

One more thing is specific to DORA. A financial entity’s ICT providers are inside the regulation’s scope through the contract. Article 30 requires the agreement to give the entity cooperation in incident handling and access to the information it needs. For a product like ours, that means the audit trail of your tenant is your evidence, available to you without a ticket to us.

Four things both laws want

Read together, the two sets of rules converge on four demands. They are a better checklist than any field list.

The right events. Who signed in and who failed to, who was created, changed or removed, who was given access to what and by whom, who took it away, who downloaded, who changed a security setting. Human users and machine accounts alike.
Integrity. A log that can be edited or trimmed without trace is not evidence. Both frameworks name tampering and deletion as the threats to protect against.
Retention that is decided. Not “forever” and not “whatever the database holds”. A period, chosen for a reason, with the removal under control.
Answers under a deadline. When the clock is running, you need to answer “what happened to this file, who had access to this folder, what did this account do” in minutes, from the product, without engineering help.

How Sapherbox answers each

Events. The audit log records 159 distinct actions, grouped into eighteen categories so that an administrator can read it without a legend. Authentication and accounts: sign-in, sign-out, failed attempts, lockouts, idle timeouts, session revocation, password changes and resets, SSO link and sign-in, MFA and passkey registration. User administration: accounts created, deactivated and deleted, roles changed, quotas and access controls set. Files and folders: uploads, downloads, renames, moves, deletions, restores and purges. Sharing: every grant and every revocation, group membership changes, download links created, accessed and revoked, upload links created and revoked, invitations sent and completed. Settings: every change to a security setting, naming the setting that changed. Service accounts and API keys created and deleted. Escrow configuration changes and administrator-assisted account recoveries. The daily retention purge itself. Actions taken through an API key are attributed to the service account that holds it, so a machine actor is as visible as a person.

Each entry carries the actor, the action, the resource, the time as recorded by the database, and the action’s details. Recording the client IP address is a switch the administrator turns on, because for many tenants the address is personal data they would rather not keep. File and folder names in the log are masked, as described in what our servers can and cannot see. The server never had the contents, so the log cannot contain them either, and that is the point of the product rather than a gap in the log.

Integrity. Every entry is linked to the one before it with an HMAC-SHA-256 chain, keyed with a secret the database never sees. The role the application uses can insert and read entries but cannot update or delete them. An administrator verifies the whole retained chain with one button, or by API, and a break is reported as a security incident, naming the first entry that does not verify. We wrote the design up in an audit trail that cannot be quietly edited. For a DORA or NIS2 file, that article is the answer to “how are logs protected against tampering and deletion”.

Retention. Retention is a tenant setting, 365 days by default. Entries older than that are purged daily, and the purge is itself an audited, chained event that records the new anchor of the chain and the number of entries removed. The period you chose and the reason for it go in your policy. The product enforces it and shows that it did.

Answers under a deadline. The audit page filters by action and by free text. Every file and every folder has its own audit view, so “what happened to this document” is one click from the document. The access report lists, for everything you own, who has access and at which level, which is the fastest way to scope an incident that involves a compromised account. Bulk activity is flagged as it happens: when one account downloads or uploads more than a threshold number of files within a short window, the administrators receive an alert e-mail at once rather than finding the pattern in the log a week later. The thresholds are settings. The CSV export puts the retained log, or a filtered part of it, into a file for the incident record.

Where the gaps are

Sapherbox does not push entries to your SIEM. Both laws expect you to correlate logs across systems, and the implementing regulation expects the logging system to be watched independently. The export is a file you download, not a feed. A scheduled export, and a native syslog or webhook push, are on the roadmap; until then, a scripted pull through the API is the way to keep an external copy current, and we help set up that integration for your SIEM.

For the compliance file

If your reviewer wants the one-paragraph version: the tenant’s audit log records authentication, account, access, sharing, transfer and configuration events for human and machine actors; entries are HMAC-chained with a key held outside the database and cannot be altered by the application role; the chain is verifiable on demand; retention is a configured period whose enforcement is itself logged; per-resource views, filters, bulk-activity alerts and an export support incident reporting within the NIS2 and DORA deadlines; and the log is the tenant’s own, accessible without the provider’s involvement. The longer version is this article and the two linked ones.

Questions?

If you are mapping your NIS2 or DORA controls and want our answers in your questionnaire’s format, write to hello@sapherbox.com.