PECB DORA Foundation common mistakes
PECB DORA Foundation · Understand the traps and how to avoid them.
Treating DORA as a cybersecurity or information-security standard and answering questions about confidentiality, access control, and malware defence as if they were the core of the regulation, instead of framing answers around ICT risk to operational resilience and continuity of critical or important functions.
Candidates arrive from ISO/IEC 27001, NIST CSF, or CISSP backgrounds where CIA-triad language dominates, and DORA's own wording overlaps heavily with security vocabulary, so the resilience lens (ability to withstand, absorb, recover from disruption) is never consciously applied.
What to do instead
Before answering, restate the question in resilience terms: which critical or important function is affected, can the entity keep operating, and how fast can it recover? Practise mapping each topic (patch management, encryption, logging) back to the disruption scenario it mitigates, and drop answers that only address secrecy of data.
Confusing the proportionality principle with a blanket exemption, concluding that small or non-systemically important entities are 'out of scope' for a requirement rather than applying a simplified but still binding version of it.
Proportionality is repeatedly mentioned in DORA, and candidates read it as a sliding scale that can reduce obligations to zero, especially for the ICT risk management framework and the register of information.
What to do instead
Learn the distinction between scope (which entities DORA covers, including small and non-interconnected investment firms) and proportionality (how requirements are calibrated to size, risk profile, and complexity). Remember that the ICT risk management framework, register of information, and incident classification apply to all in-scope entities; only specific items such as certain advanced testing or dedicated reporting obligations are simplified.
Assuming the management body can delegate ICT risk responsibility to the CISO, CIO, or an ICT committee, and selecting answers where accountability sits with a senior manager rather than the management body.
In many organisations day-to-day ICT risk ownership sits with technology leadership, and candidates project that operating model onto the regulation, missing that DORA places ultimate responsibility and accountability on the management body itself.
What to do instead
Memorise the management body's non-delegable role: defining and approving the digital operational resilience strategy and the ICT risk management framework, setting risk tolerance, approving and reviewing the business continuity and incident response policies, allocating budget, and being accountable for ICT risk oversight. Answers that move final accountability away from the management body are almost always wrong.
Confusing the three-tier incident reporting timeline, for example stating that the initial notification is due within 24 hours and the final report within one month, or swapping the intermediate and final deadlines.
The deadlines are close together and easily mixed up, and the clock start (classification of the incident as major, not first detection) is often overlooked, so candidates guess at plausible-sounding intervals.
What to do instead
Anchor the sequence: initial notification within four hours of classifying the incident as major and no later than 24 hours from detection; intermediate report within 72 hours of the initial notification; final report within one month of the initial notification. Also learn that the initial notification may be based on preliminary information and that the entity must inform clients where the incident affects their interests.
Treating the register of information as an optional internal inventory and answering that it only needs to cover direct contractual counterparties, rather than the full chain of ICT third-party service providers including subcontractors supporting critical or important functions.
Candidates skim the third-party section and assume a standard vendor list suffices, missing the regulatory technical standard requirement for a structured, hierarchically linked register reported to competent authorities.
What to do instead
Study the register as a formal deliverable: it records all contractual arrangements with ICT third-party service providers, identifies which support critical or important functions, captures the chain of subcontracting for those arrangements, and is reported to the competent authority at least annually and on request. Practise distinguishing providers of ICT services from general suppliers such as utilities or insurance.
Mixing up the roles of the ICT risk management framework, the business continuity policy, the disaster recovery plan, and the ICT incident response plan, and choosing a document that does not match the scenario described in the question stem.
The documents overlap in content and are described in adjacent articles, so candidates pattern-match on keywords such as 'continuity' or 'recovery' without checking which artefact the question is actually asking about.
What to do instead
Build a one-line definition for each: the ICT risk management framework is the overarching governance and control system; the business continuity policy sets objectives and arrangements for protecting critical or important functions; the disaster recovery plan covers restoration of ICT systems and data after disruption; the incident response plan covers detection, management, and notification of ICT incidents. Read the stem for the trigger (disruption of service versus occurrence of an incident) before selecting.
Answering that the ICT risk management framework must be reviewed only when a significant change occurs or only annually, instead of recognising the periodic review requirement together with review after significant incidents or supervisory instruction.
Candidates remember the 'at least annually' rule from other frameworks and treat it as the sole trigger, ignoring the additional event-driven triggers DORA specifies.
What to do instead
Learn the combined rule: review at least once a year, and additionally after significant ICT-related incidents, after material changes to the operating environment or risk profile, and following supervisory findings or instructions. When a question offers both a periodic and an event-driven option, identify whether the stem describes a triggering event before choosing.
Classifying every ICT incident as reportable, or conversely treating only incidents with a direct financial loss as major, rather than applying the classification criteria covering clients affected, duration, geographical spread, data losses, and criticality of services.
Candidates either over-apply reporting to avoid missing something or under-apply because they rely on intuition about severity, and the classification criteria are easy to reduce to a single dimension such as downtime.
What to do instead
Learn that reporting applies to major ICT-related incidents, and that classification weighs several criteria including the number of clients affected and whether they are in another jurisdiction, the duration and service downtime, the geographical spread, the economic impact, and the impact on critical or important functions. Practise deciding 'major or not' on short scenarios and justify the decision against at least two criteria.
Confusing the threat-led penetration testing regime with the general vulnerability assessment and scanning obligations, and answering that all entities must perform TLPT annually or that TLPT is the same as an internal penetration test.
Both sit under the ICT risk management framework, and candidates merge the continuous testing programme with the advanced, supervisory-driven testing regime, missing that TLPT applies only to entities identified by authorities and follows a specific methodology with a threat intelligence phase.
What to do instead
Separate the two: all entities must run a documented, risk-based testing programme including vulnerability assessments and scans at defined frequencies; TLPT is an advanced, intelligence-led test of critical or important functions, performed at least every three years by entities identified by the competent authority, and it is not a substitute for routine testing.
Answering that contractual arrangements with ICT third-party providers need only commercial terms, and missing the mandatory contractual clauses such as service level descriptions, audit and access rights, exit strategies, and cooperation with competent authorities.
Candidates treat third-party risk as procurement practice and assume standard vendor contracts are sufficient, so they fail to recall the specific clause set the regulation prescribes for ICT service arrangements, especially those supporting critical or important functions.
What to do instead
Memorise the required contract elements as a checklist: clear description of services, locations of data processing, service levels, availability and reliability provisions, data protection and access rights, audit and inspection rights for the entity and authorities, incident notification timelines, termination and exit strategy support, and participation in TLPT where relevant. When a question asks which clause is mandatory, look for audit rights, exit strategy, and authority cooperation.