You've hit a hot button for me here. (Actually several.)

Do 
not ever classify a retained copy, image, or archive of electronically 
stored information as a "backup" unless that data is truly being 
retained for disaster recovery purposes. It is absolutely critical that 
you clarify the use of your organization's terminology when referring to
 additional stored instances of electronically stored information.

A
 copy of data that is retained solely for disaster recovery purposes, 
cycles with a fair amount of frequency (daily or weekly), and is not 
needed to be retained for more than 60 to 90 days (and typically not 
more than 35days) is a backup. Backups are generally not easily accessed
 to retrieve information and often require that the primary system be 
suspended in order to be restored -- in other words, you need acts of 
god in order to get to the data. I'll let your attorneys quibble about 
the language to use regarding burden. You should govern backups by 
policy, not necessarily by retention schedule. The reason is that by 
putting "backups" on the retention schedule, you've created a record 
type of "backup" and effectively designated that "backups" are a system 
of record. I suspect many folks will disagree with me on this point. My 
sense is that you want to do whatever you can to ensure that you have a 
clear distinction between operationally necessary disaster recovery backups and data maintained as a system of record as an archive copy of the data.

A
 copy of data that is retained for record-keeping or compliance purposes
 is an archive (I hate that term, but most IT types understand it). An 
archive should be tied to your retention schedule and be retained to the
 schedule, not retained to the whim of IT or described as a "backup". 
Regardless of the means used to create the copy, it is imperative to be 
very precise in your descriptions and retention of copies of ESI.

In
 defining backups and archives, also take care to define "test" data. 
Many organizations find that they have control over backups and 
archives, but the data center is chock full of tapes of test data that 
are being retained on whim of the database administrator. Since test 
data often originates as live data, you want to make sure that those 
tapes are not retained longer than live or archived data. It's also 
critical that this is not defined as a system of record on a retention 
schedule and should be governed by separate policy unless test data is 
required to be retained by law or regulation.

There is no 
requirement anywhere for periodic archives of data (frankly, the 
frequency of backups is likewise seldom required by law or regulation). 
Those decisions are business / IT decisions based upon the 
organization's risk profile and system limitations. Some organizations 
may want to have a monthly data snapshot retained for compliance 
purposes. Some may do that annually. Some may never do that.

As
 noted by others, SOx does not have retention requirements on anything 
except workpapers, which are generally the domain of internal and 
external SOx auditors. That seven year thing is another hot button. 


Patrick Cunningham, CRM, FAI
[log in to unmask]


"Perpetual optimism is a force multiplier." 
-- Colin Powell

________________________________

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]