DaveWentzel.com            All Things Data

What is a Data Retention Plan (Part 2)

This is Part 2 of my What is a Data Retention Plan series.  If you are a data architect you really need to understand data retention from many different perspectives.  In the last post I covered technology considerations for data retention.  These are probably no-brainers for most data architects.  Now I want to cover some of the functional issues around data retention that I have seen.  Hopefully you will find this information useful.  

The Data Governance Team

Certainly you will need to rely on your data governance and risk management teams for final determination of any data retention policy, but you need to bring some intelligence to the table too to help guide decisions.  You aren't just the implementer, take an active role in the decision making.  Some examples of data retention concerns...

  • Show an interest in understanding the business from a legal and regulatory perspective.  In banking there are BASEL Accords (BASEL I, II, and III as of this writing).  Know them if banking is your industry.  Everyone knows about SarbOx in accounting/finance, but do you know precisely what the rules are?  If you work in accounting/finance you really need to know the subsections, most especially Section 404.  Likewise, there is HIPAA in healthcare.  Don't just know a summary of the rules that you read in the paper, KNOW THE RULES.  Be able to speak intelligently.  
  • Understand non-regulatory and industry standards.  It would be pointless to work as a data architect in the insurance industry without understanding ACORD.  ACORD is a set of industry standards, specifically industry standard forms, but also covers XML, EDI, even e-commerce standards in the industry.  Best to always stick with industry standards.  Don't reinvent the wheel only to find out later your wheel isn't as round as a competitor's wheel.  
  • Subscribe to business journals, subject matter blogs, attend conferences in the field, etc.  Get immersed.  Don't just rely on regulation to guide data retention policies, know what the industry standard is, and what your competitors are doing.  Example, I worked in an industry where there were no data retention regulations, however, the industry was highly regulated and subject to audits by regulators with zero notice.  Do I really want a regulator snooping around data that I don't want them to see, especially if I don't need it operationally?  Sometimes we store too much data that can get us into trouble.  If that is the case, then maybe it should be purged.  
  • Understand state and local laws too.  And international.  Many people forget this.  For instance, if you do any business in Europe you need to be concerned with the Data Protection Directive.  Essentially this says that there is a right to privacy that all persons have and that personally identifiable information can never be disseminated.  Compare that directive to what we have in the United States where privacy is not a constitutional right.  Further, in Europe the Directive outlines that data cannot be stored or transferred to systems in other countries that do not legally guarantee the same level of protection.  Now assume you are architecting a database that will store employee certification and training data for an international corporation.   Can I store employee information for all employees in a single database in the US?  Probably not.  
  • Always get your legal department to sign off on any data retention plan.  Then ensure everything you do to architect the data retention policy is handled to that plan.  You don't want to be found negligent years later.  
  • Consider getting third party verification of your data retention plan.  We do this for the same reason we consult our legal department.  

In the next post I'll discuss electronic discovery concerns.