In the previous article we covered Business Elements and Data Elements, however we didn’t cover how they can be used in conjunction with the terms “Critical” and “Key”. These two terms are part of a solution that enables a way to prioritize managed information, this article explores how these terms can be used to scope elements into bite sized chunks.
Before we go into “what” they mean let’s understand “why” we need them and understand how they are scoped to a specific perspective.
Why we need Critical and Key labels
Data is nearly always collected before it is managed. So whenever a data management effort is started there is a backlog. Commonly this involves tens, hundreds or even thousands of data platforms – that is a big backlog!
Given the backlog exists, how do we start to make demonstrable progress? Simply put, we have to prioritize. Ideally we solve some high value (i.e. critical, or key) items that are meaningful to management. This helps us move out of the intangible theoretical space into concrete value, which can drive management acceptance of the issue (and therefore funding).
From here you need to move on to the other known problem areas – as we well know, there will always be areas that need help! It is also important to reiterate the point that to sustain this effort funding is needed (either explicitly or as part of BAU), so being able to demonstrate progress provides evidence to enable continued data management initiatives. This is especially true if, as a result of your efforts, the cost to the business goes down in a tangible way (e.g. improvement in recognized Tier 1 Capital requirements due to data quality improvements on RWA).
Unfortunately it is human nature to forget how bad things were in the past and only remember the good. So, a little like data, you have to keep making progress to be seen as valuable. However for Data Management to succeed over time we cannot just retroactively fix things after they become a problem, a parallel effort to establish sustainable data management fundamentals must be baked into all new data driven initiatives. As the organization’s data management capability matures this retroactive fixing strategy can lessen. The goal is to move Data Management from a Data Defense posture to one that can allow the organization to capitalize on the value associated with quality Data Assets.
Interestingly, in our experience it is rare that data has fundamentally bad quality, but more often the case is that it is incorrectly used. As these situations are found, performing Root Cause Analysis (RCA) on these misunderstandings may change the way data is manufactured which then stops the backlog from getting bigger. Often resolving one or two root causes allows enough breathing space to move away from pure defensive posture to at least the middle road where data management starts to help find positive value in your data.
However before we can get to this state of nirvana we need to be positioned in a way that can demonstrate progress. This is where the Critical (and Key) classification come in.
Understanding how Context Affects Classification
So now we know why we need Critical or Key data classifications, let’s look at what exactly they are.
One of the most important things to understand about data classification is that it is “in the eye of the beholder” (EOTB).
In other words, there isn’t a one size fits all for classification (e.g. critical elements to a data storage function will be very different to the credit control team’s calculation of a “credit scorecard”). When organizations are asked about Critical Elements it is typically within a single context and assumed to be enterprise level or “top of the house”. However this doesn’t then prevent individual functions from managing their own set of materially significant elements, but these have a different EOTB with a different context.
Aside from Togas, very few things are “one size fits all”, the same is true of data classification.
Critical elements are recognized as the most impactful in each context (e.g. BCBS239 is one context, GDPR is another). The reason for the context varies by use case. Recently for Financial Institutions these have been heavily influenced by regulations but others also exist. Key Elements are often considered elements that support Critical Elements (assuming they have not already been classified as critical).
For example, in the Financial Institution world there are many context specific regulatory examples, but for demonstration purposes we will highlight three representatives for our example (BCBS 239, DFAST, DFS 504) with fictional elements:
This illustration attempts to show that for a given context they each specify the importance of the element to them.
Looking at all the crossing lines it is hard to understand what element relates to what, and what priority it has. However, in a tabular form it is easier to see:
From a holistic Data Management perspective for these three example contexts we can see that EL4 gives us the most return across all the contexts, as it is critical to two contexts and key to the third. EL6 and EL7 are also referenced by all three. However, we can also see that we cannot sensibly tag anything that is “Key” or “Critical” at the Element level – it must be within a specific context (aka the EOTB).
The one last thing to cover in this introductory view into Key and Critical is how these classifications actually help us in Data Management.
Each classification may come with a minimum set of standards that must be met, so being tagged with a Critical tag in a given context implies certain controls need to be in place, while Key may have a less strict set of controls.
A fictional example for a context (any one of the above example contexts would do):
Controls / Rigor
Within the scope of the context:
- All places the element is stored and transferred need to be recorded.
- Attestation for End-to-End lineage.
Same as Key, but in addition:
- Data Quality must be executed up to a defined level.
- Executive personally accountable to content.
Normal Data Management rules and standards apply
Finally you may have picked up throughout this article we have consistently referred to “Elements” rather than “Data Elements” or “Business Elements”. This has been entirely intentional, as dependent on your context and scenario you may be chose to classify at either level. We didn’t want to go down the rabbit hole of should it be CBE or CDE – we have our views, but that again is for a later article.
However we hope at the end of this article you can see the rationale of using both Key and Critical to support your Data Management activities.
There will be additional follow up deeper dive articles on ways is more to leverage this classifications strategy in your Data Management program.
We are always interested in feedback so if you have questions, disagree with what we say and would like to engage in debate, or want more information on Ortecha please contact us at firstname.lastname@example.org