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:
Fri, 26 Jan 2007 07:46:00 -0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (80 lines)
On 1/26/07, Timothy Piatt <[log in to unmask]> wrote:
>
> I have a couple quick questions concerning an electronic records policy I
> am
> creating.  I welcome opinions, but also need some good authority on the
> policies.


Okay, a couple of opinions, because there really are no correct answers as
one size DOES NOT fit all.

1)  How often should the files be backed up?  I know that organizations may
> backup their data on a daily, weekly, and also monthly basis.  Do we need
> to
> keep all these?\


This (in part) is an exercise in risk management and should be part of your
continuity of operations plan.  You need to gain a greater understanding of
what is meant by a "backup" in the language of whoever is making them for
your organization.  Many/most IT shops make complete and incremental
backups... complete would include all applications, etc. and are made MUCH
less frequently, because in most cases, the applications can be reloaded
from master disks/tapes if needed.

Data on the other hand, is backed up in a variety of manners.  Sometimes
users are connected to servers and their data is largely stored on a server.
In other cases, all data is stored at the desktop level, and in some cases,
it's a combination of the two. When a "backup" is made, you need to know
what it represents, and depending on the answer to this, you can determine
which ones need to be held for how long.

The basic rule is a backup is intended to restore data that may be lost in a
system failure, or following an "oopsie" by a user.  The only backups that
should be retained are those that represent the most recent data on the
machine.  If you are running complete backups weekly, and incremental
backups daily, then the "old" weekly can be discarded when a new weekly is
run, as can the dailys that are now included in the "new" weekly.  If you're
running complete backups monthly and incremental backups weekly, then the
"old"  monthly can be discarded when a new monthly is run, as can the
weeklys that are now included in the "new" monthly.

As far as policy goes, again, that's an individual issue.  You should meet
collaboratively with your risk manager, legal, IT, and operations personnel
and determine what makes sense for your organization to establish a
policy... then there should be procedures/practices developed to support
achieving the goals of that policy.

2)  What happens if a person receives business email to a personal email
> address?  What should they do?


This is an example of what should be addressed in policy.  It's generally
not considered a good idea for employees of an organization to receive
business related e-mail from clients at a personal e-mail address. By doing
so, the employee potentially exposes themselves to an awkward situation
where their entire hard drive's contents can be called into question in a
legal matter.

In the event they DO receive e-mail in this manner, they should forward the
message to their work e-mail account, with a message appended to the client
suggesting that all further e-mail be addressed to that account.  Law firms
are a bit unusual in this area, as some clients came with attorneys from a
past practice and while they were "between firms", they may have maintained
contact with a client using a private e-mail account, so how they would
handle all correspondence that resulted during that time frame should be
addressed as a firm policy.

That's my $00.02 of a Friday

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

ATOM RSS1 RSS2