DORA and mapping of information assets

• 18 Sep 2024

• Article
• 0

  Comment

Information assets and DORA

DORA regulation states that^[1] an “Information asset means a collection of information, either tangible or intangible, that is worth protecting”.

Those information assets could be internal or external with wide ranging content.  They may be qualitative or quantitative, they could include client account information, customer PII (Personally Identifiable Information), firm financial data, technical data, risk data and third-party data to name a few.

DORA expects firms to know what these information assets are, where they reside in a firm’s ICT estate, and how to protect them through “Protection and Prevention”^[2] strategies such as network management, isolation and Access Management.

This expectation is supported by Article 6^[3], “the ICT risk management framework shall include at least strategies, policies, procedures, ICT protocols and tools that are necessary to duly and adequately protect all information assets and ICT assets”.

The importance of mapping information assets in DORA regulation

Mapping is the foundation^[4] of many aspects of DORA and Operational Resilience outcomes and that view is shared by the European Supervisory Authorities.

Regulatory Technical Standard JC 2023 RTS 86^[5] is clear that correct “identification and classification” of Information Assets is “one of the basic and initial steps in ensuring that the availability, authenticity, integrity and confidentiality of data is preserved”.

It goes on to emphasise that “without a correct identification and classification, it is very difficult to have a correct knowledge of these assets and a correct adaptation of the… ICT risk management framework”.

So how do firms know which information assets to identify, classify and then map?

Article 8^[6] of EU 2022/2554 states that firms must identify “all ICT supported business functions… the information assets and ICT assets supporting those functions”, assess the threats to, and vulnerabilities of those ICT and information assets.

Firms “shall map those [ICT assets] considered critical” by documenting “the configuration of those ICT and Information Assets and the links and interdependencies between the different information assets and ICT assets”

So, Article 8 gives firms a clear indication that detailed mapping is required when the ICT Asset is “considered critical”. That detailed mapping includes configuration, links, interdependencies of the ICT Assets (systems, applications, networks, hardware) and the Information Assets (flow of information in and out, in storage and in transit).

Therefore, the starting point is to define criticality, for functions, for ICT assets and for information assets.

Defining criticality

In our experience, the definition of criticality (functions or assets) works best when firms use a criteria and methodology that already exists or is directly aligned to a firm’s other approaches to risk assessment.

As resilience practitioners, possibly because of the recency of the regulation, we often revert to creating new tools and methods. However, by leveraging existing practice and finding out what’s already in use, firms will regularly find that they have an assessment methodology, or the foundations of a methodology, already in place.

This recycling or upcycling helps to create consistent classification across in-scope domains and goes some way to breaking down siloed thinking.

That said, for firms yet to develop assessment methodologies, a robust approach to Business Impact Assessments or Important Business Services identification, they could develop a new methodology which incorporates the below suggestions.

Firms could combine several areas of existing practice to classify critical or important functions:

• Consider Business Impact Assessments (BIAs) and Business Continuity programmes which should have documented a methodology and confirm a firm’s existing view on the identification of Critical Functions. A structured BIA is key for DORA with Article 11^[7] stating, “The BIA shall consider the criticality of identified and mapped business functions, support processes, third-party dependencies and information assets, and their interdependencies”
• BIAs can be overlaid onto the Important Business Services^[8] identification methodology. This might assess a wider group of internal and external functions and services and includes additional assessment criteria such as intolerable harm / material detriment, substitutability, customer volumes, time criticality and firm safety and soundness.
• Consider the definition of a Critical or Important Function^[9], i.e. “a function, the disruption of which would materially impair the financial performance of a financial entity, or the soundness or continuity of its services and activities, or the discontinued, defective or failed performance of that function would materially impair the continuing compliance of a financial entity with the conditions and obligations of its authorisation, or with its other obligations under applicable financial services law;”. Additional criteria under this clause will include non-compliance with regulatory obligations and principles for business, impact to financial performance, outsourced Control function, outsourced function requiring regulatory notification, functions material to the delivery of Important Business Services and services that are essential to the real economy.

So, following the identification of these Critical or Important Functions (and services for firms who choose to include those in DORA scope), the identification and subsequent mapping of critical information assets should follow a similar path.

Mapping information assets

Firstly, firms must identify the ICT assets and Information Assets required to support Critical or Important Functions. This can be completed using a top down or bottom-up^[10] approach.

Once understood, firms then need to map the information assets that flow in and out of the critical ICT assets, (including where they come from and where they go to) and the information assets that are stored in the critical ICT assets. This mapping should clearly show the links between critical ICT and Information Assets and where interdependencies exist. Firms will also need to show where internal information flows out of the firm into third-party ICT Assets and where external third-party Information Assets flow into internal ICT Assets.

Once mapped, it’s then essential to revisit Article 8 to ensure that “all sources of ICT risk… cyber threats and ICT vulnerabilities” have been identified and documented for all critical information assets.

DORA mapping is a significant undertaking for firms. The scope and scale of the mapping and the visualization and linkages required is most easily achieved in a technology platform and there is a strong argument to say that this is the only way to achieve DORA’s intended outcomes.

Aligning language

Often, the challenge of mapping information assets and data flows comes when determining the criticality of those assets across the multiple domains which contribute to operational resilience and DORA. Those domains will have entrenched practices to determine criticality and will include multiple stakeholders across cyber risk, ICT Risk, ICT, Applications, Networks, Infrastructure, Platforms, Third-Party Risk, Operational Resilience, Data and Business Continuity.

Those domains may all use an aligned criteria to classify criticality but may use different language to reflect that classification.

The final steps therefore for firms when identifying and mapping critical assets is the alignment of criticality taxonomies for ICT and Information Assets across DORA-contributing domains.

Without an aligned taxonomy, in a fast-moving regulatory change programme, vital classifications of information assets may fall between the gaps. Failing to identify those information assets could create future issues for Critical or Important Function resilience, response, or recovery during or following an operational disruption.

For example, using a criticality assessment methodology such as the one we outlined earlier, the ICT function may classify an asset as critical because that asset contributes to the delivery of a Critical or Important Function. The ICT function calls that asset “critical” because that’s how they’ve always done it. However, the Data function, using the same criticality assessment criteria, identifies an Information Asset as critical but their naming convention says that the Asset is an “A5”, because that’s how they’ve always done it.

In that case, DORA practitioners need to develop an approach which ensures that the criticality classification used by different business functions is recognized, documented and the assets recorded appropriately. There should be no need to reclassify all resources according to a singular taxonomy, instead firms might develop an alignment methodology to ensure accurate translation.

Conclusion

Mapping ICT and Information Assets is one of the key value drivers of the DORA programme. It feeds the overall ICT Risk Management Framework and enables a firm to pinpoint existing vulnerabilities in ICT and Information. As the regulation states, without this foundation, “it is very difficult to have… a correct adaptation of the rest of the elements of the ICT risk management framework”

Therefore, the identification of Information assets, critical data and critical data flows requires the development and application of a robust firm-wide methodology to determine criticality.

For firms struggling to make sense of information assets and critical data mapping, it’s time to build that methodology.

This article was originally published on Corporater Blogs

 About the authors

For more information, visit corporater.com

More on

• Business Continuity
• Case studies, sample tools & practical guidance
• Regulations, standards and guidelines