Description

A focused course, tailored for you

DORA ICT Risk: The Security Practitioner's Build

Build the ICT risk register, third-party tiering, and TLPT methodology a globally supervised bank actually has to submit.

A CISSP tells you how to think about ICT risk. DORA Article 28 tells you exactly what you have to produce: a complete register of third-party ICT providers, criticality tiering for every arrangement supporting a critical or important function, exit strategy documentation, and contractual clauses meeting Article 30 minimum requirements. The gap between the risk management methodology and the actual artefacts the competent authority will open is where most security practitioners stall.

$199 one-time

Tailored to your situation. Access within 24 hours. 30-day money-back.

Includes a hand-built implementation playbook delivered alongside course access, generated for your specific situation.

Why this course

DORA is enforceable across all EU-supervised financial entities. The competent authority is asking for the ICT risk management framework documentation, the third-party ICT register in Annex III field structure, the incident classification taxonomy mapped to DORA Annex I, and evidence that the DORA governance charter has board approval. Security professionals who hold CISSP are expected to lead this build. The problem is that the CISSP domains cover risk identification, asset management, and governance at a methodology level. DORA Annex III specifies the exact register fields. DORA Article 30 specifies the exact contractual clauses. DORA Annex I specifies the exact incident classification criteria. Translating the methodology into these specific artefacts is the work that gap analyses cannot substitute for, and the competent authority review cycle does not pause for functions still in planning mode.

What you walk away with

Produce the ICT third-party register in Annex III field structure with criticality tiering and exit strategy documentation for every arrangement supporting a critical or important function.
Build the contractual clause library covering Article 30 minimum requirements, including audit rights, sub-outsourcing controls, and termination provisions.
Map the institution's incident taxonomy to DORA Annex I major incident criteria and set the classification thresholds for the 4-hour, 24-hour, and 72-hour reporting cascade.
Document the DORA governance framework: ICT risk policy, committee charter, and the board reporting structure a competent authority examiner expects to see active.
Design and scope the digital operational resilience testing programme, including TLPT cycle preparation and the scope document the competent authority needs to approve.
Move the ICT risk function from gap analysis to a live compliance posture with a complete evidence pack ready for supervisory review.

The 12 modules

Module 1. DORA's Artefact Model vs the CISSP Framework

The CISSP CBK and DORA share vocabulary but diverge sharply on deliverables. This module maps each DORA Article 5 through 16 obligation to the closest CISSP domain equivalent, then identifies where DORA requires a specific documented artefact the CISSP methodology does not produce. You finish with a gap inventory for your function ranked by examiner priority, so the first artefacts you build are the ones the competent authority asks for in the opening session.

Module 2. Building the ICT Asset Register under Article 8

DORA Article 8 requires a register of information systems and ICT assets supporting business functions. This module covers the asset taxonomy, ownership fields, classification tiers from critical to non-critical, and the relationship between the asset register and the risk register. You build the register schema and the data collection procedure so the register is audit-ready from the first day of the competent authority review, not assembled under pressure the week before.

Module 3. ICT Risk Identification and Assessment under Article 6

DORA Article 6 requires continuous risk identification, not an annual cycle. This module covers the risk register structure that satisfies Article 6: risk taxonomy specific to financial services ICT, likelihood and impact scales calibrated to regulatory materiality thresholds, and escalation criteria that trigger management reporting. You produce the risk register template and the assessment cadence procedure that satisfies both the CISSP risk management domain and DORA's continuous monitoring requirement.

Module 4. ICT Business Continuity and DORA Article 11 Requirements

DORA Article 11 sets specific requirements for ICT business continuity planning that extend beyond standard BCP practice. This module covers the documentation requirements unique to DORA: RTO and RPO targets by asset criticality tier, the business impact analysis scope that satisfies Article 11, and the testing evidence the competent authority expects in the review pack. You produce the ICT continuity policy structure and the test result documentation template.

Module 5. Third-Party Register: Structure and Annex III Fields

DORA Article 28 and Annex III define the minimum information set for the ICT third-party service provider register. This module walks through every Annex III field, what each one means in practice, the common errors institutions make when sourcing data for large vendor populations, and how to structure the register for a group with hundreds of ICT third-party relationships across multiple entities. You finish with the complete register schema and a data collection process designed for scale.

Module 6. Criticality Tiering and Concentration Risk Methodology

DORA requires identification of third-party providers supporting critical or important functions. This module covers the tiering methodology: criteria for critical function determination, how to apply concentration risk analysis across the full vendor population, how to handle multi-vendor dependency chains where failure of one provider cascades across functions, and how to document the tiering rationale in a form that survives competent authority scrutiny. You produce the tiering scorecard and the concentration risk mapping template.

Module 7. Article 30 Contractual Clauses: Building the Clause Library

DORA Article 30 sets minimum contractual requirements for ICT third-party arrangements supporting critical or important functions. This module covers each Article 30 clause, how to draft the audit rights provision, the sub-outsourcing controls, the termination and exit plan requirement, and how to negotiate with major cloud and SaaS vendors who push back on non-standard terms. You produce a reusable clause library and a negotiation escalation procedure for contracts that do not meet the minimum standard.

Module 8. Incident Classification: Mapping the Taxonomy to Annex I

DORA Annex I defines six criteria for major ICT-related incident classification. This module walks through each criterion, how to set the internal threshold for each one, how borderline incidents are resolved when multiple criteria apply, and how to structure the classification committee process so decisions are defensible in a regulatory inquiry. You produce the classification matrix, the internal threshold register, and the escalation procedure that triggers the 4-hour initial notification to the competent authority.

Module 9. Regulatory Incident Reporting: The 4-Hour, 24-Hour, 72-Hour Cascade

DORA sets strict content requirements for each stage of the reporting cascade. This module covers what must be in the initial notification, the intermediate report, and the final report, how to structure the internal data collection process so the 4-hour deadline is met under operational stress, what financial entities most commonly omit from the templates, and how cross-border reporting works when the incident affects entities in multiple EU jurisdictions. You produce the reporting procedure and the complete template set.

Module 10. Digital Operational Resilience Testing: Programme Design

DORA Article 24 requires a digital operational resilience testing programme covering a range from basic vulnerability assessment to advanced threat-led testing. This module covers how to define the scope of the basic testing programme, select the test types by asset criticality, document the testing evidence the competent authority expects, and structure the remediation tracking process so test findings are closed loop. You produce the DOST programme design and the remediation tracking template.

Module 11. TLPT: Scoping, Authority Coordination, and Remediation Structure

Threat-Led Penetration Testing under DORA Article 26 follows the TIBER-EU framework and requires the competent authority to approve the scope before testing begins. This module covers the TLPT scoping methodology, how to define the scope narrative the authority accepts, how to run the threat intelligence phase, how to brief and manage the red team provider, and how to structure the remediation plan that must be submitted to the authority after testing. You produce the scope document template and the TLPT governance procedure.

Module 12. DORA Governance Framework and Examination Readiness

A complete DORA ICT risk function requires a governance layer: the ICT risk policy signed at board level, the committee charter, the management reporting pack, and the oversight committee minutes that demonstrate active governance is in place. This module covers how to structure each governance document, what the competent authority examiner asks for in the first session of an on-site review, and how to assemble the evidence pack. You finish with the documentation checklist and the examination preparation guide.

How this addresses your situation

Specific modules that map to what you said you are dealing with.

A competent authority review is scheduled next quarter and the ICT risk function does not have a complete evidence pack. Modules 1, 2, 3, and 12 close the highest-priority gaps first.

The third-party ICT register exists but criticality tiering is based on spend or contractual value rather than function criticality. Modules 5 and 6 rebuild the tiering methodology and produce an Annex III-compliant register.

A major ICT incident was not reported to the competent authority because the internal classification process could not reach a decision within the reporting window. Modules 8 and 9 build the classification matrix and the reporting cascade.

The institution has not yet scoped its first TLPT cycle and the competent authority has asked for a proposed timeline. Modules 10 and 11 design the testing programme and prepare the scope document for authority submission.

What you get with this course

12 written modules covering every DORA ICT risk artefact from the Article 8 asset register to the TLPT scope document
Downloadable ICT third-party register schema in Annex III field structure with data collection guidance
Criticality tiering scorecard with concentration risk mapping template
Article 30 contractual clause library with negotiation guidance for large vendor pushback
Incident classification matrix mapped to DORA Annex I criteria with internal threshold register
Regulatory reporting templates for the 4-hour initial notification, 24-hour intermediate report, and 72-hour final report
DORA governance documentation checklist and examination preparation guide
Hand-built implementation playbook tailored to the specific ICT risk function

What you will have in hand by Day 1, Week 1, Month 1

Course access provisioned within 24 hours of purchase, hand-built implementation playbook delivered alongside it.

Before and after

Before

The ICT risk function holds CISSP-calibre methodology and a set of gap analyses. The competent authority review is approaching. The actual artefacts are not yet complete: the Annex III register, the Article 30 clause library, the Annex I classification matrix, and the governance pack.

After

The function holds a complete DORA evidence pack: an Annex III-structured third-party register with documented criticality tiering, an Article 30 clause library, an Annex I incident classification matrix with set thresholds, a governance charter with board sign-off, and a TLPT programme ready for authority submission.

What happens if you do not address this

Competent authority review cycles proceed on their own calendar. An ICT risk function that arrives at a supervisory review with gap analyses and an incomplete third-party register is the pattern that generates formal supervisory findings and remediation timelines measured in quarters. The workload of responding to a formal finding is significantly higher than completing the artefact build before the review arrives.

Who it is for

Information security professionals at globally supervised financial institutions who hold CISSP and are the named owner of the DORA ICT risk compliance programme. Likely titled ICT Risk Manager, Head of Operational Resilience, CISO, or equivalent. Has strong risk methodology grounding but is encountering DORA's specific artefact requirements ahead of a competent authority review or internal audit cycle.

Who this is NOT for. Security practitioners already two DORA review cycles in with a live register, a complete clause library, and a running TLPT programme. Compliance officers whose scope is governance documentation rather than the ICT risk function build. Security engineers whose role is technical control implementation rather than the risk management framework.

How it arrives

Text-based course in the Art of Service learning environment, plus downloadable templates and worked examples for every module, plus the hand-built implementation playbook delivered alongside course access.

Time investment. Each module is designed for a single focused session. The full course takes 8 to 12 hours of reading and template work. Most practitioners complete the artefact build in parallel with the course over three to four weeks.

Why $199 is the right number

External consultants can build a DORA ICT risk framework, typically at a five-to-six-figure engagement cost with a delivery timeline that may not align with the supervision calendar. The EBA guidelines and DORA regulatory technical standards are publicly available but require significant interpretation to translate into a working register and clause library. This course provides the interpretation completed, the templates built, and the playbook tailored to the specific function.

FAQ

I hold CISSP. Will this cover material I already know?

Module 1 is structured as a mapping exercise between CISSP domains and DORA artefact requirements, so CISSP holders move through it quickly. Modules 2 and 3 overlap with CISSP asset management and risk methodology and are also faster for certified practitioners. The majority of the course covers DORA-specific artefacts, Annex field structures, and regulatory interpretation that have no direct CISSP equivalent.

Is the register schema designed for a bank with multiple legal entities across several jurisdictions?

Yes. The register schema in Module 5 includes group-entity fields, and Module 6 covers concentration risk methodology at a group level. Module 9 covers the cross-border incident reporting requirements when the same incident affects entities in multiple EU jurisdictions.

What if our TLPT cycle has not yet been agreed with the competent authority?

Module 10 covers the programme design phase that precedes the TLPT scoping conversation with the authority. Module 11 covers the scoping methodology and scope document that must be submitted for authority approval. The course is designed for practitioners preparing for the first TLPT cycle, not those already mid-test.

30-day money-back guarantee. If after a week of working through the materials this is not what you needed, reply to the receipt email and a full refund is processed. No questions, no forms.

Within 24 hours your account in the learning environment is provisioned and the tailored implementation playbook is delivered alongside it.