DORA FAQs: Key Questions Answered As EU Resilience Act Comes Into Force

As of 17 January 2025, the Digital Operational Resilience Act (DORA) is in effect after a two-year implementation period for financial institutions. But despite the long run-up, compliance questions remain for many organisations. Are we affected? What happens now that DORA is in effect? How do we tackle specific requirements like penetration testing and incident response?

While some requirements have been further clarified in recent months, others remain open to interpretation. Nevertheless, DORA places cyber security and operational resilience requirements on many organisations who have been brought into scope of this type of regulation for the first time and must now have measures in place to demonstrate compliance.

In this blog, we’ll tackle some of the questions most frequently asked of NCC Group’s DORA experts.

Scope and third parties  

Do you believe that only “Critical ICT third parties” are in scope of DORA? or all “ICT” third parties? How are organisations defining their critical services?

The EU Commission have stated that ‘Critical Third Parties’ are in scope. If you are providing ICT services to clients who designate you as ‘critical’ to their business operations, it is likely you will be in scope. The European Supervisory Authority are aiming to confirm the list of Critical Third Parties and services by the end of April 2025.

We would recommend following the information released by the EU commission for this and conducting business impact assessments to keep an audit trail. The information is here.

We are a UK based building society and we don’t have any exposure outside of the UK. Are we within the scope of DORA? 

If you have no business operations in the EU, you would not be in scope of DORA. However, it may be worth aligning to DORA as best practice for future regulations. Complying to the SS1/21 and SS2/21 does not mean you will be compliant with DORA.

Are organisations such as Fund Administrators in scope? 

Yes, DORA scope includes fund managers, such as those managing alternative investment funds (AIFs), UCITS management companies, and various other financial entities. Ultimately, If you are designated as an FS organisation in the EU, and you have business operations in the EU, then yes.

What needs to go in our Register of Information?

In summary, for DORA compliance, financial entities must maintain a detailed and comprehensive Register of Information that covers all critical ICT services, third-party providers, risk management frameworks, incident handling procedures, and governance processes related to digital operational resilience. This register is crucial for ensuring transparency, accountability, and proactive risk management, all of which are central to DORA’s objectives of strengthening financial sector resilience to digital disruptions. 

The Register of Information is required to be maintained at entity, sub-consolidated and consolidated levels.

This information was released in May 2024 and can be found here.

How can a financial services organisation  gain assurance from ‘critical third parties’ that they have robust tested and documented controls mapped to the DORA regulations?

The requirements for critical third parties are the same as financial institutions that must comply with DORA. NCC Group would recommend an audit on the DORA controls by an independent third party to gain assurance that the third party is complying with the regulation. When reviewing third parties it is important to consider risk, technical controls in place, resilience plans and any testing and mitigating factors as a priority.

How long will it be until DORA affects UK banks and financial services organisations who do not ‘play’ in the EU?

Currently, if you are in the UK, and regulated by the PRA, you may fall under the SS2/21 Operational Resilience regulations, which are in line with the controls of DORA. DORA itself will never directly impact UK only operating organisations as we have left the EU, however, if a UK organisation has business operations in Europe, they will be in scope. It is our view that DORA is considered good practice and demonstrates mature operational resilience to both your current client base and investors.

Businesses may also want to align to DORA for this reason, and doing so is good future-proofing in case they one day operate in Europe.

Just how much of the requirements must be achieved to be compliant?

If you are in scope of the DORA, everything noted in the requirements must be achieved to attain DORA compliance. However, it is important to note that compliance is an ongoing process and cannot be obtained overnight.

It is about constantly testing, updating, and auditing, and ensuring a clear plan to maintain compliance. If you are considered or confirmed to be a critical third party, you would be required to comply fully with DORA.

Audit and Enforcement

How will the organisation be audited by the competent authorities on DORA? Will it just involve providing the reporting, or will they check the controls and conduct the audit on premises?

This is not yet clear, and we expect more information on this in the coming months. You should, however, prepare for all eventualities. Using GDPR as an example, audits or investigations have been triggered by data breaches or complaints to the regulator.

 Based upon the example of NIS/NIS2, we are seeing a number of approaches by competent authorities, varying from periodic self-assessment and declaration of compliance to full on-site audits. 
It is our opinion that all organisations should at least presume to have up to date, relevant evidence that can be presented if required to support any future audit.

How exactly will DORA be enforced? Is this another tick-box exercise?

DORA aims to ensure financial sectors resiliency across the European Union, and as this is one of the biggest frameworks published since GDPR, we’d imagine that enforcement will be quite stringent.

 Whether the EU Commission audit organisations, or request evidence of compliance, we’re not sure yet. However, if you are not compliant, you may be fined up to 1% of daily turnover for 6 months.

When gathering all the information for the Register of Information, what happens if it was not ready by 17 January?

You should have planned to have everything ready and in place by 17 January, however, it is important not to panic if you were not compliant in that timeframe. The important thing is to have baselined current activities and have a plan and adequate resources in place to close the gaps in compliance in a timely manner. There has been a two-year implementation period to ensure time to implement the controls in DORA. The worst-case scenario here would be a fine from the regulator (unlikely but a possibility). Fines are up to 1% of daily turnover for up to 6 months. NCC Group recommends starting with a QuickCheck to assess your gaps and form a remediation plan as soon as possible.

Demystifying Testing, Incident Response and Other Aspects of DORA

The pen testing requirement A26(7) mentions submitting and approval of testing to the authority. Assuming this is the local regulator, has there been any information on how this will be managed?

Threat-Led Penetration Testing (TLPT), typically known as red teaming in the UK, will need to be conducted every three years. Internal teams will be permitted to perform two out of every three TLPT cycles, but an external testing team must be used at least once every three cycles.

 Both internal and external teams must meet requirements as outlined in A27, however specific definitions and detail are not available yet. Detail around processes for approval of testers/tests and report submission and how these processes will be managed is also not currently available. In our opinion, for any service provider who is CBEST accredited, TIBER will be suitable. For smaller providers, this is expensive and therefore considerations will be given to other qualifications e.g. CREST or the UK CHECK scheme. 

In our opinion, based upon experience in other schemes, it is highly unlikely that regulators will give explicit approval for scopes, and therefore we advocate being able to present a robust scope that you believe meets your requirements.

Are there any thoughts around compliance to Article 25 and what standards will be applied here? I have seen and heard references to TIBER being the standard.

TIBER and ART are relevant to Article 26, which relates to Threat Led Penetration Testing (TLPT), generally known as red teaming in the UK. 

Firms that are already required to perform TIBER assessments should be well-placed to fulfil the Article 26 requirements for DORA. 

The standards for other organisations are likely to be based on ART, which is comparable to a reduced version of TIBER. 

This differs to Article 25, where we believe that compliance will require companies to provide evidence of business as-usual security assessments being performed regularly, such as annual vulnerability assessments and standard penetration testing (rather than red teaming). 

Our view is that adherence to the ART, although voluntary, will align to the requirements of DORA for a smaller organisation.

How do you see the relationship between the scenario library and incident response plans - is the scenario library to be used by the operations teams as well as the resilience teams - like a dual use tool?

In our view the scenario library and incident response plans are related in that the scenario library would feed into the incident response plans. For operational teams, the library could be used to inform training or for preparedness and real-time response planning. 

For the resilience teams, it could be used to inform testing, drills and strategy development.

Any guidance on what constitutes “Major Change” as per Article 8?

Major change is subjective and has not been confirmed within DORA. We would recommend that for any change a formal risk assessment is conducted based on your business impact assessment and criticality of systems or applications. 

The business can define thresholds based upon monetary value, or size and scale of change. It is our opinion, for example, that changes such as tech refreshes and software version updates constitute BAU minor changes. However, a significant change in how a business operates, its technology, or merger and acquisition (M&A) activity would constitute a “major change”. If in doubt, speak to your local regulator. 

An example of ‘significant change’ from v4 of PCIDSS could support in your decision making for ‘major change’ in DORA. 

Please see the below explanation: 

Significant Change description – PCI v4: 

There are certain requirements for which performance is specified upon a significant change in an entity’s environment.

While what constitutes a significant change is highly dependent on the configuration of a given environment, each of the following activities, at a minimum, has potential impacts on the security of the CDE and must be considered as a significant change in the context of related PCI DSS requirements: 

• New hardware, software, or networking equipment added to the CDE.
•  Any replacement or major upgrades of hardware and software in the CDE. 
• Any changes in the flow or storage of account data. 
• Any changes to the boundary of the CDE and/or to the scope of the PCI DSS assessment. 
• Any changes to the underlying supporting infrastructure of the CDE (including, but not limited to, changes to directory services, time servers, logging, and monitoring). 
• Any changes to third party vendors.

What comes after DORA?

Beyond compliance, are there practical operational benefits that firms stand to benefit from after implementation of DORA requirements?

Yes, absolutely. For the first time, all financial organisations within the EU will be subject to strict operational resilience requirements, ensuring that there is a baseline of cyber security measures in place across the sector. 

Whilst DORA compliance may take time, the benefits to the sector as a whole will far outweigh the time taken to gain compliance.

What is the specific difference between DORA and Operational Resilience?

DORA (Digital Operational Resilience Act) is the EU’s formal legislative framework for enforcing operational resilience requirements in the financial sector within the EU.

Is there documentation offering differences in adherence requirements between DORA and the UK PSR regime?

There isn’t any documentation comparing the regulatory requirements for DORA and PSR.... but as a best practice we’d suggest that any PSR regulated firm should voluntarily follow the DORA requirements, as long term they would be able to demonstrate resilience, be ESA compliant and remain attractive to any DORA captured firm.

Thinking about building a framework with DORA in mind, what should be our key considerations?

DORA can be mapped to multiple information security frameworks including ISO27001, NIS2, NIST. The key is to ensure you have conducted a gap analysis against the DORA controls and have a clear plan in place for any mitigation. We’d also pay specific attention to the stressed exit plan requirements and the scenario testing around supplier insolvency. 

There are some good resources such as SCF (Secure Controls Framework) which contains mapping across multiple frameworks and should be used as a baseline to build upon any pre-existing framework.

Preparation and implementation

What areas of readiness testing should I do?

Without knowing what type of organisation you represent, it is difficult to give a precise answer, however, if you are in scope of DORA, we’d recommend that you should first undergo a readiness assessment or gap analysis to identify gaps and areas for improvement, ensuring that you can remediate before the January 2025 deadline. 

Testing such as BAU testing, compliance audits, maturity testing and pen testing, all contribute to readiness testing and will provide a baseline for DORA.

Who are the key stakeholders for effective implementation of the DORA regulations?

The key for any regulatory requirement is to have executive sponsorship within the business as a first requirement (someone at executive board level).

Based on our previous experience, you will need a broad church of input including: Non-financial risk, Third Party Risk management, Supplier Management, Operational Resilience, Crisis Management, Audit, Business Continuity, Compliance, Legal, Individual service owners, New Business and IT change, Recovery and resolution planning. 

It is paramount, however, to ensure that a small functional steering group is established to maintain momentum during implementation with working groups established for specific areas. 

The executive sponsor must also be responsible and accountable for through-life compliance.