I am in the process of trying to develop a similar policy with regard to hosted 
systems.  The issue is that it can be extremely difficult and probably 
impossible to identify discreet records within such a system.  At best we can 
apply retention and disposition to the discreet records created FROM the 
system ("produced records"), but when we destroy those records the data 
used to create them still exists (and likely the record can be easily recreated).

The approach in my policy is to treat these produced records the way we 
treat all records, even though the data behind them continue to exist.  Then, 
at the time that the system is closed (e.g. the organization upgrades to a 
new system) the most appropriate retention is applied to it, one that best 
describes the main function of the system (potentially difficult to determine, 
certainly) or that best adheres to the spirit of the retention schedule.  That 
would be true even if the data were migrated to the new system.  IT loves 
this approach, because these days they are stuck with the task of keeping old 
legacy servers spinning even though no one's accessed the data in years.

This is a policy only in writing so far, not in practice, so I can't give concrete 
evidence as to its effectiveness.  The next step is putting it in practice, and I 
would say that the final step is some kind of confirmation from the courts that 
this is an appropriate way to manage hosted systems.

List archives at http://lists.ufl.edu/archives/recmgmt-l.html
Contact [log in to unmask] for assistance
To unsubscribe from this list, click the below link. If not already present, place UNSUBSCRIBE RECMGMT-L or UNSUB RECMGMT-L in the body of the message.
mailto:[log in to unmask]