How do I retain DORA ICT incident logs so they cannot be tampered with?

DORA Article 17(2) requires financial entities to record all ICT-related incidents and significant cyber threats, and the DORA logging RTS requires those logs to be protected against tampering, deletion and unauthorised access. You keep them tamper-proof by recording each incident event in an append-only, hash-chained, independently timestamped log and retaining signed receipts you can verify offline. AlgoVoi's self-hosted Verifiable Audit Log, in the Verifiable Compliance Suite, gives you that record, air-gap capable and vendor-independent.

Last updated 21 August 2026

What DORA expects of your incident records

DORA (Regulation (EU) 2022/2554) has applied to financial entities since 17 January 2025. Article 17(2) requires you to record all ICT-related incidents and significant cyber threats inside an incident-management process that identifies, documents and addresses root causes. The DORA logging RTS (Commission Delegated Regulation (EU) 2024/1774, Article 12) goes further: logging procedures must set a retention period, protect the logs against tampering, deletion and unauthorised access at rest and in transit, synchronise clocks to a documented reliable time source, and detect a failure of the logging system itself. Reconstruction and reporting timelines only work if the incident record is complete and provably unaltered.

Making the incident log tamper-proof

• Automatic capture: each incident event (detection, classification, escalation, resolution) written as it happens.
• Hash-chained entries: every entry chained to the previous one, so a deleted or edited entry breaks the chain and is detectable.
• Independent timestamps: the incident timeline cannot be back-dated to look better than it was.
• Retention and offline verification: signed receipts retained for the required period and checkable by a supervisor without trusting you.

How to meet it with AlgoVoi

Record each ICT incident event (detection, classification, escalation, resolution) in the self-hosted Verifiable Audit Log as a Falcon-1024-signed, hash-chained entry, timestamped and retained under enforced policy. It ships inside the Verifiable Compliance Suite, runs on your own infrastructure under your own keys, and every record verifies offline, air-gap capable. For the full DORA and MiCA mapping, see the docs: MiCA and DORA evidence.

Verify it, the way an auditor would

The whole point is that someone else can check the record. Verification runs offline against the exported receipts and the log's public key, with no call back to AlgoVoi and no trust in whoever holds the log:

from algovoi_audit_log import verify_chain

# `receipts` are the exported, signed log entries; `public_key`
# is the log's Falcon-1024 public key. No network, no vendor.
result = verify_chain(receipts, public_key)
assert result.valid   # fails the moment any entry is altered,
                      # inserted, removed, reordered, or back-dated

A competent authority can run the same check against the same exported receipts and reach the same verdict. That reproducibility is what turns "we kept logs" into evidence.

Do it with AlgoVoi

The self-hosted Verifiable Audit Log produces the tamper-evident record. It ships standalone and inside the Verifiable Compliance Suite, runs entirely on your own infrastructure, and is air-gap capable (no PyPI). Anyone you hand an exported record to can verify it offline, no licence and no AlgoVoi account needed.

• Get the log: Suite Store (Verifiable Audit Log, or the full Compliance Suite)
• Related answer: MiCA Article 68(9) record-keeping
• Related answer: EU AI Act Article 12 record-keeping
• Product: Regulatory evidence · Evidence Auditor

Start with the docs: docs.algovoi.co.uk/audit-log