UK GDPR and EU GDPR
Log minimisation for GDPR: mask personal data on the Windows host, before it reaches your SIEM.
Security logs are full of personal data: user names, email addresses, IP addresses, phone numbers. DPLens filters what you do not need and masks or pseudonymises what you keep, on the machine that produced it.
- Art. 5(1)(c) minimisation
- Art. 25 by design
- Art. 32 pseudonymisation
- No telemetry
In short
DPLens supports UK GDPR data minimisation in security logging by dropping events you have no purpose for and masking personal data in the events you keep, before anything is written to its disk cache or sent. Keyed hashing lets analysts still correlate activity by user or address without the SIEM holding the raw value. The software sends no event data to DPLens Ltd. Your lawful basis, retention and records of processing remain yours to decide and document.
This page describes how DPLens features relate to UK GDPR principles. It is not legal advice. Your data protection officer or counsel decides what is necessary for your purposes and whether your measures are appropriate. DPLens Ltd holds no certification, and using DPLens does not make your processing lawful or compliant.
The law
What UK GDPR asks for
A paraphrase of the provisions most relevant to security logging.
Art. 5(1)(c)
Data minimisation
Personal data should be adequate, relevant and limited to what is necessary for the purpose. Collecting every field of every event "just in case" is hard to square with that.
Art. 5(1)(f)
Integrity and confidentiality
Personal data is processed with appropriate security, including protection against unauthorised processing, loss and damage.
Art. 25
Data protection by design and by default
Build data protection into processing from the start, with measures such as pseudonymisation, and by default process only the personal data each purpose needs.
Art. 32
Security of processing
Appropriate technical and organisational measures, which the article says may include pseudonymisation and encryption of personal data.
Recital 49 recognises processing that is strictly necessary and proportionate for network and information security as a legitimate interest. Security logging can therefore have a sound basis; the harder question is how much personal data it carries, and where it ends up. Pseudonymised data is still personal data, so masking reduces risk rather than taking logs outside the regulation.
Control map
UK GDPR mapping
| Requirement | How DPLens supports it | What you do |
|---|---|---|
| Art. 5(1)(c) Data minimisation | Filter at the source by channel and event ID, and in the pipeline by any field, so events with no security purpose are never sent. Aggregation collapses repeats into one event with a count. | Define the purpose of each log source and decide what is necessary for it |
| Art. 25 By design and by default | Masking runs before anything is written to the disk cache or sent, so a value a rule rewrites reaches neither. Removing a masking rule needs a deliberate confirmation. | Decide which fields to mask, and review the rules as sources change |
| Art. 32 Pseudonymisation | Keyed hashing replaces a value so the same input always gives the same output for correlation, with the key held as a protected secret on the machine | Manage the key: who can hold it and how re-identification is controlled |
| Art. 32 Encryption in transit | TLS with certificate validation on by default; mutual TLS where the receiver requires it | Choose TLS for every destination that supports it, and always across untrusted networks |
| Art. 5(1)(f) Integrity and confidentiality | Agent cache, state and secrets protected on the host; the console is reachable from the machine itself by default | Control administrative access to the host and to the SIEM |
| Art. 5(2) Accountability | Every mask and drop is counted per rule; masking policy changes are written to the tamper-evident audit trail with the account and time | Keep this evidence with your records of processing and DPIA |
| Art. 5(1)(e) Storage limitation | DPLens holds events only until they are delivered | Set retention periods in your SIEM and archive |
In practice
Choosing what to mask
A mask rule is a detector, the fields to search and an action. The built-in detectors find email addresses, IPv4 and IPv6 addresses, phone numbers, UK National Insurance numbers, US social security numbers and card numbers; a pattern rule covers anything else, such as customer reference numbers in an application log. Rules can search every text field, named fields only, or the raw record before parsing.
Masking everything is rarely the right answer for security logs: an analyst still needs to know that the same account failed to log on from the same address forty times. Use keyed hashing where correlation matters and redaction where it does not. The DPLens docs advise treating hashed low-entropy values, such as national identifiers and phone numbers, as pseudonymised rather than anonymised, because they can be guessed and re-hashed.
The console's live stream shows events in their masked form, because that is what leaves the machine. Use it, and the per-rule counts, to check a rule does what you intended before you rely on it. The log masking and PII redaction page walks through the detectors, and SIEM cost reduction covers filtering for volume as well as minimisation.
How to do it
In the documentation
FAQ
Questions DPOs and security teams ask
Is a hashed user name still personal data?
Yes, if it can be linked back to a person by anyone holding the key or by guessing likely inputs. That is pseudonymisation, which reduces risk and is named as a measure in Articles 25 and 32, but the data stays within the regulation.
Does DPLens Ltd receive any of our log data?
No. The agent has no telemetry, no licensing service and no cloud control plane. Events go only to the destinations you configure; the Trust Centre sets out exactly what the agent connects to. How that affects your processor and controller analysis is a question for your DPO.
Our SIEM is hosted outside the UK. Does masking help?
Masking and filtering on the host reduce how much personal data reaches it, wherever it is hosted, alongside the transfer safeguards your counsel advises for that service.
How do we keep detections working with masking on?
Use keyed hashing for the user names and addresses you correlate on, so the same value always masks to the same output, and check rules against the live stream before applying them.
See it on your own logs
Try DPLens on one Windows server before you talk to anyone.
Book a demo, or request an evaluation licence and install it on a test host. The documentation covers everything from requirements to Group Policy rollout.