The Tough Stuff: Creating a Policy on Policies

4
4069

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 [email protected]

4 COMMENTS

  1. Agree with you, but there should be a unit that act like a custodian for all company policies, procedures etc.

    Also the Delegation of Authority (DoA) should clearly articulate the approval process for each policy. As a matter of fact, many policies requires BoD approval because it touch the BoD duties in away or another & some policies will need AGM approval e.g Remuneration Policy.

  2. Excellent article Kristy. As a compliance department of one, I cannot possibly maintain all the policies within organization. My compliance plan consists of policies and regulatory guidance, I do not want to muddy up the compliance plan with detailed operational policies. I direct the creation and maintenance of those to the department affected by the regulation. i.e. billing compliance, coding compliance…etc.. I require each affected department to take ownership of their compliance by creating operational policies that in turn tie back to the Risk Section of the Compliance Plan document/guidance affecting their area/department. I will then include the department operational policies by listing them in the Compliance Plan document for that department. As I am in the process of my annual review of the Compliance Plan, I am going to consider some of your suggestions. Thank you

  3. This is a great overview! Having traversed this important issue several times, I note that it also is important to identify relevant stakeholders for each policy, and to consult them in developing new policies and revisions. Their insight is vital, as they ultimately champion compliance with the resulting policies, procedures and processes. I also found it helpful to issue a set of drafting guidelines, with templates and examples. Finally, designating a central reviewer, and allocating their dedicated effort, ensures success with consistency in tone, defined terms, and presentation.

  4. Kristy: This is a great overview, and I certainly agree that each company is unique so there will be lots of variations in terms of how these documents are managed, maintained and approved over time. I have a small point I hope to clarify in terms of your definitions though. I have always thought that Policies should document the high-level “what” must be done or not done, and I agree that these are statements that should not change mich over time. It is equally helpful to document the “why”, but I think the “what” statements are critical to drive efficient and effective behavior.

    Another point that is not included in your overview that I think is important to note it that all Policies and Procedures both document required behaviors that must be followed by all workers. While Guidelines provide supporting information so workers are provided with clear ways to implement the policies and procedures without having to “reinvent the wheel” on their own, other approaches might be equally effective, so other common and effective implementation approaches can be added over time as they evolve.

Comments are closed.