Conducting ICT Risk Audits Under DORA for Banking

Description

What is the Conducting ICT Risk Audits Under DORA course about?

Build the audit methodology that satisfies your CAE, your external auditors, and the ECB in a single workpaper trail. ICT risk control tests at regulated banks frequently document what was tested without demonstrating whether the control is effective or who owns it. The CAE sends reports back. Regulators ask questions the workpapers cannot answer without a verbal walkthrough. The audit committee receives.

Why this course?

What do you take away from the Conducting ICT Risk Audits Under DORA course?

Design ICT risk control tests that produce evidence an ECB or ACPR examiner accepts as complete without requesting additional documentation. Build a control attribute matrix that maps each DORA RTS requirement to a testable control and a named accountable owner. Write findings that survive multiple internal review cycles and retain their substance in the audit committee pack. Construct a workpaper trail so.

What you get with this course?

12 written modules in the Art of Service learning environment, accessible on enrolment Control attribute matrix template populated for a representative banking ICT environment, ready to adapt for the first audit cycle Workpaper trail template covering index structure, cross-reference guide, and review sign-off format Three-tier ownership attestation format ready for fieldwork use DORA RTS-to-testable-control mapping workbook Downloadable templates and worked examples for.

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

Access to all 12 modules and downloadable templates on enrolment day. Hand-built implementation playbook delivered alongside course access within 24 hours.

What does the Conducting ICT Risk Audits Under DORA cover on before and after?

ICT risk audit workpapers document what was tested without demonstrating control effectiveness or ownership. Reports go back for internal revision. Regulators ask follow-up questions that require verbal reconstruction of the evidence trail. Each ICT risk audit cycle produces a workpaper trail that maps from DORA RTS requirement to control to evidence to finding, with ownership documented at every tier. Reports satisfy CAE.

What happens if you do not address this?

The next ACPR or ECB supervisory review of ICT risk will examine the internal audit function's methodology, not just the ICT function's controls. If the workpapers from prior cycles do not demonstrate effective testing methodology and ownership documentation at the required standard, the finding lands on the audit function itself.

Who it is for?

Internal auditors at regulated banks who now carry ICT risk in their annual audit plan. The senior auditor who can write a financial crime or credit risk finding in an hour but who sat in an ICT risk audit fieldwork session last cycle and realised the testing approach, the evidence standard, and the findings structure are different in ways that were not.

More answers: what you get with every course, refund policy, all help answers.

A focused course, tailored for you

Conducting ICT Risk Audits Under DORA for Banking

Build the audit methodology that satisfies your CAE, your external auditors, and the ECB in a single workpaper trail.

ICT risk control tests at regulated banks frequently document what was tested without demonstrating whether the control is effective or who owns it. The CAE sends reports back. Regulators ask questions the workpapers cannot answer without a verbal walkthrough. The audit committee receives assurance it cannot verify.

$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

Banking internal audit is facing a methodology gap that DORA made visible. Before DORA, ICT risk audits were often conducted by technology specialists using IT audit methodology, delegated to external parties, or bundled inside operational risk programmes. DORA made ICT risk a standalone regulatory obligation with its own testing and documentation standards. Most banking internal auditors who now carry ICT risk audits were trained in credit risk, financial crime, or treasury audit, and their methodology does not translate cleanly. The consequence: workpapers that describe controls rather than test them, findings without the ownership attribution DORA requires, and report structures that satisfy the audit team but not the ACPR or ECB examiner reading the same document.

What you walk away with

Design ICT risk control tests that produce evidence an ECB or ACPR examiner accepts as complete without requesting additional documentation.
Build a control attribute matrix that maps each DORA RTS requirement to a testable control and a named accountable owner.
Write findings that survive multiple internal review cycles and retain their substance in the audit committee pack.
Construct a workpaper trail so the evidence chain from control test to final report requires no reconstruction during examination.
Conduct a DORA-compliant ICT risk audit from planning through report without importing methodology from another audit domain.

The 12 modules

Module 1. The ICT Risk Audit Universe: How DORA Changes What Banking Internal Audit Must Cover

Banking audit plans before DORA treated ICT risk as a subset of operational risk, often delegated to IT specialists or bundled with technology change audits. DORA defined ICT risk as a standalone regulatory obligation with its own testing standards and board-level reporting requirements. This module maps the DORA scope against a typical banking audit universe, identifies which existing audit objectives transfer and which need rebuilding, and shows how to construct an annual ICT risk audit plan that satisfies supervisory expectations without duplicating second-line work.

Module 2. Control Design vs Control Testing: The Evidence Standard DORA RTS Requires

Most ICT control testing documentation shows what the control is designed to do. DORA RTS Article 9 requires evidence that the control actually functions, that someone owns it, and that the effectiveness conclusion is auditor-defensible. This module builds the conceptual framework for evidence-grade ICT control testing, distinguishes design adequacy from operating effectiveness in a banking ICT context, and establishes the documentation standard that prevents examiner follow-up questions after the report is submitted.

Module 3. The Control Attribute Matrix: Mapping DORA RTS to Testable Controls and Named Owners

The control attribute matrix is the foundational workpaper for ICT risk audit under DORA. It maps each relevant RTS requirement to a discrete control, names the function and individual accountable for it, and records the testing objective before fieldwork begins. This module builds a working template for a representative banking ICT environment, shows how to populate it during audit planning, and explains how the matrix becomes the spine of the audit report without being reproduced in full as an appendix.

Module 4. ICT Risk Fieldwork Design: What to Test, How to Test It, and What Constitutes Sufficient Evidence

Fieldwork design for ICT risk differs from financial control testing because the evidence is often system-generated logs, configuration exports, and vendor attestations rather than transaction records and reconciliations. This module covers how to select and scope fieldwork for DORA's five ICT risk categories, how to evaluate log and configuration evidence against the testing objective, how to treat third-party and managed-service evidence, and what constitutes a complete population versus an acceptable representative sample for each control type.

Module 5. Three-Tier Ownership Attestation: Building the Accountability Chain from Desk to Board

DORA requires that ICT risk ownership is documented to the management body level. In most banks, operational ownership is clear but management and senior management-level ownership is informal and holds operationally until an examiner asks for documentation. This module builds a three-tier attestation format covering operational owner, management owner, and senior management confirmation, shows how to gather it during fieldwork without creating resistance, and explains how it must appear in both the workpapers and the final report.

Module 6. Findings That Hold: Writing ICT Risk Observations That Survive CAE Review and Examiner Scrutiny

ICT risk findings fail internal review for two reasons: they describe a gap without naming the specific control that failed, or they name the control without stating what the evidence showed. This module covers the four-component finding structure applied to ICT risk situations, shows how to anchor each component to the control attribute matrix and the relevant DORA RTS article, and demonstrates the practical difference between a finding an audit committee trusts and one that generates a clarification request from the CAE or an ECB examiner.

Module 7. EBA Guidelines and ECB Supervisory Expectations: What the External Reader Wants to See

The ICT risk audit report will be read by the CAE, the audit committee, and potentially EBA or ECB examiners. Each reader has a different primary question: the audit committee wants assurance, the ECB examiner wants methodology traceability. This module maps what each reader is looking for, shows how a single findings and workpaper structure can satisfy all audiences without producing multiple versions, and covers how EBA GL 2019/04 on ICT and security risk management intersects with DORA audit obligations.

Module 8. ACPR and National Regulator Expectations: The Local Layer on Top of DORA

For banks operating under ACPR supervision, the ICT risk audit framework carries a second layer of expectation on top of DORA. ACPR has published supervisory priorities specifically addressing ICT risk for French-domiciled institutions. This module covers how to read and apply ACPR expectations, how to structure audit scope so the annual plan addresses both DORA and ACPR priorities without duplicating coverage, and what ACPR supervisory reviews have flagged at peer institutions when ICT audit methodology was found insufficient.

Module 9. Third-Party and Outsourcing Audit: Testing ICT Risk in Managed and Cloud Environments

A material portion of banking ICT risk sits outside the bank, in managed service providers, cloud platforms, and critical third-party technology vendors. DORA created explicit requirements for third-party ICT risk management that the internal audit function must now test and report on. This module covers how to design third-party ICT risk audit procedures, how to evaluate vendor SOC 2 and ISO 27001 reports as audit evidence, and how to document residual risk when direct access to the vendor environment is not possible.

Module 10. The Workpaper Trail: Building the Chain of Evidence from Control Test to Audit Report

The most common reason ICT risk audit reports fail examination is that the reader cannot trace from the final report through the findings back to the workpapers and the original control tests. This module builds the workpaper trail as a structured artefact: the workpaper index, cross-referencing discipline, naming conventions, and review sign-off procedures that allow any reader to follow the chain of evidence from DORA RTS requirement to testing conclusion without a verbal walkthrough from the audit team.

Module 11. ICT Risk Audit Report Structure: What Belongs In and What Stays Out

ICT risk audit reports typically fail one of two audiences: they over-describe the technical environment, relevant only to IT teams, or they under-explain the control deficiency, insufficient for regulatory purposes. This module covers the report structure that serves both audiences, what belongs in the executive summary versus the detailed findings section, how to position management responses to ICT findings, and how to write an audit conclusion that is defensible without being hedged past usefulness for the audit committee.

Module 12. Audit Universe Refresh and Annual Plan Cycle Under DORA's Ongoing Requirements

DORA is not a one-cycle obligation. The ICT risk audit universe must be refreshed as the bank's ICT environment changes, as DORA RTS and EBA guidance evolves, and as supervisory priorities shift between examination cycles. This module covers the methodology for annual audit universe refresh, how prior-cycle findings inform the next planning period, how to handle mid-year scope changes triggered by ECB or ACPR supervisory activity, and how to report ICT audit coverage to the audit committee across the full annual cycle.

How this addresses your situation

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

ICT risk has entered the annual audit plan for the first time because DORA is now in scope and the team has no existing methodology to adapt from prior cycles.

The previous ICT audit cycle produced findings that the CAE, external auditors, or supervisors asked follow-up questions about, indicating the workpaper evidence standard was not sufficient.

The audit committee or board has asked for explicit confirmation that the ICT risk audit approach meets DORA requirements, not just the pre-DORA operational risk audit standard.

A cloud migration, outsourcing restructure, or acquisition has materially changed the ICT risk profile and the prior audit methodology no longer maps cleanly to the current environment.

What you get with this course

12 written modules in the Art of Service learning environment, accessible on enrolment
Control attribute matrix template populated for a representative banking ICT environment, ready to adapt for the first audit cycle
Workpaper trail template covering index structure, cross-reference guide, and review sign-off format
Three-tier ownership attestation format ready for fieldwork use
DORA RTS-to-testable-control mapping workbook
Downloadable templates and worked examples for every module
Hand-built implementation playbook delivered alongside course access
30-day money-back guarantee

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

Access to all 12 modules and downloadable templates on enrolment day.

Hand-built implementation playbook delivered alongside course access within 24 hours.

Before and after

Before

After

Each ICT risk audit cycle produces a workpaper trail that maps from DORA RTS requirement to control to evidence to finding, with ownership documented at every tier. Reports satisfy CAE review and ECB examination without additional explanation.

What happens if you do not address this

Who it is for

Who this is NOT for. Technology risk and compliance teams looking for a DORA implementation checklist; IT security teams preparing to pass an audit rather than conduct one; internal auditors who do not carry ICT risk in their audit universe; and teams looking for a high-level DORA overview rather than a working audit methodology.

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. Five to seven hours across the 12 modules. Templates are ready to apply in the first fieldwork cycle after completion.

Why $199 is the right number

IIA training on technology audit covers general methodology but does not address DORA's specific ICT risk requirements for EU-regulated banks. Big4 advisory on DORA implementation covers the second-line compliance function, not the testing methodology the internal audit function needs to conduct, document, and report. This course covers the intersection: how a banking internal auditor conducts, evidences, and reports an ICT risk audit that satisfies both internal quality standards and supervisory examination.

FAQ

Does this course require a technology background?

No. The course is designed for banking internal auditors who carry ICT risk in their audit universe and understand banking regulation but do not come from a technology specialty. The methodology translates banking audit rigour into ICT risk testing, not the other way around.

Is this specific to DORA or does it cover other ICT risk frameworks?

The methodology is built around DORA and EBA GL requirements as the primary framework for EU-regulated banks. The workpaper and findings structures are transferable to other frameworks, but the examples and regulatory anchors throughout the course are DORA and EBA-specific.

What is the implementation playbook?

A hand-built document delivered within 24 hours of enrolment, specific to your role and institution type. It covers the ICT risk audit planning cycle, the key artefacts for your audit universe, and a sequenced action plan for the first three months after completing the course.

Is there a refund policy?

Yes. 30-day money-back guarantee if the course does not deliver what is described.

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.