Module 11: Operating Model and Control Design for Ongoing Compliance

Step 1 – From ‘Project DORA’ to ‘Business‑as‑Usual DORA’

DORA (Regulation (EU) 2022/2554) has applied since 17 January 2025. By today (December 2025), the focus for EU financial entities is no longer just implementation but operationalisation:

• Moving from a one‑off compliance project to a steady‑state operating model
• Ensuring DORA requirements are embedded into ICT, security, risk, procurement, and business operations
• Designing controls, documentation, and assurance that can withstand ongoing supervisory scrutiny, thematic reviews, and incident‑driven inspections

In this module you will design, at a conceptual level, an operating model for ongoing DORA compliance. You should connect this to:

• Module 9 – penalties and supervisory expectations: your operating model must reduce the risk of enforcement, especially for material ICT incidents or third‑party failures.
• Module 10 – implementation roadmap: you now assume the roadmap is largely executed, and you are designing the “run” state, not the “build” phase.

We will structure the module around three recurring questions for every DORA area (ICT risk, incident management, testing, third‑party oversight, etc.):

1. Who is responsible, accountable, consulted, and informed (RACI)?
2. What controls and artefacts demonstrate compliance on an ongoing basis?
3. How are these controls tested, evidenced, and improved over time?

Keep in mind throughout: DORA is principles‑based in many areas. There is no single correct operating model, but there are patterns supervisors expect to see, especially in larger institutions.

> Thought anchor: Imagine you are the supervisor visiting a mid‑size EU bank in late 2025. What would convince you that DORA is genuinely embedded, not just documented on paper?

Step 2 – Designing a DORA Operating Model: Core Building Blocks

A robust DORA operating model can be decomposed into six building blocks. Visualise this as a layered diagram:

1. Governance & Accountability (Top layer)

• Board oversight, management body roles, ICT risk committee, third‑party risk committee, etc.
• Clear allocation of responsibilities under DORA Articles 4–6.

1. Risk & Control Framework (Design layer)

• ICT risk taxonomy aligned with DORA (availability, integrity, confidentiality, authenticity, continuity).
• Control objectives mapped to DORA Articles and RTS/ITS (e.g., incident management, testing, third‑party oversight).

1. Processes & Procedures (Execution layer)

• BAU processes for change management, incident handling, vulnerability management, outsourcing, etc.
• Each process has embedded DORA control points.

1. Data, Documentation & Evidence (Records layer)

• Policies, standards, runbooks, contracts, logs, tickets, test reports, risk assessments.
• Structured so that evidence can be retrieved quickly for audits and supervisors.

1. Assurance & Monitoring (Challenge layer)

• First‑line control testing, second‑line compliance/ICT‑risk monitoring, third‑line internal audit.
• Key risk indicators (KRIs), key performance indicators (KPIs), and dashboards.

1. Continuous Improvement (Feedback layer)

• Lessons learned from incidents, test results, audit findings, and supervisory feedback.
• Formal mechanisms to update controls, policies, and training.

In the next steps, you will:

• Map DORA requirements into this structure
• Define control examples for ICT risk, incidents, testing, and third‑party risk
• Design assurance activities across the three lines of defense

> Mini‑task: Sketch this 6‑layer model on paper and write one concrete artefact you would expect to see in each layer (e.g., for the Records layer: central DORA evidence register).

Step 3 – Embedding DORA into BAU ICT & Security Processes

To move from theory to practice, consider how DORA requirements are embedded into everyday ICT and security processes. Below is a structured example.

1. ICT Risk Management Process

Objective: Ensure ICT risks are identified, assessed, treated, and monitored in line with DORA Articles 5, 6, 8–10.

BAU process elements:

• Quarterly ICT risk assessments per critical business service
• Risk acceptance and exception process
• Integration with enterprise risk management (ERM)

Embedded DORA controls (examples):

• Control D‑R1: All ICT risks affecting DORA‑critical functions are logged in the central risk register with explicit mapping to DORA impact dimensions (availability, integrity, confidentiality, etc.).
• Control D‑R2: Risk treatment decisions for high and critical ICT risks require approval by a management body delegate with DORA accountability.
• Control D‑R3: Risk acceptance above a defined threshold must be time‑bound and reported to the risk committee with justification referencing DORA obligations.

2. Change & Release Management

Objective: Ensure changes do not jeopardize digital operational resilience.

Embedded DORA controls:

• Control D‑C1: All changes affecting critical or important functions must include an ICT risk impact assessment referencing DORA‑critical services and recovery objectives.
• Control D‑C2: Emergency changes are retrospectively reviewed within 5 working days for DORA impact and logged for potential inclusion in incident trend analysis.

3. Identity & Access Management (IAM)

Objective: Protect confidentiality and integrity of data and systems.

Embedded DORA controls:

• Control D‑I1: Access to systems supporting critical or important functions is granted based on role‑based access control (RBAC) with documented approval from the business owner and ICT security.
• Control D‑I2: Quarterly access recertification is performed for all privileged accounts and documented for audit.

> Reflection: For one process in your own experience (e.g., change management, vendor onboarding), write down two concrete DORA‑aligned controls you would embed. Make them specific enough that they could be tested by an auditor.

Step 4 – Designing a Control: A Structured Template Exercise

Strong DORA controls are precise, testable, and owned. Use the following template mentally (or write it out) and complete it for a control you would design.

Control Design Template (Conceptual)

Control ID: D‑INC‑01

Area: ICT Incident Management (DORA Articles 17–23)

Objective: Ensure timely detection, classification, and reporting of major ICT‑related incidents.

Control statement (example):

> All ICT incidents affecting systems that support critical or important functions are classified within 4 hours of detection according to the DORA incident taxonomy and, where thresholds are met, escalated to the DORA incident coordinator for potential regulatory notification.

Key attributes to define:

• Frequency: Continuous (trigger‑based) / per incident
• Owner (1st line): Head of IT Operations
• Challenger (2nd line): ICT Risk / Operational Risk
• Evidence generated:
• Incident ticket with timestamps
• Classification fields completed
• Escalation log or email trail
• Systems involved: ITSM tool (e.g., ServiceNow, JIRA Service Management)
• Testing approach:
• Sample incidents from each month
• Verify classification time < 4 hours
• Check correct use of DORA categories and thresholds

---

Your Turn (Thought Exercise)

Pick one of the following areas and mentally design a control using the same structure:

• ICT risk assessment for critical functions
• Vulnerability management and patching
• Third‑party onboarding and due diligence
• ICT business continuity testing

For your chosen area, specify:

1. Control objective (1–2 sentences)
2. Control statement (one precise, testable sentence)
3. Evidence you would expect to see

> Challenge yourself: Could a supervisor, arriving unannounced, verify this control within one day using your evidence list? If not, refine your control.

Step 5 – Documentation Standards, Evidence, and Audit Readiness

DORA supervision in 2025 is increasingly evidence‑driven. Institutions that struggle are usually those that:

• Have controls in practice but cannot prove them
• Keep evidence in fragmented, unsearchable formats
• Cannot link evidence to specific DORA provisions

1. Documentation Hierarchy

Visualise a pyramid (top to bottom):

1. Policies – high‑level commitments (e.g., ICT Risk Management Policy) referencing DORA.
2. Standards – mandatory requirements (e.g., Patch Management Standard: severity‑based SLAs).
3. Procedures / Runbooks – step‑by‑step instructions (e.g., Incident Classification Runbook).
4. Records / Evidence – outputs of execution (tickets, logs, reports, minutes).

Each layer should reference the one above (e.g., procedure cites relevant standard and policy) and, where possible, tag the DORA Articles it supports.

2. Evidence Strategy

Design a DORA Evidence Catalogue with, at minimum:

• Control ID → e.g., D‑TST‑03
• DORA reference → e.g., Art. 24–27 (digital operational resilience testing)
• Evidence type → test reports, screenshots, logs, minutes
• Location & owner → SharePoint path, GRC tool reference, system owner
• Retention period → aligned with legal and audit requirements

3. Audit Readiness Practices

• Pre‑packaged evidence sets for key topics: incident management, testing, third‑party risk, ICT risk management.
• Walkthrough scripts: short narratives explaining how a process works, aligned with actual practice.
• Version control: policies and standards under change control, with archived versions in case a supervisor asks about a past period.

> Self‑check: If asked tomorrow to demonstrate compliance with DORA’s ICT testing requirements over the last 12 months, could you produce a complete and ordered set of test plans, results, defect logs, and remediation actions within 48 hours?

Step 6 – Three Lines of Defense Under DORA: Roles and Edge Cases

DORA does not explicitly use the phrase “three lines of defense”, but supervisors and ESAs implicitly expect institutions to apply that model. Here is how it typically maps in 2025.

1st Line – Business & ICT (Ownership and Execution)

• Own and manage ICT and security risks in day‑to‑day operations
• Design and operate primary DORA controls (e.g., incident detection, backups, change management, vendor due diligence)
• Maintain process documentation, runbooks, and operating procedures

2nd Line – Risk & Compliance (Oversight and Challenge)

• Define ICT risk framework and policies aligned with DORA
• Monitor and challenge 1st line: are controls adequate and effective?
• Run DORA compliance monitoring programs and maintain a DORA obligations register
• Advise on regulatory interpretation (e.g., what counts as a “major incident” or “critical/important function”)

3rd Line – Internal Audit (Independent Assurance)

• Provide independent, risk‑based assurance over the design and effectiveness of DORA controls
• Assess whether governance, risk management, and internal controls are adequate to meet DORA obligations
• Report directly to the audit committee / board

---

Edge Cases and Tensions

1. Small institutions: May have combined roles (e.g., CISO also acting as ICT risk lead). The challenge is to preserve independence of challenge and audit.
2. Outsourcing of internal audit: Still acceptable if independence and competence are assured, but the accountability remains internal.
3. CISO location: If the CISO sits in the 1st line (common), you must ensure a separate 2nd‑line ICT risk/compliance function exists to avoid self‑review.

> Thought exercise: For a mid‑size payment institution, draft a short RACI (Responsible, Accountable, Consulted, Informed) for DORA incident reporting to competent authorities. Who is R, A, C, I across 1st, 2nd, and 3rd line?

Step 7 – Quick Check: Lines of Defense

Test your understanding of how the three lines of defense support ongoing DORA compliance.

Step 8 – Internal Assurance Program for DORA Controls

An internal assurance program coordinates testing across 1st, 2nd, and 3rd lines to provide a coherent view of DORA control effectiveness.

1. Assurance Layers

1. 1st line control testing (self‑assessment)

• Regular sampling of tickets, logs, and reports by process owners
• Control attestations (e.g., quarterly sign‑offs by system owners)

1. 2nd line monitoring and thematic reviews

• Key control indicators (KCIs) for DORA areas (e.g., % of critical patches applied within SLA)
• Thematic reviews (e.g., review of all third‑party contracts supporting critical functions)

1. 3rd line internal audit

• Multi‑year audit plan including dedicated DORA audits (e.g., ICT risk governance, testing framework, incident management, third‑party risk)
• Follow‑up audits to verify remediation of high‑priority findings

2. Risk‑Based Planning

Internal audit and 2nd line functions should use a risk‑based approach to prioritise DORA topics:

• Criticality of services and ICT assets
• Concentration of third‑party dependencies (especially critical ICT third‑party service providers)
• Incident history and near misses
• Findings from supervisors, external auditors, and peer institutions

3. Assurance Outputs

• Assurance maps: show where each DORA requirement is covered by 1st, 2nd, and 3rd line testing
• Consolidated issue register: tracks DORA‑related weaknesses, owners, deadlines, and status
• Management reporting: dashboards for the management body and risk committee on DORA control health

> Advanced consideration: How would you avoid assurance fatigue (multiple teams testing the same controls) while still giving supervisors comfort that DORA controls are robust?

Step 9 – Mini Design Lab: Mapping a DORA Requirement to Controls and Assurance

Apply what you have learned by walking through a concrete DORA requirement.

Scenario

Your institution must comply with DORA Article 28–30 on ICT third‑party risk management. Focus on the requirement to ensure that contracts with ICT third‑party service providers supporting critical or important functions include minimum mandatory clauses (e.g., on availability, security, access, audit, and termination).

Task (Thought Exercise)

1. Define the operating model elements:

• Which functions are involved? (e.g., Procurement, Legal, ICT, Business Owners, 2nd line risk)
• Where does the process start and end? (from vendor selection to contract signature and periodic review)

1. Design at least two controls:

• Control 1 (Preventive): e.g., No new contract for an ICT third‑party supporting a critical function can be signed unless a standard DORA‑compliant contractual clause set, approved by Legal and 2nd line risk, is used.
• Control 2 (Detective): e.g., Annual review of all active ICT third‑party contracts supporting critical or important functions to confirm the presence of DORA‑required clauses; deficiencies are logged and remediated within defined timelines.

1. Specify evidence:

• What documents, logs, or system fields would prove that each control is working?
• Where is this evidence stored and who owns it?

1. Plan assurance:

• How will 2nd line monitor this area (e.g., periodic sampling, KRIs)?
• What would an internal audit of third‑party DORA compliance focus on (scope, samples, test procedures)?

> Stretch question: How would your design change for intra‑group ICT service arrangements, where the provider is another entity in the same group but DORA still applies?

Step 10 – Flashcard Review: Key Concepts

Flip through these cards mentally to reinforce core ideas from this module.

Step 11 – Synthesis Quiz: Control Design and Assurance

A final scenario to consolidate your understanding of control design, documentation, and assurance for DORA.