Article 6: ICT risk management framework

Article 6 requires you to establish and operate a sound, well-documented ICT risk management framework embedded in your enterprise risk management system, so your organization can identify, assess, respond to, and monitor ICT risk fast and end-to-end. Operationalize it by assigning clear ownership, mapping controls to ICT risks, and maintaining supervisor-ready evidence. (Regulation (EU) 2022/2554, Article 6)

Key takeaways:

• You need an ICT risk management framework that is documented, owned, and integrated into overall risk management. (Regulation (EU) 2022/2554, Article 6)
• Supervisors will look for proof of operation: decisions, testing, incidents, remediation, and governance records, not just policy. (Regulation (EU) 2022/2554, Article 6)
• The fastest path is a single traceability register that ties Article 6 obligations to controls, owners, and evidence artifacts.

“Framework” in Article 6 is not a template document. It is the operating system for how your financial entity governs ICT risk: who owns decisions, how risk is identified and measured, how controls are selected and tested, how incidents and weaknesses are remediated, and how leadership oversees performance. Article 6 also makes a structural point: ICT risk management cannot sit off to the side as “security’s job.” It must be part of the overall risk management system. (Regulation (EU) 2022/2554, Article 6)

For a CCO, GRC lead, or operational risk head, the practical challenge is speed and auditability. You need to stand up something that works across IT, security, resilience, and third-party owners, and you need evidence that it works without building a bureaucracy. The operational strategy is simple: define scope, define ownership, define minimum required processes, then build traceability from the regulation to controls and artifacts. This page gives requirement-level implementation guidance you can execute quickly and defend under supervisory review for the article 6: ict risk management framework requirement. (Regulation (EU) 2022/2554, Article 6)

Regulatory text

Requirement (excerpt): “Financial entities shall have a sound, comprehensive and well-documented ICT risk management framework as part of their overall risk management system, which enables them to address ICT risk quickly, efficiently and comprehensively and to ensure a high level of digital operational resilience.” (Regulation (EU) 2022/2554, Article 6)

What the operator must do:
You must (1) define and document an ICT risk management framework, (2) embed it into enterprise/overall risk management (governance, reporting, risk appetite/tolerance where applicable in your internal system), and (3) prove it is capable of timely, effective ICT risk handling across the organization. The test is operational: can you show that ICT risk is identified, owned, acted on, and tracked to closure with management oversight? (Regulation (EU) 2022/2554, Article 6)

Plain-English interpretation (what “good” looks like)

A supervisor reading Article 6 expects you to answer, with evidence:

• What is in scope? Critical services, systems, data, and supporting third parties that could affect operational resilience.
• Who is accountable? Named owners for ICT risk management, control operation, and risk acceptance decisions.
• How do you manage ICT risk end-to-end? A repeatable lifecycle: identify → assess → treat → monitor → report → improve.
• Can you act quickly? Clear escalation paths, incident decisioning, and remediation discipline. (Regulation (EU) 2022/2554, Article 6)

Who it applies to (entity and operational context)

Entities: “Financial entities” under DORA must meet Article 6. (Regulation (EU) 2022/2554, Article 6)
Operational context: Applies wherever ICT supports regulated services and business processes, including:

• Production infrastructure and endpoints
• Core applications, cloud/SaaS platforms, and network services
• Security operations and identity services
• Change/release processes
• Data flows and integrations
• Third parties that provide ICT services or materially affect ICT resilience

If your ICT risk management is fragmented across security, IT operations, and operational risk, Article 6 forces you to tie it together into one framework with coherent governance and evidence. (Regulation (EU) 2022/2554, Article 6)

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

Step 1: Define framework scope and integration points

1. Write a one-page scope statement: in-scope entities, business lines, geographies, and ICT domains (apps, infra, cloud, endpoints, data, third parties).
2. List integration points to enterprise risk management: risk taxonomy alignment, reporting cadence to risk committees, risk acceptance approvals, and issue management.
3. Set a boundary rule for subsidiaries/joint ventures: whether they follow the group framework or a local variant, and how equivalence is demonstrated. (Regulation (EU) 2022/2554, Article 6)

Step 2: Assign ownership with a RACI that matches reality

Common failure mode: DORA obligations assigned to “ICT” generically. Fix it with named roles.

• Accountable executive for ICT risk framework operation (often CIO/CISO/COO depending on model).
• GRC owner for control mapping, evidence standards, and supervisory responses.
• Control owners in IT/security (change, access, vulnerability mgmt, backup/restore, monitoring, third-party oversight).
• Risk acceptance authorities (who can sign off residual ICT risk). (Regulation (EU) 2022/2554, Article 6)

Deliverable: a RACI that includes escalation routes for incidents and material control failures.

Step 3: Build a single “Article 6 traceability register”

This is the fastest way to make the framework “well-documented” and auditable. Create a register with columns:

• Article 6 obligation statement (your internal decomposition)
• Control objective (what must be true)
• Implemented controls (policies/standards/procedures + technical controls)
• Control owner and operator
• Frequency/triggers (event-based is acceptable if defined)
• Evidence artifacts (exact names/locations)
• Last performed/last tested
• Open issues and remediation target dates (internal targets)

This register is also where Daydream fits naturally: it can function as the system-of-record that ties obligations to controls, owners, and evidence requests so you can respond consistently under supervisory pressure.

Step 4: Define the ICT risk lifecycle and minimum operating procedures

Document “minimum viable” procedures that show you can address ICT risk quickly:

• Risk identification: asset/service inventory inputs, threat/vulnerability inputs, third-party changes, and major change initiatives.
• Risk assessment: method, rating approach, and criteria for materiality (define internally; don’t overcomplicate).
• Risk treatment: control selection, exception handling, and approval workflow for residual risk acceptance.
• Monitoring and reporting: KRIs/KPIs you actually produce, who reviews them, and what triggers action.
• Issue and remediation management: triage, assignment, due dates, validation evidence, and closure approvals. (Regulation (EU) 2022/2554, Article 6)

Keep the framework readable. Put detail in standards/procedures and point to them from the framework.

Step 5: Prove operation through “closed-loop” evidence

Supervisors rarely accept “we have a policy” as proof of resilience outcomes. Design your evidence so it shows the loop:

• Detection/identification record (finding, incident, test result)
• Decision record (risk acceptance, prioritization, change approval)
• Remediation record (ticket, change record, patch evidence)
• Validation record (re-test, control check, QA sign-off)
• Governance record (committee minutes, management reporting) (Regulation (EU) 2022/2554, Article 6)

Step 6: Put a regulatory-response workflow in place

You need a consistent way to answer regulator questions fast:

• Intake channel and triage (Compliance/GRC owns)
• Evidence request checklist per control area
• Legal/compliance review and sign-off
• Escalation for gaps and remediation commitments
• Version-controlled response packages

This is where many organizations burn time. A workflow plus a curated evidence library prevents scramble.

Required evidence and artifacts to retain (supervisor-ready)

Use an “evidence menu” tied to the traceability register. Typical artifacts:

• ICT risk management framework document (approved, versioned) (Regulation (EU) 2022/2554, Article 6)
• RACI and governance charters (committees, decision rights)
• ICT risk register (or integrated enterprise risk register with ICT tagging)
• Control library and control narratives (what the control is, who runs it, what evidence exists)
• Policies/standards/procedures referenced by the framework
• Meeting minutes and management reports showing oversight and action
• Issue/remediation logs with closure validation
• Testing outputs where relevant (control testing, resilience exercises, readiness drills)
• Supervisory request/response packages (what was asked, what you produced, who approved)

Retention periods are not specified in the provided Article 6 excerpt; set internal retention rules and apply them consistently.

Common exam/audit questions and hangups

Expect questions that probe integration, ownership, and proof:

• “Show me where ICT risk is governed within the overall risk management system.” (Regulation (EU) 2022/2554, Article 6)
• “Who can accept ICT risk, and where is it documented?”
• “Show one example of an ICT risk from identification through remediation closure.”
• “How do you know controls are operating, not just designed?”
• “Where is the evidence stored, and how do you ensure it is complete and tamper-resistant?”
• “How do third-party ICT services feed into ICT risk management?” (Article 6 is framework-level; demonstrate your internal integration.)

Hangups that stall audits:

• Conflicting versions of policies/standards in different repositories
• Evidence that exists but isn’t traceable to a control owner and date
• Unclear risk acceptance authority (decisions made informally)

Frequent implementation mistakes (and how to avoid them)

1. Writing a framework that restates the regulation.
   Fix: decompose Article 6 into internal obligations, then map each to concrete controls and artifacts in your register. (Regulation (EU) 2022/2554, Article 6)

2. No single owner for evidence quality.
   Fix: assign a GRC evidence steward per control domain with a standard naming convention and minimum evidence requirements.

3. Overbuilding a theoretical risk methodology.
   Fix: keep the method simple, then prove it runs through real cases, issues, and remediation closures.

4. Treating third-party risk as separate.
   Fix: ensure third-party ICT dependencies appear in scope, risk identification triggers, and reporting.

5. No remediation validation.
   Fix: require a closure checklist: what changed, how it was verified, who approved closure.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite specific outcomes. Practically, Article 6 failures create supervisory risk because they indicate you cannot reliably identify and control ICT risk across the institution, which can cascade into incident response breakdowns, unresolved weaknesses, and inconsistent regulatory responses. (Regulation (EU) 2022/2554, Article 6)

Practical 30/60/90-day execution plan

Numeric day counts are directional project phases, not regulatory deadlines.

First 30 days: establish structure and traceability

• Confirm in-scope entities, services, and ICT domains.
• Appoint accountable executive and publish RACI.
• Stand up the Article 6 traceability register with owners and evidence placeholders.
• Draft the ICT risk management framework outline and link existing policies/standards. (Regulation (EU) 2022/2554, Article 6)

Next 60 days: make it operational

• Run one end-to-end “closed-loop” walk-through: pick a real ICT risk or control gap and document identification → decision → remediation → validation.
• Implement the regulatory-response workflow and response package template.
• Standardize evidence storage and naming; assign evidence stewards.
• Start regular management reporting (cadence aligned to your existing risk governance). (Regulation (EU) 2022/2554, Article 6)

Next 90 days: demonstrate resilience discipline

• Run a readiness drill focused on evidence retrieval and decision records (not just technical testing).
• Review open ICT issues and create a tracked corrective action plan with validation steps.
• Perform an internal audit-style review against the traceability register and close documentation gaps.
• Decide whether to adopt Daydream as the system-of-record for obligation-to-evidence traceability and supervisory response workflow.

Frequently Asked Questions

Do we need a separate “DORA ICT risk framework” document, or can we extend what we already have?

You can extend existing risk management documentation as long as the result is sound, well-documented, and clearly part of the overall risk management system. The key is traceability: supervisors must see where ICT risk is owned, operated, and evidenced. (Regulation (EU) 2022/2554, Article 6)

What does “address ICT risk quickly” mean in practice?

It means your framework has defined escalation, decision rights, and remediation workflows that work under pressure. You should be able to produce a recent example that shows timely identification, action, and closure evidence. (Regulation (EU) 2022/2554, Article 6)

Who should own Article 6 compliance: CISO, CIO, or Compliance?

Assign a single accountable executive for the framework’s operation, and make Compliance/GRC accountable for regulatory mapping, evidence standards, and supervisory responses. If ownership is split without a RACI, you will lose time and consistency during exams. (Regulation (EU) 2022/2554, Article 6)

How do we prove the framework is “comprehensive” without documenting everything?

Use a traceability register that lists the lifecycle components (identify, assess, treat, monitor, report, improve), links to supporting standards, and points to evidence artifacts. Depth lives in procedures and records, not in a single massive policy. (Regulation (EU) 2022/2554, Article 6)

Where do third parties fit into an ICT risk management framework?

Treat third-party ICT services as in-scope dependencies: include them in risk identification triggers, risk assessments, control oversight, and issue remediation. The framework should show who owns third-party ICT risk and what evidence you retain. (Regulation (EU) 2022/2554, Article 6)

What is the minimum evidence set we should have ready for a supervisory request?

Keep the framework document, governance/RACI, the traceability register, one or more end-to-end examples (risk to remediation closure), and a curated evidence library with named owners. That package shows both design and operation. (Regulation (EU) 2022/2554, Article 6)