This special feature is being published in association with the Data Governance Conference that will be held in Orlando, Florida on December 4-6. For more information, please visit: www.debtechint.com
Data Governance is not new. As long as there has been data, people have governed aspects of its creation and use. So why is it that Data Governance has become such a hot topic?
One answer is “complexity.” The number of factors and stakeholders involved in making data-related decisions has grown exponentially in recent years. As a result, it’s often not advisable to use
informal governance mechanisms to make data-related decisions, to protect data, and to manage the risk that data can represent for an organization. Instead, formal governance mechanisms are
employed.
Why has complexity increased? Two factors have contributed greatly: data integration and compliance requirements.
Data Integration
In recent years, most organizations have experienced a slow but steady move from silos of information to integrated systems and data. Every integration point represents risk: risk that data will be
misunderstood, misused, misappropriated.
And it’s not just that our data is AT risk. It also REPRESENTS risk, since inappropriate disclosure of sensitive information results in significant costs – direct and indirect – to the
organization supposed to protect that information.
So, increased data integration results in increased data-related risk. What do we do with risk? We manage it. You don’t have to be a data professional to complete the following line of reasoning,
which begins with risk and ends with governance.
The Risk-to-Governance Accountability Chain
- Data is AT risk, and data REPRESENTS risk.
- All risk requires a management strategy.
- Risk Management strategies are implemented through controls.
- People (through their roles) must be accountable for human-based controls and also for technology-enabled controls.
- Governance sets the rules of engagement for accountabilities.
What does this mean for data professionals? Business managers now expect IT and data managers to be fluent in the language of Risk Management. As data stakeholders, business groups expect to be
included in discussions that identify data-related risks, and they expect to be involved in developing and approving risk management strategies, controls, and accountabilities.
Stakeholders’ growing expectations mean that Decision Rights for data-related decisions are more complex. Often they are too complex to be managed in an informal manner. The job of allocating
Decision Rights (and making decisions according to that allocation) becomes too complex to be treated as just another management task.
When this happens, it’s time for traditional management to be supplemented with formal governance.
The Post-Compliance Paradigm Shift
What were you doing in the year 1999? If you worked with data or IT systems, chances are you were helping prepare for Y2K. Speed was of the essence – the calendar couldn’t be stopped, and our
systems had to be ready. How this was accomplished did not seem as important as when. The battle cry became “Just Do It!”
The years 2000 through 2002 had a theme of their own. We were all in a race to web-enable our applications. This called for new architectures, new development approaches, new ways of thinking about
what we do. “Time to market” constraints often made it impossible to deliver systems that were developed with the discipline of earlier times. Once again, “Just Do It!” was the rallying cry of
many data and IT teams.
And then came the Sarbanes-Oxley Act of 2002 (SOX). Among other things, it requires that CEOs and CFOs of publicly-traded companies attest to the accuracy of their financial data. Moreover, it
requires them to assess and report on the adequacy of their company’s controls over that data.
It took awhile for the ramifications of this particular requirement – Section 404 – to sink in. Eventually, however, the full effect of the law became clear. Shortcuts that had been taken during
the “Just Do It” era were exposed. The magnitude of the work required to comply with SOX became clear.
The effort to achieve compliance was orders of magnitude more complex than simply “doing” the work required to get systems and applications operational. According to this Post-Compliance Paradigm
Shift, a data-related job isn’t done until we
- Do the work
- Control it
- Document it, and then
- Prove compliance.
All four steps have to be completed, because Compliance is Not Optional! And to make things more complicated, SOX mandates formal risk assessments and requires that controls adhere
to an industry-recognized controls framework. A best practice-based approach to managing risk simply isn’t good enough.
Of course, Sarbanes-Oxley isn’t the only compliance challenge. Several other laws that are now in effect also require us to protect “sensitive” data.
For instance, Gramm-Leach-Bliley (GLB) includes “The Safeguards Rule,” which requires all financial institutions to design, implement, and maintain safeguards to protect customer information.
HIPAA (The Health Insurance Portability and Accountability Act of 1996) requires groups that work with Protected Health Information (PHI) to ensure its confidentiality, integrity, and availability.
They must also protect PHI against threats and disclosures. And The Payment Card Industry (PCI) Data Security Standard requires Visa and MasterCard Members, merchants, and service providers that
store, process or transmit cardholder data to:
- Build and maintain a secure network
- Protect stored data
- Maintain a vulnerability management program
- Implement strong access control measures
- Regularly monitor and test networks.
How do we stay in compliance? How do we work to numerous – and often complex – data-related requirements? How do we meet operational goals for our data while also meeting the needs of stakeholders
from Compliance, Risk Management, Privacy, Security, and other departments?
It’s tough. Achieving success means working to complicated plans that are constantly being re-evaluated and adjusted to ensure that meeting one set of stakeholders’ needs doesn’t inadvertently
take another group out of compliance.
One key is understanding all those requirements and turning them into a set of well-aligned policies and procedures. But this raises questions that are much harder to answer than they were in the
pre-compliance days of silo applications.
- Who decides how to interpret requirements and how to apply them to Data Administration?
- Who decides which risks should be managed through procedural controls, and which deserve automated controls?
- Who decides which requirements take precedence?
Clearly, in a post-compliance world, these questions need to be decided at the enterprise level. They are too important to be answered by a single manager of any Business, IT, or Data group. Look
at a corporate org chart, and you won’t find any one box representing a role who is equipped to independently make such complicated decisions.
This type of decision-making needs to be made by boundary-spanning teams representing multiple branches and levels of the corporate org chart. And before such an assemblage can make these
decisions, higher-level (meta) questions must be answered. Who is empowered to make such decisions, and how, and when, and using what processes?
Answering such meta-questions is one of the jobs of enterprise-level Data Governance. And that is why Data Governance has become such a hot topic in the post-compliance world.
