Solution
The bank had worked with me for over a year before deciding it was time to transfer me from another one of its compliance engagements to assist in this effort. My background in Sarbanes-Oxley, risk management, and process improvement paired well with the project’s requirements.
The current process of evaluating data elements for financial reporting impacts was undefined and inconsistent. We needed to (1) evaluate the current state and (2) establish a sustainable process to identify new or modified key data elements. After learning about the current challenges, I collaborated with the SOX and Data Governance teams to define 10 steps making up the basic framework:
Inventory the population of data elements
This step requires coordination between many different teams depending on the size and nature of the organization. In our case, we had to speak with model developers, model governance, data governance, and credit risk management. We included all data elements used in each of the processes. 
Agree on a methodology to evaluate the criticality of each data element
We needed to rank each data element using a meaningful, quantifiable scale to compare significance. One formula you can use is (S = N * I) where:
S = significance
N = Number of business use cases for which the data elements are used
I = Impact (0-5). We assigned each number a dollar threshold with five being the highest.
The science isn’t perfect for several reasons I won’t get into here, but it was close enough to rank our KDEs.
Determine the bar for what’s key vs. non-key
Similar to calculating a materiality threshold for SOX scoping, we needed to land on a ‘significance score’ output that would make a data element ‘key.’ A KDE could be defined as any data element with a significance score over X.
Enhance process documentation and system diagrams to include KDEs
We layered KDEs on flowcharts and diagrams to illustrate the data flow from source to financial statements. This helps visualize each step in the process and where we need to inquire about controls.
Identify control gaps
There should be internal controls for all Instances where KDEs are created, transferred, or transformed. If not, this is considered a gap. All gaps should be compiled and evaluated to determine the next steps.
Remediate control gaps
No different than any other remediation effort. You can create a new control or modify an existing control. We often found reconciliation controls where we could add the KDE to cover the gap.
Report the results
Although stakeholders were updated throughout the engagement, it’s essential to summarize the results for Management, so they understand the additional efforts still needed.
Identify future triggering events that could lead to changes in KDEs
Just as important as identifying the existing KDEs and controls – we needed to prevent repeating this comprehensive exercise in the future. Specific triggering events and systematic flags were created to notify appropriate personnel when new data elements or inputs into our analysis had been changed.
Define the process of evaluating KDEs after triggering events
This process allows management to mitigate risk much earlier by evaluating the KDEs in real-time.
Finalize, approve and implement the new process
Update the policy and procedural documentation for the changes. Ensure executives are held accountable, and the new process is formally approved.
0 Comments