Sweden's financial regulator investigates cyber threats from AI

The investigation

Finansinspektionen, Sweden's financial supervisory authority, has started an in-depth analysis of how financial firms protect themselves against cyber threats from advanced AI models ^[1]. The regulator has not published further details, but the timing is clear: the technical standard on ICT risk management under DORA requires logs to be protected against tampering, deletion and unauthorised access, and it has applied since 17 January 2025 ^[2].

The question is not whether institutions are keeping logs. Most are. The question is whether those logs can be relied upon when something goes wrong.

What DORA requires

The Digital Operational Resilience Act applies to financial entities across the EU: banks, insurance firms, payment institutions, investment firms and others ^[2]. One part of the technical standard on ICT risk management is brief and easy to miss. It says that logging procedures must protect log systems and log information against tampering, deletion and unauthorised access, and detect errors in logging ^[2].

That is not a technical description. It is a statement of intent. Logs must be kept in a way that people can trust them.

The evidence question

Logs are what tell you what happened during an incident. When an attacker gains access, when a system behaves unexpectedly or when an AI model makes a decision that is later challenged, the logs are the first place people look.

If you keep the logs yourself, you can change them. If your systems are compromised, so might the logs be. If a third party keeps them, that third party becomes the one everyone has to trust.

Access controls are the foundation. They limit who can read and write logs, and they record who did what. Monitoring adds a layer. It flags when something unexpected happens to a log. Both are necessary. Neither answers the question: how do you show an auditor, a regulator or a court that a log has not changed, when you are the one who keeps it?

One way to answer it

A digital witness takes a fingerprint of each log entry. The fingerprint is sealed on a chain where any later change would show, even one made by the institution itself. When the log is questioned, you calculate the fingerprint again. If it matches, nothing has changed. Change a single character and it will not match.

The log itself stays with the institution. The witness keeps the fingerprint and the time. The institution can share the log, the fingerprint and the witness reference with anyone who needs to check it: an auditor, a supervisor or another party in a dispute. That party can calculate the fingerprint and see whether it matches.

That is what a digital witness is for. It does not make a log tamper-proof. It makes tampering visible.

Why it matters for financial firms

Financial firms are targeted. Attacks are sophisticated. Advanced AI models can find vulnerabilities faster than people can close them, and once inside a system an attacker can alter the traces of their presence.

When an incident is investigated, the institution has to show what happened. Regulators will ask to see the logs. Customers may demand them. The institution's own forensic team needs them. If the logs have been altered, the investigation starts on uncertain ground.

Finansinspektionen's analysis will presumably look at how institutions are preparing for AI-driven threats. A large part of that preparation is evidentiary: not just detecting an attack, but being able to prove what the attack did.

What this means for you

If you work in a financial institution covered by DORA, these are questions worth asking now:

• Can you show a regulator that your logs have not been altered since they were created?
• If your logging infrastructure were compromised during an incident, would you know which logs to trust?
• Do you rely on access controls alone, or do you have an independent record that a log existed at a certain time and has not changed since?
• When you hand logs to an auditor or investigator, what evidence can you give them that those logs are intact?

The technical standard on ICT risk management is already in force ^[2]. The question is no longer what the law requires. The question is how you show that you meet it.