Save time with unbiased, independent feedback on vendor solutions.
Watch weekly bite-sized webinars hosted by IANS Faculty.
There are many components to a data governance program, but the most critical element transcends all others – the understanding that data governance is a practice, not a project. Building a practice for the entire organization to follow ensures
you can move through the initial project into the numerous iterations it will take to build the practice into business as usual – where the practice itself is simply part of the everyday functions of the organization.
Key steps for building a strong program include determining program ownership, conducting a data inventory, assessing data quality, implementing data tracking, integrating the program at both a tactical and operational level, and ensuring a plan for succession
so that maintainers can take over once the building phase is complete. You should also form a team consisting of:
At that point, you can build a design to reflect the ideal case, work with the business to identify how the ideal case will face difficulties and then abstract away those challenges. Once those pieces are in place, the overall governance plan can move
forward at a rate that can be absorbed by the organization.
The first element to consider is who will own the program. While it is common to assign an IT staffer to this role, it is critical the person running the program views data as both an asset and a risk. Some people may want to retain multiple copies of
data “just in case.” Similarly, others might want to delete data as soon as it isn’t needed any longer. The program owner must enforce reasonable retention and destruction rules, as well as more complex rules involving which roles
may access which data, how data is to be stored, how it is to be monitored and several other elements.
The owner will need deep experience in how the organization operates, as well as an understanding of how the technology works.
Once the program ownership is identified, all data elements used within the organization must be inventoried. The inventory process will require the development of standardized data definitions, e.g., personally identifiable information (PII), Social
Security number, Payment Card Industry data, customer metadata, private data, user names, passwords, etc. The data definitions should cover all elements of data, even if it may not be feasible to implement a complete definition set at the beginning
of the program.
While the definitions/classification of data should be against an idealized standard, a secondary abstraction process will be needed to balance the flexibility of the business against accurate descriptions of data. This abstraction will need regular review
as the technology matures.
It will also be important to identify how the inventoried data is used. The use of data helps to identify how complete different data sets may be. It is critical to recognize that it is possible for data sets to be over-complete. If your organization
is sending data of insufficient quality to a process, a certain element of re-work will be needed to address the issue. Similarly, if your organization is sending too much data through a process, the overall risk level of that process is raised. This
concern is particularly strong when it comes to integrating with third parties – who often receive far more data than is strictly needed to perform their function.
By identifying how data quality is measured and how it can be improved, it is possible to lower the overall level of risk throughout the organization while also streamlining inefficient processes.
With critical data elements identified, it becomes possible to track how data is used. While there are certainly technical challenges to doing so, tracking data as it moves through your organization can help you integrate the overall data governance program
with other aspects of the organization and add verification steps to different transfer processes.
Most parts of a data governance program operate at the strategic level – identifying what needs to happen for the program to benefit the entirety of the organization over the long term. However, it is also important that the program integrate with
the tactical aspects of the organization, tying into other programs like compliance, incident management, vendor management, document management, change management and any other standard processes that may exist.
By tying into the incident management process, for example, you give responders the ability to involve the appropriate people much earlier in the response process because the runbooks can be written to branch appropriately when certain data types are
uncovered. Vendor management can be similarly streamlined by requiring different levels of risk assurance depending on the types of data being accessed by the vendors.
Operational integration is also critical to consider. When the data governance program helps streamline operations, saving people time, it will be adopted quickly. In contrast, if the program is seen to be disruptive, requiring more of people without
freeing up their existing cycles, it will be resisted and may ultimately fail.
Success with operational integration often requires identifying where existing pockets of data governance may exist and working to expand those or duplicate them in other areas of the organization. By identifying those individuals who are already treating
a form of data governance as a business as usual practice, it is possible to leverage them as internal advocates for your changes, improving your chances of success.
Succession planning is also critical. Many teams consist of individuals who are natural builders – focusing on creating new technology and processes and thriving as they implement them. However, other individuals are maintainers and resist change,
preferring to maintain the status quo.
Success requires moving from the building phase to the maintaining phase, which usually requires succession planning for when the builders either leave the organization or move on to other projects.
Once all the above elements have been determined, it should be possible to form a team that consists of builders and maintainers, from across the entire organization, and put attention on all aspects of the program so it can be grown organically within
the existing structure of the organization.
To that end, you should:
Once those pieces are in place, the overall governance plan can move forward at a rate that can be absorbed by the organization.
Although reasonable efforts will be made to ensure the completeness and accuracy of the information contained in our blog posts, no liability can be accepted by IANS or our Faculty members for the results of any actions taken by individuals or firms in
connection with such information, opinions, or advice.
February 21, 2024
By IANS Research
Learn why cloud IR is critical to security and not just another box to check. Find guidance to get started building a strong cloud IR program.
February 15, 2024
By Alex Sharpe, IANS Faculty
IANS Faculty member Alex Sharpe discusses the risks around AI adoption and provides governance guidance to make your AI launch safe and mitigate risk.
February 13, 2024
By IANS Faculty
Learn how to how to use NIST to modify secure baseline configurations to account for risk and improve security posture.