DORA's quiet requirement: logs you can trust

What the standard says

The Digital Operational Resilience Act has applied across the EU since 17 January 2025. ^[2] One of its delegated regulations sets technical standards on ICT risk management, and Article 12 deals with logging. ^[1]

It asks financial entities to put in place logging procedures that, among other things, protect log systems and log information against tampering, deletion and unauthorised access, and detect faults in the logging itself. ^[1] The article doesn't spell out how to do that, but it is clear about what supervisors expect the logs to do: support incident detection, investigation and response.

Logs are what tell you what happened during an incident or an audit. For them to be useful, people have to be able to trust them.

Who it applies to

The requirement applies to the entities listed in Article 2 of DORA: credit institutions, payment institutions, electronic money institutions, investment firms, insurance and reinsurance undertakings, and several other categories. ^[2] Small and non-interconnected investment firms, payment institutions and electronic money institutions under the simplified ICT risk management framework have lighter duties under Article 16 of the technical standard, but protection of logs still matters. ^[1]

For entities in Sweden, Finansinspektionen supervises compliance. ^[3]

What supervisors and auditors look for

When a supervisor or an auditor asks about logging, they want to see that logs exist, that they cover the right events, and that they can be relied on. A log kept on a server where anyone with administrative rights can quietly edit or delete entries is harder to rely on.

Access control is the foundation: only the people who need to read or manage logs should be able to, and their access should be documented. Monitoring is the next step: spotting unusual access or changes. Backups and retention policies keep logs available.

But when the people who keep the logs could also change them, there is a gap. A supervisor might ask: how do you know nobody edited a log entry after an incident was closed? If a log is the only record of what happened, its integrity becomes the question.

The hard part: proving nobody changed it

Here is the problem. Logs are stored by the organisation that needs them. The people with the technical ability to protect the logs are often the same people who could, if they wanted to, edit them. That doesn't mean anyone does. It means that if someone questions a log, the organisation has to show it hasn't been touched.

That is where a digital witness fits. Instead of asking people to trust that nobody changed the log, you give them a way to check.

How a witness makes logs checkable

A digital witness seals log segments as they close, for example every few minutes. The log itself stays on your systems. What gets sealed is a fingerprint: a short, fixed-length string calculated from the log segment. If a single character in the log changes, the fingerprint won't match.

Anyone you share the log with can calculate the fingerprint again and compare it with the sealed one. If they match, the log hasn't changed since it was sealed. If they don't, it has.

The seal is permanent and sits on a chain where any later change, even one made by us, would show. That gives internal audit, supervisors and incident responders something they can check for themselves, without having to trust whoever keeps the logs.

WitniumChain lets you seal log segments continuously through its REST API, SDK or MCP server. The content never leaves your infrastructure. The first 2,000 witnesses a month are free. Documentation shows how to integrate it.

A witness doesn't replace access control, monitoring or backups. It doesn't show that a log is complete, or that every event was logged correctly. What it does is turn "trust us" into "check it".

How it would work

1. Your logging system closes a segment, calculates its fingerprint and sends it to the API.
2. The API returns a witness ID. You store the ID with the segment.
3. When someone wants to verify the log, they recalculate the fingerprint and check it against the sealed one using the witness ID.

What this means for you

If you work with ICT risk in a financial entity, here are three questions worth asking:

• Could we show a supervisor that a log from three months ago hasn't been edited, even by someone with administrator rights?
• Do our incident response procedures include a step to seal logs as soon as an incident is detected?
• When we archive logs for the retention period DORA requires, can we prove they stayed unchanged?

The technical standard doesn't mandate any particular method for protecting logs. But supervisors will want to see that you have thought about it, that you can demonstrate it, and that it works when they ask.

What to watch

DORA's main requirements have applied since 17 January 2025, but work on technical standards and guidelines continues. The European Supervisory Authorities have published joint guidance on several areas under DORA. ^[4]

In Sweden, Finansinspektionen has issued its own guidance on operational resilience for financial undertakings. ^[3] Entities that haven't yet reviewed their logging procedures against Article 12 of the technical standard should do so soon.

Logs tend to be taken for granted until the day someone asks a hard question about them. DORA makes that day more likely.