Policies first then procedures or procedures then policies: Or, what comes first -- the chicken or the egg of document retention?
By Cary J. Calderone, Esquire
“Should we create our policies or our technology procedures first?” This is a question I am asked frequently by data consultants, lawyers, and IT people. At first I believed the question was a sign that people were looking to shift responsibility for document retention management away from themselves and onto someone else. (Who could blame them given all the new regulations and rules now in effect? See FRCP Changes) While shifting responsibility is a valid real-world motivation, in reality, the question itself raises good issues to consider by anybody considering implementing or updating an electronically stored data retention policy . Like many good questions, the answer is not a simple one.
My general rule would be to create a good policy according to your legal and compliance requirements and then coordinate personnel and technology to support that policy. This would put the burden on Legal and/or Compliance to set the policy and then IT to deliver it. However, by “good” policy I mean something that should take into consideration the capabilities of the current hardware, software, and usage. Too many times in my early technology consulting days I would be retained to find and recommend a software program that could do XYZ and I would research the client’s existing applications and discover they already had programs with the ability to do XYZ, or something extremely close to it. However, nobody knew enough about their own applications to work towards the desired result. So, I saved them some good chunks of money and everyone would conclude that I had brought value-added service to the gig.
Given that background, setting policies without looking at current systems, usage, and the reasons behind them is not a prudent practice. One could argue that Google provides a good example of one end of the spectrum. Their overriding company policy is “don’t be evil .” It follows that every action by every employee would be in an effort to support that policy. Sure must be nice for an attorney to represent a client with that honorable and well-published policy in place…makes for a great opening argument in any case or hearing. On the other hand, what might be an acceptable policy for your current “technology” (or lack thereof) may not fit well with your company’s plans for growth and innovation, and as I like to recommend, becoming a “lean, mean, litigation-ready fighting machine .” If the drivers behind policy are more related to operations, company image, security and other non-technology factors then you may indeed need to make an investment in new software and hardware and possibly personnel and training too in order to adequately support any re-aligned policies. And until the infrastructure is in place, changing your existing policies would not make sense, especially if they have already been approved, followed, and battle tested.
Furthermore, the ultimate goal is to manage your electronic data according to reasonable standards for your industry and under the legal requirements that govern it. The greatest sounding “policy” in the world will not help you if your practices and procedures do not support it or, at worst, conflict with it. If one policy statement says “X” and another policy describes, “Not X but Y”it will not withstand even a cursory legal challenge and therefore will have failed you in one of its basic functions. And, while I would not ever champion a mediocre policy, one that is strictly followed and supported would probably protect you more than a grandiose policy that is thrown out as a sham because it was not followed or was contradicted by other company documents and policies.
In conclusion, the answer to the question of what comes first is: it does not matter – and it does. Both Legal and IT, and other supporting departments will need to work together to make any policy legitimate. So, bringing both/all groups into the process early is the best and most prudent practice. Start by determining what your current policies are, where they are published, and why they were created. Then you can work to edit/modify/replace them with joint understanding of the likely overall costs and benefits.
