IG and RM Policies and Procedures: Best Practices

Here are a few best practices for developing and implementing policies and procedures that will get you on the right track toward putting in place a Records/Information Governance Program. I describe three areas where companies have the most problems. The first two are really prerequisites to developing your policies and procedures. The third addresses how you should design your policies and procedures.

Clarify your hierarchy of objectives for justifying and prioritizing your policies and procedures.

This isn’t the trite point it seems. Most companies get rolling with records management policies and procedures without understanding what business objectives the Records/Information Governance Program or the policies and procedures are supposed to fulfill. They therefore have no clear idea regarding how the objectives should be prioritized or how the inevitable conflicts between them should be resolved.

Taking action to reduce risk is good, but it costs money and can often impact productivity. So it would be good to have an ordered set of records management (RM) objectives against which any RM policies and procedures should be evaluated. The idea behind an ordered list of objectives is that since it is in descending order of priority, you have to adequately satisfy the first objective before you can satisfy the second, and so on. Here’s my list, and it’s worked in almost all cases (sometimes with tweaking):

  1. Ensure compliance with regulatory and legal requirements
  2. Reduce the cost of compliance
  3. Reduce the impact of compliance on the organization
  4. Don’t be invasive; don’t hinder the organization’s performance or user productivity
  5. Ensure that RM policies and procedures, and the actual practices that implement them, are all consistent with the organization’s mission
  6. Enable (or at least don’t hinder) later “offensive” enterprise initiatives (e.g. line-of-business initiatives using enterprise content management [ECM])
  7. Provide some “offensive” business benefits now (primarily to encourage compliance participation and secondarily to improve productivity or decrease operational costs now)

Clearly define your territory.

The simplest way to explain it is that there are three fundamental subsets of information in your company, with the second contained in the first,and the third contained in the second:

  1. All the information in your company—or for simplicity, we can narrow it to all the electronically stored information (ESI)
  2. The likely discoverable information (a smaller subset than all your information)
  3. The declared records (which may be a smaller subset of the likely discoverable information)

You can’t develop clear policies without taking this step of defining your territory, and you certainly can’t communicate your policies to your employees and hope to have them follow them without having taken this step. Very few organizations do this, however. Another way to put the problem is that your company’s information ranges in terms of risk, value, and manageability:

  • Some of your information scores high on all three dimensions. These are typically the most important documents in your company, and they are almost certainly managed very well by your records program.
  • Some of your information scores low on all three dimensions. These are the trivial and harmless items littering your shared drives, hard drives, and email boxes.
  • Most of your company’s information is somewhere in the middle, being of indeterminate value, risk, and manageability. Some of this stuff is records-worthy. More of it is relevant to discovery.

Your territory (the information in your company) therefore presents gradations of risk and relevance, and you must address it with gradations of focus and different approaches.

  • You shouldn’t just take a simplistic narrow view and focus exclusively on the declared records (a much smaller subset of what’s relevant to compliance, risk, and discovery), or your company will be hopelessly exposed.
  • On the other hand, you shouldn’t just take a simplistic broad view by “declaring every document a record” and treat them all equally, or you will dissipate your focus and resources and fail to manage even your most vital declared records.

The good news is that you’ll be fine if you take either a narrow or broad view, with gradations that effectively address the likely discoverable information in the middle. It doesn’t matter so much which one you take. What does matter is that you follow through on its implications. In other words, a best practice is
to clearly:

  • Define declared records narrowly—but then also address the gradations of non-records, from high-value and high-risk non-records all the way down to the trivial and harmless non-records, or
  • Define declared records broadly—but then address the required differential treatment of higher- versus moderate- versus lower-priority records

You will end up with tiers or categories of information. Many organizations end up with three basic categories (high, middle, and low priority). They then handle the different types in something like the following ways:

  • Tier 1: The currently declared records they keep as records, putting them in a rigorous enterprise standard ECM system with an RM module and managing them as declared records. They sometimes also find that some document types were not classified as declared records, but are very high value and high risk. So they redefine them as declared records and manage them as records in an ECM system.
  • Tier 2: Some document types they keep as non-records, but move to the rigorous enterprise standard ECM/RM system. They manage these documents in the ECM system without declaring them as records and managing them with the RM module.
  • Tier 3:  Some document types they keep as non-records on (better managed) shared drives. If they’re lucky, there’s not much left here, since the bulk of it has been moved or disposed of according to general rules regarding low-priority transitory documents. But most companies aren’t so lucky; they may have tens or hundreds of terabytes. At the bottom of this tier is ESI that’s not worth worrying about, or spending resources to sort in a granular way, or managing in an expensive repository. Just keep or dispose according to general rules.

Design your policies and procedures with a clear, logically tight, hierarchical structure.
I mean several things by this. Your policies point up and down. They should logically connect to your company’s business and RM goals (up) and be actionable (down). The sole justification for any policy is that it should ensure the fulfillment of the RM objectives it serves (e.g. to ensure compliance). Policies connect to the procedures below them, and procedures in turn face up and down: up to the policies they must fulfill, and down to fulfillment by actual human actions. If you perform a procedure, you should by definition have fulfilled its associated policy—which in turn should have furthered your explicit RM objectives.

I’ll be posting more soon on the topics of what’s wrong with most policy and procedure design for information governance and RM, and how to do it right, so stay tuned.

Rich Medina
Rich Medina
I’m a Principal Consultant and co-founder of Doculabs, and the resident expert in using ECM for information lifecycle management.