DORA's change and access rules, point by point, and the record Opafra writes for each.
Commission Delegated Regulation (EU) 2024/1774 sets the technical standards for ICT risk management under DORA. Below, 19 of its points on change management, access, logging, patching and continuity testing are each paired with the record that answers it, and the points Opafra answers only in part, or not at all, are listed too.
Who it applies to
Financial entities, and the providers they use.
DORA applies to financial entities. The technical standards are in Delegated Regulation (EU) 2024/1774, which supplements Regulation (EU) 2022/2554 (DORA).
A hoster or a managed service provider that serves a financial entity is an ICT third-party service provider. It is bound through the entity's contract, not by these points directly, so the questions in the contract are the ones to answer.
Articles 28 to 41 of the Regulation are the simplified ICT risk management framework, for the entities in DORA article 16(1). Their versions of the access and change articles below are 33 (access control) and 38 (ICT project and change management). Whether the full or the simplified framework applies to you is a question for your own advisers.
How to read it
What your DORA program asks, and the record that answers it.
Yes means a record Opafra writes answers the point, for work done through Opafra. Partly means the record is a part of the answer. No means Opafra does not answer it. The quotations are the Regulation’s own, from EUR-Lex; where a quotation has three dots, words of the text are left out.
13 yes, 5 partly, 1 no
Change management, article 17
Who approved the change, and what it did.
- 17(1)(b): independence of approving and requesting
- Yes. The point asks for “mechanisms to ensure the independence of the functions that approve changes and the functions responsible for requesting and implementing those changes”. The approval is bound to the revision, a person cannot approve their own change, and the requester, the approver and the runner are recorded. See the change record.
- 17(1)(c)(iii): changes tested in a controlled manner
- Partly. The point asks that “the changes are tested and finalised in a controlled manner”. A dry run shows each host what the run would do before it runs. The testing regime itself is the entity’s.
- 17(1)(d): documentation of change details
- Yes. The point asks for “the documentation and communication of change details, including: (i) the purpose and scope of the change; (ii) the timeline for the implementation of the change; (iii) the expected outcomes”. The change record holds the plan, the revision, the targets, the dry-run diff, the schedule and the outcome per host.
- 17(1)(e): fall-back procedures
- Partly. The point asks for “the identification of fall-back procedures and responsibilities, including procedures and responsibilities for aborting changes or recovering from changes not successfully implemented”. Fall-back steps can be written into the plan. Reverting what a run did on a server is not built.
- 17(1)(f): emergency changes
- Yes. The point asks for “procedures, protocols, and tools to manage emergency changes that provide adequate safeguards”. The emergency path runs now with a reason and records the run as an emergency change.
- 17(1)(g): emergency changes reviewed afterwards
- Yes. The point asks for “procedures to document, re-evaluate, assess, and approve emergency changes after their implementation, including workarounds and patches”. An independent approver reviews the emergency change afterwards, within a set window, and signs the record.
Access and identity, articles 20 and 21
Who had access, on whose approval, for how long.
- 20(2)(a): a unique identity for each person
- Yes. The point asks that “a unique identity corresponding to a unique user account shall be assigned to each staff member of the financial entity or staff of the ICT third-party service providers accessing the information assets and ICT assets”. Each person has their own account and their own SSH certificate in Opafra, suppliers included.
- 21(a): need-to-know and least privilege
- Yes. The point asks for “the assignment of access rights to ICT assets based on need-to-know, need-to-use and least privilege principles, including for remote and emergency access”. Access is a time-limited grant per environment, and emergency access goes through the same grant.
- 21(c): users identifiable for their actions
- Yes. The point asks for “ensuring that users are identifiable for the actions performed in the ICT systems at all times”. Every run and every grant names the person, and on the Opafra side there are no shared accounts.
- 21(e)(ii): privileged and emergency access on a need-to-use basis
- Yes. The point asks for “assignment of privileged, emergency, and administrator access on a need-to-use or an ad-hoc basis for all ICT systems”. Grants expire on their own and are approved per request.
- 21(e)(iii): withdrawal of access rights
- Yes. The point asks for “withdrawal of access rights without undue delay upon termination of the employment or when the access is no longer necessary”. The leaver event removes a person everywhere in one step, with proof per host.
- 21(e)(iv): regular update of access rights
- Yes. The point asks for “update of access rights where changes are necessary and at least once a year for all ICT systems ... and at least every 6 months for ICT systems supporting critical or important functions”. The access review is signed off on a set interval.
- 21(f)(ii): strong authentication for remote and privileged access
- Yes. The point asks for “the use of strong authentication methods ... for remote access ..., for privileged access”. Signing in to Opafra uses multi-factor authentication, and the SSH certificates it issues last five minutes.
- 21, closing sentence: automated privileged access management
- Yes. The article closes: “Where feasible and appropriate, financial entities shall deploy automated solutions for the privilege access management.” Grants, approvals and expiry are automated.
Logging, article 12
The log of access and change.
- 12(2)(c)(i) and (iii): logging of access control and change management
- Yes. The point lists the logging of “logical and physical access control” and of “change management”. Access and change events are in the audit log. It covers logical access only; physical access is not Opafra’s.
- 12(2)(d): protection of logs
- Partly. The point asks for “measures to protect logging systems and log information against tampering, deletion, and unauthorised access”. The audit log is append-only, enforced by a database trigger. The entity’s other logs are outside Opafra.
- 12(2)(f): clock synchronization
- No. The point asks for “the synchronisation of the clocks of each of the financial entity’s ICT systems upon a documented reliable reference time source”. Opafra does not publish its time source.
Patching, article 10
Patches and their records.
- 10(2)(f) and (g): patch deployment and remediation
- Partly. The points ask to “prioritise the deployment of patches” and to “monitor and verify the remediation of vulnerabilities”. Patch campaigns and their records show what was patched and where. Opafra does not scan for vulnerabilities, so it does not show what is missing.
Continuity testing, article 25
Restores that were tested.
- 25(2)(c): testing of switchover to backups
- Partly. The point asks for testing that contains “scenarios of switchover from primary ICT infrastructure to the redundant capacity, backups and redundant facilities”. A restore test records its result and the time it took to restore. See the restore test. The continuity plan and its scenarios are the entity’s.
What Opafra does not cover
Evidence for a point, not a verdict.
- Physical access, 21(g)
- No. Opafra records logical access to servers. Physical access to premises and equipment is outside it.
- Network traffic and anomaly detection
- No. Opafra does not watch network traffic or detect anomalies. The audit log can be exported or fetched through the API by the system that does.
- Weekly vulnerability scanning, 10(2)(b)
- No. Point 10(2)(b) asks for automated vulnerability scanning every week. Opafra does not scan.
- A reliable time source, 12(2)(f)
- No. Opafra does not publish its time source, as the logging section says.
- Reverting a run, 17(1)(e)
- No. Opafra does not undo what a run did on a server. Fall-back steps are written into the plan, as the change section says.
- Work outside Opafra
- No. Opafra records what goes through it: plans, runs, grants and the sign-in to Opafra itself. Work done on a server by another route is not in these records.
- A verdict on DORA
- No. The records are evidence for the points above. They do not say that an entity meets them, and Opafra is not a certification. DORA asks for much more than change and access, and whether it applies to you is a question for your own advisers.
See the records for your own servers.
Tell us what you run and which questions your auditors ask. You get a demo and your price in writing within one business day, with no call.