ISO 27001 Logging Evidence for NIS2, DORA and GDPR

The alert landed in the SOC channel at 2:17 AM on a Tuesday: multiple failed login attempts for the privileged user admin from a new IP address. The attempts stopped after a few minutes. A junior analyst noted the alert, assumed it was a misconfigured script or a sysadmin working late, and moved on.

Two days later, Maria, the CISO of a fast-growing FinTech company, was in a management meeting when her phone buzzed. Engineering had found unusually high CPU usage on a production database instance. A new unauthorized user account had been created. The 2:17 AM alert was not a false positive. It was the first visible sign of an intrusion attempt.

The incident was contained, but the investigation exposed a bigger problem. Firewall logs were in one system. Kubernetes logs were in another. Database audit logs were stored separately. Several timestamps were out of sync by minutes. The team had data, but could not quickly tell a defensible story about detection, review, escalation, containment and breach assessment.

Maria’s ISO/IEC 27001:2022 surveillance audit had ended successfully, but the auditor left one warning: the organization had logging and monitoring controls, yet would struggle to produce timely, correlated evidence for NIS2, DORA and GDPR reporting decisions.

That is the reality many organizations face in 2026. They do not have a logging problem. They have an evidence problem.

A SIEM, EDR platform, cloud audit trail or firewall log is not audit-ready evidence by itself. Evidence becomes defensible only when it is governed by policy, protected against tampering, reviewed on a defined cadence, linked to incident decisions and retained long enough to reconstruct events.

For ISO/IEC 27001:2022, NIS2, DORA and GDPR, the key question is no longer, “Do we collect logs?” The question is, “Can we prove what happened, who reviewed it, how it was classified, whether reporting was required and whether leadership had oversight?”

Why logging and monitoring became a compliance evidence issue

NIS2, DORA and GDPR have changed the business meaning of security logs.

Under NIS2, essential and important entities must implement appropriate and proportionate cybersecurity risk-management measures. Article 21 includes incident handling, business continuity, supply-chain security, secure development, effectiveness assessment, cyber hygiene, cryptography, human resources security, access control, asset management, MFA and secure communications. Article 23 creates a staged reporting model, including an early warning within 24 hours, incident notification within 72 hours, intermediate updates where relevant and a final report not later than one month after the incident notification.

That model depends on logging and monitoring. You cannot send a credible early warning if you cannot show when the event was detected. You cannot classify a significant incident if you cannot reconstruct affected systems, user activity, service impact and containment actions.

DORA applies similar pressure to financial entities. Articles 5 to 14 establish governance and ICT risk-management expectations, including management-body responsibility, ICT asset identification, protection and prevention, detection, response and recovery, backup, restoration, learning and communication. Articles 17 to 23 require an ICT-related incident management process covering detection, recording, classification, escalation, notification and follow-up. Articles 24 to 27 address digital operational resilience testing. Articles 28 to 31 create ICT third-party risk management obligations.

GDPR adds the privacy accountability layer. Article 32 requires appropriate security of processing. Article 33 requires personal data breach notification to the supervisory authority without undue delay and, where feasible, not later than 72 hours after becoming aware of it, unless the breach is unlikely to result in a risk to individuals. Article 34 may require communication to affected data subjects when the risk is high. Logs help determine whether personal data was accessed, altered, exfiltrated or exposed, but logs can also contain personal data and must be governed accordingly.

ISO/IEC 27001:2022 provides the management-system backbone. Clauses 4.1 to 4.4 require the organization to understand context, interested parties, requirements and ISMS scope. Clauses 5.1 to 5.3 require leadership, policy alignment, roles, responsibilities and authority. Clauses 6.1.1 to 6.1.3 require a repeatable risk assessment and treatment process, including risk criteria, risk owners, treatment options, Annex A control comparison, the Statement of Applicability and residual risk acceptance. Clause 6.2 requires measurable information security objectives.

This is why logging and monitoring evidence cannot live only inside the SOC. It belongs in the ISMS, the risk register, the Statement of Applicability, the incident response process, the privacy breach workflow, supplier governance and management reporting.

The ISO 27001 logging controls auditors connect first

In Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, the Controls in Action phase, Step 19: Technological Controls I, treats logging, monitoring and clock synchronization as one evidence chain.

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

A.8.16 – Monitoring activities: “Networks, systems, and applications should be monitored for
anomalous behavior and appropriate actions taken to evaluate potential information security
incidents”

A.8.17 – Clock synchronization: “The clocks of information processing systems used by the
organization should be synchronized to approved time sources.”

These controls answer three audit questions:

Zenith Controls: The Cross-Compliance Guide Zenith Controls makes the relationship explicit:

“Logging serves as the foundational data layer for monitoring. Control 8.16 depends on the logs generated under 8.15 to analyze security events, detect anomalies, and identify potential breaches. Without comprehensive logging, monitoring systems are ineffective.”

Zenith Controls classifies ISO/IEC 27002:2022 control 8.15, Logging, as a detective control supporting confidentiality, integrity and availability. It maps to the Detect cybersecurity concept and information security event management. It also connects Logging to Monitoring activities, Assessment and decision on information security events, and Clock synchronization.

For control 8.16, Monitoring activities, Zenith Controls classifies it as detective and corrective, mapped to Detect and Respond. It connects monitoring to supplier service monitoring and event assessment, which is essential for cloud, SaaS, managed service and outsourcing environments.

The practical message is simple. Logs provide the facts. Monitoring identifies anomalies. Clock synchronization makes the facts reliable across systems. Event assessment turns alerts into decisions.

What audit-ready logging evidence actually looks like

Audit-ready evidence is not a screenshot folder. It is a coherent trail that proves control design, control operation and decision-making.

A mature logging and monitoring evidence file usually contains the following:

Clarysec’s Enterprise Logging and Monitoring Policy Logging and Monitoring Policy frames this directly:

“This policy is essential to support ISO/IEC 27001 Clause 8.1 and Annex A Controls 8.15 (Logging), 8.16 (Monitoring), and 8.17 (Clock Synchronization), and is directly mapped to regulatory obligations under GDPR, NIS2, DORA, and COBIT 2019.”

From section “Purpose”, policy clause 1.3.

The same policy sets the operational expectation:

“Establish centralized logging and alerting systems (e.g., SIEM) to aggregate, correlate, and escalate suspicious activity in near real time.”

From section “Objectives”, policy clause 3.4.

For smaller organizations, Clarysec’s SME Logging and Monitoring Policy-sme Logging and Monitoring Policy - SME translates the same principle into proportional requirements:

“The IT Support Provider must define and follow a regular schedule for log review:”

From section “Governance Requirements”, policy clause 5.1.1.

It also defines retention and protection:

“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.”

From section “Governance Requirements”, policy clause 5.2.1.

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

From section “Governance Requirements”, policy clause 5.3.1.

For NIS2 and DORA, a 12-month evidence baseline can be the difference between credible reconstruction and failed investigation. For GDPR, it supports accountability while still requiring minimisation, access control and retention discipline.

The missing bridge: event assessment and reporting thresholds

Many organizations collect logs and alert on anomalies, but fail at the decision point.

Was the alert only a security event, or did it become an information security incident? Was it significant under NIS2? Was it a major ICT-related incident under DORA? Was personal data involved? Is GDPR breach notification analysis required?

That decision point maps to ISO/IEC 27002:2022 control 5.25, Assessment and decision on information security events. Zenith Controls describes 5.25 as the triage function between raw monitoring alerts and formal incident handling. It connects 5.25 to incident management planning, monitoring activities, response to information security incidents and logging. It also maps 5.25 to GDPR Articles 33 and 34 for breach notification and risk evaluation, NIS2 incident notification and classification criteria, and DORA major ICT-related incident classification.

Clarysec’s Incident Response Policy Incident Response Policy supports that escalation point:

“If an incident results in confirmed or likely exposure of personal data or other regulated data, Legal and the DPO must assess the applicability of:”

From section “Policy Implementation Requirements”, policy clause 6.4.1.

For SMEs, the Incident Response Policy-sme Incident Response Policy - SME sets the technical evidence requirement:

“Logging systems must be configured to capture sufficient detail to support investigation.”

From section “Policy Implementation Requirements”, policy clause 6.4.1.

This is where GDPR Article 33 becomes operational. The question is not only whether personal data was accessed. The question is whether logs, monitoring alerts and incident records allow the DPO to make a timely, defensible breach assessment.

NIS2 Article 23 and DORA Articles 17 to 23 create similar pressure. Reporting timelines depend on awareness, classification and materiality assessment. The organization must be able to prove when the alert was generated, when it was reviewed, who assessed it, what decision was made and when escalation occurred.

A 60-minute evidence drill for a privileged login investigation

A useful way to test evidence readiness is to rehearse a real scenario before the audit or incident.

Scenario: a privileged administrator account logs in from an unusual country at 02:13 UTC. Five minutes later, the account attempts to access a customer data export function. Conditional access blocks the session and an alert is generated.

Goal: in 60 minutes, produce an evidence pack proving detection, review, escalation, assessment and closure.

Step 1: Confirm the event exists in logs

Use the Logging and Monitoring Policy to identify required log sources: identity provider logs, cloud admin logs, application logs, database logs, endpoint logs and firewall or secure access logs.

Export the event record with timestamp, user ID, source IP, device, action, result and correlation ID. If the event exists only in one console and not in the SIEM or log collector, record that as a control gap.

Zenith Blueprint Step 19 recommends ensuring critical systems forward logs to the SIEM or central log collector and validating that retention aligns with policy.

Step 2: Prove monitoring detected it

Show the SIEM alert, EDR alert or identity protection alert. Include the rule name, severity, timestamp, triggered condition and notification route. If the organization uses manual review, show the daily report and reviewer sign-off.

The Enterprise Logging and Monitoring Policy makes this a role responsibility:

“Reviews daily reports and ensures anomalies are analyzed, documented, and escalated as needed.”

From section “Roles and Responsibilities”, policy clause 4.2.3.

Step 3: Prove escalation occurred within policy

For SMEs, the escalation requirement is explicit:

“High-priority alerts must be escalated to the GM and Privacy Coordinator within 24 hours”

From section “Enforcement and Compliance”, policy clause 8.1.2.

For enterprise teams, evidence can include an incident ticket, Teams or Slack escalation record, paging log, email notification, SOC handover note or case management entry.

Step 4: Classify the event

Use the 5.25 event assessment logic from Zenith Controls. Capture whether the alert is a security event, information security incident, personal data breach, significant NIS2 incident or DORA major ICT-related incident.

The classification note should answer:

• Was authentication successful or blocked?
• Was privileged access used?
• Was customer data accessed, altered or exfiltrated?
• Were regulated services disrupted?
• Were critical ICT assets affected?
• Are suppliers or processors involved?
• Does the event meet internal reporting thresholds?
• Is DPO, Legal, regulator or customer notification required?

Step 5: Build a trusted timeline

Clock synchronization is often ignored until an investigation fails. Zenith Blueprint Step 19 states that synchronized time is vital for event correlation because logs from different systems must line up during incident analysis.

Include NTP configuration evidence for identity platforms, cloud services, servers, endpoints, databases, firewalls and the SIEM. Normalize timestamps to UTC where possible.

Step 6: Close or escalate

If the event is contained and no data was accessed, document closure, lessons learned and preventive action. If it becomes an incident, link it to incident response, legal review and any NIS2, DORA or GDPR reporting workflow.

Finally, protect the evidence. Clarysec’s Audit and Compliance Monitoring Policy Audit and Compliance Monitoring Policy states:

“All audit logs, findings, and remediation reports shall be retained, encrypted, and protected against tampering.”

From section “Enforcement and Compliance”, policy clause 8.5.1.

This single drill gives evidence for Annex A.8.15, A.8.16, A.8.17, ISO/IEC 27002:2022 control 5.25, GDPR breach accountability, NIS2 incident handling and DORA ICT incident classification.

Cross-compliance evidence map for ISO 27001, NIS2, DORA and GDPR

The strongest compliance programs do not build separate evidence sets for each framework. They build one evidence system that can be viewed through multiple audit lenses.

NIST Cybersecurity Framework 2.0 can help operationalize this as a communication layer. Its six Functions, GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND and RECOVER, show that logging and monitoring sit mainly in DETECT and RESPOND, but depend on governance, asset understanding and risk priorities.

NIST CSF 2.0 Profiles can also support a 2026 roadmap. A Current Profile can show today’s logging coverage and alert maturity. A Target Profile can define required coverage for regulated systems, privileged activity, supplier platforms and personal data environments. The gap between them becomes the remediation plan.

Supplier and cloud logs: the evidence gap auditors increasingly test

In modern audits, the hardest logging questions often involve outsourced platforms.

Can you access authentication logs from your cloud provider? Are SaaS admin actions logged? Are database audit logs enabled in managed services? Does your MSSP retain alerts long enough? Do contracts require incident cooperation? Can suppliers provide logs fast enough for NIS2 or DORA reporting timelines? Are processor logs available for GDPR breach assessment?

Zenith Controls connects Monitoring activities, control 8.16, to Monitoring of supplier services, control 5.22. It also maps monitoring to ISO/IEC 27005:2024 clause 10.5, which emphasizes monitoring and review of risk treatment plans and controls, and ISO/IEC 27035-2:2023 clause 7.3, where continuous monitoring mechanisms detect information security events and trigger incident management.

DORA makes supplier logging especially important for financial entities because ICT third-party risk management includes supplier registers, contractual arrangements, subcontracting risk, concentration risk and exit strategies. NIS2 Article 21 places supply-chain security within cybersecurity risk-management measures. GDPR can make supplier logs decisive when a processor incident may become a controller-notifiable personal data breach.

A practical supplier logging clause should require:

• Security-relevant audit logs for authentication, privilege changes, administrative actions, API access, data export and configuration changes.
• Log retention aligned to policy, regulatory duties and contract risk.
• Time synchronization and timezone normalization.
• Tamper protection and restricted access to logs.
• Incident cooperation within defined timeframes.
• Evidence delivery for audits, investigations and regulatory inquiries.
• Notification triggers for suspicious access, service compromise or data exposure.
• Subprocessor logging and escalation obligations where relevant.

Supplier logging should be handled before an incident, not negotiated during one.

How different auditors test the same logging control

A good evidence pack must survive different professional lenses. An ISO auditor, NIS2 reviewer, DORA supervisor, GDPR reviewer and COBIT 2019 or ISACA-oriented auditor may look at the same SIEM dashboard, but they will ask different questions.

Zenith Blueprint Step 19 prepares organizations for these questions. For Logging, auditors focus on whether key security events are logged and whether logs are retained, protected and useful. For Monitoring activities, they ask how unusual or unauthorized activity is detected, evaluated and escalated. For Clock synchronization, they may compare timestamps across systems and flag misalignment.

Step 16: People Controls II, control 6.8, also matters because incident reporting mechanisms connect human reporting to technical detection. GDPR Article 33, NIS2 Article 23 and DORA incident reporting obligations all depend on timely internal escalation.

Common audit findings and practical fixes

Most logging and monitoring findings are predictable. The issue is that organizations often discover them during the audit rather than during internal testing.

For organizations with limited resources, the SME policy approach is realistic. It does not require a full SOC on day one. It requires defined review schedules, 12-month retention unless longer is needed, write-protected storage, restricted access and escalation of high-priority alerts. That creates a defensible baseline while the organization matures toward centralized SIEM, automated correlation and managed detection.

Metrics that make logging credible to leadership

Boards and executives do not need raw SIEM events. They need risk-relevant assurance. Because NIS2 Article 20 and DORA governance requirements place responsibility on management bodies, logging and monitoring metrics should appear in security governance reporting.

Useful metrics include:

• Percentage of critical assets forwarding logs to the SIEM or log collector.
• Percentage of privileged access events covered by alerting.
• Number of high-priority alerts reviewed within SLA.
• Mean time from alert generation to analyst review.
• Mean time from detection to escalation.
• Number of events classified under the incident response process.
• Number of events requiring DPO or Legal review.
• Log retention compliance by system category.
• Number of supplier platforms with contractual log access.
• Number of systems failing clock synchronization checks.
• Open logging and monitoring remediation actions by risk level.

These metrics support ISO/IEC 27001:2022 clause 6.2 for measurable information security objectives. They also strengthen NIS2 and DORA leadership oversight and GDPR accountability.

Building your 2026 logging and monitoring evidence pack

A strong 2026 evidence pack should be assembled before the audit or incident. Clarysec typically recommends a structured folder or GRC evidence object with these sections:

1. Governance and scope: ISMS scope, interested parties, regulatory applicability, management approval and role assignments.
2. Policy: Logging and Monitoring Policy, Incident Response Policy, Audit and Compliance Monitoring Policy, retention requirements and escalation requirements.
3. Risk and SoA: Risk assessment, treatment plan, Statement of Applicability rationale for A.8.15, A.8.16, A.8.17 and related controls.
4. Architecture: SIEM or log collector diagram, log source inventory, cloud logging settings and supplier log dependencies.
5. Control operation: Review records, alerts, tickets, escalation logs, closure evidence and exceptions.
6. Incident linkage: Event classification worksheet, incident register, DPO assessment record and reporting decision log.
7. Integrity and retention: Access controls, encryption, write protection, archive settings, deletion controls and retention proof.
8. Time synchronization: NTP configuration, secure baseline, monitoring of clock drift and UTC normalization approach.
9. Supplier evidence: Contract clauses, supplier assurance reports, cloud audit log availability and incident cooperation procedures.
10. Improvement: Internal audit findings, remediation tracker, tabletop exercise results, alert tuning records and management reports.

The purpose is not to overwhelm auditors with volume. The purpose is to prove that logging and monitoring operate as a controlled process from governance to detection, assessment, escalation, reporting and improvement.

Turn logs into defensible compliance evidence

Maria’s team did not solve its problem by buying another dashboard. It solved the problem by turning logging and monitoring into an evidence engine. Policies defined the requirements. SIEM rules and cloud logs provided signals. Incident workflows captured decisions. Clock synchronization made the timeline credible. Management reporting made the risk visible.

That is the standard organizations need for ISO/IEC 27001:2022, NIS2, DORA and GDPR in 2026.

Start with one practical test: take a real alert from the last 30 days and prove, end to end, how it was logged, detected, reviewed, escalated, classified, retained and reported.

If the answer is not confident, Clarysec can help you close the gap.

Use Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint to implement Step 19 for logging, monitoring and clock synchronization, and Step 16 for incident reporting mechanisms. Use Zenith Controls: The Cross-Compliance Guide Zenith Controls to map Annex A.8.15, A.8.16, A.8.17 and ISO/IEC 27002:2022 control 5.25 across NIS2, DORA, GDPR, NIST CSF 2.0 and COBIT 2019 perspectives.

Then operationalize the requirements through Clarysec’s Logging and Monitoring Policy Logging and Monitoring Policy, Logging and Monitoring Policy-sme Logging and Monitoring Policy - SME, Incident Response Policy Incident Response Policy, Incident Response Policy-sme Incident Response Policy - SME and Audit and Compliance Monitoring Policy Audit and Compliance Monitoring Policy.

Logs are not evidence until they are governed, protected, reviewed and connected to decisions. The organizations that can prove that chain will pass audits faster, respond to incidents better and give leadership confidence when the next 2:17 AM alert arrives.