Ariovis

Use case

Complying with DORA: which controls for identities, access, privileges and data?

The Digital Operational Resilience Act (DORA), Regulation (EU) 2022/2554, has applied since 17 January 2025. It broadly frames the digital operational resilience of the financial entities concerned: ICT risk management, incidents, continuity, testing, third-party providers, protection of systems and data.

Part of these requirements concerns identities and access very directly. Delegated Regulation (EU) 2024/1774 sets out in particular obligations relating to identity management, least privilege, strong authentication, administrator access, logging, detection of anomalous activities and prevention of data leakage.

It would nonetheless be misleading to look for “the DORA solution”. These controls take place at different moments: before access, during authentication, at the point of the authorisation decision, when a privilege is used, or when data is viewed, modified or transferred.

This page therefore offers a technical mapping of certain DORA controls and of the building blocks that can contribute to implementing them.

DORA: one requirement, several controls

The Alliance pour la Confiance Numérique describes DORA as a regulation that harmonises a previously fragmented regulatory environment by introducing, in particular, new requirements for governance, risk management and internal control.

This reading matters: DORA should not be treated as a list of products to buy. For one and the same access, several controls may apply in sequence. The identity and its entitlements must be governed, its authentication verified, a decision taken as to whether a precise action is authorised, any privileges controlled, usable traces retained, and certain uses or transfers of data prevented.

The question therefore becomes less “which tool answers DORA?” than “which control must we implement, at which moment, and with what evidence?”.

Analysis — French source, not a regulatory authority

Alliance pour la Confiance Numérique

« Detailed analysis of the European DORA regulation »

10 September 2024

The Alliance pour la Confiance Numérique is a French source of analysis; it is not a regulatory authority.

Matrix of DORA controls

This matrix maps technical contributions to certain DORA requirements. It does not represent exhaustive coverage of the regulation, which also covers overall ICT risk governance, incidents, continuity, resilience testing, ICT third-party providers, regulatory reporting and other organisational and technical measures.

  • Governance

    Govern identities and the lifecycle of rights

    • Article 20
    • Article 21(a)
    • Article 21(b)
    • Article 21(c)
    • Article 21(e)

    Who must have what, why and until when?

    Technology building block

    Netwrix Identity Manager (formerly Usercube)

    • Identity repository, matching of identities and accounts
    • Joiner-Mover-Leaver, provisioning and deprovisioning
    • Role catalogue, assignment rules
    • Separation of duties, High Privilege risks
    • Certification campaigns
  • Authentication

    Authenticate with a level of trust matched to the risk

    • Article 20(1)
    • Article 21(f)

    Is the person presenting themselves correctly authenticated with regard to the risk of the resource and the context?

    Technology building block

    Ping Identity / PingOne

    • Authentication policies, MFA, strong authentication
    • FIDO2 depending on configuration
    • Adaptive policies and risk signals with PingOne Protect
    • Step-up and control of session durations
  • Authorisation

    Decide dynamically whether a precise action should be authorised

    • Article 11(a)
    • Article 21(a)
    • Article 21(d)

    Even authenticated and eligible, can this user perform this action on this resource in this context?

    Technology building block

    Axiomatics

    • ABAC/PBAC authorisation, centralised policies
    • Attributes of the subject, the action, the resource and the environment
    • Dynamic decision at runtime through a PDP
    • Enforcement of the decision through a PEP
  • Privileges

    Grant privileges on a need-to-use or ad hoc basis

    • Article 21(e)(ii)
    • Article 12 — associated traces

    How can an administrative operation be allowed without keeping the privilege unnecessarily?

    Technology building block

    Netwrix Privilege Secure

    • Privileged sessions subject to policies
    • Approval where necessary, maximum duration
    • Pre-session and post-session actions allowing access to be granted and then revoked
    • Proxy and session recording

    The regulation also states that, where feasible and appropriate, financial entities are to deploy automated privileged access management solutions.

  • Privileges

    Protect credentials, secrets and privileged access

    • Article 21(e)(ii)
    • Article 12 — traceability of activities

    How can the secrets required for privileged operations be protected, used and renewed?

    Technology building block

    KeeperPAM / Keeper Secrets Manager

    • Management and automated rotation of credentials, application secrets
    • Privileged connections without exposing the credential
    • Session management and recording, Zero Trust connections
    • Temporary sharing of connections or tunnels, reporting of PAM events

    Keeper and Netwrix Privilege Secure overlap in places and answer different architectures or use cases: these two building blocks are not to be deployed systematically on top of one another.

  • Audit

    Log access, changes and activities

    • Article 12
    • Contribution to the mechanisms of Article 23

    Who did what, when and where, and which changes or activities have we actually observed?

    Technology building block

    Netwrix Auditor

    • Collection and reporting of changes and activities on supported environments
    • Logon activity, access to certain resources
    • Permission changes
    • Searches to find who changed what, when and where

    Netwrix Auditor contributes to visibility, investigation and the production of evidence; it should not be presented as replacing, on its own, a SIEM, a SOC or the whole mechanism for detecting anomalous activities under Article 23.

  • Data

    Prevent unauthorised transfers or uses of data from endpoints

    • Article 11(e)
    • Article 11(f)(iii)
    • Article 11(i)
    • Article 14(b)

    Even if the user may legitimately view this data, may they transfer it through this medium or channel?

    Technology building block

    Netwrix Endpoint Protector

    • Device Control to govern peripherals and removable media
    • Content Aware Protection to detect sensitive content
    • Blocking, allow or reporting policies on exit points
    • Complementary eDiscovery and Enforced Encryption capabilities

    Endpoint Protector contributes directly to data loss and leakage prevention controls, but does not on its own cover all the endpoint security requirements set out in Article 11.

How the controls fit together

These building blocks do not answer at the same moment of the security decision. Netwrix Identity Manager acts mainly upstream to determine and govern the rights an identity should hold. Ping Identity comes in at the time of authentication and makes it possible to match the level of trust required to the risk of the access. Axiomatics then makes it possible to go further when the decision cannot be determined from a role alone and must take the action, the resource and the context into account at runtime.

When a privilege is required, a PAM building block such as Netwrix Privilege Secure or Keeper makes it possible to control its use according to the chosen architecture. Netwrix Auditor then brings visibility and elements of evidence on the activities and changes observed, while Netwrix Endpoint Protector comes in when the risk relates to data leaving or being transferred from endpoints.

This separation is deliberate. A coherent DORA project does not consist in stacking these solutions, but in determining which controls are necessary in the light of the risks, the assets concerned and the existing landscape.

An example: an administrator on a critical system

Take the case of an administrator who has to work on an ICT system supporting a critical or important function. IAM governance can establish that they are eligible for this responsibility and maintain that decision over time. Access Management can require strong authentication matched to the risk. PAM can limit administrative access to the duration needed for the intervention and retain the traces required by policy. If the application requires a finer decision, an authorisation policy can further limit certain operations depending on the resource or the context.

The events produced by these various controls can then feed the logging and investigation mechanisms. If the administrator legitimately accesses sensitive data, a DLP policy can finally prevent it from being copied to a device or transferred through a forbidden channel.

This example illustrates why a single technology cannot constitute a “DORA solution”. The control results from the articulation between governance, authentication, authorisation, privilege, traceability and data protection.

DORA goes much further

This mapping deliberately covers only part of DORA: the part on which identity, access, privilege, audit and data protection technologies can bring concrete controls.

The regulation also contains important requirements on overall ICT risk management, incidents, continuity and recovery, operational resilience testing, the management of ICT third-party service providers and the associated regulatory mechanisms. An organisation therefore cannot conclude that it is DORA compliant on the basis of the controls presented here alone.

The value of the matrix is different: making it possible to start from a precise requirement, identify the necessary control, understand the role of each building block and determine the expected evidence.

From requirement to evidence

Compliance becomes genuinely usable when each requirement can be linked to a process, an owner, a technical control and evidence. On the identity and access side, that means for example being able to demonstrate why an entitlement exists, when it was reviewed, how a privilege was obtained, which level of authentication was imposed, which authorisation decision was taken, or which data transfer was blocked.

That is the logic we follow: starting not from the product, but from the control to implement.

Sources

Regulatory requirements point to EUR-Lex; technical capabilities point to the vendors' official documentation.

Regulatory texts — EUR-Lex

Analysis — Alliance pour la Confiance Numérique, 10 September 2024

Netwrix Identity Manager

Ping Identity

Axiomatics

Netwrix Privilege Secure

Keeper

Netwrix Auditor

Netwrix Endpoint Protector

Go further

Discuss your DORA controls

Ariovis starts from the control to implement, the evidence expected and the existing landscape, before discussing tooling.

Discuss your DORA trajectorySee the Identity governance offer