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:
Larry Medina <[log in to unmask]>
Reply To:
Records Management Program <[log in to unmask]>
Date:
Thu, 5 Jun 2014 14:24:17 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (71 lines)
On Thu, Jun 5, 2014 at 11:23 AM, Fairchild Jessica <[log in to unmask]> wrote:

>
> For those of you who are actively protecting personnel records from
> disaster or other loss, I would like to hear about your protection strategy
> and what is working and what's not working.
>
> I thank you in advance for your feedback.
>

My initial comment is don't throw the term "vital" around lightly when
you're referring to records, especially if you work in a public setting.
They maybe "important" or "essential" or of "significant value"... and for
that reason, they may (and likely do) require special methods of
protection... but VITAL is a whole different thing.

Depending on what your organization includes in your personnel records,
they typically contain a lot of sensitive and personal information... PII,
PFI and sometimes PHI and for this reason they require a higher level of
physical protection than other records, to ensure only those authorized to
view the content are able to.

In many cases, they are also subject to extremely long retention periods
(ours are 75 years beyond separation form employment),  so they also
require increased levels of environmental protection. And it's not uncommon
for these to be stored in an independent area that had increased fire
protection, better temperature and humidity controls, and controlled access.

The reason I made the comment about the differentiation between 'vital' and
'non-vital' is typically, systems are designed that ensure vital records
are duplicated and a second copy is kept in a discrete location, providing
physical separation to ensure if one set is damaged by a catastrophic
incident (natural or man made), that the second set remains safe from
impact by the same event.  Its uncommon for personnel files to be
duplicated in this manner, mainly because a percentage of the documents
have 'wet signatures' or imprinted seals or other 'pedigree' that prevents
a copy from serving the same purpose as the original.

One thing that happens more regularly is the "Original Personnel Files" are
imaged under strict quality control guidelines, ensuring all content is
captured in a legible and accurate manner, including requisite metadata
capture to ensure proper access controls can be placed on the content. This
may involve making 'intercopies' of some records at higher contrast to
capture the content, addressing issues of differing resolution when
scanning (150 to 600 dpi or higher, if necessary) and pre and post
production issues, to ensure contents of files are returned to the same
order they started out in. This image database serves as the "reference
copy" and the source materials are the original.

It's important to work with any agency that regulates your record keeping
and or your legal or risk management staff to ensure they are on-board with
any project of this type.  One reason is the retention period applies to
the RECORD "copy" and the reference (imaged) "copy" is a non-record that
can be discarded as desired... so while the intent is to have it as a
"backup" of the source materials, it does not require the same controls of
protection as your record copy. Someone has to buy off on this and accept
this as fact, and that should be documented.

Larry
[log in to unmask]

-- 


*Lawrence J. Medina Danville, CARIM 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]

ATOM RSS1 RSS2