Operationalizing data governance means putting processes and tools in place for defining, enforcing and reporting on compliance with data quality and validation standards. There is a life cycle associated with a data policy, which is typically motivated by an externally mandated business policy or expectation, such as regulatory compliance.

A data policy is effectively a contract that specifies what the expectations are for compliance with a set of business/data quality rules, the specification of levels of acceptability for compliance with those rules, the process of notification when a noncompliance is detected, and the escalation strategy when identified issues are not adequately addressed.

There are three operational aspects to defining and managing data policies. There is a “user-facing” facet that must represent all of the qualitative information associated with a data policy. There is a “life cycle” facet that must capture the status of policies as they are defined, reviewed, approved and moved into production. And there is what we might call an “automation” facet that would feed the automated validation of data and notifications when data does not comply with users’ defined expectations.

In essence, this defines the starting criteria for a data model for representing data policies. There is a structural component for capturing the text associated with the policy definition, including:

• Source business policy – The authority under which the data policy is being defined. To use the example from my prior post, a device manufacturer’s policy for documenting data lineage might refer to the section of 21 CFR Part 11 that specifies that each step of a computerized system must be identified and documented.
• Description of the policy – This provides the high-level business details of what the policy is intended to enforced.
• Roles and responsibilities – This names the roles that participate in the policy and what the responsibilities are for each role.

There must be data elements to capture the state of the approval process, including:

• Author – The name of the individual who drafted the policy.
• Reviewers – The names of the people who are reviewing the policy.
• Approvers – The names of the people who must approve the policy.
• Current status – The stages through which the policy has progressed (initial draft, initial review, approved, etc.).

And there must be data elements that capture the automated operationalization:

• Measures – One or more business rules defined in a way that can be consumed by a data validation service for automated implementation.
• Levels of acceptability – The percentage of the pool of data being tested that must comply with each rule, along with the cadence in which the data sets are tested.
• The metrics – Weights associated with each of the measures that are aggregated, if requested.
• Data stewards – The names of the data stewards to be notified when a violation occurs.
• Escalation chain – The sequence of individuals to be notified if an issue is not resolved.

The business rules would be accessed by an automation tool (such as a data profiling product) that would assess the level of quality and provide a report. A monitoring service can review the results and compare them to the levels of acceptability, and generate notifications when the levels of acceptability are missed. An incident reporting and tracking system can use the roles, responsibilities, notifications and escalation chain data to supplement its use for tracking the status of incidents.

These are just starting points. Hopefully this will motivate more in-depth discussions of what would need to be designed into a data model for managing data policies.