On 8/23/07, Steve Morgan <[log in to unmask]> wrote:
>
> Although it was a very long time ago, I remember one case from about 15
> or 20 years back that will always stick in my mind. It was Piper
> Aircraft and the judge called their retention schedule a sham. Some
> records that met their retention were destroyed and some were not. The
> judge determined they were selectively destroying records.


GREAT point, Steve.

The inconsistent application of a retention schedule can be cited as being
essentially the same as not having one at all.  This is one of the reasons
we have approvals of destruction requirements rather than an indiscriminate
application of practice .  I recall this discussion going on a few weeks
ago, and while it's all well and good to say "RIM should be in the process"
and notified of all legal holds, etc. that's not always going to happen.

SOMEONE needs to make a decision prior to destruction of the records, and
that someone should be the one identified as the records owner.  Once their
signature releases the records for destruction, then it's not RM that is
making the decision. In our case at least, that's outside of our
responsibility.

Something else to think about here is the old "regardless of form or format"
issue with respect to destruction.  There are many organizations that manage
records in both paper and electronic form, even though they generate records
primarily in electronic form now.  If you are destroying your paper records
according to the retention schedule, you should have the capability to do
the same with your electronic records.

Yeah, yeah, and don't roll your eyes, because in the case of a discovery
action... if you aren't applying the same retention schedule to ALL FORMS OF
YOUR RECORDS, the same claim of "selective destruction practices" can be
made.

Larry

-- 
Larry Medina
Danville, CA
RIM Professional since 1972

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]