DORA: what it means for cyber hiring in finance
DORA: which cyber profiles banks, insurers and financial firms need to hire to handle ICT risk, incident reporting, resilience testing and third parties.
Since 17 January 2025, the DORA regulation has applied to banks, insurers, investment firms, payment institutions and many other financial entities. Many security teams first treated it as a compliance project. They then found that it is mostly a skills question: who will run ICT risk, maintain the third-party register, classify a major incident or coordinate a threat-led penetration test? This article maps the regulation's requirements to the profiles you need, and suggests how to prioritise.
DORA in brief
Regulation (EU) 2022/2554 on digital operational resilience for the financial sector, known as DORA, is available on eur-lex.europa.eu. Unlike the NIS2 directive, it is a regulation: it applies directly in every member state, with no transposition. For the financial entities it covers, it acts as the sector-specific rule relative to NIS2.
In France, supervision mainly sits with the ACPR and the AMF, depending on the type of entity. The regulation is supplemented by technical standards (RTS and ITS) that set out the details, such as incident classification criteria or the format of the register of information.
Two principles matter for hiring:
- Proportionality. Article 4 requires measures to reflect the size, risk profile and nature of the business. Some smaller entities benefit from a simplified framework (Article 16).
- Management accountability. Article 5 makes the management body responsible for the ICT risk management framework. Its members must keep their knowledge sufficient, including through regular training.
This article is not legal advice. Check the exact scope and the obligations that apply to your entity with your compliance team and your supervisors.
The five pillars and the skills they demand
DORA is built around five main chapters of obligations. Each one calls for different expertise.
ICT risk management
Chapter II requires an ICT risk management framework: identifying assets and dependencies, protection, detection, response, recovery, backups and business continuity. Article 6 also requires that managing and monitoring this risk be assigned to a control function with an appropriate level of independence, separate from operational teams and from internal audit.
In practice, this creates or expands a second-line role: an ICT risk lead who can challenge IT, track action plans and report to management.
Incident management and reporting
Chapter III requires an ICT incident management process, classification against defined criteria, and reporting of major incidents to the competent authority in several stages (initial notification, intermediate report, final report). Deadlines are set by the related technical standards.
Meeting those stages means detecting fast, classifying correctly and documenting the incident while it unfolds. That is SOC and incident response work, but it also requires close coordination with compliance.
Digital operational resilience testing
Chapter IV requires a proportionate testing programme: vulnerability assessments, source code reviews, scenario-based tests and penetration tests, among others. Entities designated by the authorities must also run, in principle every three years, threat-led penetration testing (TLPT), based on the European TIBER-EU framework. Article 27 sets requirements for testers and governs the use of internal testers.
ICT third-party risk
Chapter V is often the heaviest in workload. It requires a third-party risk strategy, a register of information covering contractual arrangements with ICT service providers, minimum contractual provisions (Article 30) and exit strategies. Providers deemed critical at European level are also overseen by the European Supervisory Authorities.
Information sharing
Chapter VI allows financial entities to exchange cyber threat information within trusted arrangements. It is an option rather than an obligation, but it needs people able to use and share threat intelligence.
From requirements to profiles
| DORA requirement | Main profile | What they bring |
|---|---|---|
| Management accountability, roadmap | CISO | Takes the topic to the executive committee, makes trade-offs, reports |
| ICT risk control function | ICT risk lead, senior GRC profile | Risk framework, metrics, challenge of the first line |
| Register of information, contract clauses | ICT third-party risk analyst | Contract inventory, provider assessment, follow-up on commitments |
| Incident classification and reporting | SOC analyst, incident response specialist | Detection, classification, factual timeline for reports |
| Testing programme, TLPT | Security testing lead, pentester, red teamer | Runs campaigns, reads results critically, coordinates TLPT |
| Continuity and recovery | Business continuity manager | Continuity plans, exercises, restore tests |
| Cloud and identity security | Cloud security engineer, IAM engineer | Technical protection measures, access management |
| Independent assurance | IT auditor (third line) | Reviews the framework and its effectiveness |
As with NIS2, one person often covers several rows in a mid-sized entity. What matters is that no row is left without an owner, and that the separation between those who operate and those who control is respected. Our article on which profiles to hire for NIS2 applies the same approach outside financial services.
The most contested profiles
The ICT risk lead
This is often the hardest role to fill. It takes two cultures: understanding an architecture, a recovery plan or a chain of cloud dependencies, and mastering operational risk and banking supervision. Candidates usually come from GRC, IT audit or risk consulting. Our guide to hiring a GRC analyst gives an assessment baseline, to be completed with a case study specific to financial services.
The third-party risk analyst
The register of information and contract reviews call for rigour, persistence and comfort working with procurement and legal. This profile can come from compliance, procurement or GRC. It is frequently underestimated, yet it is the person who unblocks much of Chapter V.
The resilience testing lead
Even when TLPT is carried out by an external provider, the entity must prepare it, define the scope, coordinate the internal control team and act on the results. A former pentester or red teamer who can talk to the business is valuable. To assess these skills, see our guide to hiring a pentester.
The incident response lead
Reporting major incidents requires verified facts, fast. An incident response lead structures the process, prepares report templates with compliance and runs exercises. See our article on hiring an incident response lead.
Prioritising your hires
For an entity strengthening its team for DORA, this order often works:
- Clarify leadership. An identified CISO and a distinct ICT risk control function. Without them, other hires lack a frame. See our guide to hiring a CISO.
- Tackle third parties. A third-party risk analyst, because the register and contract reviews take time and depend on many stakeholders.
- Secure the incident chain. Detection, classification and reporting: a SOC (in-house or managed) overseen by someone internal, plus incident response capability.
- Structure testing. A lead for the testing programme, especially if your entity is likely to be designated for TLPT.
- Strengthen the third line. An IT auditor able to verify that the framework works.
Adjust the order to your starting point. A bank with a mature SOC will focus on third-party risk; a fast-growing payment institution will often start with leadership.
Pitfalls to avoid
- Looking for "a DORA profile". That job does not exist. Start from the uncovered requirements and hire the matching skills.
- Blurring the lines of defence. Placing the risk control function under the IT department it is meant to challenge weakens its independence.
- Outsourcing everything. Using providers is legitimate, but accountability stays with the financial entity. You need people in-house who can steer providers and read their deliverables.
- Hiring on regulatory vocabulary alone. A candidate who quotes the articles is not necessarily able to classify an incident or review a cloud contract. Assess with practical cases.
- Underestimating competition. The whole financial sector is hiring the same profiles at the same time. A slow process will cost you the best candidates.
In short
DORA does not create new jobs, but it makes essential some functions that many financial entities had left vague: independent control of ICT risk, rigorous third-party management, an incident chain able to report quickly and a well-run testing programme. Find the gaps, respect the separation of roles, then hire in the order that reduces your exposure fastest.
Strengthening your team for DORA? At Cyber Recrut, a recruiter and a security practitioner scope the role with you and run the search together. Our shortlisted candidates prove their skills on hands-on labs tailored to the role. See how we work or share your hiring need.