DORA Lead Manager common mistakes
DORA Lead Manager · Understand the traps and how to avoid them.
Treating DORA as a standalone regulation to memorise, rather than as a Regulation that builds on and interacts with NIS2, GDPR, EBA/ESMA/EIOPA guidelines and existing national supervisory practice, so answers describe DORA's requirements in isolation and miss questions about how obligations are layered or where DORA prevails.
Candidates prepare from a single summary of DORA's five pillars and never map it against the surrounding EU regulatory stack, so they cannot reason about scope overlaps, lex specialis, or which authority does what.
What to do instead
Build a one-page interaction map: DORA vs NIS2 (DORA is lex specialis for ICT risk for in-scope financial entities), DORA vs GDPR (incident reporting runs in parallel, not instead of, personal data breach notification), and DORA vs sectoral outsourcing rules. For each pair, write one sentence on which instrument governs and one on what must still be done separately. Test yourself by taking any incident scenario and listing every reporting channel it triggers.
Applying the proportionality logic backwards - assuming small or non-complex entities are exempt from whole chapters of DORA, or conversely that every entity must run the full advanced testing programme.
The proportionality principle is real but narrow: it modulates how requirements are met (simplified ICT risk management framework, simplified testing), and it never removes the obligation to manage ICT risk or report major incidents. Candidates conflate 'simplified' with 'optional'.
What to do instead
Memorise the three-way split: obligations that are always full (incident management and reporting, register of information, contractual minimums), obligations that can be simplified (ICT risk management framework, some testing), and obligations that only apply to certain entity types (threat-led penetration testing for significant entities identified under the criteria, advanced testing where required). For each chapter of DORA, state which category it falls into and cite the article that creates the proportionality option.
Describing the ICT risk management framework as a policy document to be written, rather than as a governance system with defined roles, a three-lines-of-defence structure, and specific board accountability, so answers on governance questions stay at the level of 'the board should be involved'.
Candidates read the framework chapter as a list of topics to cover and miss the structural requirements: the management body's ultimate responsibility, its need for sufficient digital and ICT knowledge, the separate roles of the risk management function and internal audit, and the requirement for a dedicated ICT risk management function where justified by size and risk profile.
What to do instead
Draw the governance diagram: management body (defines risk appetite, approves and reviews the framework at least annually, bears ultimate responsibility), a senior ICT risk owner, the three lines of defence, and internal audit independent of the second line. Attach to each box the specific duty and review frequency. Practise answering 'who approves what and how often' until you can do it without notes.
Producing an implementation plan that is a list of DORA articles with owners, without sequencing dependencies, without a gap assessment baseline, and without a defined target operating model - then failing scenario questions that ask what should happen first or how to handle a slipping milestone.
Candidates treat the planning domain as project-management boilerplate and underestimate how much of the exam tests judgement about ordering, resourcing and stakeholder buy-in during a two-year implementation.
What to do instead
Structure your plan around a phased model: mobilise and scope (entity classification, scope of entities and ICT third-party providers, governance setup), gap assessment against each pillar, remediation design (framework, register of information, incident process, testing programme, contract remediation), then embedding and assurance. For each phase, know the deliverable, the key dependency and the main risk. Prepare two or three concrete answers on how to recover a delayed register of information or a delayed contract remediation programme.
Planning the register of information as an IT task late in the programme, rather than as an early, data-heavy exercise that depends on legal, procurement and business input and feeds multiple obligations.
The register looks like a spreadsheet, so candidates schedule it as a quick deliverable. In practice it requires identifying every contractual arrangement with ICT third-party providers, mapping subcontracting chains, and aligning with the reporting templates - and it is a prerequisite for contract remediation and for supervisory reporting.
What to do instead
Treat the register as a workstream starting in the first phase: define a data model covering the entity, the provider, the service, the criticality assessment, the data location, the subcontracting chain and the contract references; assign a single accountable owner; set a reconciliation process with procurement and legal; and plan a dry run of the reporting submission before the deadline. Be ready to explain how you would validate completeness.
Reducing ICT-related incident management to a ticketing workflow and a template notification, without the classification logic, the detection and monitoring capability, or the evidence and log retention that a major incident determination depends on.
Candidates memorise the reporting timelines but not the machinery behind them - how an incident is detected, logged, escalated, classified as major against the criteria, and evidenced. Exam scenarios probe exactly that machinery.
What to do instead
Build an incident playbook you can recite: detection sources and monitoring, logging and retention, severity and impact assessment, escalation path and decision-maker for the major-incident determination, the classification criteria (clients affected, duration, geographical spread, data losses, criticality of services, economic impact), and the reporting chain with its initial, intermediate and final stages. Know who decides, on what evidence, and how the decision is documented and revisited.
Getting the incident reporting mechanics wrong in detail - confusing which reports are mandatory, who submits to which authority, how the timelines are counted, or whether a report goes to clients as well as to the competent authority.
The reporting regime has several stages with different content and different addressees, and candidates learn the headlines rather than the sequence, so they mix up the initial notification with the intermediate and final reports and misstate the triggers and clocks.
What to do instead
Make a one-page timeline table: for each report, the trigger, the addressee (competent authority, and the voluntary or client-facing channels where relevant), the content, and the deadline measured from classification as major. Add the rules on significant cyber threats (voluntary notification) and on informing clients where the incident materially affects their financial interests. Rehearse with three worked scenarios of different severity and check your table against each.
Treating digital operational resilience testing as a single annual exercise, and failing to distinguish the baseline testing programme that every in-scope entity must run from the advanced, threat-led penetration testing that applies only to identified significant entities.
Candidates collapse the testing chapter into 'do penetration tests', missing the risk-based testing programme, the requirement for independence and validation of results, the treatment of findings, and the specific governance and scope conditions attached to threat-led testing including the use of external testers and the supervisory involvement.
What to do instead
Separate the two layers explicitly. Baseline: a documented, risk-based programme covering a range of assessments and tests, run by independent parties where required, with findings logged, prioritised, remediated and reported to the management body. Advanced: threat-led penetration testing with defined scope, intelligence-led scenarios, tester qualifications, a closed production environment where required, and a summary and attestation process. For each layer, know who approves, who executes, how findings are treated, and what is shared with the supervisor.
Approving or assessing an ICT third-party contract on commercial and service terms only, without checking it against the mandatory contractual clauses, the exit strategy, the subcontracting conditions and the concentration risk analysis.
Candidates answer contract questions from a procurement mindset and forget that DORA imposes a minimum content for ICT contracts, requires a documented exit strategy for critical arrangements, and requires oversight of subcontracting chains and concentration risk at entity level.
What to do instead
Keep a checklist of the mandatory contract elements (description of services, locations and data processing, availability and quality levels, access and audit rights, security and incident assistance, subcontracting conditions, termination and exit assistance, participation in testing where relevant). Apply it to a real or invented critical arrangement and mark each gap with the remediation route: renegotiate, add an addendum, or plan exit. Pair this with a concentration-risk view: how many critical services depend on the same provider or the same underlying infrastructure.
Treating review and continual improvement as a closing chapter - an annual policy refresh - rather than as a feedback loop fed by incident lessons, testing findings, threat intelligence, third-party performance and supervisory feedback, with defined metrics and management-body reporting.
Candidates prepare the first four domains in depth and skim the last, so they cannot describe how the framework actually evolves, how lessons learned are captured and verified, or how the management body knows the framework is working.
What to do instead
Design the loop explicitly: inputs (incident post-mortems, testing and threat-led testing findings, third-party monitoring and audit results, threat intelligence, supervisory observations, audit findings), a review cadence per artefact (framework, policies, register, testing plan, exit strategies), defined indicators reported to the management body, and a change-control process that tracks remediation to closure with evidence. Prepare one concrete example of a lesson learned from an incident or test that changed a control, and how you would prove the change was effective.