1. Building and Refreshing Retention Schedules John Montaña 1

2. What’s a Retention Schedule? Conceptually, it’s nothing more than: A list of records or record types A retention period for each item on the list In reality, it’s: An index and finding aid A policy and work instructions A legal compliance document 2

3. The Overall Plan for Building a Schedule 1.Identify your records 2.Organize them into a meaningful structure 3.Determine retention periods 4.Vet the result 5.Repeat the above until satisfied 3

4. Change Management Over Time What changes? Potentially anything Laws Jurisdictions Systems Record and data types Risk tolerance Organizational culture 4

5. Revising a Retention Schedule How often? As often as need be – but emerging standard is every year or two What to review? Bucket structure Legal authority Retention periods Example records A very old schedule may bear little resemblance to what’s actually there 5

6. Outcomes of Review Old schedules may need extensive revision, or scrapping entirely Brand new schedules likely to undergo some revision the first couple of cycles Mature, regularly updated schedules usually need only small revisions, absent significant organizational changes 6

7. Issues High Stakes Product liability Regulatory actions Lawsuits Adverse publicity Undesirable political attention 7

8. Regulatory Landscape Possible Issues: Heavily regulated organization Multiple jurisdictions Requirements that: Overlap Conflict 8

9. Jurisdictional and Preemption Issues: Potential concurrent state and federal jurisdiction and foreign jurisdiction Potential concurrent jurisdiction by different agencies Different regulatory regimes for different business processes Cross-border issues of regulation 9

10. Regulatory Compliance Regulators: International, state, federal, local, industry The list will depend on your industry: Pharma Banking Utilities Etc. Everybody will have some: Wage and hour OSH Tax 10

11. Utilities FERC State Utilities Commission NARUC NERC 11

12. Insurance State Insurance Commissions State Securities agencies SEC Frank-Dodd agencies 12

13. Pharmaceuticals FDA EU Medicines agencies European national pharma agencies Germany France Belgium Switzerland Other national pharma agencies – Asia, South America, etc. Mercosur, PIC scheme, WHO, ASEAN 13

14. Banking FDIC Treasury State Banking Commissions SEC Farm Credit Administration, etc., etc., etc. etc., etc. 14

15. Issues with Statutory and Regulatory Language Vague or outdated statutory language Poor match between records contemplated by law and those actually found No or few implementing regulations when the statute calls for them Unreasonable retention requirements Verbatim state adoption of federal requirements What if federal requirements change? 15

16. A Common Problem Laws require the keeping of “records” but: “Record” as used in most laws is outdated – it assumes discrete, permanent objects such as paper records Many modern records are reports from databases or other electronic repositories The “record” often used for business purposes is often an nth generation version of the data originally collected. 16

17. Still More Problems U.S.-centric solutions may not comply with requirements in foreign jurisdictions Foreign requirements may be burdensome in the U.S. Changing legal landscapes – i.e., Frank Dodd Failures and uncertainties mean increased costs and risks 17

18. And More Problems Conflicting and burdensome legal requirements No data map No full organizational knowledge of system Personnel shifts and changes Data migration Legacy systems Orphan systems and repositories 18

19. And More Problems Distributed systems Virtual addresses for data The “Cloud” Bad management practices no standard data structures No standard indexing, etc. 19

20. Particular Requirements Controlling laws may require: Specific information in a record Specific formats or media Specific records or kinds of records Retention in specific locations or systems 20

21. So, What do We Do? Legal requirements usually require interpretation Theoretical legal requirements may conflict with reality Risk management is always an issue Your job is to balance these against cost of compliance 21

22. Development of Record Series Two sources: Information collection What we know we have Legal research What the law requires us to have Iterative process: Research suggests new record series Record series suggest additional research Repeat as needed 22

23. Some Issues to Resolve Big versus small buckets Resolving conflicts Consistent implementation Updating and staying current 23

24. Big Buckets v. Little Buckets No hard and fast rule, but: Bigger buckets means: longer retention periods Less detail More potential conflicts Smaller buckets means: Longer, more complex schedule More administrative overhead 24

25. Databases and Electronic Systems Often cross geographic boundaries Often co-mingle data types May have limited purge/disposition capabilities May force purge categories on you Dynamic Databases may make legal comliance very problematic 25

26. Differences Between Paper and Electronic Data Sets Data structures and separability Granularity of management Ease of disposition Organization or lack thereof 26

27. Data Structures and Separability Paper system example -- accounting: Many record series Payables Receivables Ledger Etc. Electronic system One big database “Record series” are merely reports out of the db The reports are duplicates 27

28. What This Means As a practical matter, there’s only one record series, or at most a few You probably cannot meaningfully assign different record series and different retention periods to different parts of the database You’re going to go big bucket, like it or not 28

29. Extreme Cases Enterprise content systems (SAP, Peoplesoft, etc.) Buckets are very, very big May encompass many record series that would not be traditionally related May be virtually impossible to reconfigure once installed Make sure you know what you’re getting into before you go live 29

30. Granularity of Management Could go either way: Great big buckets, or Extremely detailed granular management on a document-by-document basis It depends on: The particular software and system How it’s configured 30

31. An Example of Granular Management Personnel files Many individual items within a personnel file are legally regulated It’s possible to assign different retention period to these individual items No one ever does Why? No one will go through them to cull individual pieces of paper 31

32. Privacy and Maximum Retention Periods Common in Europe, increasingly seen in the U.S. – e.g., HIPAA Very challenging to implement Often very granular May only implcate part of a larger record Creates serious issues in ERP systems (e.g., SAP, Peoplesoft) The more jurisdictions you add into the equaton, the worse it gets 32

33. Conflicts Record series with conflicting legal requirements Your bucket’s too big – break it out Legal conflict between jurisdictions Break out jurisdictions or go so smaller buckets 33

34. Legal Research and Analysis Preliminary assessment of scope of research Jurisdictions Industries and topics Research Analysis What do requirements mean in aggregate? How do we deal with Ambiguous requirements? Statues of limitation? Absence of requirements? Conflicting requirements? Concurrent jurisdiction? 34

35. Resolution of Legal Issues and Conflicts Do the research – define the boundaries We must do X to be minimally compliant with everything Map the research to the schedule Identify the conflicts Re-work the schedule to eliminate conflicts Exceptions: Jurisdictions Unmanageable repositories and systems 35

36. Regulators Know thy regulators’ behavior: Do they audit? How often are they supposed to audit? How often do they REALLY audit? Do they ask for records older than the legal requirement? Are you prepared to refuse them if they do? Do they ask for other things they aren’t really entitled to? Are you prepared to refuse them? 36

37. Risk Management Know thy legal and risk environment! What kinds of lawsuits, regulatory actions and other disputes do we get into? What kind of money are we talking about? What kinds of records are involved in them? How far back into time do these records go? What’s our comfort level? Do we like to have lots of records in these cases? 37

38. Common Mistakes Poorly chosen buckets result in very long retention periods – e.g., “environmental records” Record series don’t correspond to any real world data objects When in doubt – PERMANENT! Excessive complexity 38

39. Bottom Line Know the legal boundaries Make sure you understand how legal requirements map to your records Make sure you understand the high-risk.high-value repositories and systems Make sure you understand the high-risk/high-value issues Make sure that record series or categories corrsspond to data objects you can actually manage The final retention schedule must accommodate all of these Remember --- a retention schedule is not a static document. It lives and changes, just like your organization 39

40. Questions? John Montaña Montaña & Associates 4340 South Pennsylvania St. Englewood CO 80113 610-255-1588 484-653-8422 mobile jcmontana@montana-associates.com www.montana-associates.com twitter: @johncmontana 40