CYBCybersecurity

Sherlock Holmes and the log files: how long to keep them, and where, to reconstruct an attack

After an incident the questions are always the same. Who got in, when, from where, and what did they touch? The log files answer them, if they still exist. Here is which logs to collect, how long to keep them and where.

Strategic editorial team 28 March 2026 9 min read

Cover: “Sherlock Holmes and the log files”, Cybersecurity

Without log files you cannot reconstruct a cyber-attack. You do not know who got in, when, from where or what they touched. For logs to be any use on the day of an incident, they need three things. They must be collected on the systems that matter, kept long enough and away from the servers they describe, and read by someone before it is too late. How long to keep them is not a single number that suits everyone. It depends on the risk, on the rules that apply and on the rules protecting employees’ privacy.

What has Sherlock Holmes got to do with it?

Faced with a burglary, Sherlock Holmes did not start by asking who the culprit was. He asked to see the lock, the window and the footprints on the floor. In IT systems the footprints are called logs. They are records, often dull and bulky, in which every system notes what happens. They capture a successful login, a wrong password, a downloaded file or a firewall rule blocking a connection.

The trouble is that many companies discover they have none precisely when they need them. By then the crime scene has already been vacuumed clean.

What does a log file tell you?

A log entry is a line with a date, a time, a system, a user and an action. On its own it says little. Lined up with the others it tells a story, and it answers the questions that management, lawyers and the authorities will ask:

Where the attacker got in: a remote connection, a mailbox, an exposed application.
When it happened: the first unusual access, not the day someone noticed the problem.
What they touched: which folders, which databases, which accounts.
Whether they are still inside: recent logins with stolen credentials, or tools left on the servers.

For a company subject to NIS2, the EU directive on network and information security, these answers are not a matter of curiosity. Within one month of notifying a significant incident, the directive requires a final report with a detailed description of what happened, the type of threat or root cause and the measures taken. Without logs, that report becomes an exercise in guesswork.

Why are logs so often missing after an attack?

The reasons come up again and again, and none of them is about cost.

Default retention is short. Many systems keep their logs for a few days or a few weeks, or up to a certain size, and then overwrite them. The setting is designed to stop disks filling up, not to support investigations.

Attacks are discovered late. According to Mandiant’s M-Trends 2026 report, published in March 2026, the global median time between an attacker getting in and being discovered was 14 days in 2025. In almost half of cases, the alarm was raised by someone outside the company. If logs last a week, the beginning of the story has already been erased.

The logs sit on the same server they describe. Anyone who obtains administrator privileges can alter or delete them, and it is one of the first things a careful attacker does.

They are not switched on where they are needed. Remote access goes unrecorded. Detailed logging on cloud services has never been switched on. Server clocks are out of sync, which makes it impossible to put events in order.

How long should logs be kept?

There is no single period, but there are clear reference points to start from.

NIS entities in Italy. The basic measures set by Italy’s National Cybersecurity Agency (Agenzia per la Cybersicurezza Nazionale, ACN) in Determination 379907/2025 (measure PR.PS-04) require organisations to log all remote access and all access with administrative accounts. The logs needed to monitor security events must be kept securely, and centrally where possible, and retention periods must be set in writing on the basis of a risk assessment.
System administrators. The decision of the Italian Data Protection Authority (Garante) of 27 November 2008 requires the logical access of system administrators to be recorded. Those records must be kept complete and unalterable for an appropriate period of no less than six months.
Employee email. For email metadata collected to run the service, the Garante’s guidance document of 6 June 2024 indicates, as a guideline, a retention period that should not exceed 21 days. Longer periods must be justified and, beyond certain limits, require the safeguards set out in Article 4 of Italy’s Workers’ Statute (Statuto dei lavoratori).

The right balance is found by bringing IT, the data protection officer (DPO) and, where needed, an employment lawyer around the same table. Security logs are needed for months, but they contain personal data and must not become a way of monitoring employees. The result belongs in a retention policy, with the periods for each type of log and the people allowed to consult them. For companies based in San Marino the framework is different and must be assessed case by case.

Where should they be kept?

The rule is simple: away from the system they describe. Logs should be sent, as they are produced, to a central store that the administrators of individual servers cannot write to. A good log store has a few recognisable features:

It keeps data in a form that cannot be altered or deleted before the set expiry date.
It has separate access, which is itself logged.
It takes its time from a common source, so that events from different systems can be put in order.
It is sized for the agreed period, with a check that flags when a source stops sending data.

The event logging guidance published in 2024 by the Australian Signals Directorate’s cyber security centre, with CISA, the FBI, the NSA and other international partners, stresses exactly these points. It calls for protected storage, timely and centralised collection and consistent formats.

Which logs should you collect first?

Collecting everything straight away is expensive and of little use. It pays to start with the sources that answer the most common questions after an incident.

Source	What it tells you	Why it matters
Remote access (VPN, remote desktop)	who connects from outside, from where and at what time	it is one of the most common ways in
Authentication and the company directory	successful and failed logins, new accounts, privilege changes	it shows stolen credentials being used
Email	access to mailboxes, forwarding rules created	it reveals compromised mailboxes and information theft
Firewalls and perimeter systems	blocked and allowed connections	it reconstructs where traffic comes from and where it goes
Critical servers and databases	administrative access, exports, changes	it tells you what was touched
Endpoint protection (EDR)	suspicious programs, unusual behaviour	it links the event to the machine where it started
Cloud services	console access, keys created, sharing	it covers what does not pass through the company network

Who reads them?

Collecting logs is not the same as keeping watch over them. An archive that nobody consults is only useful afterwards, for the investigation. An archive with a few well-chosen alerts can stop an attack while it is under way. The events to start with are few: many failed logins followed by a successful one, a login from a country where the company does not operate, a new administrative account, a protection being switched off, an unusual data export.

Every alert needs a written answer to two questions. Who receives it, and what do they do? Usually the internal IT team handles this, with a periodic review of alerts and rules. What matters is that the alert does not end up in an inbox nobody opens. Even the remote connection set up by a fake tech support caller leaves traces that someone has to notice. And logs are no substitute for protection on the computers themselves, which is the subject of the article on antivirus.

What about AI assistants?

The same rules apply. An AI assistant connected to email, documents or the ERP system must leave a log that can be consulted: who asked what, which documents it read, which actions it proposed or carried out. Without that log there is no way to tell whether confidential information has leaked, or whether the system has followed instructions hidden in a document. It is one of the controls built into projects on AI security and governance.

In brief

Logs are the footprints of an attack. Without them, you do not know who got in, when, or what they touched.
Default retention often lasts a few days or weeks, while attacks are discovered weeks later.
For NIS entities, the ACN measures require remote and administrative access to be logged and retention periods to be set in writing.
According to the Garante, system administrators’ access records are kept for at least six months.
Logs must be kept away from the servers they describe, in a protected store and with synchronised time.
Retention periods and uses are decided with the DPO. Security logs must not turn into a way of monitoring employees.
A few well-chosen alerts, each with an owner, are worth more than an archive that nobody reads.

Frequently asked questions

How long do security logs need to be kept?

There is no single period. For system administrators’ access, the Garante indicates at least six months. NIS entities must set periods on the basis of their risk assessment. For employees’ email metadata, the Garante suggests short periods. The choice should be documented in a retention policy agreed with IT and the DPO.

Is it enough to switch on logging on the servers?

No. If the logs stay on the same server, whoever compromises it can delete them. They must be sent to a separate store, protected against changes and with access that is separate from that of the systems they describe.

Does collecting logs mean monitoring employees?

It must not. Security logs exist to protect systems and data, and their use must be limited to that purpose, with restricted access and proportionate retention periods. When they record what employees do, the Italian rules on remote monitoring of workers also come into play. It is wise to decide with the DPO and an employment lawyer.

Which logs should you start with?

Start with remote access, authentication, email, firewalls and critical systems. These are the sources that answer the most common questions after an incident: where the attacker got in, and with which credentials.

Who should read the alerts?

A person or a team with a written remit that says who receives the alert, how quickly they look at it and what they do. It can be the internal IT team or an external service. What matters is that no alert goes unanswered.

A good log set-up makes the difference between “we know what happened” and “we can only guess”. Strategic’s Cybersecurity division helps you choose the sources to collect, set retention periods with the DPO and organise incident management, so that on the day the evidence is needed, it is there.

Sources

Consulted on 16 September 2026.

Find out moreCybersecurityTesting carried out the way an attacker would (penetration tests), incident management, business continuity and support in meeting NIS2 requirements, suppliers included.