Security logging and monitoring (SIEM, SOC, MDR) as evidence

A practical guide to security logging, SIEM and SOC or MDR services: what to log, retention, detection use cases, alert triage and how to show supervisors that detection works.

This guide is for IT and security managers, CISOs and the MSPs or vCISOs advising them who need to set up or tidy up security logging and monitoring in a way that stands up to a NIS2, CyFun or DORA review. It covers what to log, how long to keep it, which detections to build first, how alerts should be handled and how to choose between an in-house SOC, an outsourced SOC and managed detection and response (MDR). At the end you will have a register and a way to show that detection works.

Before you start

You need three inputs: a list of critical services and the systems that support them (from your asset inventory or business impact analysis), your current risk assessment, and an overview of what you already collect. Involve the DPO early. Security logs contain personal data, so purpose, minimisation, access and retention need to be documented under the GDPR^[7].

Step 1: Understand what the rules actually require

NIS2 Article 21(2)(b) requires measures for incident handling, and you cannot handle what you do not detect^[1]. For digital infrastructure and digital service providers, Implementing Regulation 2024/2690 is specific. Annex point 3.2 asks entities to monitor and log activity to detect events that could be incidents; to log, where appropriate, network traffic, account and authentication events, privileged activity, changes to critical configuration and backup files, and security tool events; to automate monitoring where feasible and tune it to limit false positives and negatives; to retain and protect logs for a predefined period; to synchronise time sources; to make logging redundant; and to review the set-up at intervals and after significant incidents^[2]. The Implementing Regulation formally applies only to those provider types, but it is a practical benchmark for any entity, and ENISA’s technical guidance explains each point^[5].

For financial entities, DORA Article 10 requires mechanisms to promptly detect anomalous activities, multiple layers of control, alert thresholds that trigger incident response and regular testing of detection^[3]. Delegated Regulation 2024/1774 adds detail: logging procedures that define events, retention and protection (Article 12), clock synchronisation to a documented reliable time source, and alerts on anomalous activity at least for assets supporting critical or important functions, handled both during and outside working hours (Article 23)^[4].

Step 2: Define detection use cases first

A use case is a specific thing you want to detect, with a defined response. Start with ten to fifteen that match your risks; ransomware precursors, account takeover and misuse of privileged access are sensible starting points.

• Sign-in from an unusual country or impossible travel on a privileged account.
• MFA fatigue (repeated push denials) or MFA method changed, followed by a sign-in.
• New mailbox forwarding rule to an external address.
• Member added to a privileged group (domain admins, global administrators).
• Endpoint protection disabled or tampered with; ransomware behaviour detected.
• Deletion or modification of backup jobs, snapshots or backup repositories.
• Mass file download or upload to unknown cloud storage.
• Outbound connections to known malicious infrastructure (threat intelligence match).
• Audit logging disabled on a critical system.

Map each use case to the log sources it needs and record which ones you can detect today. This gap view is your most useful document.

Step 3: Prioritise log sources

Work in tiers. Tier 1 sources are where most attacks become visible and are usually cheap to collect. Tier 2 sources add depth for critical services.

Area	Tier 1 (start here)	Tier 2 (add for critical services)
Identity	Entra ID or other IdP sign-ins and audit logs, Active Directory security events, MFA events	Privileged access management sessions, service account usage
Endpoints and servers	EDR alerts and telemetry, Windows security and PowerShell logs on servers	Sysmon or equivalent detailed telemetry, Linux audit logs
Cloud and SaaS	Microsoft 365 or Google Workspace audit logs, cloud control-plane logs (AWS CloudTrail, Azure Activity, GCP Audit)	Storage access logs, key vault access, SaaS admin logs for business-critical apps
Network	Firewall allow and deny logs, VPN and remote access, DNS queries	Proxy logs, NetFlow, network detection and response, OT network monitoring
Critical applications	Admin actions, authentication, configuration changes	Business transactions with fraud relevance, database audit
Security and backup tools	Backup console changes and failures, email security alerts, vulnerability scanner findings	Data loss prevention, deception tools

Step 4: Set retention, integrity and time synchronisation

Neither NIS2 nor the Implementing Regulation fixes a number of months for log retention. The requirement is a predefined, justified period. Base it on how long attackers typically remain undetected in your environment, on legal hold and investigation needs, and on any sector rules. A common design is a “hot” period that can be searched quickly and a cheaper archive for the rest of the period. Write down the rationale.

• Protect logs against modification and deletion: separate storage, restricted admin rights, immutability where available.
• Monitor the logging pipeline itself: alert when a source goes silent.
• Synchronise all systems to a documented reliable time source (NTP from a trusted internal or national source) and log in UTC or with time zone information.

Step 5: Choose your operating model: in-house, SOC service or MDR

The question is who watches the alerts at 3 a.m. and who has the authority to act.

Model	What you get	Suits	Watch for
In-house SOC	Full control, deep knowledge of your environment	Large entities with budget for 24/7 staffing	Staffing a 24/7 rota needs several analysts; key-person risk
Outsourced SOC / managed SIEM	Provider monitors your SIEM and escalates alerts	Entities that want to own the platform and data	Escalation without response: someone in-house must still act
MDR	Provider monitors mainly EDR and identity telemetry and can contain (isolate a host, disable an account)	Small and mid-sized entities	Scope limited to the provider’s tools; confirm which logs are covered and who decides on containment
Hybrid	MDR for 24/7 coverage, in-house team for use cases and investigations	Growing organisations	Clear split of responsibilities in a RACI

Whatever you choose, the provider is an ICT supplier and falls under your supply chain measures. Contracts should cover service levels for triage and escalation, containment authority, log ownership and return at exit, data location, and support for your incident reporting deadlines.

Step 6: Address EU data residency and employee monitoring

Security logs contain user names, IP addresses, device identifiers and sometimes message metadata, so GDPR applies in full. Under Chapter V of the GDPR, transfers of personal data outside the EEA need a legal basis such as an adequacy decision or appropriate safeguards^[7]. Remote access to EU-stored logs by analysts in a third country can also amount to a transfer.

• Ask where logs are stored, processed and backed up, and where SOC analysts work.
• Prefer an EU region for the SIEM and the provider’s analysis tools, and check the provider’s subprocessors.
• Document a data protection impact assessment where monitoring is extensive or systematic.
• Respect national employee monitoring rules: in Belgium, Collective Labour Agreement No. 81 on monitoring of electronic online communications; in the Netherlands, the works council consent right under Article 27 of the Works Councils Act; in Luxembourg, the Labour Code rules on workplace monitoring.

Step 7: Define alert triage and escalation

An alert that nobody handles is evidence against you. Define severities, response times and who does what, and link high-severity alerts to your incident response plan and your NIS2 reporting decision.

• Severity levels with target times to acknowledge and to escalate (for example, critical alerts acknowledged within 30 minutes, 24/7).
• Triage steps per use case: what to check, when to close as false positive, when to escalate.
• Escalation chain with named people and deputies, including outside office hours.
• A clear point where an alert becomes an incident and the clock for the 24-hour early warning under NIS2 Article 23 may start^[1].

Step 8: Prove that detection works

This is where most organisations fall short. A modest set-up that is tested and improving is more convincing than an expensive one nobody can explain. The CyFun 2025 framework is aligned with the NIST CSF 2.0 and follows its structure, including the Detect function^[6].

• Test each priority use case at least yearly with a safe simulation (create a test forwarding rule, add a test account to an admin group, run a benign attack simulation tool) and record whether the alert fired and was handled in time.
• Report coverage: percentage of critical systems sending logs, percentage of priority use cases tested in the last 12 months, mean time to acknowledge and to escalate.
• Include detection in your tabletop exercises; the tabletop exercise playbook shows how.

In Secrato, the log source and use-case register can be attached as evidence to the monitoring controls in the Compliance Engine, so a single test result supports NIS2, CyFun, ISO 27001 and DORA at the same time.

The companion template includes a log source register, a detection use-case register with 30 pre-filled use cases, and a detection test log.

How this connects to other frameworks

ISO/IEC 27001:2022 Annex A covers logging (8.15), monitoring activities (8.16) and clock synchronisation (8.17); the same register evidences all three. In NIST CSF 2.0 and CyFun, this work sits in the Detect function. Under DORA, Article 10 and the Delegated Regulation make detection testing explicit. The register you build once serves all of them.

Frequently asked questions

Do we need a SIEM to comply with NIS2?

No law names a product. You need to collect relevant logs, detect suspicious activity and respond in time. A small organisation can meet that with an MDR service on endpoints and identity plus centralised cloud audit logs. Larger or more complex entities usually need a SIEM to correlate sources.

How long should we keep security logs?

There is no fixed EU-wide figure under NIS2. Choose a period that lets you investigate incidents discovered late, justify it in writing, and check sector rules and contracts. Keep personal data no longer than that purpose requires.

Is 24/7 monitoring mandatory?

NIS2 does not state it explicitly. DORA’s delegated regulation requires alerts for critical or important functions to be handled during and outside working hours. For entities with critical services, out-of-hours coverage is a practical necessity.