Revolut outage shows why DORA requires *protected* logs, not just logs

The outage

On 8 May 2025, a power failure at a Google Cloud data centre in London caused an outage that disrupted services for several customers, including the digital bank Revolut ^[1]. The outage lasted several hours. Google Cloud restored service later that day and stated it was investigating the cause.

Revolut confirmed the disruption affected its app and customer services during the incident. Customers reported being unable to access their accounts or make payments whilst the outage lasted.

Google Cloud under DORA supervision

In November 2025, the European Supervisory Authorities designated Google Cloud as a critical third-party ICT service provider under DORA ^[2]. That designation brings Google Cloud under direct EU oversight for its services to the financial sector.

The designation means Google Cloud must meet DORA's requirements for operational resilience, including detailed incident reporting and regular audits. Financial firms that use Google Cloud remain responsible for their own resilience, but the designation gives supervisors a direct line to one of the sector's largest infrastructure providers.

For Revolut, the incident is a reminder that relying on a third party doesn't shift the obligation. DORA applies to the financial firm, not just to the cloud provider.

What DORA says about logs

DORA's technical standard on ICT risk management requires financial firms to have logging procedures that protect log systems and log information against tampering, deletion and unauthorised access, and that detect failures in the logging ^[3].

Logs are a bit like receipts. Nobody looks at them until there's a question, and then they matter a great deal. The rule isn't just that you must keep them. It's that you must keep them in a way people can trust.

The standard doesn't say how to protect the logs. It says what the protection must achieve: that nobody can quietly edit or delete them, and that you notice if the logging breaks.

The hard part: proving the logs are intact

When an incident like the Revolut outage happens, supervisors, auditors and insurers will want to see the logs. The question isn't only whether the logs exist. It's whether they can be trusted.

A log kept by the same people who could change it is easy to challenge. Access controls and monitoring are the foundation, but they don't answer the question a supervisor is really asking: how do I know this log is exactly what was written at the time, and that nobody with the right access has edited it since?

That's where the protection requirement in DORA's technical standard becomes more than a checkbox. It's a question about evidence.

How a digital witness protects logs

Here, the thing to seal is each log segment as it closes, for example every few minutes. The fingerprint goes to WitniumChain through the REST API, the SDK or the MCP server, and you get a witness ID back. The content stays in your systems.

When the incident is being reviewed, internal audit, FI or an incident responder can check that a log segment hasn't changed. They calculate the fingerprint again and compare it with the sealed one. If it matches, the segment is unchanged. Change a single character and it won't match.

A digital witness doesn't replace access control, monitoring or backups. It adds one thing: a way to show that a log segment is exactly what was written, even when the people who keep the logs could also change them. That matters when a supervisor asks to see the timeline of an incident and wants to know the record is sound.

The first 2,000 witnesses a month are free. Read the documentation at witniumchain.com/docs or get access now at witniumchain.com/signup.

What this means for you

If you're responsible for ICT risk in a financial firm, here are three questions worth asking this week:

• Could you show a supervisor that your incident logs from last month haven't been edited, even by someone with administrator rights?
• If a third-party provider has an outage, do your own logs capture enough detail to reconstruct what happened on your side?
• Have you tested whether your logging detects its own failures, as the technical standard requires?

An incident will happen. The question is whether your logs will hold up when someone asks to see them.

What to watch

DORA has applied since 17 January 2025 ^[3]. Financial firms must report significant incidents to their national supervisor: an early warning within 24 hours of becoming aware, an incident notification within 72 hours and a final report within a month.

The European Supervisory Authorities publish an updated list of designated critical ICT third-party service providers. Google Cloud joined that list in November 2025 ^[2].

Watch for further guidance from the ESAs on what counts as adequate protection of logs under the technical standard. Until then, the test is whether you could show a supervisor that your logs are intact.