Hello,

I'm going to say from the perspective of someone who wrote a history book,
that information like this can be an absolute treasure trove. Had anyone in
the community I wrote my book on had been in jail, something like this
could have been incredibly helpful. I could have known what specific crime
they were incarcerated for, how long, which prison they'd been in, and
other details, such as what they were doing while in jail might have been
included.

I'm also going to point out, that it's not the most complicated thing in
the world to divide materials that are of historic value from things that
are in the records retention. That's pretty much what we do where I work.
Paper and digital materials that have records retention periods will be
destroyed when they come up to their destruction date. Materials that
people can tell have obvious historic value (such as a precedent setting
case) could be taken out of that cycle. We don't need administrative files
beyond their retention period, but we may have use for case files.

-Jennie Dubin-Rhodin
MLS


On Fri, Jun 17, 2016 at 8:13 AM, Jones, Virginia <[log in to unmask]> wrote:

> <A question: Why change the law?>
> Another foray into the issue of too much data vs. why get rid of it.   My
> first reaction to Frank's remarks is the cost of technology is dropping but
> the cost of increased response time is not.  At some point, there is just
> too much data on the system to get quick responses to queries.  And quick
> responses are necessary when working with customers.  The usual answer to
> that is "archive it off to another SAN or backup."  Not helpful if the data
> is required to respond to Freedom of Information Act requests (we have 5
> days to respond in VA) or e-discovery.  Having to go to 2 or 3 (or more)
> different locations for data is like having to go to 2 or 3 (or more)
> locations for paper records.  Both are very time consuming and eventually
> costly.  And of course, there is the fact that when new operating systems
> are implemented, rarely is the archived data migrated to the new
> application.  The cost to recover data housed or backed up on old operating
> systems is phenomenal as we discover!
>  ed last year.
>
> And then there is the argument that some data should not be kept beyond
> its legal retention because of potential legal issues.  I am not a
> proponent of defining RM as the data/records destruction group, but many
> organizations see it that way. I see our function more as the group to set
> procedures in place to retain what must be retained for whatever time
> period required and get rid of the clutter that is in the way of access and
> response time (data/records with expired retentions). There is also the
> issue of some federal and state laws that require the timely
> destruction/deletion of certain data (especially PII data) or records.  For
> example, in Virginia local and state government MUST delete data or destroy
> records containing any PII within 6 months of the expiration of its
> official retention period.
>
> Simply applying a mass retention to the archived or less active data
> storage based on the day it was moved over  or last accessed is not a
> solution for a whole bunch of reasons - most of them to do with legal
> retention requirements.  If you have to apply some type of retention to
> archived records, why not put it in place for all data and keep it in place?
>
>
> Ginny Jones
> (Virginia A. Jones, CRM, FAI)
> Records Manager
> Information Technology Division
> Newport News Dept. of Public Utilities
> Newport News, VA
> [log in to unmask]
>
> 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]
>

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]