Log masking and PII redaction
Mask PII in Windows logs before they reach your SIEM.
Find card numbers, email addresses, national identifiers and your own patterns on the machine that wrote the log, and rewrite them before anything is written to the disk cache or sent over the network.
- Card numbers
- Email, IP, phone
- UK NI and US SSN
- Custom patterns
- Redact, partial, token, hash
In short
DPLens does log masking and PII redaction on the Windows host: its mask stage finds card numbers, email and IP addresses, phone numbers, UK National Insurance and US Social Security numbers, or any pattern you write, and redacts, partially masks, tokenises or hashes them. Masking runs before anything is written to the disk cache or sent, so a rewritten value never reaches disk or the wire. That supports GDPR data minimisation and PCI DSS PAN protection without a separate redaction tier.
Why at the source
Why mask PII before it reaches the SIEM?
Once sensitive data is in the SIEM, it is everywhere: a card number or email address is copied into indexes, replicas, backups, cold storage, search results and exported reports, and deleting it later means finding every copy. Masking at the search head or in a central pipeline still moves the raw value across your network and stores it somewhere first.
DPLens is a UK-built, self-hosted log collection and security data pipeline agent for Windows. It runs its stages in a fixed order on the machine that produced the event: filter, parse, aggregate, optimise, enrich, mask, rate limit. Mask comes after enrichment, so values added by enrichment are covered too, and before the per-destination disk cache and delivery. In the documentation's words, no unmasked value can reach the cache or the wire.
The console follows the same rule. Live stream shows events as they leave, encoded exactly as the destination receives them, so masked values stay masked everywhere you look.
How it works
How does a masking rule work?
Each masking rule has three parts. Build it in the console and roll it out across your estate with DPLens Manager.
01
Detector
Built in: card numbers, email addresses, IPv4 and IPv6 addresses, US Social Security numbers, UK National Insurance numbers and phone numbers. For anything else, add your own pattern.
02
Fields
Search every text field on the event, only the fields you name, or the original record before parsing.
03
Action
Redact the value entirely, partially mask it to keep the last few characters, replace it with a marker you choose, or hash it so you can still correlate.
| Action | What you get | Good for |
|---|---|---|
| Redact | The value is replaced entirely | Data the SIEM never needs, such as email addresses in application logs |
| Partial | All but the last few characters are replaced | Card numbers: enough to recognise a card, not enough to use it |
| Token | A fixed marker you choose, such as "[aws-key]" | Secrets and credentials, where the fact of a match is the useful signal |
| Hash | The same input always gives the same output, without carrying the value itself | Identifiers you still need to correlate across events, such as a national identifier or a user |
Configuration
A worked example
One masking stage can apply a different treatment to each kind of sensitive value. The documented example does four things at once.
- Email addresses are redacted wherever they appear.
- Card numbers are truncated to their last four digits.
- UK National Insurance numbers are hashed, so analysts can still follow one person across events.
- AWS access key IDs in the message are replaced with the marker "[aws-key]".
The same rules apply to every event the stage sees, before anything is cached or sent, and every match is counted against the rule that made it.
Evidence
How do I show an auditor what was masked?
Counted per rule
Every masking decision is counted, attributed to the rule that caused it, and shown in the console. The stage ribbon shows events in and out of the mask stage, measured rather than estimated.
Policy changes in the audit log
Masking-policy changes are recorded in the tamper-evident audit log, with the time and the console account that made them, so you can show when each rule came into force.
Deliberate changes only
Removing a masking rule asks for an explicit confirmation, because it changes what leaves the machine.
Tamper-evident
The audit trail is append-only and tamper-evident, and can be shipped to your SIEM so the record survives the machine.
Compliance
How masking supports GDPR and PCI DSS v4.0.1
UK GDPR and EU GDPR
- Article 5(1)(c), data minimisation. Personal data should be limited to what is necessary for the purpose. Redacting or truncating values your security team does not need, before they are stored centrally, is a practical way to apply that to log data.
- Article 25, data protection by design and by default. Masking at the source is a default you configure once and roll out across the fleet with DPLens Manager.
- Article 32, security of processing. Pseudonymisation is one of the measures Article 32 names. A hash pseudonymises a value. Treat hashed values of low-entropy data – national identifiers, card numbers, phone numbers – as pseudonymised, and therefore still personal data.
PCI DSS v4.0.1
Requirement 3 covers protecting stored account data, including rendering the primary account number (PAN) unreadable wherever it is stored. A PAN that reaches your SIEM unmasked is stored account data, with all that implies for scope. Masking PANs on the host – truncated, replaced with a marker, redacted or hashed – helps keep full PANs out of your log pipeline, its caches and your SIEM.
DPLens supports these controls. Scope, method and sufficiency are decisions for your organisation, your DPO and your QSA. This is not legal advice. See DPLens and GDPR and DPLens and PCI DSS v4.0.1.
Testing
How do I test masking rules?
Use Send test event from a source's row menu: the test event travels the whole pipeline, including masking, to the destination you choose. Then watch Live stream with that destination selected to see the exact bytes your SIEM receives, including which fields your rules rewrote. Do this with samples of your real logs as well as synthetic ones.
Secure by design
An agent you can defend in a security review.
FAQ
Questions buyers ask
Which sensitive data can it find without custom patterns?
Card numbers, email addresses, IPv4 and IPv6 addresses, US Social Security numbers, UK National Insurance numbers and phone numbers. For anything else, add your own pattern.
Can I still correlate events after masking?
Yes, with the hash action. The same input always gives the same output, so you can count or join on a hashed user or identifier without carrying the value.
How should hashed values be treated under GDPR?
As pseudonymised data. A hash of low-entropy data such as a national identifier, card number or phone number should still be treated as personal data, and hashing supports the pseudonymisation measures Article 32 describes.
Will masking PANs take my SIEM out of PCI DSS scope?
It can help keep full PANs out of your log pipeline and SIEM, which is part of a scoping argument. Whether a system is in scope is for your organisation and your QSA to decide.
Is masking included in the licence?
Yes. The agent entitlement covers every processing stage, including mask.
Related
Keep going
GDPR
Minimisation, pseudonymisation and security of processing for log data.
Read more →PCI DSS v4.0.1
PAN protection, logging requirements 10.2–10.5 and change detection.
Read more →SIEM integrations
Deliver masked events to Splunk or any SIEM that accepts syslog or JSON.
Read more →DPLens vs Cribl Edge
Masking and reduction at the edge, compared.
Read more →SIEM cost reduction
Filter, aggregate and cap what leaves the host, in the same pipeline.
Read more →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.