Save time with unbiased, independent feedback on vendor solutions.
Watch weekly bite-sized webinars hosted by IANS Faculty.
Establishing strong data management and governance requires assigning clear roles (especially for data ownership) and an iterative approach that slowly moves the needle away from unowned/unmanaged data repositories to a modern environment where all data
is fully understood, secured and managed. This piece explains how to put a workable data management and governance process in place.
It’s critical to define roles for data management transformation and understand how they should function. We recommend identifying the following:
However, that approach presumes in situ improvement and not fundamental technical and cultural transformation. The greater challenge requires additional roles and a more rigorous approach to the analysis and moving of data.
To successfully make such a transformation, a one-time data inventory process will not be sufficient. Instead, an iterative approach will be needed to identify data that can be moved to a new, structured environment and then to reassess the data that
remains. The principle at play will be one of continual winnowing, parceling the centralized data out to a large number of structured repositories.
However, it is critical to recognize that, while the understanding of the overall approach is required to start, it is best not to start with the winnowing. Instead, a strong analysis of roles and responsibilities should be in place first, driving from
a presumed future state of a large number of small data repositories managed by different individuals.
While a senior leader is needed to oversee the program, and the builders and maintainers must be identified, those roles are just for the data management component. Those roles alone cannot drive cultural change. Organizations should consider the following
additional roles defined for each new data repository:
The data owner is responsible for overseeing and delegating tasks to ensure data is available, minimized,
up to date and protected throughout its lifespan within that data owner’s repositories.The data owner is also responsible for ensuring data retention and destruction practices run as they should for those repositories.
It is natural that, over time, the individuals assigned to specific roles will move to other work. It is critical the roles not be left open or the system will break down. When the organization loses a reporter, it should identify how much of the reporting
was automated and will continue in that person’s absence. A new individual should be prioritized to learn the reporting process and maintain the reporting scripts. While the reporting practice can continue without a role for a period of time,
it must be understood that the quality and accuracy of the reports will likely degrade over time and, if not maintained, will drive the data owner to make the wrong decisions.
When an educator leaves, that role should be replaced according to the cadence of the particular knowledge set. For example, PCI DSS updates on a yearly cycle and, even if the standard does not change, enough clarification documents are issued by the
PCI Security Standards Council that an annual cadence is needed to stay current. In contrast, if an expert in intrusion and exfiltration moves on, that role may need to be replaced within a month, because attack groups update their capabilities much
more quickly than a standards body makes updates.
Data owners should be replaced immediately, even if it means bringing in an unrelated senior manager until a long-term replacement can be found. While the teams know what they need to do, and are generally good at doing it, the message an open data owner
position sends to those teams is that data security and compliance is unimportant and is just a checkbox exercise. For data transformation to be successful, there should never be an absence of leadership.
Once the new roles are understood, the creation of the newer “data niches” can begin. The form a data niche can take varies drastically, but as a general rule of thumb, data should move counter-entropically. In other words, data should become
more structured as it goes through this process. Examples:
As the form of each repository is defined, the appropriate data owner, educator(s) and reporter(s) should be assigned, and each should sign off on requirements (educator), implementation details (reporter) and operational readiness (data owner) before
the new repository goes live.
As each new niche repository is moved to an operational state, the data in the centralized system should be archived and removed from the centralized system. Ideally, such data would be archived to an air-gapped system. Even if the system is a virtual
machine that may simply be turned off, the networking should be adjusted so that when it is turned on, it is not re-exposed to the network, but instead to an archival DMZ that must be accessed via VPN. This approach keeps the data from doubling and
causing internal conflicts and loss of data control.
As this process continues, the centralized repository will shrink through the archival process and new niche repositories will be implemented to replace the legacy systems and legacy data methods. It is critical to recognize this reduction process is
part of the migration itself. It is common for migrations to occur and the older systems retained “just in case.” However, such data storage areas are sources of data leaks, because no one is responsible for maintaining or even monitoring
them. Many data breaches have come from older systems that were simply never removed properly.
As the process continues, the concentration of data confusion will grow on the legacy repository. Data confusion shows itself in the form of files that have no owner, legacy systems that “just run themselves” and files that exist because they
were important to someone who no longer works at the organization. It’s important this confusion be resolved, so these issues can be addressed. In many cases, the best approach may be to simply delete that data, but cultural norms may prevent
that solution. Once the legacy repository reaches a high enough concentration, it is often best to assign ownership of the entire repository to a single role – such as the head of the data team – and task them with sorting out the rest.
The task of this role is, however, not to solve the problems, but to eliminate the confusion, so the remaining files can be assigned to appropriate owners and migrated to the niche repositories.
Eventually, when no data is left in the centralized location(s), it/they may be removed.
Transforming data while transforming a culture can be tricky. To improve the chances of success organizations should consider:
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.
September 21, 2023
By IANS Faculty
Learn why CISOs Need D&O Liability Insurance Coverage now more than ever along with guidance to help minimize potential cyber liability risk.
September 19, 2023
Discover the diversity of IANS Faculty's real-world expertise. Learn how our faculty members can help you solve your most challenging security issues.
September 14, 2023
Learn how to use a three-step approach to defending and managing public and private APIs while avoiding common mistakes.