The Tough Stuff: Creating a Policy on Policies

Post By: Kristy Grant-Hart

One of the most frequent questions I’m asked is, “While Compliance owns compliance-related policies, I’m being asked to manage all of the policies in the company.  This seems ridiculous.  Who the heck should own all the policies?  HR? Compliance? Operations?”

To no one’s surprise, the answer is, it depends.  Upon what does it depend?  The company’s structure, size, function makeup, and of course, the availability of time, technology, and human resources to manage policy architecture.

While there isn’t any one answer about who should own the polices or policy architecture, there are best practices for managing this beast. The best way to start is with a “Policy on Policies” that governs the policy architecture. A Policy on Policies should always include:

The Outline of a Singular Structure

Nothing is worse than disparate policies from different departments with no commonality of structure, branding, or style.  People like to see consistency in the structure of policies so they know where to find the information they need.  A Policy on Policies should lay out the structure required for all polices.  Better yet, it should contain an appendix that vividly displays each piece of the standard policy, along with the font, style, and branding required.  This will help ensure that all policies are consistent.

The Requirement of a Policy Owner

Each policy needs an owner.  This can be harder than it sounds. The truth is, for many policies, there are several stakeholders.  For instance, in responding to a data breach, Information Technology, Information Security, Legal, Compliance, Privacy, and Human Resources will all likely be involved.  Which should own the Data Breach Response policy?  It doesn’t really matter – what matters is that someone does.

The Requirement to Note the Policy Approver

Just as policies need to have an owner, they also need to have an approver.  The approver can be either a person (e.g., Bob Smith) or a role (e.g., Vice President, Human Resources).  An individual needs to be responsible for the content of the policy.  Make sure it is clear who has approved the policy so the approver can be identified and asked questions if the policy language is ambiguous.

A Process for Approval

In many companies, policies are issued willy-nilly by anyone who decides one is warranted.  This can lead to extreme policy creep.  One of our clients at Spark Compliance had 224 policies, another well over 300.  Guess who reads these policies?  No one.  Unread policies lead to confusion and disorder.  A Policy on Policies should include a process for approval of all policies.  Common choices for this include the requirement that a Senior or Executive Vice President (or higher) agree that a policy is necessary, then that person signs off on the final version.

Version control

Version control is critical for policy maintenance.  Employees should be able to easily discern which of several versions of a policy is the most recent.  Version control can be maintained numerically (v.1, v.2, v.3) or by date.  Best practice is to keep the version number/date in the footer of each page of the policy so it is obvious which version is being read.

Instructions for what Happens when a New Version is Rolled Out

So you’ve got a shiny new version of your policy?  Great! How can we ensure that the correct one is accessed going forward?  Include information on where policies need to be deleted and updated in the Policy on Policies.  It may be as simple as stating, “Previous versions must be removed from the intranet and other places in which they are posted.”  This will go a long way to ensure employees are only able to access the most recent version.

Statement on Board Approval

In some companies, all policies must be approved by the Board.  In others, only key policies need Board assent.  Either way, make clear the chain of command required for the most critical policies.  Best practice is for most compliance policies to at least have Board review (especially the Code of Conduct and Anti-Bribery Policy).

A Structure for Procedures and Guidance

In many companies, the word “policy” is greatly overused.  Previously I wrote of companies with more than 200 policies.  If there are 200 “policies,” it’s likely that a huge number of those are actually procedure documents.  Others are likely guidance on use of the policy. When we work on policy architecture, we recommend that clients separate four ideas – policies, procedures, guidance, and forms.

• Policies represent the why – why do we forbid bribery?  Why do we need to ensure our drivers are licensed and carry insurance?  Why do we abide by trade sanctions?  These statements are universal to the company and are unlikely to change.
• Procedures represent the how – how are we going to implement controls to stop bribery and mitigate bribery risk? Procedures are likely to change frequently, so they should be in a different category from policies.
• Guidance represents clarity – they guide employees in decision-making and navigating the nuances and application of the policies and procedures. Guidance is not the why or the how – instead it helps employees to consider grey areas and how those grey areas should be resolved in line with the policies and procedures.
• Forms represent consistency – they give a consistent way of managing data. Forms can change easily, like procedures.

By implementing a strategy of separating policies from procedures, guidance, and forms, the architecture will be built on a hierarchy, leaving the policies as the most important and critical piece.  The policies won’t change much or ever, but the procedures, guidance, and forms can change easily.

Instructions on where policies should be Stored

Policies should be available in an obvious place so employees can find them easily.  This may mean that there is a policy portal on the intranet, or that each department has a SharePoint site where its policies are kept.  Regardless of where the policies live, there should be uniformity where possible so that employees don’t get confused.

Policy architecture and ownership are always difficult subjects.  By using the checklist provided above, your Policy on Policies will guide the architectural process smoothly for maximum useability and efficiency.

About the Author: Kristy Grant-Hart is the CEO of Spark Compliance Consulting, and the best-selling author of “How to Be a Wildly Effective Compliance Officer.”  She can be reached at kgranthart@sparkcompliance.com