DORA Article 6 ICT Risk Management Framework: A Practical Reading

A reading of what Article 6 actually requires of a financial entity’s ICT function, written for the people who have to own and report on the framework.

Most of what is written about DORA is written by people selling something — a GRC tool, a compliance service, a penetration test. This is a reading by someone who has had to commission and own one of these frameworks. The aim is to describe what Article 6 substantively demands and what regulators have started to ask for in supervisory engagements since DORA came into application in January 2025.

What Article 6 actually says

DORA’s Article 6 occupies a single page of regulation. It says, in essence, four things:

1. The financial entity shall have a sound, comprehensive, and well-documented ICT risk management framework.
2. The framework shall be part of, and integrated into, the entity’s overall risk management.
3. The framework shall be documented and reviewed at least once a year, and upon the occurrence of major ICT-related incidents or material changes.
4. The management body has ultimate responsibility for the framework.

That is the article. The rest of the chapter — Articles 7 through 13 — elaborates what the framework must contain: the technical systems, identification of risks, protection and prevention, detection, response and recovery, and learning. Article 6 sets the frame; the rest provides the structure.

What competent authorities have started to ask for in supervisory engagements is concrete. Show us the framework document. Show us the board minutes where it was approved. Show us the integration with enterprise risk management. Show us the last annual review. Show us your ICT risk appetite statement.

If you cannot produce all five of those, on demand, you have a problem.

Who this is for

This reading is for:

• The board director of an EU financial entity whose committee has been asked to approve an ICT risk framework and who wants to know what to look for in it.
• The CTO or CIO who has been told to “produce an ICT risk framework” and is wondering whether the existing IT security policy is enough. It is not.
• The chief risk officer integrating ICT risk into the enterprise risk management framework for the first time.

It is not a compliance checklist. It is a reading of what Article 6 actually requires you to be able to demonstrate.

The framework is not the security policy

The single most common confusion is that an ICT risk management framework is the same thing as an existing IT security policy. It is not.

A security policy describes controls — what controls are in place, who operates them, what the access rules are. A risk management framework describes how the organisation identifies, evaluates, treats, and reports on ICT risks over time. The security policy is one output of the framework. The framework is the system that produces it.

A workable framework typically contains:

• A risk taxonomy specific to ICT, rather than borrowed from operational risk wholesale.
• A defined ICT risk appetite — quantitative where possible.
• A statement of how ICT risk integrates with enterprise risk.
• Defined roles and responsibilities — the three lines of defence, applied to ICT.
• A change-driven and time-driven review cycle.
• An audit and assurance plan covering the framework itself.
• A scope statement covering third-party ICT dependencies.

The last item is where most firms have the most work to do. Article 6 read together with Articles 28 to 30 makes ICT third-party dependencies explicitly in-scope for the framework. The framework cannot stop at the firm’s own perimeter.

Where firms get this wrong

In supervisory engagements visible from the first eighteen months of DORA enforcement, the recurring patterns are:

1. The framework is owned by IT, not by the board. Article 6(4) is explicit: the management body has ultimate responsibility. If your board has not seen and approved the framework, you do not have one for DORA purposes — you have an IT document.

2. ICT risk appetite is missing or undefined. Many firms have an enterprise risk appetite statement but no separate articulation of ICT risk appetite. Regulators are increasingly asking for the latter. “We accept low-to-moderate operational risk” is not an ICT risk appetite.

3. Third-party scope is incomplete. Cloud providers are usually in scope. SaaS providers serving critical functions are usually in scope. The smaller, harder-to-classify suppliers — code repositories, payment routing, identity providers, dependency package registries — are routinely missed. The framework has to include them, with the same rigour.

4. The annual review is a tick-box. A thirty-minute board approval of an unchanged document does not satisfy Article 6’s review requirement. The review must consider material changes, recent incidents, and regulatory developments, and must produce evidence of having considered them.

5. The framework is not embedded in change governance. When a new system, vendor, or platform is procured, the framework should demonstrably influence the decision. If procurement papers do not reference the framework, the framework is not embedded.

What “good” looks like, evidentially

A regulator asking to see your ICT risk management framework expects to see, on the day of the visit:

• The framework document itself — typically 30 to 80 pages, depending on size and complexity.
• Board minutes approving the current version.
• The most recent annual review report.
• A risk register reflecting the framework’s risk taxonomy.
• Evidence of the framework’s influence on a recent material change — a vendor selection, a new system, a cloud migration.
• An internal audit report on the framework — typically on a two-to-three-year substantive cycle.

If you have all six and they tell a coherent story, you are in a defensible position. If you have the document but cannot show influence or audit, you are in a position of stated compliance without evidence of operation. Regulators have started to be explicit that the second position is not enough.

A note on proportionality

DORA applies proportionality. A microenterprise of fifteen people running a small payment institution is not expected to maintain the same framework as a major bank. Article 6 acknowledges this. In practice, proportionality reduces the depth of documentation and the frequency of review, but it does not remove the substantive requirements. Even the smallest in-scope entity needs a documented framework, board approval, an annual review, and consideration of third-party ICT risk. The depth varies; the existence does not.

How we engage with this

We read ICT risk frameworks. That is one of the things we do — not in the abstract, but as part of a Technology Control Review or a Supplier and Dependency Review. The output is a written assessment of where the framework stands relative to what Article 6 demands of your firm at your size and complexity, with specific recommendations the board can act on.

We do not implement frameworks. We do not run penetration tests. We do not sell GRC software. We read what is there, identify what is missing, and write it down for the people who have to decide what to do about it.

Pricing is published at /pricing/. If your board has asked you to demonstrate DORA Article 6 compliance and you would like an independent reading before the next supervisory engagement, the place to start is a conversation.

Sixteen Pillars is a technology governance consultancy based in Cyprus. Engagements run remote across the EU, UK, and Middle East, with on-site time where the engagement requires it.