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

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 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 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 non compliance it violates dora, which requires a complete register loss of oversight the register loses its value as an inventory instrument ineffective risk management without a complete picture, you cannot conduct effective ict risk management supervisory risk regulators expect completeness 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 critical or important the service supports a critical function and failure jeopardizes business operations (e g , microsoft 365, bloomberg terminal) non materially critical the service is used by a critical function but failure doesn't jeopardize operations (e g , adobe reader, docusign) 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 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 implementation recommendations start with a complete inventory first map all ict services, regardless of their criticality apply the materiality test use objective criteria such as maximum tolerable downtime impact on business operations availability of alternatives cost of failure document your choices record why a service is or isn't materially supporting stay consistent use the same criteria for all services review periodically services can change in criticality 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