Security Logging and Monitoring Under the GDPR
How to run security logging, SIEM, EDR and DLP in line with GDPR: lawful basis, employee monitoring, retention periods, access control and field masking.
Logging is one of the few security controls the GDPR practically demands. Article 32(1)(b) requires the ability to ensure the ongoing confidentiality, integrity, availability and resilience of systems, Article 32(1)(d) requires regular testing of the effectiveness of measures, and Article 33 expects you to describe a breach, its scope and its consequences within tight deadlines. None of that is possible without good telemetry. Yet logs are also a large, often forgotten store of personal data: IP addresses, usernames, email addresses, URLs, device identifiers and sometimes message content. A SIEM that keeps everything forever, readable by everyone in IT, is itself a privacy risk. This guide shows how to build logging and monitoring that is both effective for security and defensible under the GDPR.
Logs contain personal data
Under Article 4(1), personal data is any information relating to an identified or identifiable natural person. Security logs are full of it:
- Authentication events with usernames and source IPs
- Proxy and DNS logs revealing browsing behaviour
- Email gateway logs with sender and recipient addresses
- EDR telemetry with process command lines, file paths and user context
- Application logs that accidentally capture request bodies, tokens or form fields
IP addresses deserve a specific mention. In Breyer (C-582/14, 19 October 2016), the CJEU held that a dynamic IP address can be personal data for a website operator that has legal means to identify the person using additional data held by the ISP. Treat IPs in logs as personal data by default.
Lawful basis: legitimate interests and Recital 49
Every processing needs a lawful basis under Article 6(1). For security monitoring, the usual basis is legitimate interests under Article 6(1)(f). Recital 49 is helpful here: it states that processing of personal data to the extent strictly necessary and proportionate for ensuring network and information security constitutes a legitimate interest of the data controller concerned. It mentions public authorities' CERTs and CSIRTs, providers of electronic communications networks and services, and providers of security technologies and services.
Note the qualifiers: "strictly necessary and proportionate". Recital 49 does not mean any logging is automatically lawful. You still need to document the balancing of your interest against the rights of the people in the logs, and the answer depends on what you collect, how long you keep it and who can see it.
Where a law requires you to keep specific logs, for example in regulated sectors, Article 6(1)(c) (legal obligation) may be the relevant basis for that part. Which laws apply to you is a question for your DPO and legal team; check national rules and sector regulation rather than assuming.
Proportionality in practice
Proportionality is where security engineering and data protection meet. The principles of Article 5(1)(c) data minimisation and Article 25 data protection by design translate into concrete logging decisions.
| Log source | Security value | Privacy risk | Proportionate approach |
|---|---|---|---|
| Authentication logs | High: account compromise, brute force | Low to medium | Collect fully; restrict access; defined retention |
| DNS and proxy logs | High: C2, exfiltration, phishing | High: reveals browsing | Collect domains; avoid full URLs with query strings where possible |
| EDR telemetry | High: endpoint threats | Medium to high | Collect security events; avoid capturing document content |
| Email gateway | High: phishing, malware | High: communications metadata | Metadata for detection; content only in quarantine workflows |
| DLP | Medium to high: data leakage | High: content inspection | Narrow rules, alert on patterns, restrict who sees matched content |
| TLS inspection | Medium to high: hidden threats | High: decrypts private traffic | Bypass categories such as health and banking; inform users |
| Application debug logs | Low for security | Variable, often high | Do not log secrets, tokens or request bodies in production |
Monitoring employees
Most security monitoring also monitors employees, which brings extra constraints. Article 88 allows Member States to adopt more specific rules on processing in the employment context, so national labour and data protection law may add requirements such as consulting employee representatives. Check your national supervisory authority's guidance and involve HR and legal early.
The Article 29 Working Party Opinion 2/2017 on data processing at work sets the general expectations. Monitoring must be necessary, proportionate and transparent. Employers should prefer preventive measures and less intrusive means over blanket surveillance, carry out a legitimate interest balancing, and inform employees. The Opinion specifically flags that technologies such as DLP, TLS inspection and monitoring of employees' communications need care.
Practical safeguards:
- Purpose limitation: security telemetry is for security. Do not reuse it for productivity measurement or performance reviews without a separate assessment (Article 5(1)(b)).
- Graduated access: analysts see pseudonymised identities by default; de-pseudonymisation requires a justified case and is logged.
- Transparency: an IT acceptable use policy and an employee privacy notice that describe what is logged, why, for how long and who can access it.
- DPIA: large-scale or systematic monitoring of employees often meets several WP248 criteria (systematic monitoring, vulnerable data subjects including employees). See our guide on DPIAs for IT projects.
Retention
Article 5(1)(e), storage limitation, requires that personal data be kept in identifiable form no longer than necessary. Logs are no exception. The GDPR sets no number of days, so you need a documented, justified period per log category.
A useful benchmark is the French supervisory authority's recommendation on logging (CNIL délibération n° 2021-122 of 14 October 2021). It recommends retaining logs for 6 months to 1 year as a general rule, unless a legal obligation or a specific risk justifies a different period, and it recommends that logs be protected, access restricted and logs actually analysed. This is one regulator's guidance, not a pan-EU rule, but it is a reasonable starting point to discuss with your DPO. For broader retention patterns, see data minimisation and retention.
A local retention configuration for systemd-journald might look like this. Values are examples; align them with your documented retention schedule and your central log platform.
# /etc/systemd/journald.conf.d/retention.conf
# Local journal is a short buffer; central SIEM holds the authoritative copy.
[Journal]
Storage=persistent
Compress=yes
Seal=yes
SystemMaxUse=2G
# Delete local entries older than 30 days
MaxRetentionSec=30day
# Forward to the local syslog daemon for central shipping
ForwardToSyslog=yes
And a logrotate policy for application logs on the same host:
# /etc/logrotate.d/webapp
/var/log/webapp/*.log {
daily
rotate 30
compress
delaycompress
missingok
notifempty
create 0640 webapp adm
# Old rotations are removed after 30 days
maxage 30
}
In the SIEM, configure index lifecycle policies per data category rather than a single global value, and make sure deletion actually happens, including in cold storage and archives.
Minimise and mask at ingestion
The cheapest personal data to protect is the data you never store. Mask or pseudonymise at the pipeline stage, before events reach long-term storage. The example below uses a keyed hash (HMAC) so that the same user produces the same token for correlation, while the key is held separately, in line with the Article 4(5) definition of pseudonymisation.
# Log pipeline field-masking policy (illustrative, vendor-neutral)
pipeline: security-events
rules:
- field: user.email
action: hmac_sha256 # keyed hash: consistent token, not reversible without key
key_ref: "kms://eu/log-pseudonymisation-key"
output_field: user.email_token
drop_original: true
- field: source.ip
action: keep # needed for detection and incident scoping
- field: url.query
action: drop # query strings often carry tokens and personal data
- field: http.request.body
action: drop
- field: http.request.headers.authorization
action: drop
- field: message
action: regex_redact
patterns:
- '(?i)password=\S+'
- '(?i)bearer\s+[A-Za-z0-9._-]+'
replacement: "[REDACTED]"
access:
default_role: soc-analyst # sees tokens, not raw emails
reidentification_role: ir-lead # can resolve tokens, every lookup audited
Do not use plain unsalted hashes for identifiers such as email addresses: they can be reversed by enumeration or dictionary attacks. Use keyed hashing or tokenisation.
Protect the logs themselves
Logs are a high-value target, both for attackers covering their tracks and as a source of personal data. Apply Article 32 to the logging platform itself:
- Role-based access, least privilege and MFA for SIEM and log storage
- Audit logging of access to logs, especially searches on named individuals
- Integrity protection: append-only or write-once storage, forward sealing, central shipping
- Encryption in transit and at rest
- Segregation of duties so administrators cannot silently delete their own traces
Logging as breach evidence
When an incident happens, logs are how you answer the Article 33(3) questions: the nature of the breach, categories and approximate number of data subjects and records concerned, likely consequences, and measures taken. Article 33(5) requires you to document every personal data breach. Without adequate logs, you may have to assume the worst case for scoping. Plan your logging with the 72-hour notification process in mind: which data stores are accessed, by whom, from where, and what was exported.
Checklist
- Documented lawful basis and legitimate interest balancing for each monitoring tool
- Log source inventory with purpose, data categories and retention per source
- Masking of secrets and unnecessary personal data at ingestion
- Retention enforced technically, including archives
- Restricted, audited access to logs; pseudonymised views for analysts
- Employee information and, where relevant, consultation under national rules
- DPIA for intrusive or large-scale monitoring
- Logging coverage tested against breach scoping scenarios
Scope of this guide
This article is technical guidance for security and IT teams on logging and monitoring under the GDPR. It is not legal advice. Lawful basis, retention periods and employee monitoring arrangements should be confirmed with your data protection officer and legal counsel, taking national law into account.