How to Map ICT Services to Business Functions: A Complete Yet Proportionate Approach

01

The Problem: When Technology and Regulation Collide

The DORA register of information is central to the new European legislation for digital operational resilience. Financial institutions must map and report their complete ICT supplier landscape. However, there's a fundamental problem: the register's technical data model doesn't support a risk-based approach, while DORA specifically prescribes this.

Binary Linkage: All or Nothing

The Data Point Model (DPM) operates with a binary linkage between ICT services and business functions. Once you link an ICT service to a business function classified as critical or important, that ICT service automatically receives the same status. No middle ground is possible.

This means concretely: if you link DocuSign to your critical compliance function, DocuSign is automatically classified as "supporting a critical function" – with all the consequences that entails.

02

The Consequences: A Cascade of Obligations

When an ICT service is classified as supporting a critical or important function, this automatically triggers a series of enhanced obligations:

Direct DORA Requirements:

• Periodic risk assessments – Vulnerability assessments, business impact analyses, substitutability and exit possibilities
• Supply chain mapping – Identification of all subcontractors in the chain whose failure would jeopardize the service
• Enhanced contractual provisions – Audit rights, information security standards, incident reporting
• Exit strategy – Documented exit plans with alternative scenarios
• ICT concentration risk assessment – Analysis of dependencies and single points of failure

The Practical Dilemma

This creates an impossible situation for organizations. A typical financial institution uses hundreds of ICT services, many of which are used by critical functions but are not materially supporting. Consider:

• Zoom for meetings
• DocuSign for digital signatures
• Adobe Reader for reading documents
• Slack for internal communication

According to the register's binary logic, all these services would receive the same status as genuinely critical systems like Bloomberg terminals, core banking systems or trading platforms.

03

What Happens in Practice?

Confronted with this dilemma, many organizations choose a pragmatic but problematic solution: they only report the ICT services they consider genuinely critical – often no more than 30-40 services out of a total of 200+.

Why This Is Problematic:

1. Non-compliance – It violates DORA, which requires a complete register
2. Loss of oversight – The register loses its value as an inventory instrument
3. Ineffective risk management – Without a complete picture, you cannot conduct effective ICT risk management
4. Supervisory risk – Regulators expect completeness

04

The Solution: Working Within the Constraints

The solution lies in cleverly using the data model by creating an additional business function. We have discussed this approach with various local regulators.

Step 1: Distinguish Three Categories

Assess each ICT service based on causality AND materiality:

1. Critical or important – The service supports a critical function AND failure jeopardizes business operations (e.g., Microsoft 365, Bloomberg Terminal)
2. Non-materially critical – The service is used by a critical function BUT failure doesn't jeopardize operations (e.g., Adobe Reader, DocuSign)
3. Not critical – The service only supports non-critical functions (e.g., Basecone for Finance)

Step 2: Create a 'Catch-All Function'

Create a new business function in the register:

• Name: "Non-critical supporting IT" or "Supporting functions – not material"
• Classification: Not critical/not important
• Description: "ICT services that are not materially supporting critical or important functions"

Step 3: Link Services Intelligently

• Link only genuinely critical ICT services (category 1) to your critical business functions
• Link all non-material services (category 2) to the new "Non-critical supporting IT" function
• Link other services (category 3) to their respective non-critical functions

05

The Result: Compliance AND Workability

This approach offers the best of both worlds:

Complete register – All ICT services are included (DORA-compliant) Risk-based – Only genuinely critical services receive enhanced status Workable – Prevents unnecessary administrative burden for non-material services Supervisory-proof – Approved by local regulators as a pragmatic solution Maintains oversight – Complete inventory for effective risk management

06

Implementation Recommendations

1. Start with a complete inventory – First map all ICT services, regardless of their criticality
2. Apply the materiality test – Use objective criteria such as:
3. Maximum tolerable downtime
4. Impact on business operations
5. Availability of alternatives
6. Cost of failure
7. Document your choices – Record why a service is or isn't materially supporting
8. Stay consistent – Use the same criteria for all services
9. Review periodically – Services can change in criticality

07

Conclusion

The DORA register of information forces organizations into a balancing act between technical limitations and regulatory requirements. The binary linkage in the data model contradicts the risk-based approach that DORA prescribes.

By cleverly using an additional business function for non-material services, organizations can meet the completeness requirement without drowning in disproportionate compliance burdens. This pragmatic solution, accepted by supervisors, makes it possible to use the register for its intended purpose: an effective instrument for ICT risk management.

The success of this approach depends on consistent application and clear documentation of choices made. Only then does the register retain its value as a foundation for digital resilience in the financial sector.

Originally published on DORA Solutions Insights.