Article 5: Governance and organisation

Article 5 is the governance “root requirement” that makes the rest of DORA auditable. It does not ask you to deploy a single technical control; it asks you to prove that ICT risk is managed through a functioning internal governance and control framework that drives consistent decisions, execution, and accountability across the firm (Regulation (EU) 2022/2554, Article 5). For a Compliance Officer, CCO, or GRC lead, the operational challenge is predictable: ICT risk work exists across security, IT operations, enterprise risk, third-party management, and business owners, but evidence is scattered and accountability is implied rather than explicit.

This page gives requirement-level implementation guidance you can put into motion immediately. The goal is to create a governance spine that (1) assigns ownership for ICT risk management outcomes, (2) connects those outcomes to concrete controls and operating procedures, and (3) produces evidence that stands up to supervisory review. You will also see practical artifacts to retain, exam questions you should be ready for, and common mistakes that cause otherwise capable programs to fail a review. Regulatory text is cited only to the provided primary sources (Regulation (EU) 2022/2554, Article 5).

Regulatory text

Excerpt (binding requirement): “Financial entities shall have in place an internal governance and control framework that ensures an effective and prudent management of ICT risk, in accordance with Article 6(4), in order to achieve a high level of digital operational resilience.” (Regulation (EU) 2022/2554, Article 5)

Operator interpretation (what the regulator is asking you to prove):
You must be able to demonstrate that ICT risk is governed like other material risks: with defined roles, management oversight, internal controls, and a control environment that works in day-to-day operations. “In place” means documented, approved, and implemented. “Effective and prudent” means it is capable of preventing, detecting, and correcting ICT risk issues through decisions, controls, monitoring, and remediation, not through informal heroics (Regulation (EU) 2022/2554, Article 5).

Plain-English interpretation (what this means in practice)

Article 5 expects you to answer, with evidence:

• Who is accountable for ICT risk outcomes (not just tasks).
• What the control framework is, and how it is organized (policies, standards, procedures, control owners, reporting).
• How governance works (committees/decision forums, escalation thresholds, exception handling, risk acceptance).
• How you know it’s working (KRIs/KPIs, control testing, issues and remediation tracking).
• How the framework connects to DORA obligations, including the ICT risk management expectations referenced in Article 6(4) (Regulation (EU) 2022/2554, Article 5).

If you can’t trace a DORA obligation to a control owner and to repeatable evidence, your program will look “paper-based” even if teams do good work.

Who it applies to (entity and operational context)

Entities: “Financial entities” in scope of DORA are the direct addressees for Article 5 (Regulation (EU) 2022/2554, Article 5). Practically, if your firm is implementing DORA, treat Article 5 as applicable across the consolidated control environment that supports regulated operations.

Operational scope:

• ICT risk governance covering technology, information security, IT operations, and third-party delivered ICT services used by the business.
• Governance that spans business lines, shared services, and outsourced arrangements, because accountability for ICT risk cannot be outsourced even if services are.

Who inside the firm must engage:

• Board/management body delegates and executive sponsors for ICT risk
• CISO/Head of Security, CIO/Head of IT, Head of IT Risk, Operational Resilience lead
• Third-party risk management (TPRM) / procurement / supplier owners
• Compliance and internal audit (second and third line assurance)

What you actually need to do (step-by-step)

Step 1: Define the “ICT risk governance and control framework” boundary

Create a written scope statement that answers: Which entities, business lines, platforms, and third-party ICT services are included? Tie the scope to regulated activities and critical business services where you can. Keep it stable so evidence can accumulate.

Output: ICT Risk Governance Framework scope and applicability statement.

Step 2: Establish accountability and decision rights (RACI plus escalations)

Build a RACI that covers at least:

• ICT risk identification and assessment
• Control ownership (prevent/detect/correct)
• Risk acceptance and exception approvals
• Incident governance handoffs
• Remediation ownership and due dates
• Third-party ICT risk decisions (onboarding, renewals, material changes)

Add a clear escalation path: who decides when risk is outside tolerance, and how exceptions are time-bound.

Evidence tip: A RACI without names and forums fails under exam pressure. Put roles and named accountable owners for major domains.

Step 3: Map Article 5 to your control universe (single register)

Create one register that maps:
DORA Article 5 requirement → internal control objective → control(s) → control owner → evidence artifact → review cadence → related issue/remediation tracking.

This is the fastest way to operationalize the requirement because it turns a legal sentence into a testable checklist.

Practical control (recommended): Map the DORA requirement to concrete ICT controls, accountable owners, and supervisory evidence artifacts in a single register.

Step 4: Formalize governance forums and reporting packs

Document governance forums that actually make decisions (not “FYI meetings”):

• Charter (purpose, scope, authority)
• Attendees and required roles
• Inputs (metrics, incidents, risk exceptions, third-party issues)
• Outputs (decisions, actions, risk acceptances, escalations)

Create a consistent reporting pack covering: key risks, control performance, issues, remediation status, major incidents, and third-party risk concerns.

Step 5: Implement a regulatory-response workflow (supervisory readiness)

Regulators can request artifacts, explanations, and timelines quickly. Put a workflow in place:

• Intake channel and triage
• Owner assignment and internal deadlines
• Legal/compliance review before submission
• Evidence packaging standards (versioning, timestamps, system-of-record)
• Tracking of commitments and remedial actions

Practical control (recommended): Implement a regulatory-response workflow for requests, escalations, and remedial actions with legal/compliance sign-off.

Step 6: Run readiness drills and close gaps through CAPs

Run periodic internal drills that simulate common supervisory requests:

• “Show me evidence this control operated”
• “Show the last risk acceptance and who approved it”
• “Show remediation validation and closure criteria”

Track findings as corrective action plans (CAPs) with owners, target dates, and validation evidence.

Practical control (recommended): Run periodic readiness drills and close identified gaps through tracked corrective action plans with validation evidence.

Step 7: Make it auditable: testing, assurance, and issue management

Tie Article 5 governance to your assurance model:

• Control testing plan (first line monitoring, second line testing, third line audit where applicable)
• Central issue register (including ICT and third-party issues)
• Closure standards (what “fixed” means; evidence required; who signs off)

Required evidence and artifacts to retain

Maintain these as “supervisory ready” artifacts (versioned, approved, retrievable):

• ICT governance framework document (scope, roles, decision rights)
• RACI with accountable owners and escalation paths
• Committee charters, agendas, minutes, and action logs
• ICT risk appetite / tolerance statements, plus exception process and approvals
• Control library and mapping register for Article 5 to controls and evidence
• Metrics/KRI dashboards and management reporting packs
• Issue register and CAP tracker (including validation evidence)
• Regulatory inquiry workflow records (requests, responses, approvals, submissions)
• Evidence of periodic governance review and updates

Common exam/audit questions and hangups

Expect reviewers to ask for “show me” proof:

1. Show the framework. Where is it documented, who approved it, and what changed since last review? (Regulation (EU) 2022/2554, Article 5)
2. Who is accountable for ICT risk? Name the role and show decision forums and escalation.
3. How do you know it’s effective? Provide testing, monitoring results, and examples of issues driven to closure.
4. How do third parties fit? Demonstrate governance over outsourced ICT services and how issues are managed.
5. Show evidence quickly. Can you assemble a clean evidence pack without scraping emails and screenshots?

Hangups usually come from fragmented ownership (security vs IT vs risk) and inconsistent evidence standards.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails under review	How to avoid it
Treating Article 5 as “write a policy”	Policies don’t prove governance operates	Build the mapping register and maintain decision records
RACI without decision rights	Tasks get done, but no accountable owner	Add escalation, risk acceptance authority, and named accountable owners
Evidence scattered across tools	Slow, inconsistent supervisory response	Define system-of-record per artifact and enforce naming/versioning
No remediation discipline	“Known issues” linger without proof of closure	Use CAPs with validation and clear closure criteria
Third-party governance left to procurement	Procurement alone can’t manage ICT risk	Connect TPRM, security, and service owners into governance forums

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not list specific cases. Practically, Article 5 failures tend to surface as “program weaknesses” during supervisory reviews: unclear accountability, weak oversight, and inability to evidence effective ICT risk management. That increases the chance of formal remediation programs and heightened supervisory attention because governance is the mechanism regulators rely on to trust the rest of your DORA implementation (Regulation (EU) 2022/2554, Article 5).

Practical 30/60/90-day execution plan

You asked for speed. Use a phased plan without calendar-day promises.

First 30 days (Immediate: establish structure and traceability)

• Appoint an executive owner for ICT risk governance and confirm second-line ownership in Compliance/GRC.
• Publish the Article 5 scope statement and initial RACI (with named accountable owners).
• Stand up the DORA mapping register for Article 5: requirement → controls → owners → evidence.
• Define evidence standards: system-of-record, versioning, minimum artifacts for governance forums.

Days 31–60 (Near-term: make governance run and produce evidence)

• Finalize committee charters and start producing minutes/action logs consistently.
• Implement regulatory-response workflow with legal/compliance sign-off and a tracker for commitments.
• Build the management reporting pack: ICT risk posture, exceptions, key issues, remediation status, major third-party ICT risks.
• Populate the CAP tracker and define closure/validation requirements.

Days 61–90 (Operationalize: test, drill, remediate)

• Run a readiness drill: pull an evidence pack for Article 5 and fix retrieval gaps.
• Perform targeted control testing focused on governance operation (risk acceptance, exceptions, remediation closure).
• Close the highest-risk gaps with validated remediation evidence.
• Set the ongoing cadence for framework review, metrics review, and issue governance.

How Daydream fits (earned, not bolted-on)

Most teams fail Article 5 because they cannot keep traceability current across controls, owners, and evidence as the organization changes. Daydream is useful when you need a living register that ties DORA requirements to accountable owners, controls, and supervisory-ready artifacts, plus a workflow for regulatory requests and remediation tracking.

Frequently Asked Questions

Does Article 5 require a specific committee structure?

Article 5 requires an internal governance and control framework that effectively manages ICT risk, but it does not prescribe committee names or counts (Regulation (EU) 2022/2554, Article 5). Use decision forums you already have, then document authority, inputs, and outputs clearly.

What’s the minimum evidence set to prove the framework is “in place”?

Keep an approved framework document, a RACI with decision rights, governance forum minutes with actions, and a mapping register tying Article 5 to controls and evidence (Regulation (EU) 2022/2554, Article 5). Add issue/CAP records that show problems get fixed and verified.

How do we connect Article 5 to Article 6(4) without rewriting the whole ICT risk program?

Treat Article 5 as the governance wrapper and map it to the parts of your existing ICT risk management program that satisfy Article 6(4) expectations (Regulation (EU) 2022/2554, Article 5). The mapping register is the bridge: requirement to control objective to control owner to evidence.

Can we rely on ISO 27001 or NIST CSF as our “framework”?

You can align your internal control framework to recognized standards, but you still must show internal governance and control operation for ICT risk management under DORA (Regulation (EU) 2022/2554, Article 5). Examiners will focus on accountability, decisions, and evidence, not the label on the standard.

Who should own the Article 5 mapping register: Security, IT Risk, or Compliance?

Put day-to-day maintenance with the function that manages the control library and evidence collection (often GRC/IT risk), and require control owners to attest to accuracy. Compliance should own interpretive sign-off and supervisory response quality control.

What’s the fastest way to find gaps before a regulator does?

Run an internal evidence drill: pick a governance decision (risk acceptance, exception, or remediation closure) and assemble the full chain of approvals and artifacts. Any step that depends on personal inboxes or undocumented decisions is a gap against Article 5 (Regulation (EU) 2022/2554, Article 5).