RECMGMT-L Archives

Records Management

RECMGMT-L@LISTSERV.IGGURU.US

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
"Julie J. Colgan" <[log in to unmask]>
Reply To:
Records Management Program <[log in to unmask]>
Date:
Thu, 12 Jul 2012 13:02:21 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (78 lines)
Hi Angie, etal,

I know this topic has come across the list at least once in the not too
distant past, but it is a good one.  I'm glad to see it pop up again
particularly because I do think this is an area in which we are lacking
sufficient standards/best-practice that are tailored to our needs
specifically.

I view the issue as this:

1) You manage records/info in the normal course of business, according to a
documented, approved and reasonable policy/schedule, and that
policy/schedule was developed, and its resulting actions are carried out
consistently, in good-faith.

2) Sometimes you have to prove to someone (courts, regulators, auditors,
etc.) that you, in fact, are managing information in the normal course of
business, according to a documented, approved and reasonable
policy/schedule, and that the policy/schedule was developed, and its
resulting actions are carried out consistently, in good-faith.

In my mind, the question being asked (or that should be asked) is what is
the best way to prove reasonable, consistent, good-faith actions?  Whether
metadata - all or select - is part of the answer is secondary to the
question of proof in general.

In Angie's example, she is being asked in a deposition to prove why the
requested content can't be produced, regardless of the fact that counsel
can see that the content being requested **shouldn't exist because it
should have been destroyed according to a documented, approved, reasonable
schedule** (the point here is that opposing counsel is asking for content
that doesn't and shouldn't exist, so the attack is on process not on the
policy itself).  So, she needs to prove that her program works,
operationally, as designed and expected.  And in order to prove that, she
needs to be auditing her program on a regular basis, according to sound
auditing practices.  Those audit papers, to me, would be the best proof in
this kind of scenario; not necessarily being able to prove that one
particular file/folder was destroyed on a particular date but that all
disposition actions are carried out as designed and expected.

So then the question becomes, what constitutes auditing best practices with
regard to the disposition of content in accordance with an approved
retention schedule ... which will likely result in the use of metadata to
audit the program, but likely won't require a blanket retention of metadata
(all or select) on the whole for long periods of time (outside of Larry's
very salient points regarding regulatory requirements applicable to records
disposition documentation for some entities).

I think in professional practice we (as a general profession - please don't
take my comments personally and I'm sure some of you have awesome audit
practices in place) don't spend enough time building in audit control
points in our programs to serve exactly this purpose (as well as other
benefits of regular audit of program operations such as fine-tuning process
for efficiency, etc.), and even more often don't actually perform audits on
a regular basis, which then renders any audits you might have performed as
insufficient for purposes of proving reasonable, consistent, good-faith
operations over a period of time.

I know I didn't solve the problem here, but I hope these thoughts are
useful to highlight perhaps another approach to the issue.  I look forward
to additional thoughts and discussion.

Best,
Julie


-- 
Julie J. Colgan, CRM

[log in to unmask]
http://twitter.com/juliecolgan
http://www.linkedin.com/in/juliejcolgan

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]

ATOM RSS1 RSS2