Operating Systems

Compliance Options: Embedded Compliance

Has this ever happened to you?  You have a job to do, so you make a plan and then execute it. The work is done, you’ve checked it twice, and you’ve completed all your follow-on documentation and reporting. You breathe a big sigh of relief. Except—out of the blue—someone tells you there’s another thread of activities to be done.  You have to start over, from the beginning …

When it comes to compliance jobs, this is an all too frequent situation. Why? Compliance—like governance and risk & controls—is a dispersed problem with dispersed solutions. If you’re going to be thorough, you’d better know where parts of the problem are likely to be embedded.

Luckily, this is predictable. Compliance requirements and/or solutions, again like governance and risk & controls, tend to be found in the following 10 distinct places in organizations:

1. Centralized locations: Centralized teams such as data Governance offices (DGOs), Privacy Teams, or Compliance offices may have a list of requirements. They also may implement certain types of solutions and controls, such as training programs, policies, and standards. They probably also hold high-level descriptions of compliance programs, requirements, and success measures. If you know you’re going to be required to design and/or implement a technical compliance control, it may be useful to check with the centralized team for context and expectations.

2. Federated locations: Especially in larger enterprises, it’s common to have business and technical silos (programs and business units and departments) working independently, but with guidance from a centralized group. These groups also may be able to provide context for the specific compliance requirements you must deal with.

3. Decentralized locations: In your organization, do some managers of projects or data stores operate independently? Will your compliance control serve multiple teams or data repositories? If so, you may need to get requirements and success measures from several sources that may not even be aware of each other.

4. Embedded in hand-off points: Data flows; that’s its nature. What happens when data moves from the control of one party to another, such as partners, vendors, data suppliers, outsourcers, or applications? Is your compliance requirement to secure the data during that segment of its journey? To ensure that quality—or another data characteristic—adheres to regulatory, contractual, or internal requirements? If so, is it OK to do a one-off, manual process, or is the compliance control expected to be embedded in the process, so it’s self-perpetuating? Better find out; the answer will influence your approach.

5. Horizontally across an organization: Some of the toughest compliance requirements are those expected to be applied to processes that span an entire data flow. These requirements tend to actually be a collection of compliance controls for which it can be tough to iron out accountability agreements. You may need to call in some brass to negotiate success for such requirements.

6. Embedded in projects: Project protocols and processes can enforce governance and compliance through mechanisms such as checkpoints, standards and policies, processes, controls, documentation, and gathering proof of compliance. It can be difficult to convince project teams to undertake extra work that isn’t in a project plan, so your best bet is to ensure that compliance requirements are reflected in the official plan.

7. Embedded in data management: Often, steady-state data management processes can be used to enforce policies and standards specified by governance and compliance. Again, if data resources are going to be expected to do extra work, your best bet is to have that work legitimately specified.

8. Embedded in operational management activities: Compliance officers dream of having compliance steps “disappear” into the very fabric of everyday work. For this to happen, look at your business workflows. Where can you embed governance and compliance activities?

9. Embedded in Governance, Risk, and Compliance (GRC) activities: Here’s another chance to leverage other groups’ efforts. Does your compliance requirement involve, for example, monitoring data flows? If so, chances are you’re not the only group looking at that flow. Try to find another team addressing a related concern so you can “piggyback” your activity.

10. Embedded in other governance and architecture processes: Every organization has a collection of teams, task forces, and special projects that address specific activities that are subject to governance. data governance and compliance goals and controls can often be satisfied through activities already being successfully completed by other mechanisms and programs, such as change control, modeling, or IT governance. Z