Published 12 October 2026

Summary: ”Tamper-proof” is a strong phrase that often appears in a product sheet without anything in the solution carrying it. A log the administrator can edit is not tamper-proof, whatever the wording says. Three things make a log hold up in an audit: it is protected against modification, you can show how, and the retention reaches back over the period the auditor is looking at.

Logs are what separate believing from knowing what happened. They are also one of the areas where the wording in a tender or a security description is usually stronger than the technology behind it.

Three levels that get mixed up

The log is written. The event is recorded with a time, an identity and an outcome. That is the starting point, and it is not always in place – many systems log writes but not reads, or log in local time with no time zone.
The log is protected against modification. Permission to delete or edit is separate from permission to do the thing being logged, and the records are forwarded away from the system that produced them. This is the level most organisations can realistically reach.
The integrity of the log has stronger technical protection. Append-only or WORM storage can prevent or severely limit changes during the retention period. Cryptographic integrity checks, such as a hash chain between the records or independent time-stamping, can also make a later change verifiable. Here you can show how the log is protected, rather than argue that nobody should have been able to change it. The technology you use decides both how hard it is to change the log and how well a change is detected afterwards.

The phrase ”tamper-proof” can only be defended at level three, and even there ”tamper-resistant” or, with cryptographic checks, ”tamper-evident” is more accurate: the technology hinders or reveals a change but rarely makes it entirely impossible. Writing ”tamper-proof” without having level three is a claim an auditor can dismiss in five minutes, and that puts the rest of your security description in question too.

The question that settles it: who can change the log?

The practical test is simple and uncomfortable. Can the role that carried out an action also delete the trace of it? In many environments the answer is yes, because the same domain administrator or the same cloud administrator role owns both the system and its logs.

Two measures move most of it: separate the permissions so that operations and log management are not the same role, and forward the log from the system that produces it to somewhere that role has no write access. It does not have to be a SIEM platform to count – central log collection the administrator cannot tidy up in is already a different situation from a local log file.

Retention is half the question

A log that is perfectly protected for 30 days does not help in an audit that looks at the last 12 months. At the same time data minimisation pulls the other way: logs often contain personal data, and unlimited retention is not the right answer either.

What works is deciding the period per log type and being able to justify it: authentication events and administrative actions longer, application debug shorter. Write the decision down. The question ”why do you keep this for so long?” comes from auditors and from data protection officers alike, and it should have the same answer.

What the standards actually require

ISO/IEC 27001:2022 covers logging in Annex A.8.15 and monitoring activities in A.8.16: logs shall be produced, kept and protected, and they shall be reviewed. The control does not say the log has to be immutable – it says it has to be protected, which is exactly the distinction that makes ”protected audit logs” a sustainable claim and ”tamper-proof” a risky one.

The time stamps also need to be trustworthy. Systems that will be compared with one another should take their time from a common, controlled time source, and time zones and clock drift need to be handled; ISO/IEC 27001:2022 covers this in A.8.17 on clock synchronisation. Otherwise the events cannot be put in the right order when an auditor or an incident investigation asks.

NIS2 and DORA approach the same thing from the incident side: the reporting requires you to describe what happened, when it was detected and what impact it had. The log is the material that makes such a description something you can substantiate rather than reconstruct from memory.

Four steps that take half an hour

Carry out an action in a system that is in scope – add a permission, open a file, change a setting.
Find the action in the log. Note how long it took and what the record contains: identity, time, source and outcome.
Try to delete the record as the role that carried out the action. If it works, you have your answer.
Check how far back the log actually reaches, not how far the policy says it reaches.

The outcome is either a passed test you can show, or a concrete list of what needs to change. Both are worth more than the wording on the product sheet.

Verifying that controls work in practice, rather than that they are described somewhere, is the same work we go through in assurance and control testing.

We work with assurance and internal audit, and can test logging and traceability as a scoped engagement through our control testing offer. If you would like to know how your logs hold up, you are welcome to contact us.

Sources: ISO/IEC 27001:2022, Annex A.8.15 on logging, A.8.16 on monitoring activities and A.8.17 on clock synchronisation; the NIS2 Directive Article 21 on risk-management measures and Article 23 on reporting obligations; DORA on the management and reporting of ICT-related incidents.

This text is general information and does not constitute legal advice in an individual matter.