Description

A focused course, tailored for you

DORA ICT Risk Management for Bank Security Officers

Build the ICT risk register and governance artefacts that KNF examiners sign off on, not send back.

Your ICT risk register passes internal review and still comes back from the KNF examiner with the same annotation. The problem is not effort, it is knowing which specific artefacts a Polish banking supervisor expects to see, in what form, with what evidence trail behind them.

$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's ICT Risk Management Framework requirement (Article 6) is clear in principle and ambiguous in practice. The European Banking Authority technical standards define a structure. KNF applies that structure through supervisory expectations shaped by Polish banking law and the KNF Recommendation on ICT and IT Environment Security. A Security Officer at a banking subsidiary sits at the intersection of three layers: the group security policy from the parent entity, the EBA RTS on ICT risk management, and the KNF examiner's actual checklist. These three do not produce the same artefact. Group policy documents are too abstract for KNF. EBA templates are too generic. The result is a risk register that satisfies none of them fully, and the Security Officer is the person who has to reconcile all three before the next supervisory visit.

What you walk away with

Produce an ICT risk register that satisfies both EBA RTS structure and KNF supervisory expectations in a single document.
Build a threat scenario library anchored to the EBA TIBER-EU taxonomy and aligned to the specific asset categories KNF examiners check.
Draft a TLPT scope document that passes the pre-engagement review without a request for clarification.
Establish an ICT incident classification register with the severity matrix and escalation criteria KNF expects to see tested.
Create the governance trail that links risk identification, treatment decisions, and monitoring evidence into one reviewable package.
Reduce the ICT Risk Management Framework review cycle from multiple revision rounds to a first-pass approval.

The 12 modules

Module 1. The Three-Layer Conflict: Group Policy, EBA RTS, and KNF Expectations

This module maps the specific points where banking group security policies, EBA RTS on ICT risk management, and KNF supervisory guidance diverge. You identify which layer governs which artefact, where the conflicts are structural versus interpretive, and how to document your resolution rationale so the examiner can follow your logic without a separate explanation meeting. Output: a one-page policy hierarchy map you attach to the ICT Risk Management Framework document.

Module 2. ICT Risk Register Structure: What KNF Examiners Actually Check

KNF examination methodology for ICT risk reviews draws on the EBA Guidelines on ICT and Security Risk Management plus the KNF Recommendation on ICT Security. This module breaks down the exact register fields examiners annotate, the evidence they expect behind each risk entry, and the common gaps that trigger a return. You build the register template from those requirements rather than adapting a generic spreadsheet. Output: a populated register template with field-level annotation guide.

Module 3. Threat Scenario Library: TIBER-EU Taxonomy for Polish Banking Context

The EBA TIBER-EU framework defines threat intelligence categories used in TLPT and referenced in ICT risk assessments. This module maps those categories to the specific asset types a retail and corporate banking subsidiary holds, adds Polish-context threat actors identified in KNF sector risk reports, and produces a scenario library in the format examiners expect to see referenced in the risk register. Output: a 40-scenario threat library cross-referenced to asset categories and likelihood ratings.

Module 4. Risk Treatment Rationale: Writing Decisions the Examiner Can Follow

The annotation "risk treatment rationale not demonstrable" appears when the register records a treatment decision but not the evidence or logic behind it. This module covers the three-sentence rationale format KNF examiners look for, how to document accept versus mitigate versus transfer decisions with supporting evidence, and how to handle residual risk entries where the treatment is ongoing. Output: a rationale writing guide with worked examples for the ten most common ICT risk categories in banking.

Module 5. Ongoing Monitoring: Evidence That Satisfies "Insufficient Evidence of Monitoring"

The second most common return annotation is "insufficient evidence of ongoing monitoring". This module identifies what constitutes acceptable monitoring evidence under EBA guidelines: log retention references, vulnerability scan cadence documentation, control testing records, and the review sign-off trail. You build a monitoring evidence register that sits alongside the risk register and can be presented as a single package. Output: monitoring evidence register template with cadence table and sign-off workflow.

Module 6. DORA Article 6 Framework Document: From Policy to Examiner-Ready Artefact

DORA Article 6 requires a documented ICT Risk Management Framework. This module walks through the specific sections the EBA technical standards require, the KNF-specific additions that supervision experience shows examiners look for, and how to structure the document so the governance trail is visible from the first page. You produce a framework document that doubles as the submission to the group CISO and the artefact handed to the KNF examiner. Output: a complete Article 6 framework document in submission-ready format.

Module 7. TLPT Scope Document: Passing Pre-Engagement Review

Threat-led penetration testing under DORA requires a scope document that passes pre-engagement review by the test provider and, for significant institutions, by KNF. The common failure point is scope boundary definition: what is in, what is excluded, and why. This module covers the EBA TIBER-EU scope document structure, the exclusion rationale format KNF expects, and how to describe crown jewel functions in banking operations terms rather than IT architecture. Output: a TLPT scope document template with pre-engagement checklist.

Module 8. ICT Incident Classification Register: The Severity Matrix KNF Expects to Test

DORA Chapter III requires an ICT incident classification framework. KNF supervisory practice includes testing whether the severity matrix is operational, not only documented. This module builds the classification register with impact criteria matching EBA RTS on major ICT-related incidents, adds escalation criteria specific to Polish banking regulation, and produces a tabletop test scenario to verify the register before an examiner does. Output: a classification register with severity matrix, escalation criteria, and one tabletop test scenario.

Module 9. Third-Party ICT Risk: Vendor Register and Due Diligence Artefacts

DORA Chapter V addresses third-party ICT service providers. KNF examiners check whether the ICT risk register reflects third-party dependencies and whether the due diligence artefacts behind critical vendor relationships are accessible. This module covers the vendor register structure, the due diligence evidence chain, and how to document contractual ICT security requirements in a form that maps to the risk register entries. Output: a vendor ICT risk register template with due diligence evidence index.

Module 10. Governance Trail: Linking Risk Identification to Treatment to Review

The governance trail lets an examiner follow a single risk from identification through treatment decision through monitoring evidence to the most recent review sign-off. This module covers structuring the trail for examination navigation, handling risks open across multiple review cycles, and documenting risk owner accountability in a form that satisfies both the group CISO and the KNF examiner. Output: a governance trail index template with navigation guide.

Module 11. KNF Supervisory Visit: Preparing the Security Officer for the Examination Room

The examination visit is distinct from the document review. Examiners ask questions the register does not always answer, and the Security Officer has to speak to decisions made months earlier. This module covers KNF ICT examiner question types, how to prepare briefing notes that let you respond without reading back from the register, and how to handle the three most common follow-up requests without triggering a finding. Output: a preparation brief template with examiner question list and suggested response structure.

Module 12. Annual Review Cycle: Keeping the Register Current Without Starting Over

The ICT risk register must be reviewed at least annually under DORA, with review evidence visible in the artefact itself. This module covers the workflow that updates risk entries without losing the audit trail, how to document material changes in the threat landscape, and how to present the revised register to the KNF examiner as a maintained document rather than a new submission. Output: an annual review workflow with change log template and sign-off record.

How this addresses your situation

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

Risk register returned by KNF examiner with annotation: use modules 2, 4, 5, 10.

TLPT pre-engagement review failed: use module 7.

Group CISO and local compliance team disagree on framework document structure: use modules 1, 6.

Preparing for an upcoming KNF supervisory visit: use modules 11, 12.

What you get with this course

12 written modules, each producing a completed artefact rather than a framework concept.
Downloadable templates: ICT risk register, threat scenario library, TLPT scope document, incident classification register, vendor risk register, governance trail index, annual review workflow.
Hand-built implementation playbook tailored to a banking subsidiary Security Officer operating under KNF supervision and group CISO reporting.
Access in the Art of Service learning environment, available at your own pace.

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

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

Before and after

Before

The ICT risk register passes internal review and comes back from KNF with annotations. You redraft, re-circulate, and submit again. Each cycle costs three to four weeks and leaves the underlying artefact structure unchanged.

After

You submit a risk register with the governance trail, monitoring evidence, and treatment rationale in the form KNF examiners look for. The first-pass approval rate improves. The examination visit has a preparation brief behind it.

What happens if you do not address this

The next KNF supervisory visit will check the same artefacts. If the ICT risk register structure has not changed, the same annotations will come back. A repeated finding in the same area triggers an escalated supervisory response under KNF's ICT examination methodology.

Who it is for

Security Officers and IT Security Managers at commercial banks and financial institutions operating under KNF supervision who are responsible for DORA ICT Risk Management Framework implementation. Typically 5-12 years in security roles, carrying a personal signature on the ICT risk register, and accountable to both a group CISO and a local regulatory compliance team.

Who this is NOT for. IT engineers building technical controls. Consultants advising clients on DORA compliance. Security Officers at non-financial entities outside the DORA scope.

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 to complete in one focused session. The full course runs across 12 sessions. Most Security Officers work through the modules most relevant to their immediate examination priority first, then complete the remainder over the following weeks.

Why $199 is the right number

EBA and KNF publish guidance documents, but they describe requirements rather than produce artefacts. Consulting engagements address the same gap but at a cost that is 20 to 50 times higher and on a timeline set by the consultant's schedule. This course produces the artefacts in your own environment at your own pace.

FAQ

Does this course cover the KNF Recommendation on ICT Security specifically, or only DORA?

Both. The course maps the points where the KNF Recommendation and DORA requirements overlap and diverge, because a Security Officer under KNF supervision has to satisfy both simultaneously. Module 1 covers the mapping explicitly.

The templates are produced for a subsidiary of a large European banking group. Will they work for a standalone Polish bank?

Yes. The three-layer conflict module (group policy, EBA RTS, KNF expectations) is specific to subsidiary structures. Standalone banks skip the group layer and work directly from the EBA and KNF artefact requirements. The templates are designed for both cases.

How current is the DORA material?

The course covers the DORA Level 1 text, the EBA RTS and guidelines published under DORA, and KNF supervisory expectations as reflected in publicly available examination guidance. The implementation playbook includes a note on any open regulatory technical standards that are pending.

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.