Spain's financial regulator publishes FAQs on DORA implementation: what you need to know

The Digital Operational Resilience Act (DORA) has applied across the EU since 17 January 2025. It sets a comprehensive framework for managing information and communication technology (ICT) risks and strengthening digital resilience in the financial sector. 

One year on, many organisations are still grappling with practical questions around governance, incident notification timelines, testing obligations and third-party risk management.

Spain’s Securities Market Commission (CNMV) has now published detailed FAQs on how DORA should be implemented by entities under its supervision, including investment firms, crypto‑asset service providers, market infrastructures and asset managers.

The FAQs provide practical guidance on supervisory expectations, proportionality and how firms should assess their own level of compliance. They are supported by a glossary of key concepts such as critical or important functions, ICT‑related incidents, microenterprises, third‑party ICT service providers and threat‑led penetration testing (TLPT).

Below we highlight the main takeaways and what they mean in practice.

1. Definitions, scope and proportionality

• Who is in scope: DORA applies, among others, to investment firms, crypto-asset service providers authorised under the Markets in Crypto-Assets Regulation (MiCA), market infrastructures, management companies and alternative investment fund managers, data reporting service providers, and crowdfunding service providers authorised under Regulation 2020/1503/EU.

• Exclusions for some asset managers: Certain small alternative investment fund managers (AIFMs) are excluded if they remain below the relevant assets under management thresholds (EUR 100 million, or EUR 500 million for non‑leveraged funds with five‑year lock‑ups). They may still choose to apply DORA voluntarily.

• National financial advisory firms (EAFNs): EAFNs are out of scope, as they are not considered investment firms under MiFID II.

• Responsibility to determine scope: Firms must determine for themselves whether DORA applies and act accordingly. The CNMV expects proactive compliance, not reliance on regulatory notifications.

• Branches: Obligations sit with the legal entity and its home authority, but branches must comply as part of the entity, and their risks form part of the overall framework.

• Proportionality principle: DORA applies proportionately, taking into account size, risk profile and the nature, scale and complexity of activities. Small and non‑interconnected investment firms benefit from a simplified framework and microenterprises from certain exemptions. Proportionality can reduce complexity but does not remove core obligations: even microenterprises must have a robust, documented resilience framework.

Practical recommendation:

Document your scope analysis and how you apply proportionality, including the rationale for any simplifications, so it can be explained to supervisors.

2. ICT risk management

• Board responsibilities: The Board has ultimate responsibility for the ICT risk management framework. It must have sufficient knowledge, skills and experience on ICT risk and digital resilience. This responsibility cannot be outsourced.

• Independence of the control function: For entities other than microenterprises, risk management and control functions must be independent. Smaller firms are not required to have a dedicated chief technology officer, chief information security officer or ICT auditor in‑house; these roles can be outsourced, intragroup or externally, provided independence and effective oversight are preserved.

• ISO 27001 is not enough: ISO 27001 certification does not equal DORA compliance. All entities are expected to perform a DORA-specific gap analysis.

• Critical or important functions: Firms must identify, document and regularly update their critical or important functions, assess associated ICT risks and put in place dedicated continuity and recovery plans.

• ICT asset inventory: A current, structured inventory of ICT assets is the foundation of risk management. Key decisions must be based on accurate, up‑to‑date information.

• Business impact analysis (BIA): A BIA is required to identify critical functions, analyse the impact of disruption and set recovery objectives. It underpins continuity and recovery planning.

• Business continuity policy and plans: These should set procedures, responsibilities and resources to ensure continuity of critical functions during ICT incidents, operational failures or cyberattacks. They should be BIA‑based and approved by the management body.

• Review cycle: The ICT risk management framework must be reviewed at least annually (or periodically for microenterprises) and after serious incidents or supervisory requests.

Practical recommendation:

A good starting point is to check whether your list of critical functions, ICT asset inventory, BIA and continuity plans are all aligned, and whether the Board has clear, documented oversight of ICT risk.

3. Management, classification and notification of ICT-related incidents

• Definition of ICT-related incident: Any unforeseen event that disrupts normal ICT operations and adversely affects the availability, authenticity, integrity or confidentiality of data or systems.

• Incident management process: Firms must have a documented process covering detection and logging, classification and severity assessment (in line with Delegated Regulation (EU) 2024/1772), governance and escalation (including to senior management), response and recovery, regulatory notification, documentation and traceability, post‑incident lessons learnt, and coordination with third parties and ICT providers.

• When is an incident “major”?: An incident is major if it affects critical services as defined in Article 6 of Delegated Regulation (EU) 2024/1772 and either: (i) involves effective, malicious and unauthorised access that may result in data loss; or (ii) meets at least two materiality thresholds in Article 9 (e.g. client impact, reputational damage, duration, geographical spread, data loss, or economic impact above EUR 100,000).

• Notification timelines: 

  • Initial notification: within four hours of classifying the incident as major, and no later than 24 hours after becoming aware of it.

  • Intermediate notification: within 72 hours of the initial notification, with updates without undue delay once normal activities resume.

  • Final notification: within one month of the last intermediate report.

• Consequences of late notification: Failure to notify in time may result in corrective measures or sanctions and can undermine coordinated responses and financial stability.

• Client communication: Where a major incident affects clients’ financial interests, entities must inform affected clients without undue delay and explain mitigation measures.

• Branches: Branches do not notify separately. The parent entity is responsible for classification and notification, including assessing geographical extent and identifying affected countries.

Practical recommendation:

Firms should rehearse their incident classification and notification process to check they can meet the four‑hour and 24-hour deadlines in practice, including coordination with group entities and ICT providers.

4. Digital operational resilience testing

• Objective and independence: All entities other than microenterprises must establish a robust, comprehensive digital operational resilience testing programme as part of their ICT risk management framework. The aim is to assess and strengthen the ability to resist, respond to and recover from incidents affecting ICT systems that support critical or important functions. Tests must be carried out by independent parties, which may be internal or external. If internal teams are used, entities must allocate sufficient resources and avoid conflicts of interest throughout design and execution.

• Frequency: At least annually, non‑microenterprises must test all ICT systems and applications supporting critical functions. Mature entities must carry out advanced TLPT at least every three years.

• Scope and methods: The programme should include a mix of techniques, such as vulnerability scans, network security reviews, gap analyses, penetration tests, scenario‑based tests, performance and end‑to‑end tests, and testing of continuity, response and recovery measures, including during acquisition, development and maintenance of ICT systems.

• TLPT and TIBER-EU/TIBER-ES: TIBER‑EU is the common European TLPT framework. TIBER‑ES follows the same principles, and tests performed under TIBER‑ES are recognised by other European Union authorities. The CNMV is the designated authority for TIBER‑ES tests for entities it supervises, working with the Bank of Spain and the Directorate‑General for Insurance and Pension Funds. Both frameworks are aligned with TLPT requirements under Articles 26 and 27 of DORA and Delegated Regulation (EU) 2025/1190.

Practical recommendation:

Entities should map their existing security and continuity testing to DORA, identify gaps in coverage of critical functions and plan a roadmap towards TLPT where they fall within the “mature” category.

5. Management of ICT third-party risk

• ICT services vs financial services: ICT services are broadly defined and cover digital and data services provided through ICT systems. Services that are not regulated financial services may still be ICT services for DORA purposes.

• Critical providers vs providers supporting critical functions:

  • Critical ICT service providers are designated at European level by the European Supervisory Authorities and subject to a specific supervisory regime, based on systemic impact, dependency and substitutability.

  • Separately, each firm must identify which of its providers support critical or important functions based on potential operational, legal or reputational impact.
    A provider may be both. While DORA applies directly to financial entities, ICT providers must enable compliance, for example by accepting contractual clauses under Article 30 and providing information for the provider register.

• Register of ICT arrangements: Entities must keep a register of all ICT service contracts, distinguishing those that support critical or important functions. The CNMV expects prioritisation of critical providers in risk management.

• Notifications to the CNMV: Entities must inform the CNMV when proposing to enter into ICT arrangements that support critical functions, report at least annually on new agreements and providers, and provide the complete register on request. The full register is required annually by 31 March.

• Pre‑contract due diligence and concentration risk: Before entering into ICT contracts, entities must assess whether the service supports a critical function, check supervisory conditions, identify relevant risks (including concentration risk), perform due diligence and consider conflicts of interest. Where providers are in third countries, firms must consider local law and compliance with EU data protection rules. The FAQs encourage consideration of multi‑provider solutions to avoid excessive dependence on a single provider.

• Termination rights: Contracts must allow termination in cases of significant breach, material changes affecting performance, weaknesses in the provider’s ICT risk management or threats to effective supervision.

• Intragroup providers: Intragroup ICT providers are treated as third‑party providers. Contracts must meet DORA requirements, be included in the provider register and remain under Board responsibility.

Practical recommendation:

Prioritise building a complete ICT provider register, review key contracts for DORA-compliant clauses and concentration risk, and ensure intragroup arrangements are brought within scope.

Looking ahead

The CNMV’s FAQs are an important step in translating DORA’s requirements into concrete expectations for supervised entities in Spain. They clarify how the CNMV interprets key concepts and how proportionality should work in practice.

Firms should now use the FAQs to:

• confirm their DORA scope and proportionality approach;

• conduct or update a gap analysis against DORA, even where ISO 27001 certified;

• align governance structures with Board‑level accountability for ICT risk;

• test incident management and notification processes against DORA timelines;

• ensure ICT third‑party arrangements, including intragroup services, meet contractual, oversight and reporting expectations; and

• confirm that resilience testing programmes cover all systems supporting critical or important functions and are on track for TLPT where relevant.

With supervisory scrutiny expected to intensify, this is a timely opportunity for financial entities to reinforce their digital resilience frameworks and prepare to evidence their approach to the CNMV.

If you would like to discuss what these FAQs mean for your organisation, or need support in reviewing your DORA compliance programme, please get in touch with your usual Linklaters contact or any member of our team.