Logs, the foundation of the SOC: what to collect, how long to keep it, how to centralize and protect it

Up to date as of November 7, 2026. The requirements cited come from the European texts and from the recommendations of ANSSI and the CNIL. The French transposition of NIS2 may make them more specific.

On the day of an incident, the same questions come up: how long has the attacker been there? How did they get in? What data did they access? Without complete, timestamped and intact logs, they cannot be answered. Which means you cannot remediate properly, notify the authorities on time or provide evidence to the insurer.

Logs are also the fuel of the SOC: SIEM correlation rules, threat hunting and, increasingly, the AI that assists analysts are only as good as the data they work with.

What to collect

It is better to start from the risks and priority detection scenarios than to try to collect everything: each source has a storage, licensing and analysis cost. The must-have sources, however, remain the same:

identities and access: directory (Active Directory, Entra ID), single sign-on, VPN, multi-factor authentication, privileged accounts;
endpoints and servers: telemetry from EDR and XDR solutions, Windows event logs, Linux system logs;
the network and the perimeter: firewalls, proxies, DNS, DHCP;
email and collaboration tools;
cloud and SaaS services: audit logs of the administration consoles, often limited or disabled by default;
sensitive business applications and databases;
the security tools themselves, and the logging infrastructure;
AI systems and agents: prompts, answers, tool calls and data accessed (see our analysis Securing AI agents in the enterprise).

Mapping to MITRE ATT&CK attack techniques helps spot blind spots: which techniques are not visible in any collected source?

How long to keep logs

There is no single retention period: it depends on the purpose, the applicable texts and the sensitivity of the data. A few benchmarks:

the CNIL recommends keeping the logs that trace access to personal data between six months and one year, a longer period being justifiable in some cases, for example a legal obligation or litigation;
the AI Act requires providers and deployers of high-risk AI systems to keep automatically generated logs for at least six months;
some sector-specific regulations may require longer periods.

From a security standpoint, keep in mind that some intrusions are only discovered after several months. Common practice is to distinguish:

“hot” storage, quickly searchable in the SIEM, over a few weeks or a few months;
“cold” archiving, compressed and integrity-protected, for the period set by the retention policy.

This policy must be written down, justified for each type of log and validated with the DPO, because logs contain personal data.

How to centralize

A layered architecture

In its guide to the architecture of a logging system, ANSSI details the principles of controlled collection: centralize the logs, isolate the logging infrastructure and standardize timestamps. Without a common clock across all devices, it is impossible to rebuild a reliable timeline.

In practice, there are three levels:

collection, as close as possible to the sources;
transport and processing: filtering, normalization, enrichment, buffering in case of an outage;
use: the SIEM for detection and investigation, and archive storage for long-term retention.

The role of syslog-ng

A collection layer such as syslog-ng, published by One Identity, links the sources to their destinations. It makes it possible to collect heterogeneous formats, filter and normalize events before they are sent to the SIEM in order to control volumes, encrypt the transport, keep the logs when the destination is unavailable, and send the same stream to several destinations, for example the SIEM and encrypted, timestamped archive storage.

The SIEM, at the core of operations

The SIEM centralizes events, correlates them to detect suspicious behavior and serves as the basis for investigation. Its value depends directly on what it receives:

complete and correctly parsed sources, so that every field can be used in rules and searches;
detection rules that are maintained and tested, aligned with real threats;
controlled volumes, because the cost of a SIEM often depends on the volume of data ingested.

With a collection layer upstream, the sources only need to be configured once, and each stream can be routed to the SIEM, to the archive or to both, depending on its value for detection.

How to protect logs

A seasoned attacker tries to cover their tracks. Logs must therefore be protected like sensitive data:

export them quickly out of the monitored systems, so that compromising the machine is not enough to erase them;
restrict access to the logging infrastructure, with dedicated administration accounts;
guarantee integrity: hashes, signatures or immutable storage;
encrypt logs in transit and at rest;
detect silence: a source that stops sending must trigger an alert, because it is sometimes the first sign of an attack.

What the texts say

Text	Requirements on logs
NIS2 (Implementing Regulation 2024/2690, Annex, section 3.2)	Monitoring and logging processes covering a baseline of events, for certain digital providers (cloud, data centers, managed services and managed security services, DNS…). A useful reference for all entities.
DORA (Delegated Regulation 2024/1774, Article 12)	Documented logging procedures and tools, protection of logs against tampering, deletion and unauthorized access, detection of failures of the logging systems.
AI Act (Articles 12, 19 and 26)	Automatic logging of the events of high-risk AI systems, retention of logs for at least six months.
GDPR (CNIL recommendation of 2021)	Traceability of access to personal data, retention from six months to one year unless justified.

In June 2025, ENISA published technical implementation guidance for these NIS2 measures, which details in particular what is expected in terms of monitoring and logging.

Where to start

Inventory the sources and check what actually reaches the SIEM, and what is missing.
Start from the priority detection scenarios to decide what to collect, using MITRE ATT&CK.
Synchronize the time of all devices to the same reference.
Set up a collection layer decoupled from the SIEM, with filtering, encryption and buffering.
Write the retention policy for each type of log, between hot storage and archiving, and have it validated by the DPO.
Protect and monitor the logging infrastructure, including silent sources.
Test on a real scenario: can you rebuild the complete timeline of an incident within a few hours?

These logs are also the raw material for incident notifications (see One incident, several clocks) and for AI applied to the SOC (see The AI-augmented SOC).

Sources

← All insights