IBITGQ C-DORA common mistakes
IBITGQ C-DORA · Understand the traps and how to avoid them.
Treating DORA as a pure IT-security standard and answering questions on confidentiality and data protection grounds, instead of framing answers around operational resilience of ICT-supported business services and continuity of critical or important functions.
Candidates arrive with ISO 27001 or GDPR habits and map DORA concepts onto CIA-triad or privacy logic, missing that DORA's regulatory objective is the ability to withstand, respond to and recover from ICT disruptions.
What to do instead
Before each scenario question, restate the objective in resilience terms: which business function, which impact tolerance, which recovery objective. Where an option is framed purely around data confidentiality or lawful processing, treat it as a distractor unless the question explicitly asks about personal data.
Confusing the roles of the management body and the ICT risk management function, for example saying the management body approves individual ICT risk decisions or that the risk function bears ultimate responsibility for ICT risk.
Overlap with general corporate-governance knowledge leads candidates to blur approval, oversight and execution. The management body's accountability, approval of the digital operational resilience strategy and tolerance for ICT risk are easy to mix with the second-line and third-line duties.
What to do instead
Build a three-column table: management body (defines and approves strategy and risk tolerance, oversees, is ultimately accountable, promotes use of ICT resources), ICT risk management function (implements the framework, monitors, reports), internal audit (independent assurance). Answer by locating the actor named in the stem before choosing the action.
Answering incident-reporting questions with generic breach-notification timing (for example 72 hours) or describing a single report, rather than the staged DORA sequence of initial notification, intermediate report and final report with their distinct content and purposes.
GDPR and NIS habits anchor strongly on 72 hours, and candidates do not separate the three reporting stages or recall which stage carries root-cause analysis and which carries the activation of business continuity plans.
What to do instead
Memorise the reporting chain as a timeline with content attached to each stage: initial notification (classification, whether the incident is major, impact, and whether continuity measures were activated), intermediate report (updated status, root cause where known), final report (full root cause, total impact, remedial actions). Practise sorting content items into the correct stage rather than only recalling deadlines.
Classifying incidents by gut feel rather than applying the major-incident criteria, or treating every disruption as reportable, or conversely missing that an incident affecting only internal systems can still be major if it hits critical services.
The criteria involve multiple dimensions (affected clients, transaction and downtime thresholds, geographical spread, economic impact, data losses, criticality of services) and candidates reduce them to a single dimension such as outage duration.
What to do instead
Work through the criteria as a checklist and state explicitly which dimensions the scenario triggers. Note that criteria are cumulative in the sense that not all must be met, and that classification is a documented, repeatable process owned by the entity, not a discretionary judgement.
Treating the resilience testing programme as an annual penetration test or vulnerability scan, and failing to distinguish the required advanced testing using threat-led penetration testing from other testing methods.
Candidates collapse all testing into security testing and do not separate the proportionate, risk-based testing programme applied to all ICT systems from the advanced, threat-led testing required for significant entities, including the role of the tester, scope and remediation.
What to do instead
Separate two layers: the ongoing risk-based testing programme (scenario-based, performance, recovery and continuity testing) and the advanced threat-led penetration test with its own governance, independence of testers and remediation follow-up. When a question mentions a significant entity or threat-led testing, look for answers about scope, tester independence and remediation plans, not scan frequency.
Misapplying the proportionality regime by assuming every entity has the same obligations, or misidentifying which entities are significant and therefore subject to the advanced testing and the oversight framework.
DORA differentiates obligations by size, risk profile and systemic importance, and the designation of significant entities follows a supervisory assessment. Candidates default to a single uniform obligation set.
What to do instead
Learn which obligations apply to all financial entities (ICT risk management framework, incident reporting, register of information, contractual requirements) and which attach to significant entities (advanced threat-led testing, direct oversight of critical ICT third-party providers). For each scenario, first decide the entity category, then apply obligations.
Treating third-party ICT risk as a procurement or legal-review exercise, answering with commercial due diligence and contract negotiation steps while ignoring the register of information, concentration risk and the exit strategy requirements.
Candidates rely on outsourcing experience and focus on contract clauses, overlooking that DORA requires a maintained register of all contractual arrangements with ICT third-party providers, ongoing monitoring, concentration-risk assessment and tested exit plans.
What to do instead
For any third-party question, run through the lifecycle: due diligence and selection, contractual provisions, register of information entry, ongoing monitoring and performance review, concentration-risk assessment, exit strategy and termination. Choose the option that names the specific artefact or control the question targets rather than generic contract management.
Confusing critical ICT third-party providers with ordinary material service providers, and attributing direct supervision or the ability to impose recommendations on any provider the entity deems important.
The critical designation is made by the European supervisory authorities through a designation process, and the oversight framework applies to those designated providers, not to every important vendor. Candidates transfer their own internal criticality label onto the regulatory regime.
What to do instead
Keep three labels distinct: the entity's own assessment of important or critical functions supported by a provider, the contractual requirements that apply to all ICT third-party providers, and the regulatory critical designation with its oversight consequences. Match the label in the stem to the correct consequence.
Answering questions about the register of information or contractual requirements with vague statements ('contracts must cover security') instead of the specific mandatory provisions such as service-level descriptions, data location, access and audit rights, termination and exit assistance, and participation in testing.
The contract provisions are numerous and similar-sounding, and candidates recall the general theme without the itemised content, so they pick plausible but incomplete options.
What to do instead
Memorise the mandatory contract content as a numbered list grouped by theme: description of services and locations, data protection and availability, access, recovery and return of data, service levels and monitoring, audit and access rights, exit and termination assistance, cooperation with authorities, and participation in resilience testing. Drill by eliminating options that omit a required element.
Ignoring the information-sharing and threat-intelligence dimension, or conversely treating cyber-threat information sharing as unconstrained, missing the conditions under which sharing is permitted and the notification duty toward authorities.
Candidates focus on the four main pillars and skip the provisions on exchanging cyber-threat information within trusted communities, so they either miss questions on it or answer as if any sharing is permitted.
What to do instead
Study the sharing arrangements as a distinct topic: sharing within trusted communities of financial entities, protection of shared information, the requirement to notify competent authorities of participation, and the fact that sharing does not by itself create liability or breach confidentiality when the conditions are respected. Include it in your revision checklist alongside the four pillars.