When police, prosecutors or other competent authorities process personal data to fight crime, the GDPR does not apply: Directive (EU) 2016/680, the Law Enforcement Directive (LED), does, and its security and logging rules are stricter in places than the GDPR. Member States had to transpose it by 6 May 2018, and the last transitional period for logging in older automated systems ended on 6 May 2026, so every in-scope system should now produce the logs the Directive requires. This guide is for security, identity and data protection teams in police forces, justice ministries, prosecution services and the private bodies Member State law entrusts with public powers, and for the suppliers who host or build their systems. It covers what the GDPR guides do not: the LED's own scope test, the Article 25 logging duty, the Article 29 security controls, breach notification and transfers. For general GDPR controls see the GDPR Compliance Guide for Security Teams.
Key takeaways
- Purpose decides the law. The LED applies when a competent authority processes data for the prevention, investigation, detection or prosecution of criminal offences or the execution of criminal penalties (Article 1(1)); the same authority's HR or facilities data stays under the GDPR.
- Logging is mandatory, not best practice. Article 25 requires logs of collection, alteration, consultation, disclosure including transfers, combination and erasure in automated processing systems, and consultation logs must show the justification, date, time and, as far as possible, who looked.
- The security article reads like a control catalogue. Article 29(2) lists ten control objectives, from equipment access control to recovery and integrity, that map directly onto identity, logging and resilience controls.
- Breach clocks match the GDPR. Article 30 requires notification to the supervisory authority without undue delay and, where feasible, within 72 hours, plus onward notice to another Member State's controller when its data is involved.
- Every controller needs a DPO. Article 32 makes a data protection officer mandatory, with an optional exemption for courts acting in their judicial capacity.
Scope: when the LED applies instead of the GDPR
Article 2 applies the Directive to processing by competent authorities for the Article 1(1) purposes, whether automated or part of a filing system. Article 3(7) defines a competent authority as (a) any public authority competent for the prevention, investigation, detection or prosecution of criminal offences or the execution of criminal penalties, or (b) any other body or entity entrusted by Member State law to exercise public authority and public powers for those purposes. Point (b) can reach private operators, so check national transposing law.
| Processing example | Likely regime | Why |
|---|---|---|
| Police case management and intelligence systems | LED | Competent authority, criminal law purpose |
| Prosecution service evidence repository | LED | Prosecution of criminal offences |
| Police force payroll and HR records | GDPR | Not processed for an Article 1(1) purpose |
| Private body running a function entrusted by national law with public powers for crime prevention | LED, if national law entrusts it under Article 3(7)(b) | Depends on transposing law |
| Retailer sharing CCTV with police on request | GDPR for the retailer; LED for the police once received | The retailer is not a competent authority |
| Union institutions and agencies | Neither: Regulation (EU) 2018/1725 | Article 2(3) excludes Union bodies |
| National security activities | Outside Union law | Article 2(3) excludes activities outside Union law |
Article 59 repealed the earlier Council Framework Decision 2008/977/JHA with effect from 6 May 2018. The Commission presented its first evaluation report on 25 July 2022, finding transposition generally satisfactory but with issues that led to infringement procedures; the EDPB said in January 2026 that the Commission intended to present its second report in May 2026, so check for it before relying on this page. In the United Kingdom, Part 3 of the Data Protection Act 2018 carries equivalent rules; see the UK GDPR and Data Protection Act 2018 Guide.
Principles and data subject rules that shape system design
- Principles (Article 4(1)): lawful and fair processing, specified and legitimate purposes, data that are adequate and not excessive, accurate, kept no longer than necessary and secured.
- Time limits (Article 5): Member States must set time limits for erasure or for periodic review of the need to store data. Build review dates into the data model, not into a policy document.
- Categories of data subject (Article 6): where possible, distinguish suspects, convicted persons, victims and other parties such as witnesses. This is a schema requirement: records need a category field that drives access and retention.
- Special categories (Article 10): biometric, genetic, health and similar data may be processed only where strictly necessary, with safeguards, and only if authorised by law, to protect vital interests, or where manifestly made public by the data subject. See the Biometrics Guide.
- Automated decisions (Article 11): solely automated decisions with adverse legal effect are prohibited unless authorised by law with safeguards including at least the right to human intervention, and profiling that discriminates on special category data is prohibited. Analytics and AI tools in policing need this designed in; see the EU AI Act High-Risk AI Systems Guide.
- By design and by default (Article 20): measures such as pseudonymisation, and by default only the data necessary for each purpose, with data not made accessible to an indefinite number of people without the individual's intervention.
Article 25 logging: what must be recorded
Article 25 is the LED's most distinctive technical duty. Logs must be kept in automated processing systems for at least the six operations below. For consultation and disclosure, logs must make it possible to establish the justification, the date and time, and, as far as possible, the identity of the person who consulted or disclosed the data and the identity of recipients.
| Operation | Minimum log content (our implementation reading) | Typical gap |
|---|---|---|
| Collection | Source, record ID, user or system account, timestamp | Bulk imports logged as one event with no record IDs |
| Alteration | Record ID, field changed, before and after reference, user | Direct database changes by administrators bypass application logs |
| Consultation | User identity, record ID, justification (case or reference number), date and time | No justification field, so lawfulness cannot be checked |
| Disclosure, including transfers | Recipient identity, legal basis, records sent, user, date and time | API integrations log the service account only, not the requesting officer |
| Combination | Datasets combined, purpose, user | Analytics platforms join data outside the logged application |
| Erasure | Record ID, reason (time limit or review), user | Automated deletion jobs with no audit record |
Article 25(2) restricts the use of logs to verifying lawfulness, self-monitoring, ensuring integrity and security, and criminal proceedings, and Article 25(3) requires them to be made available to the supervisory authority on request. That purpose limitation matters for security operations: logs fed to a SIEM for security monitoring fit "ensuring integrity and security", but reusing them for staff performance management does not.
The transitional periods have ended
Article 63(2) allowed automated systems set up before 6 May 2016 to reach Article 25(1) compliance by 6 May 2023 where earlier compliance would take disproportionate effort, and Article 63(3) allowed a further period in exceptional cases, but no later than 6 May 2026. As of November 2026, no transitional relief remains under the Directive. The EDPB's January 2026 contribution to the LED evaluation notes one supervisory authority that could not investigate a past violation because deletion routines had removed the log data, so retention settings deserve the same attention as coverage. See the Log Management and Retention Guide.
Article 29 security controls
Article 29(1) requires appropriate technical and organisational measures for a level of security appropriate to the risk. For automated processing, Article 29(2) requires measures designed to achieve the ten objectives below, following a risk evaluation.
| Article 29(2) | Objective | Practical controls | NIST SP 800-53 Rev 5 |
|---|---|---|---|
| (a) Equipment access control | Deny unauthorised access to processing equipment | Physical access, privileged access workstations | PE-3 |
| (b) Data media control | Prevent unauthorised reading, copying, modification or removal of media | Removable media policy, disk encryption | MP-7 |
| (c) Storage control | Prevent unauthorised input, inspection, modification or deletion of stored data | Database privilege separation, change control | AC-6 |
| (d) User control | Prevent use of systems by unauthorised persons via data communication equipment | MFA for all remote and interactive access | IA-2 |
| (e) Data access control | Users access only data covered by their authorisation | Role and case-based access, Article 6 category filters | AC-3 |
| (f) Communication control | Verify recipients of transmitted data | Mutual TLS, recipient allow lists for interfaces | SC-8 |
| (g) Input control | Verify what data was input, when and by whom | Application audit logging tied to individual identity | AU-2 |
| (h) Transport control | Prevent unauthorised access during transfer or transport of media | Encryption in transit and for physical media | SC-8 |
| (i) Recovery | Restore systems after interruption | Tested backups and recovery plans | CP-10 |
| (j) Reliability and integrity | Functions perform, faults are reported, data is not corrupted | Monitoring, integrity checks, protected logs | AU-9 |
The control mapping is ours; the Directive does not reference NIST. For identity programmes in policing and justice, the Public Sector Identity Security Guide and, for US data exchanges, the CJIS Security Policy Guide cover overlapping ground.
Where identity fits
Article 25 asks for the identity of the person who consulted or disclosed data, which breaks down whenever a shared account, a generic service account or an integration token sits between the officer and the record. Three practical rules follow (our recommendations): propagate the end user's identity through middleware and APIs rather than logging only the calling service; give each integration its own non-human identity with a named owner and a narrow scope; and treat administrator and database access as consultation that must be logged. See the Privileged Access Management Guide and the Non-Human Identity (NHI) Guide.
Processors, records, DPIA and prior consultation
- Processors (Article 22): a binding written contract or legal act requiring the processor to act only on instructions, ensure confidentiality, assist with rights, delete or return data and follow sub-processor rules. Sub-processors need prior specific or general written authorisation. Cloud and managed service providers to police forces sit here.
- Records of processing (Article 24): include the legal basis, profiling, transfers, erasure time limits where possible and a general description of security measures where possible, in writing and available to the supervisory authority.
- DPIA (Article 27): required before processing likely to result in high risk, in particular with new technologies, covering risks, safeguards and security measures. See the DPIA Guide.
- Prior consultation (Article 28): required for new filing systems where the DPIA shows high risk without mitigation or where the type of processing involves high risk. The supervisory authority gives written advice within six weeks, extendable by one month for complex cases.
Breach notification and transfers
| Duty | Rule | Article |
|---|---|---|
| Notify the supervisory authority | Without undue delay and, where feasible, within 72 hours of becoming aware, with reasons if late; not required if unlikely to result in a risk to rights and freedoms | 30(1) |
| Processor to controller | Without undue delay | 30(2) |
| Contents | Nature of the breach, approximate numbers of data subjects and records, DPO contact, likely consequences, measures taken; may be provided in phases | 30(3), (4) |
| Documentation | Every breach documented | 30(5) |
| Cross-border data | Information passed without undue delay to the controller of the other Member State that sent or received the data | 30(6) |
| Tell data subjects | Without undue delay where high risk is likely, unless encryption rendered data unintelligible, the risk was eliminated or effort is disproportionate; may be delayed or restricted under Article 13(3) | 31 |
| Third-country transfers | Only if necessary for Article 1(1) purposes, normally to a competent authority, with an adequacy decision, appropriate safeguards or a listed derogation; direct transfers to other recipients only in individual cases under strict conditions | 35 to 39 |
The EDPB reports that 18 supervisory authorities separate LED breaches from GDPR breaches in their notification handling and 9 do not, so check your authority's own form. Article 57 leaves penalties to Member States, and the same EDPB report notes that 16 authorities can impose administrative fines under the LED while 11 cannot. For the wider notification landscape see the Data Breach Notification Checklist.
Implementation approach
- Classify systems by regime: tag each system LED, GDPR or mixed, using the Article 1(1) purpose test and your national transposing law.
- Audit logging against Article 25: for each LED system, test whether all six operations are logged and whether consultation entries carry a justification and an individual identity. Start with the systems that hold the most sensitive Article 10 data.
- Fix identity propagation: remove shared accounts, propagate end user identity through APIs, and inventory integration accounts and keys.
- Protect and retain logs: send logs to a protected store with integrity controls and retention long enough to support proactive self-monitoring and supervisory requests; restrict access to the Article 25(2) purposes.
- Run self-monitoring: sample consultation logs for missing or weak justifications each month, and investigate outliers.
- Rehearse breach handling: include the Article 30(6) onward notice to other Member States' controllers in the runbook.
- Roll back safely: when enabling new logging, run it in parallel with the old audit trail for one cycle so no gap appears if the new pipeline fails.
Measuring progress
- Article 25 coverage: percentage of LED systems logging all six operations.
- Justification completeness: share of consultation events with a valid case or reference number.
- Attribution rate: share of consultation and disclosure events tied to an individual, not a shared or service account.
- Self-monitoring cadence: log reviews completed versus planned, and findings closed.
- Breach timeliness: median hours from awareness to supervisory notification.
Common failure patterns
- Treating the LED as "GDPR for police": teams apply GDPR templates and miss Article 25 logging and the Article 6 data subject categories.
- Service accounts hide the user: integrations log only the calling system, so the "identity of the person" cannot be established.
- Logs deleted too early: retention routines remove the evidence a supervisory authority later needs.
- Using logs outside their purpose: logs reused for unrelated management purposes conflict with Article 25(2).
- Analytics outside the logged system: data combined in a separate analytics tool escapes combination logging.
Framework mapping
| LED duty | NIST CSF 2.0 | NIST SP 800-53 Rev 5 |
|---|---|---|
| Article 25 logging | PR.PS-04 | AU-2 |
| Protecting logs and integrity (Article 29(2)(j)) | PR.PS-04 | AU-9 |
| Data access control (Article 29(2)(e)) | PR.AA-05 | AC-6 |
| Self-monitoring of consultations | DE.CM-03 | AU-6 |
| Breach notification (Article 30) | RS.CO-02 | IR-6 |
Practitioner checklist
- Tag every system as LED, GDPR or mixed using the Article 1(1) purpose test.
- Confirm all six Article 25 operations are logged in every automated LED system.
- Require a justification field for consultations and disclosures.
- Eliminate shared accounts and propagate individual identity through integrations.
- Give each integration its own owned, scoped non-human identity.
- Map controls to the ten Article 29(2) objectives and record evidence for each.
- Set log retention and access rules that match the Article 25(2) purposes.
- Build Article 6 categories and Article 5 review dates into the data model.
- Update the breach runbook for the 72 hour clock and Article 30(6) onward notice.
- Confirm the DPO has access to operational information and logs.
Standards and references
- EUR-Lex: Directive (EU) 2016/680 (Law Enforcement Directive)
- EDPB: Contribution to the evaluation of the Law Enforcement Directive (January 2026)
- eucrim: Commission presented first evaluation report on the Law Enforcement Directive
- NIST: SP 800-53 Rev 5 Security and Privacy Controls
- NIST: Cybersecurity Framework 2.0
This guide summarises Directive (EU) 2016/680 and is not legal advice; national transposing laws add detail, so confirm against the law of your Member State. Related NHI Mgmt Group resources: GDPR Compliance Guide for Security Teams · Public Sector Identity Security Guide · Log Management and Retention Guide · DPIA Guide