Data management risk register – Free template

Organizations have several lines of defense in addressing various risks, at the project, department, or enterprise level and it all start with the awareness and monitoring of these risks. Risks also occur within and from data and data management areas (data quality, data security ,data architecture, etc.) as well as data governance and so data management/governance risks need to be taken into account, monitored, and mitigated in order to reduce the regulatory, financial, reputational, operational risks and so on, to the organization. Data management risks are usually handled within the CDO org structure, but that too can depend on the organization and they can be managed centrally or within each data management area, project, or department. Regardless, the tool that is most used to keep track of these data management risks is a data management risk register.

Spoiler: I’m offering a free template of a data management risk register at the end of this article.

Data management risks can be tracked at the program level for the entire organization. Or they can be handled a bit more siloed at a project level or from the perspective of a particular department and in that case the risks are not only related to data management. The most common way of tracking it is from a project perspective, though the idea of tracking it holistically at a data management program level or enterprise-wide level is becoming more popular.

Regardless of how you choose to track these risks, here are the risk attributes that I typically include into a risk register (split into 3 categories):

1. Risk details

Risk ID: A unique ID is always a great idea to have for putting together any register in order to reference the data management risks quicker between all data management stakeholders such as the project and program sponsors, technical staff, business analysts, business users, and so on.

Date raised/ Date added: This date field helps you keep track of when data management risks are submitted, which can help you identify how long a risk remained unaddressed and when it was made known to those managing the data management risk register as well as its stakeholders.

Risk type: This is just a way to categorize your risks. There are many ways to create these categories, but here are some options: Solution, Timeline, Budget, Regulatory, Security, Resources, and Scope.

Risk description: A summary of the risk and any details to offer context and insight into the risk itself, what data, system(s), processes, reports, etc. are known to be affected because of this risk.

Status: Use this field to track how many data quality issues have been identified and submitted, are in progress or resolved. I recommend using the following options: backlog (initial status of an issue), assigned (when resources have been identified and assigned), in progress, testing, closed/resolved, and on hold.

Impact description: Provide a summary of what will happen if the risk is not mitigated or eliminated.

Probability level: Use this drop-down field to flag the likelihood of the risk occurring. I use a 1 (low) to 5 (high) scale, but you can also use the following categories: critical, high, medium, low. Most just use a 1-3 or low to high scale. It’s up to you to decide what is best suited, just make sure to define them to the end user and make it consistent across the following 2 levels: impact and priority.

Impact level: Use this drop-down field to flag the level of the impact if the risk occurs. Use the same categories as above.

Priority level: This drop-down field will help you prioritize the data management risk register items. Always start with the higher number/level. This is a calculated field based on the values entered in the probability level and the impact level. Note: You can also choose to refer to it as the “Severity level”.

2. Resources & Ownership

Owner: This is the individual who will manage the data management risk.

Submitted by: The individual that logged the data management risk. This could be a project coordinator, a project manager, a business analyst, or a business stakeholder. It’s all dependent on the process on how you are handling the process of submitting and logging the entries in the risk register. It’s always good to keep track of the name of this individual in case you need to reach out to them for further answers and details.

Project: You can choose to have a data management risk register for a particular project or a program. If you have one for a particular program, such as the Data Management Program, then I recommend keeping tab of the project(s) that the risk is referring to as it will help keep a better tab on the project risks and aid you in your communication to the project manager.

Project area: Not mandatory, but it provides further details on the stage of the project that is impacted by the risk. It could be as high level as: evaluation, development, deployment.

Project manager: For the reasons stated above, list the project manager that should be informed about the risk. Most often they are the same individual that submitted the risk.

3. Risk Mitigation

Action type: A drop-down field to flag the action that you should take for the risk at hand. The options are:

• Accept – Here you accept the risk it is with no action. You can use this action when the likelihood and impact are low.
• Transfer/ Share – There might be risks that were brought to your preview, but that you either need to transfer to another party, for example the Legal Council Department of your organization, or share that risk with another party.
• Mitigate – This is probably the most likely choice for the majority of your risks.

Mitigation action(s): Describe what can be done in order to lower or to eliminate the impact or probability of the risk from occurring.

Contingent action(s): At times, even if the probability of the risk materializing is low, it can still happen. In those cases it’s good to have a contingency plan to outline what actions should be taken if the risk happens.

Progress on actions: This field would contain your status update on the particular risk. Note how it is progressing, what actions have been taken and conclude with the final resolution.

Reassessment date: It’s a good reminder to add to see when the data management risk needs to be reevaluated.

A very important aspect to all the fields listed above is consistency. Ensure you’re tracking the dates in the same format, that you have guidelines on when you should fill out the progress on actions (ideally after each change, summarized by week), that you have a standard on the entries, that you always name your resources in the same way (with first and last name, for example).

There are many ways of tracking your data management risks in a risk register, but here is my template. What else do you think should be included?

Free template: