When policy is not coupled with a well-planned compliance and evaluation program, the agency will likely fail to broadly adopt improved data management practices. Furthermore, if a compliance plan is absent, the agency will be at risk.
Failing to ensure compliance with new requirements can call attention to gaps and weaknesses, akin to writing the organization’s next audit findings and delivering them to its Inspector General with a neat bow on top.
Agencies often view the creation of policy, directives, guidance, and instructions as a self-contained task. Policy shops are established, and their measure of success often is the publication of some number of policy documents. Once a policy is published, the lines of business are left to interpret the policy and develop implementation solutions from the ground up. When we look at the Federal Government, policy shops can tend to take a hands-off approach to implementation on the basis that it is best to provide the program maximum flexibility to implement policy in a way that best suits their organization. This approach very much emulates the relationship between the Federal Government and States, where the Federal Government sets a policy and program directive but allows the States wide latitude for implementation. This approach allows States to innovate and test approaches that suit their demography, culture, and particular needs, and this can result in successful pilot programs that can be adopted and adapted by other States. However, this process can take time and result in failed experiments. While this type of incubation can be beneficial for creating large-scale social and economic programs, it is not necessarily an efficient way to implement enterprise data governance policy.
Most organizations are driven to revamp or create a new enterprise data governance policy because there has been an abundance of innovation, new solutions, and problem-solving at the “State” level within the organization. These solutions (often disparagingly referred to as shadow IT) can create challenges—particularly with respect to data being interoperable or sufficiently documented to withstand audit or regulatory scrutiny. For example, in the absence of an enterprise data governance program, two different grant programs designing solutions to capture applicant information may do so separately in their own silo. These two different solutions may not use the same data standards, data naming conventions, or other aspects of data management that would allow the two programs to integrate easily. As a consequence, analyzing grant data from both programs for insights into important factors that could make both programs more effective (such as identifying risk indicators that a grantee will fail to deliver) can become significantly more difficult and time-consuming. If, in the long term, the grant programs were to be merged into a single operational platform, integrating them would be significantly more difficult than if an overarching data governance policy had been implemented from the programs’ inception.
Establishing an enterprise data governance policy is a good first step to bring consistency, interoperability, and other benefits to a data ecosystem, but if the governance program stops with policy and guidance that only establish high-level principles such as “new and existing data systems must adopt standards to ensure data interoperability,” then it is not likely that an actual change would occur in organizational processes or staff behavior. Sticking with the grant example, for a data governance program to be more effective, it would need to take an active role in designing standards that could work for both grant programs, facilitating discussions and brokering an agreement on the standards for specific data elements. It should also include a compliance program with a deadline by which the standards must be adopted to help ensure that those standards are actually being implemented.
Successful data governance policy programs should integrate policy into implementation by using their compliance program as the bridge between policy principles and driving change in data management practice. Further, the accompanying compliance program should paint the picture of what implementation looks like by establishing concrete expectations of what will be considered successful compliance with the policy. These expectations should be published as part of a compliance policy or procedure so that the lines of business have a yardstick by which to measure their efforts. Ideally, this should focus on the changes the lines of business would need to implement. For example, if a new data governance policy included a principle of strengthening data quality, the compliance document could articulate that lines of business must establish specific parameters for monitoring data quality aligned with the needs of the program they serve. An example of a data quality parameter that the compliance program could evaluate would be that grant recipient payee data will have less than 1 percent of missing values to help ensure timely and accurate delivery of payments. An effective compliance program should be able to envision a path to evaluate successful compliance. If it cannot do that or needs to rely on a program official’s attestation of compliance, then it is not reasonable to expect the lines of business to be able to comply with a policy directive on their own.
When data governance policy shops end their efforts with the publication of a document, they can leave program and business leads without direction on prioritization, timelines, and the necessary level of effort and resources needed for implementation. In many cases, the absence of this information can cause what was previously a willing coalition of business support for better data governance to get cold feet and hinder the passage of new data policies.
As policy is developed and socialized with an approving executive council, a draft compliance and evaluation plan should also be presented. This plan should always have a phased approach for the simple reason that it will take any agency time to change its processes, but also to help the lines of business prioritize and stage work.
A phased approach typically has several elements:
- Allow for some passage of time before a policy goes into effect. It is prudent to have a period between the publication of the policy and when that policy comes into effect; otherwise, there can be extended periods of time in which the organization is out of compliance with its own policy. A good rule of thumb is to have the policy become effective no sooner than 6 months after it is published. During that 6-month period, the compliance program should provide training for staff to aid in adopting new data management processes that will allow them to comply with the new policy. Training should be provided in a number of venues, including Communities of Practice for systems owners, data scientists, analysts, and (most importantly) data stewards. Training should be complemented with communication strategies, such as stories on an internal website and emails to stakeholders with links to guidance and recordings of training. The goal of the compliance program during this phase is to raise awareness of the policy change and offer guidance on how to successfully implement the policy in a manner that will meet compliance evaluation standards.
- Define the scope of data and/or IT systems that will be subject to compliance. The compliance program should also clearly articulate the scope of what it will evaluate. Put simply, it should define what is in scope versus what is out of scope. Defining the scope will depend on the specific aspect of data management being evaluated, but defining the scope based on data or IT systems is often a good place to start. Many data governance programs, early in their maturity, want to govern all data, but that is generally impossible and impractical. Data can include a spreadsheet on someone’s local hard drive, and typically, it is not valuable or cost-effective to manage that level of data in an enterprise program. Data that is critical to the business is a good starting place for scope. For instance, customer data, such as grant recipients or account holders, is always a critical asset to running a program and managing that data to improve quality, availability, and other aspects of data is valuable. In the first year, a compliance program could focus on customer data, while data such as its own human resources data might follow in a subsequent year. Limiting scope based on IT systems housing data can also offer a straightforward way to scope policy compliance. Many organizations rate their IT systems for criticality, and that rating can be used to limit the scope of a compliance program, for example, by focusing on the systems with the highest rated risk to the business. The bottom line is that a compliance program cannot and should not evaluate all data in an organization and so must, early in the process, define the scope of data that will be subject to the policy.
- Adopt a risk-based approach to evaluation and the timeline for expected compliance. Compliance programs often fall back on random sampling to guide the order and structure in which they evaluate lines of business for compliance. A better use of resources may be to establish a risk-based approach—one that sets more granular priorities for the order in which in-scope data or IT systems will be reviewed. Those with the highest risk should be prioritized first, and an openly published evaluation schedule should state which systems or programs will be evaluated, and in what order. For example, if the scope of policy compliance is grant recipient data, then a compliance review schedule should focus first on the highest-risk grant programs, which could be the ones with the largest grant awards, those most scrutinized by Congress, or some other risk factor. The compliance program should publish and socialize its review schedule so that lines of business can plan to work toward a specific date to reshape their data management processes to comply with policy. In addition, the compliance program should have clear guidance that is published and well-socialized regarding the timeframes businesses would have to make further changes if they are found not to be in full compliance during an evaluation. This information is critical to enabling lines of business to manage the work associated with new policy directives. Finally, a best practice is for policy to indicate that lines of business are not required to be in compliance sooner than the date of their compliance review. This maximizes the time that lines of business have to introduce change, and—if a line of business is hit with a new priority, it can partner with the compliance program to adjust its place in the compliance review schedule to give them more time.
This approach allows time for change management, including communicating with an array of stakeholders beyond those involved in approving policy, so that the component organizations can plan for and execute the necessary work, while creating a sense of accountability. In the same way a good project manager can drive a project toward meeting milestones and completing work, a compliance program can be a driving force to keep an organization progressing toward improved data management.
Some agencies are reluctant to establish a compliance program to accompany policy. After all, agencies have an Inspector General and the U.S. Government Accountability Office to identify their weaknesses. However, compliance and audit are not the same thing. Auditors must stop at identifying a flaw and directing an agency to fix it. Because a data governance compliance program is a management function, it can partner with the program to close any identified gaps. It can provide coaching, subject matter expertise, successful examples used by other programs, and other resources to aid the program in successfully standing up new data management practices. For example, if the compliance program were evaluating the implementation of data quality parameters, it could collect examples of these parameters and how they were implemented (e.g., the use of automated dashboards that refresh daily with the percent of blank routing and account numbers in a grant recipient’s payment profile). When it discovered a line of business struggling to comply with the new policy requirement, these examples could be shared, and a meeting with staff from a program that had successfully complied was arranged, providing practical assistance for the non-compliant group to establish a timeline for compliance with regular progress check-ins.
This type of supportive, hands-on coaching delivered with a tone of “we are in this together” can be a powerful tool in helping an organization transform and implement its data management practices. A compliance program that both supports and holds programs accountable can do this. One agency cleverly named its compliance program the “Data Management Support Program” to emphasize its intention to partner with programs on their data management journey rather than simply critique weaknesses.
Compliance and evaluation are intrinsically linked to successful implementation, and new data governance programs that link policy development with compliance dramatically improve the adoption of new enterprise data management practices.
Joah Iannotta, Ph.D., boasts 20 years of experience in data governance and analytics. Currently with ABSG Consulting Inc. (“ABS Consulting”), Global Government Sector, Dr. Iannotta has held senior leadership positions in both private industry and the federal government. She’s renowned for establishing impactful data governance compliance programs, notably as Senior Vice President at one of the nation’s largest banks, and for her contributions as Acting Deputy Assistant Commissioner for Data at the U.S. Treasury.
.
Follow Brilliance Security Magazine on Twitter and LinkedIn to ensure you receive alerts for the most up-to-date security and cybersecurity news and information.