GDPR logging and security monitoring explained

What GDPR logging and security monitoring must prove under Article 32

Your customer questionnaire or regulator letter asks how you detect intrusions, and the GDPR does not use the words logging or monitoring. What it does require is security of processing under Article 32(1), which expects measures proportionate to risk, and detection is part of that. Sweden's IMY fined the IT service provider Miljödata SEK 1,800,000 (about EUR 160,000) under Article 32(1) after a 2025 cyberattack affecting 2.2 million people, citing inadequate checks when installing new software and no automated real-time monitoring for intrusions or suspicious activity. The lesson for any organization is that an absence of detection capability can be the finding, even when prevention controls exist.

The GDPR requires no audit, attestation or certificate for this. Supervisory authorities judge whether your measures were appropriate at the time of the processing, so the question you must answer is what your evidence shows about the systems you run, the volume and sensitivity of the personal data they hold, and the threats you face. Practically, prepare a short written position covering which sources feed your detection (identity providers, endpoints, network devices, cloud control planes, applications and databases), who reviews alerts and how often, what automated rules trigger action, and how you tested that the pipeline still works after changes. Confirm which of these your current tooling actually produces before you commit to that position in writing.

Keep the evidence in a form you can hand to an assessor: configuration exports, alert samples with timestamps, review records and the results of any test that deliberately triggers an alert. The EUR-Lex text of the GDPR is the primary reference for Article 32 and should anchor the position paper. A partner can help build and document these controls, but the controller still owns them and must be able to show they operate.

What logging and monitoring must cover to pass an Article 32 review

Article 32 asks whether security measures fit the risk to personal data, and logging and monitoring are how an organization shows it can see misuse of that data. The cards below set out the components a reviewer typically asks to see, what each one shows, and the evidence that proves it runs.

Authentication and privileged access events

Logs of sign-ins, failed attempts, MFA challenges, role changes and use of administrative accounts show who touched systems holding personal data and whether strong authentication was enforced. Reviewers look for privileged activity logged separately from routine use, with a named owner for each account type. Evidence is a sample of logged events for a sample of accounts, plus the alert rules for repeated failures and out-of-hours administrator logins. Confirm with your identity platform vendor which events it emits and at what granularity.

Access to personal data stores

Record-level read, export and change events on databases, file shares and object storage show what happened to the data itself, not just to the server. This is the component most often missing when a breach investigation cannot say which records were viewed. Reviewers expect the scope of logged stores to match the record of processing and the data inventory. Evidence is a current list of covered stores with sample events showing the querying user, timestamp and object accessed. Ask your database and storage teams whether audit logging is enabled on every store in scope.

Network and perimeter events

Firewall, VPN, DNS and intrusion detection logs record traffic into and out of the environment, which supports detection of unauthorised access, malicious code and denial of service. Recital 49 treats processing for network and information security as a legitimate interest, which gives organizations a clear basis for collecting these logs. Logs in this category often contain IP addresses that are personal data, so access and retention must be controlled. Evidence is a diagram of log sources at each boundary and proof that events from those sources reach the central store.

Configuration and software change events

Logs of changes to system configuration, deployed software, security settings and access policies show whether the environment still matches its approved state. The Miljödata decision cited inadequate checks when new software was installed, so reviewers test whether installs and changes are recorded and reviewed. Evidence includes change tickets linked to deployment events, configuration drift alerts and a sample showing a change was logged before or at deployment. Confirm which change events your infrastructure-as-code and configuration tools record by default.

Alert handling and detection speed

Detection only protects personal data if someone acts on it. The Miljödata decision cited no automated real-time monitoring for intrusions or suspicious activity, so reviewers ask how quickly alerts are raised, triaged and escalated. Under EDPB Guidelines 9/2022, the controller's awareness of a breach is tied to reasonable certainty that data was compromised, so slow triage can delay the 72-hour notification clock. Evidence is an alert register with timestamps from detection to triage, documented escalation paths and tested runbooks. Set the detection and response targets in your own policy, since no supplied figure defines them.

Log integrity and time synchronization

Logs are only useful as evidence if they cannot be altered without detection and if timestamps across systems can be correlated. Reviewers look for write-once or separately administered log storage, restricted deletion rights and a documented time source for all hosts. Log access is itself personal data processing, so the same controls apply to who can read the logs. Evidence is the storage configuration showing restricted write and delete permissions, a time synchronization setting on sampled hosts, and a record of who holds administrative rights over the log platform. Confirm integrity features with your log platform vendor, since capabilities differ by product.

How the legitimate interest for network security shapes logging

Recital 49 gives controllers a useful footing for security monitoring. It states that processing personal data to the extent strictly necessary and proportionate for network and information security constitutes a legitimate interest, with examples such as preventing unauthorized access, the distribution of malicious code and denial of service attacks. For a security team, this means collecting authentication events, network flow records and endpoint alerts for detection can rest on a legitimate interest, provided the processing is limited to what detection actually needs. The key word is *strictly necessary*, and it is the reader's job to show that each log source earns its place.

The catch is that logs are personal data. Activity logs, user identifiers, IP addresses and search activity can identify a person, and pseudonymized log entries remain personal data. Article 5(1)(e) requires that identifiable data be kept no longer than necessary for the purpose, so every log category needs a documented retention period tied to its detection or investigation use. Record who can query the security platform, under what roles, and how those queries are themselves logged. Confirm with your legal team whether the legitimate interest assessment covers each source, and whether a DPIA is needed for large-scale monitoring of employees.

Plan for data subject requests before logs are collected, not after. An access request may reach security logs that mention a requester, so your team needs a way to search indexed logs, redact third-party or security-sensitive details and explain the outcome within the deadlines in Article 12. Decide how long raw logs are retained, when they are aggregated or pseudonymized, and how alerts that name individuals are closed out. Ask your platform implementer to demonstrate retention jobs and role-based query restrictions in your own environment, and treat the results as evidence for the assessor.

Which monitoring model fits: in-house, outsourced or managed

This table compares in-house, outsourced and managed monitoring for GDPR security logs and alerts, showing when each model fits and what the organization keeps owning. Read each row against your staffing, coverage hours and data location, then check whether the provider will handle personal data on your behalf. The main takeaway is that outsourcing moves labour, not accountability: the controller still answers for detection and breach decisions.

Factor	In-house monitoring	Outsourced monitoring	Managed monitoring under oversight
Who runs the monitoring	Your own security staff operate the SIEM, rules and alert queue	A service provider collects logs and runs its own monitoring operation	A provider runs alerting and triage on tools you control, with your staff approving changes
Fit with staff availability	Suits teams with enough analysts to cover shifts and handle alerts without long backlogs	Suits teams with few analysts who need detection without building a function	Suits teams that want provider depth but still need internal people to make decisions
Around-the-clock coverage	Requires shift or on-call rotation, which is costly to staff continuously	Usually provides continuous coverage; confirm hours, escalation paths and response times in writing	Usually provides continuous triage; confirm who acts on critical alerts outside business hours
Data residency constraints	Logs stay in your environment, which simplifies location and transfer questions	Logs leave your environment; confirm where they are stored and who can access them from outside the EEA	Logs can stay in your environment if the provider works through access you grant; confirm this in the design
Processor status under Article 28	Not applicable for your own staff, though vendors of tooling may still be processors	Usually a processor when it handles personal data in logs on your behalf; a written contract is required	Usually a processor for the alerting and triage it performs; sub-processors must be disclosed and approved
What the organization still owns	Detection rules, incident decisions, breach assessment, notification within 72 hours, log retention and access control	Accountability for the controller role, instructions to the provider, reviewing its reports, and breach decisions	Detection rule approval, escalation decisions, breach assessment, notification, retention limits and access reviews
Main cost driver	Analyst headcount, tooling, training and turnover risk	Volume of logs ingested, number of sources and contract scope; confirm pricing basis in the quote	Scope of alert handling, tooling you retain, and oversight time your staff must spend
What to ask for before choosing	Staffing plan, shift coverage, runbook, retention schedule and evidence of past alert reviews	Data processing agreement, sub-processor list, storage locations, access controls and breach notice terms	Written split of responsibilities, escalation matrix, data location, and your right to review alert logic

How a logging and monitoring program moves from design to evidence

This sequence turns the question of whether the organization can detect and act on security events into a scoped design, tested detection, a working triage path for personal data breaches, and a bundle of evidence an assessor or supervisory authority can review. Each phase hands a defined output to the next.

Scope the systems and personal data in scope
The controller or processor starts by listing the systems, applications, identity services and network segments that hold or provide access to personal data, along with the processing activities they support. The data protection lead and system owners confirm the list against the record of processing. The output is a signed scope statement that names each system, its data categories and its owner. Anything left outside the scope should have a recorded reason, because an assessor will ask why a personal data store was excluded from monitoring.
Define log sources and retention
For each in-scope system, the team identifies which events matter for detecting unauthorised access, malicious code and misuse, such as authentication outcomes, administrative changes, privileged sessions, data exports and network flows. It also records where those logs are written, who can read them and how long they are kept. Retention must be justified against the purpose of monitoring, since Article 5(1)(e) limits keeping personal data in identifiable form to what is necessary. The output is a log source register with a retention rationale for each source, reviewed by legal or the DPO before collection starts.
Configure collection and alert rules
Engineers route the agreed log sources into a central store, enforce time synchronisation, protect log integrity and restrict administrative access to the logging platform itself. They then write alert rules tied to the threats in the scope statement, such as repeated failed logins, access to bulk personal data outside normal patterns or changes to logging settings. Access to logs is limited to staff with a need to know, and the log data is itself treated as personal data. The output is a configuration baseline in version control and a list of active alert rules with named owners.
Test detection with controlled events
The security team runs controlled, documented test events against the scoped systems, such as a simulated credential misuse or a test export of records, and checks whether the expected alerts fire, reach the right queue and carry enough detail to act. Gaps found here go back into the configuration phase. Testing can be done internally or with an external tester, and the test plan should be approved before it runs so that it does not itself generate a reportable incident. The output is a test report showing each scenario, the result, the time to alert and the remediation for each gap.
Establish triage and escalation for personal data breaches
The organization defines who reviews alerts, how an alert becomes an incident, and how the team decides whether personal data has been compromised. Under the EDPB's view in Guidelines 9/2022, a controller is aware once it has a reasonable degree of certainty that an incident has led to personal data being compromised, so the escalation path must reach the DPO and decision makers quickly and be written down. Processors must also know how to notify their controllers without undue delay. The output is a triage runbook, an escalation matrix with named roles and a record template for breach documentation.
Assemble evidence for review
The team gathers the artefacts that show the program works as designed: the scope statement, the log source register, the configuration baseline, alert rule history, test reports, sample alert and incident tickets, triage records and access reviews for the logging platform. The bundle is indexed so that an independent auditor or a supervisory authority can trace each Article 32 claim to a specific record. Evidence should be refreshed on a set schedule agreed in the written scope. The output is a dated evidence pack that the controller owns and can produce on request, with a note on any control still open.

What must be in place before a regulator or customer asks

Regulators and customers rarely ask for a logging policy in the abstract. They ask whether monitoring works, who acts on it, and whether the logs themselves are handled lawfully. The six items below connect the security function to the documents a reviewer will request, and each can be checked internally before anyone outside looks at it.

Current inventory of systems holding personal data

Logging scope follows data scope. Maintain a list of every system, SaaS tool, database and endpoint group that processes personal data, with its owner and whether its logs are forwarded to the central monitoring platform. Check it by comparing the list against your record of processing and your cloud account inventory, and looking for systems that hold personal data but send no logs. A reviewer will ask for this list first, because a gap in it means a gap in detection that cannot be explained.

Written logging standard with retention and access rules

A logging standard states what must be logged, for how long, who may query the logs, and how access is recorded. Set retention per log source and justify it against the purpose of monitoring, since Article 5(1)(e) limits keeping personal data to what is necessary. Check that the standard names an owner, that retention is enforced by configuration rather than by memory, and that access to the log platform itself is restricted and reviewed. Reviewers will ask for the standard, the retention settings exported from each platform, and the most recent access review.

Tested alert paths with named owners

Detection only supports Article 32 if an alert reaches someone who can act on it at any hour. For each high-priority alert type, such as mass download, impossible-travel sign-ins, disabled logging or malware on an endpoint, document the route from alert to triage, escalation and containment, with a named primary and backup owner. Test each path with a planned exercise and record the time from alert to acknowledgement. Reviewers will ask for the routing configuration, the on-call roster and the results of the most recent test.

Documented legitimate interest assessment for security logging

Recital 49 treats processing strictly necessary for network and information security as a legitimate interest, but relying on it still requires a documented balancing test. Record the purpose (preventing unauthorised access, malicious code and denial of service), the data collected from users, the reasonable expectations of staff, and the safeguards applied, such as pseudonymised user identifiers and restricted analyst access. Check that the assessment matches what is actually logged today. Reviewers will ask for the signed assessment, the date of its last review, and the log source list it covers.

Process for access requests that include logs

Logs that name a person are personal data, so an access request can reach them. Define how the team searches logs for a data subject, how results are reviewed before release, and how other people's data and security-sensitive detail are removed or withheld. Keep the search proportionate: requests for extra identity information must not force excessive collection. Check the process by running a test request against a sample identity and timing the search. Reviewers will ask for the written procedure, the search queries used, and a record of at least one completed request.

Records of how detections led to decisions

A regulator reviewing a breach will ask what the monitoring saw and what the organization decided, including the reasoning behind decisions not to notify. Keep a case record for each significant detection showing the time it was raised, the triage result, whether personal data was affected, and the outcome. These records also support the awareness analysis in the breach timeline, since EDPB Guidelines 9/2022 tie awareness to a reasonable degree of certainty that personal data was compromised. Check a sample of closed cases for missing timestamps or undocumented closures. Reviewers will ask to see these records alongside the alert logs they reference.

Who does what: your team, an implementation partner and the authority

Your organization remains the controller or processor, so it owns the security measures, the risk decisions and every breach decision. Under Article 32 the appropriate level of security is set by the organization after assessing risk to individuals, and under Article 33 it is the organization that decides whether a breach must be notified and when its awareness clock starts. Internal staff also keep the Article 30 records of processing, which must describe the security measures in place.

Control ownership: Name an accountable owner for logging, alert triage and log retention, and record which events are logged and why.
Risk and detection thresholds: Decide which events are high-risk, how fast they must be triaged, and what counts as a suspected personal data breach.
Breach decisions: Run the internal decision on awareness, notification to the supervisory authority and communication to affected individuals.
Article 30 records: Keep the processing records current, including the security measures that protect logs and monitoring data.
Lawful basis and retention: Document the legitimate interest for network security monitoring and set a retention period for logs that is no longer than needed.

Check that each of these duties has a named person, a written procedure and a recent review date.

What the Miljödata fine shows about falling short

The Swedish IMY fined the IT service provider Miljödata SEK 1,800,000 (about EUR 160,000) under Article 32(1) of the GDPR in a decision dated 22 September 2026. The fine followed a 2025 cyberattack that affected 2.2 million people. The authority cited two shortcomings: inadequate checks when new software was installed, and no automated real-time monitoring for intrusions or suspicious activity. The finding concerns the security measures in place at the time, judged against the risk. Read the EDPB summary of the Swedish decision first, then the decision itself.

The first lesson concerns change checks. Treat every new software installation as a change that needs a documented check before it reaches production. In practice this means reviewing what the package or update alters, verifying its source and integrity, testing it in a non-production environment, and recording who approved it. Confirm with your change owner whether these checks also cover updates to logging agents, SIEM collectors and alert rules. If they do not, a faulty update can switch off detection without anyone noticing.

The second lesson concerns automated monitoring. Decide which events must generate alerts without waiting for a person to review logs: failed and unusual logins, new administrator accounts, privilege changes, large data exports and any change to the logging configuration itself. Confirm who receives each alert, how quickly they must act, and how the team tests that alerts still fire. Whatever the outcome in your own case, confirm your position with counsel before drawing conclusions from one authority's decision.

Common questions about GDPR logging and security monitoring

Does the GDPR explicitly require logging and security monitoring?

The GDPR does not name logging or monitoring as a specific control. Article 32 instead requires a security level appropriate to the risk, assessed with the state of the art and the cost of implementation, and it is the regulator's reading of that duty that makes detection a practical requirement. Recital 87 asks whether appropriate measures are in place to establish immediately whether a personal data breach has occurred. In Sweden, the IMY fined Miljödata SEK 1,800,000 (about EUR 160,000) under Article 32(1) after a 2025 cyberattack affecting 2.2 million people, citing no automated real-time monitoring for intrusions or suspicious activity. Treat monitoring as the evidence that your Article 32 duty is being met, and confirm the interpretation with your supervisory authority or counsel.

Can our own team handle GDPR logging work without an outside partner?

Often yes, if your engineers already run logging and detection and your legal and privacy staff can make the retention and lawful basis decisions. The work is mainly about deciding what to log, where logs are stored, who can read them, and how long they are kept, then proving those choices with records. Outside help is most useful when the team lacks detection engineering capacity, when logs span many systems and cloud accounts, or when you need an independent view before an assessment. An implementation partner can prepare systems and evidence, but the organization keeps ownership of its controls and decisions.

How much effort does GDPR logging and monitoring take, and what drives it?

Effort depends on scope, and no supplied figure gives a reliable estimate, so ask for one based on a written scope. The main drivers are the number of systems and data stores producing logs, whether logs are centralized already, the volume and retention of log data, how many detection rules you need, and how much alert triage a team must absorb. Ask any provider for a breakdown covering design, deployment, rule tuning, access controls on the log store, documentation and handover, and whether each is one-time or recurring. Ongoing tuning and review usually recur, while initial deployment does not.

How long does preparing GDPR logging and monitoring take?

The timeline is set by how many systems must feed the monitoring, how mature your current logging is, and how long approvals take for the privacy assessment and access rules. A narrow scope covering a few critical systems can move quickly, while an estate spread across several clouds and legacy platforms needs more discovery and testing. Include time for a documented legitimate interest assessment, retention decisions and staff training. Ask for milestones in the written scope so progress can be checked against them.

Do logs containing personal data have to be deleted after a set period?

No fixed period appears in the GDPR. Article 5(1)(e) requires personal data to be kept in identifiable form only for as long as necessary for the purpose, so logs holding user identifiers, IP addresses or search activity need a justified retention period. Logs that serve network security may be kept for longer than routine application logs, but the period must be proportionate and documented. Define retention per log type, enforce it automatically, and check that backups and archives follow the same rule. Pseudonymised logs remain personal data, so they do not escape these limits.

Is a managed monitoring or SIEM provider a processor under the GDPR?

Usually yes, when the provider processes personal data contained in your logs on your behalf. Article 28 then requires a written processing contract covering instructions, confidentiality, security measures, sub-processors, and assistance with breaches and data subject requests. If the provider uses its own threat intelligence derived from your data for its own purposes, its role may need separate analysis. Where the platform runs inside your own infrastructure, you keep control of the data and reduce the number of processors, which should be confirmed in your data flow mapping.

What must the organization provide to an implementation partner before work starts?

Provide a current inventory of systems and data stores, cloud accounts and network segments, existing logging sources and tooling, data flow records, and the retention and access rules your privacy team has set. Also share your incident response plan, breach notification roles, and any existing risk assessment, since these shape what detection must support. Name a decision owner who can approve retention and access choices quickly. Clear inputs keep the fixed scope accurate, and the written scope should state which items the organization owns and which the partner prepares.

How DeployOpen works on this

DeployOpen plans and implements self-hosted open-source logging and monitoring platforms inside your own cloud accounts, data centers or air-gapped networks. We prepare the systems, detection rules, retention settings and documentation that show how your organization meets its Article 32 duties, while your organization remains the controller that owns the decisions.

How we scope

Agree in writing which systems, log sources and processing activities the logging and monitoring work covers.
Record the log retention periods, access roles and legitimate interest rationale your DPO or legal team must approve.
Define which detection use cases, alert routes and response owners are in scope before any build work starts.
Confirm which parts remain with your organization, such as the 72-hour breach decision and regulator contact.

How we build

Deploy self-hosted log collection and monitoring components within your infrastructure, with no transfer of logs to outside parties.
Configure log pseudonymisation, minimisation and retention so that logs holding personal data are kept only as long as needed.
Test detection rules against simulated attack activity, and record results so you can show the monitoring works as designed.
Apply hardening, access restrictions and integrity protection to the logging platform itself, so that its own records stay reliable.

How we hand over

Document architecture, log sources, retention schedules, alert procedures and access reviews in a form your assessors can read.
Provide evidence packs that map each logging and monitoring control to the configuration, test records and review logs that support it.
Train your security and operations staff to run the platform, triage alerts and handle breach-relevant incidents.
Your independent auditor or certification body, not DeployOpen, decides whether the evidence meets the standard or regulator expectations.

How we support

Support engagements can be ongoing under a retainer covering upgrades, rule tuning and periodic monitoring tests.
Re-test detection coverage when new systems, log sources or processors are added to your environment.
Review retention and access settings on a schedule agreed with your DPO, and update documentation when they change.
Ask for a quote based on the written scope, since DeployOpen does not publish a price list.

GDPR logging and security monitoring