What do security teams get wrong about monitoring for DORA compliance?

Why This Matters for Security Teams

DORA changes monitoring from a narrow SOC activity into evidence-grade operational resilience. Security teams often assume that if alerts fire, compliance follows. That is not enough. Under the EU Digital Operational Resilience Act (DORA), telemetry must support incident classification, escalation, reporting, and post-incident review, not just detection. That makes completeness, retention, and correlation part of the control objective.

This is where NHI and service-account activity becomes a blind spot. Access logs, role changes, OAuth grants, API calls, and third-party usage can all be material to resilience reporting, yet they are frequently split across platforms and owned by different teams. NHIMG’s Ultimate Guide to NHIs — Regulatory and Audit Perspectives frames this as a lifecycle problem as much as a monitoring problem. In practice, teams usually discover the gap during an audit or incident review, not when the log pipeline is being designed.

How It Works in Practice

Effective DORA monitoring starts with defining what must be observable for operational resilience, then mapping that to the systems that actually generate the evidence. That means logs for authentication, privilege changes, secret use, administrative actions, third-party integrations, and material configuration changes must be centralised and time-synchronised. The goal is not just to detect suspicious behaviour, but to reconstruct who did what, when, from where, and under what authority.

For NHI-heavy environments, that usually requires correlating identity events with workload and application telemetry. A service account may access a payment API, rotate a token, assume a role, or trigger a downstream workflow. If those events are recorded separately, incident responders cannot produce a trustworthy timeline. Guidance in the Top 10 NHI Issues and NHI Lifecycle Management Guide shows why lifecycle control matters: the same identity that creates risk at issuance can become a reporting gap at retirement if logs are missing or fragmented.

• Capture access, role, policy, and secret-use events with consistent timestamps.
• Retain logs long enough to support incident reporting and forensic reconstruction.
• Correlate third-party activity with internal identity and asset context.
• Test whether the evidence is usable by audit, risk, and incident teams, not just searchable by the SIEM.

Best practice is evolving, but current guidance suggests using control baselines from the NIST Cybersecurity Framework 2.0 and NIST SP 800-53 Rev 5 Security and Privacy Controls to define evidence quality requirements before tuning detection logic. These controls tend to break down when identity logs are siloed in SaaS tools and third-party platforms because correlation becomes incomplete exactly when cross-system evidence is most needed.

Common Variations and Edge Cases

Tighter logging often increases storage, engineering, and privacy overhead, so organisations have to balance evidentiary depth against operational cost and data minimisation requirements. That tradeoff is especially visible in cross-border financial services, where retention rules, access restrictions, and incident reporting timelines may not align neatly.

There is no universal standard for exactly how much telemetry is enough for DORA in every environment. Current guidance suggests focusing on materiality: if an event could affect service continuity, customer impact, or recovery analysis, it should be logged in a way that is both searchable and defensible. This is where many teams over-index on central SIEM coverage while under-investing in source integrity, normalisation, and ownership of third-party logs.

NHIMG’s research on Ultimate Guide to NHIs — Key Challenges and Risks is useful here because the same operational gaps that increase compromise risk also weaken audit readiness. If log access is too restricted, incident teams cannot investigate. If it is too broad, sensitive data may be overexposed. The practical answer is role-scoped access to immutable evidence, with reviewable exceptions. In environments with heavy managed-service dependence, that guidance often breaks down because the organisation does not control the provider’s log schema or retention window.

Related resources from NHI Mgmt Group

• What do security and compliance teams get wrong about monitoring crypto transaction risk?
• What do security teams get wrong about entitlement management in distributed environments?
• What do security teams get wrong about post-login abuse?
• What do security teams get wrong about point-in-time file monitoring?