PII in Security Logs: GDPR, NIS2 and DORA Playbook

A security analyst opens the SIEM at 02:17. The alert looks routine at first, multiple failed logins, a successful session from an unusual IP address, then a burst of API calls against a customer export endpoint. Within minutes, the incident channel is full. The CISO wants to know whether this is an account takeover. Legal asks whether the logs contain personal data. The DPO asks whether the user ID, IP address, device identifier and request URLs in the SIEM are covered by the privacy notice and records of processing. The compliance manager asks whether the logs must be preserved for regulatory reporting. Customer success asks whether a customer can request erasure of the same log entries tomorrow.

This is where many organizations discover that security logging and privacy governance were built as separate worlds.

Security teams want detailed logs, long retention, immutable storage and rapid access. Privacy teams want minimization, purpose limitation, role-based access, retention discipline and deletion when data is no longer needed. Incident responders want evidence preserved exactly as it was. GDPR accountability requires the organization to explain why personal data is there, who accessed it and how long it is kept. NIS2 and DORA add urgency, because essential entities, important entities and financial organizations need enough evidence to classify incidents, report them on time and prove effective ICT risk management.

The uncomfortable truth is simple: security logs are often personal data repositories. Authentication logs can contain usernames, email addresses, IP addresses, device fingerprints and geolocation. Application logs can expose URLs, search strings, payload fragments, case numbers and message content. EDR and cloud logs can include hostnames linked to employees, file paths with names, session identifiers and administrator actions. IAM logs can reveal privilege changes, group membership and failed access attempts to sensitive systems.

If logs contain PII, they are no longer only an ISO 27001 logging issue. They become a privacy, retention, evidence, incident reporting and supplier governance issue. Clarysec treats PII in security logs governance as a cross-compliance problem, not a tool configuration problem.

The CISO’s real dilemma: detection evidence versus privacy minimization

The CISO in the 02:17 scenario faces a genuine operational conflict. If logs are too thin, the SOC cannot detect compromise, reconstruct timelines or support NIS2 and DORA reporting. If logs are too rich, the organization may collect more personal data than necessary, retain it too long, expose it to too many administrators or fail to support GDPR rights and transparency obligations.

GDPR defines personal data broadly as information relating to an identified or identifiable person. Processing includes collection, storage, use, disclosure, erasure and destruction. In practice, logs containing IP addresses, user IDs, device identifiers or activity records may be personal data depending on context. GDPR principles require lawful, fair and transparent processing, purpose limitation, data minimization, storage limitation, integrity and confidentiality, plus accountability.

The governance question is not, “Can we ever log personal data?” The better question is, “What PII do we need to log for security, incident response and compliance, what lawful basis supports it, what safeguards apply, and when must it be deleted, anonymized or placed under approved hold?”

Clarysec’s enterprise privacy policy library addresses this tension directly. The Data Protection and Privacy Policy, Policy Implementation Requirements, clause 6.2.1 states:

Only data necessary for a specific, legitimate business purpose may be collected and processed.

For SMEs, the same principle is stated in the Data Protection and Privacy Policy-sme, Policy Implementation Requirements, clause 6.2.1:

Only the minimum personal data necessary must be collected and retained

That sentence should drive every logging design decision. Is each field in each log source necessary for a defined security, operational, legal or contractual purpose?

Why ISO 27701 changes the logging conversation

ISO/IEC 27001:2022 gives the management system: scope, interested parties, risk assessment, risk treatment, operational control, monitoring, internal audit and continual improvement. ISO/IEC 27002:2022 gives practical control guidance for logging, monitoring, privacy protection of PII, evidence collection, protection of records, deletion, access control and supplier management. ISO/IEC 27701 extends the governance model into privacy information management by focusing on PII controllers and processors, privacy roles, PII processing records, privacy-by-design, rights handling and processor obligations.

For security logs, ISO 27701 matters because it forces privacy-specific questions that security teams sometimes skip:

• Does the log source process PII as controller, processor, joint controller or subprocessor?
• Is the log data included in the inventory of processing activities?
• Does the organization know which log fields contain PII?
• Is PII in logs linked to retention and deletion rules?
• Are processor customers informed about PII access logging where contractually required?
• Are logs considered when responding to access, erasure or restriction requests?
• Are PII incidents assessed across privacy, cybersecurity and financial-sector reporting triggers?

Clarysec’s PII Security and Access Control Policy translates this into operating requirements. From Logging and monitoring, clause 4.6.1:

[Both] The System Owner / Application Owner MUST define the PII logging scope for authentication events, access events, privileged actions, PII export activity and material configuration changes in REG12 before production use or material change.

Clause 4.6.2 then closes the loop between logging, access control and retention:

[Both] The Information Security Lead MUST ensure that logs containing PII are access-restricted and linked to an approved retention or deletion rule in REG02 or REG12 before log monitoring begins.

This makes PIMS governance practical. REG12 defines what PII logging is allowed and required. REG02 identifies where PII exists, including logs. Retention and deletion rules are not paperwork added later. They become preconditions for production logging.

Security logs are records, evidence and PII processing activity

A mature organization should not treat logs as disposable technical exhaust. Logs are records. During an incident, they may become legal evidence. When they contain PII, they are also privacy-governed processing data.

Clarysec’s Logging and Monitoring Policy defines log normalization expectations. From Governance Requirements, clause 5.1.4:

Log format and normalization requirements (e.g., timestamp, user ID, event type, source IP)

Those are exactly the fields that make logs useful for incident response. They are also the fields that often make logs personal data. The same enterprise policy flags what should never happen, from Governance Requirements, clause 5.3.3:

Storage of sensitive data in plain text (e.g., passwords, cryptographic secrets)

The point is not that logs should avoid all identifiers. The point is that identifiers must be intentional, protected and justified. Passwords, secrets, full tokens and unnecessary payloads should not be logged. User IDs, IP addresses and event metadata may be necessary, but they require controls.

For SMEs, Clarysec’s Logging and Monitoring Policy-sme places privacy review into the role structure. From Roles and Responsibilities, clause 4.3.1, it requires the organization to:

Verifies that log data relating to personal or sensitive information is handled in accordance with GDPR and other data protection laws

The SME version also gives a clear baseline retention requirement. From Governance Requirements, clause 5.2.1:

Logs must be retained for at least 12 months unless a longer retention period is required by law or contract, or justified as part of an active incident or legal dispute.

And it sets the protection expectation, from Governance Requirements, clause 5.3.1:

Logs must be stored in write-protected locations, and access must be restricted to authorized personnel only

For enterprise incident response, the Evidence Collection and Forensics Policy, Policy Implementation Requirements, clause 6.3.1 requires:

Logs from firewalls, SIEM, endpoint agents, Identity and Access Management (IAM) platforms, and cloud platforms shall be exported and stored in immutable formats.

The SME version adds a proportionality guardrail. The Evidence Collection and Forensics Policy-sme, Risk Treatment and Exceptions, clause 7.2.1 states:

Minimize the scope of collection; only gather what is necessary.

That is the heart of privacy-aware logging: preserve what is necessary, prove why it is necessary, restrict who can see it, and delete it when the approved purpose expires.

The Clarysec control model for privacy-safe evidence

In Zenith Blueprint: An Auditor’s 30-Step Roadmap, Clarysec places logging in the Controls in Action phase, Step 19: Technological Controls I. The guide explains the ISO/IEC 27002:2022 control expectation:

A.8.15 – Logging: “Logs that record activities, exceptions, faults, and other relevant events should be produced, stored, protected, and analyzed.”

The same step tells organizations to generate logs for key events, store them securely so they cannot be altered, retain them for a defined period and analyze them through a SIEM or review process. It also connects logging to GDPR breach notification, DORA incident records, NIS2 risk management and COBIT security log analysis.

But logging alone is not enough. In the same Controls in Action phase, Step 19, Zenith Blueprint addresses deletion. It warns that data retained beyond operational value increases exposure and regulatory risk, and it explicitly calls out backups, snapshots and archives. This matters because a SIEM retention rule is meaningless if replicated log archives or cloud object storage buckets keep the same PII indefinitely.

In Step 23: Organizational controls, Zenith Blueprint covers collection of evidence. It states that incident evidence must be identified, collected and preserved in a manner that is legally admissible, reliable and aligned with investigative needs. It also emphasizes an operational reality: evidence is often lost in the first minutes of response when logs roll over, systems are rebooted or administrators change compromised accounts before snapshots are taken.

Step 23 also addresses privacy and protection of PII. The guide frames PII as a lifecycle issue requiring data awareness, classification, access control, masking, deletion, encryption and supplier obligations. For logs, that means the SIEM, EDR, cloud logging platform and ticketing system must be part of the PII inventory.

Cross-compliance mapping for PII in logs

Zenith Controls: The Cross-Compliance Guide maps ISO/IEC 27002:2022 control 8.15, Logging, to related controls that are essential for PII governance. These relationships show why logging is not only a SOC concern.

Zenith Controls also maps Logging to ISO/IEC 27002:2022 clause 8.15, ISO/IEC 27035-1 and ISO/IEC 27035-2 for incident management, ISO/IEC 27701 for logging of PII processing activities, ISO/IEC 27017 for cloud audit logs, ISO/IEC 27018 for cloud PII access logging, ISO/IEC 27005 for risks from insufficient logging, ISO/IEC 27033 for network activity logging and ISO/IEC 15408-2 for audit functionality in evaluated products.

For privacy specifically, Zenith Controls maps ISO/IEC 27002:2022 control 5.34, Privacy and protection of PII, to asset inventory, data masking, cloud services, classification, information transfer, access control, identity management and security review of projects and changes. For a log governance program, those ties become practical design requirements:

• Inventory log stores as PII locations.
• Mask or tokenize PII where full identifiers are unnecessary.
• Review cloud logging services and SIEM vendors under cloud and supplier controls.
• Classify logs containing PII as sensitive records.
• Govern log exports and transfers as PII transfers.
• Restrict log access through identity and privileged access controls.
• Review changes to application logging before production release.

GDPR, NIS2 and DORA: one log, three regulatory lenses

The same log entry may be viewed differently under GDPR, NIS2 and DORA.

Under GDPR, the organization asks whether the log entry contains personal data, what lawful basis supports the processing, whether the data is necessary, how long it is retained, who can access it, whether it is disclosed to processors or customers, and whether it must be considered in a rights request or breach assessment.

Under NIS2, the organization asks whether logs support cybersecurity risk management, incident handling, business continuity, access control, supply-chain security and assessment of control effectiveness. NIS2 Article 20 makes management bodies accountable for approving and overseeing cybersecurity risk-management measures. Article 21 requires appropriate and proportionate technical, operational and organizational measures, including incident handling, business continuity, supply-chain security, secure development, vulnerability handling, effectiveness assessment, cyber hygiene, access control and asset management. Article 23 creates staged reporting for significant incidents, including early warning within 24 hours, notification within 72 hours and a final report within one month.

Under DORA, financial entities must operate a documented ICT risk management framework. DORA Article 5 assigns responsibility to the management body. Article 10 addresses detection. Article 17 requires an ICT-related incident management process. Article 18 covers classification of ICT-related incidents and cyber threats. Article 19 addresses reporting of major ICT-related incidents. Logs support detection, classification, root cause analysis, impact assessment, response, recovery and evidence of remediation.

A more detailed control crosswalk helps the CISO justify logging without relying on vague statements such as “we need it for security.”

Build a PII logging scope in REG12

A Clarysec client would handle the 02:17 SIEM incident before it ever happens. The organization starts with a customer-facing application that processes account data. Before production, the application owner uses REG12 to define the PII logging scope. The goal is to capture enough events for security and regulatory evidence without logging unnecessary personal data or payload content.

Next, the privacy lead confirms whether the organization is acting as controller, processor or both for each log source. If the organization is a processor, customer contractual instructions and subprocessor disclosures may constrain log access and sharing. If it is a controller, privacy notices, lawful basis and rights handling must be addressed.

The data owner then updates REG02 to include live log stores, SIEM indices, archives, backups and temporary forensic exports. This aligns with the PII Retention, Deletion and Disposal Policy, Backups, archives, replicas, logs and temporary files, clause 4.4.1:

[Both] The System Owner / Application Owner MUST identify live stores, archives, backup copies, replicas, logs, staging areas and temporary files containing PII in REG02 before production go-live and during each annual retention review.

The Data Retention and Disposal Policy should then align business retention rules with legal, contractual and evidence preservation requirements.

Finally, the security team configures the SIEM so that passwords, secrets and payload bodies are dropped or redacted before ingestion. Logs containing PII are assigned restricted indexes. Retention is automatically enforced unless an incident or legal hold is approved. Deletion actions are logged. Forensic exports require approval and chain-of-custody tracking. Dashboards show pseudonymized identifiers where full identity is not needed. Historical log retrieval is tested during internal audits.

This is the difference between saying “we log for security” and proving “we log only what is necessary, protect it, retain it under approved rules and can use it as evidence without violating privacy obligations.”

DSARs, erasure and logs: decide before the request arrives

One of the most difficult questions is whether logs must be searched, disclosed or deleted in response to data subject access or erasure requests. The answer depends on role, purpose, legal basis, feasibility, exemptions and retention obligations. But the governance process cannot be invented request by request.

The PII Principal Rights Management Policy, Identity Verification, Scope and Evaluation, clause 4.2.3 states:

[Controller] The Process Owner / Business Owner MUST identify relevant systems, records, purposes, PII categories, recipients and retention constraints from REG02 before evaluating fulfilment.

That means logs need to be in REG02 with clear metadata: what PII categories they contain, what purpose they serve, what retention constraint applies and whether a request can be fulfilled through direct disclosure, summarized access, restriction, deletion at expiry or refusal based on a documented legal ground.

Clarysec recommends a three-tier approach:

1. Operational logs with low privacy impact, such as system event logs using pseudonymous user IDs, may be searchable and disclosable where appropriate.
2. Security logs with high security sensitivity, such as SIEM correlation data or threat intelligence context, may require filtering, summary disclosure or restriction to avoid exposing detection logic or third-party data.
3. Forensic evidence under active incident or legal hold should not be altered casually. Erasure may be deferred or restricted where legally justified, with the decision documented by privacy and legal stakeholders.

If the DPO and SOC debate every DSAR from scratch, the organization will be inconsistent and slow. If REG02 and REG12 are maintained, rights handling becomes evidence-based.

Breach and incident reporting: one event, multiple clocks

The 02:17 alert may trigger several clocks. GDPR personal data breach assessment may require notification to a supervisory authority where risk thresholds are met. NIS2 significant incident reporting may require a 24-hour early warning, 72-hour notification and final report. DORA may require major ICT-related incident reporting through initial, intermediate and final stages. Customer contracts may have even shorter notice windows.

Clarysec’s PII Incident and Breach Management Policy directly addresses this cross-trigger problem. From Classification and breach assessment, clause 4.2.6:

[Conditional] The Privacy Lead / PIMS Manager MUST evaluate applicable legal, sectoral, financial-sector, cybersecurity, contractual, customer, and service-recipient reporting triggers for each high-impact PII incident and record the applicability outcome in REG01, REG08, and REG10.

During triage, the organization should ask:

• Did the attacker access personal data, or only metadata?
• Did the logs expose additional PII to unauthorized users?
• Are logs needed to determine affected persons, systems and timeframe?
• Are logs stored immutably and access-restricted?
• Has an incident hold paused deletion for relevant logs?
• Are processor customers, financial-sector customers or service recipients affected?
• Which reporting clocks apply, and who owns each notification?

Well-governed logs speed reporting because they give decision-makers reliable facts. Poor logging causes delay. Over-logging creates privacy risk. The right answer is targeted, protected and mapped logging.

Supplier and cloud logging: the processor problem hiding in your SIEM

Most organizations do not store all logs on infrastructure they fully control. Logs flow to SIEM platforms, EDR portals, cloud-native logging services, observability tools, ticketing systems and managed detection and response providers. Under GDPR, these providers may be processors or subprocessors. Under NIS2 and DORA, they may also be direct suppliers, ICT third-party service providers, managed service providers or managed security service providers.

NIS2 Article 21 explicitly includes supply-chain security, supplier vulnerabilities and overall supplier cybersecurity practices. DORA adds detailed ICT third-party risk requirements for financial entities, including pre-contract due diligence, information registers, audit and access rights, incident assistance, data location, data protection clauses, exit strategies and contract provisions for critical or important functions.

For PII in security logs, supplier reviews should include these questions:

A SIEM contract is not only a software subscription. It is a PII processing and incident evidence dependency.

Audit lens: how assessors test PII in security logs

A good auditor will not accept a statement that “logs are protected.” They will test the chain from policy to configuration to evidence to review.

A practical audit test is simple but revealing: ask the SOC to retrieve a log entry from ten months ago showing a privileged access change in a cloud platform, prove who accessed that log, prove it was not altered, show the retention rule that allowed it to exist, show the PII fields it contains, and show how it would be handled in a DSAR or incident report. If the team cannot answer across security, privacy and compliance, governance is incomplete.

Common findings in PII log audits

Clarysec often sees the same patterns:

• Application teams log full request payloads for debugging, including names, emails, account numbers or message content.
• SIEM indexes are open to broad IT administrator groups instead of restricted SOC roles.
• Log retention is set globally without regard to PII sensitivity, customer contracts or incident hold rules.
• Cloud provider logs are enabled, but provider administrator access to customer log data is not reviewed.
• DSAR procedures do not mention logs, SIEM cases or forensic exports.
• Incident response playbooks preserve evidence, but privacy teams are not involved in classification.
• Backups and archives retain log PII longer than the SIEM.
• Developers can change logging levels in production without privacy or security review.
• Test environments receive production logs with personal data.
• The organization has NIS2 or DORA reporting obligations but cannot retrieve reliable evidence quickly.

These findings rarely come from bad intent. They come from siloed ownership. Security logs sit between SOC, platform engineering, privacy, legal, compliance, audit and vendors. If no one owns the whole lifecycle, gaps appear.

A Clarysec checklist for audit-ready log governance

Use this checklist as a working starting point for your next governance review:

1. Define which log sources may contain PII: IAM, application, API gateway, SIEM, EDR, cloud, database, network, physical access and ticketing.
2. Record each log store in REG02, including live stores, archives, backups, replicas and temporary forensic exports.
3. Define the PII logging scope in REG12 before production use or material changes.
4. Identify purpose and lawful basis for security log processing.
5. Ban passwords, secrets, full tokens and unnecessary payloads from logs.
6. Use masking, hashing or pseudonymization where full identifiers are not required.
7. Restrict access to logs containing PII by role, with privileged access review.
8. Store high-value logs in immutable or write-protected formats.
9. Define retention by log type, legal obligation, contract, incident need and privacy risk.
10. Implement incident holds with approval, scope and expiry.
11. Include logs in DSAR and erasure evaluation logic.
12. Review SIEM, EDR, cloud and MDR suppliers as processors or ICT third parties.
13. Test historical retrieval and evidence integrity.
14. Map logging to GDPR, ISO 27701, NIS2, DORA, NIST CSF and COBIT reporting needs.
15. Train SOC, privacy and application teams on what may and may not be logged.

This checklist turns privacy-aware logging into a repeatable control process.

From dilemma to board-level trust

NIS2 makes cybersecurity a management responsibility. DORA makes the management body responsible for ICT risk management, digital operational resilience strategy, data confidentiality, incident communication and third-party ICT service policies. ISO/IEC 27001:2022 requires top management to align the ISMS with business objectives, assign responsibilities, provide resources and drive continual improvement.

PII in security logs is therefore not a narrow technical detail. It is a board-level trust issue. The organization’s ability to detect incidents, protect personal data, preserve evidence, respond to customers, satisfy regulators and recover operations depends on logging decisions made long before the incident.

The best governance programs do not choose between privacy and security. They define the minimum logging needed for robust security, protect that logging as sensitive PII where required, and connect it to retention, evidence, rights handling and supplier obligations.

Next steps with Clarysec

If your SIEM, IAM, EDR or cloud logs contain personal data, now is the time to govern them deliberately.

Clarysec can help you:

• Build a PII logging scope using REG12 and align it with PII Security and Access Control Policy.
• Inventory log stores, archives, backups and forensic exports using REG02 and PII Retention, Deletion and Disposal Policy.
• Align logging, monitoring, evidence and privacy controls with Zenith Blueprint.
• Map your controls across GDPR, ISO 27701, NIS2, DORA, NIST CSF and COBIT using Zenith Controls.
• Prepare audit-ready evidence for ISO, privacy, NIST, COBIT, NIS2 and DORA assurance reviews.

Start with one high-risk system: your IAM platform, SIEM or customer-facing application. Identify what PII enters the logs, why it is needed, who can access it, how long it is retained and how it would be used during an incident or rights request. That single exercise will reveal whether your current logging program is merely operational, or genuinely audit-ready.