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:
Mark Myers <[log in to unmask]>
Reply To:
Records Management Program <[log in to unmask]>
Date:
Wed, 20 May 2009 06:15:01 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (125 lines)
Not fan flames that seem to have gone out here (but I didn't read all of this until this morning,) but seeking the advice of other RIM's in related fields, institutions, and other similar agencies - isn't that called a "standard" at least an "industry standard?"  In KY when developing a record retention period, we look at what other states are doing or have done with similar records all the time.  We take into account what NARA has done.  We also ask the agency for their recommendation because they are the one that works with the records and (should at least) understand the reasoning for creating, maintaining, and preserving the record.  The scheduling process involves the agency and the records management institution working together.  A common misconception is the Dept.for Libraries and Archives dictates the retention period.  In many cases we ask the agency to tell us what they think the retention period needs to be.  We do research what laws and
 regulations govern the records in question, but what we are primarily looking for is any secondary/historical  reasons why the record should be kept permanently, or longer than the agency says they need to keep the record.  The agency should know how long they need to keep the records they produce from an administrative or legal requirement.  If they don't then they have some other issues they need to deal with.

Software licenses/validation keys - would at best (in KY) fall under things like system documentation (3yrs after the system has been replaced or is no longer in use); or maintenance contracts (3yrs after expiration of contract).  Or we would need to develop another series for it.  Don't know that we've ever been asked.  Our basic assumption is that if it is related to accessing the data in the record, you would need the license key, as long as there is data that needs to be accessed by that key.

 
Mark J. Myers
Electronic Records Archivist
Technology Analysis & Support Branch,
Public Records Division,
Kentucky Department for Libraries & Archives
300 Coffee Tree Road PO Box 537 Frankfort, KY 40602-0537
Phone:  (502)564-8300 ext. 244
Email:  [log in to unmask]
www.kdla.ky.gov 



----- Original Message ----
From: Steven Whitaker <[log in to unmask]>
To: [log in to unmask]
Sent: Tuesday, May 19, 2009 6:05:44 PM
Subject: Re: [RM] Question on retention of software licenses

"workflows, procedures, audits, and practices associated with"

I was speaking in generalities of asking others how long they keep
records and then adopting something similar, as opposed to developing
your retention policies given the particulars of your own industry, your
organization's processes, audit schedules, state requirements, etc.  I
was not speaking of software licenses in particular in this example.  In
my original reply to Dawn's posting after defining the retention factors
I mentioned "In the case of software licenses I would certainly consider
the life of the usage of the software as a contractual obligation (Legal
advice factor); protecting our organizations' fiduciary
responsibilities."

I would not and do not seek the advice of other RIM professionals as in
'how long do you retain.'  That would be of no value to me as we do not
work in the exact same industry, same company, same state; same systems;
same audit group; in other words; have all of the same influences for
retention factors.  However, if I had an information series I believed
to be regulated by the SEC (as an example) and I could not find a
pertinent regulatory requirement that I believed to exist or should
exist, I might seek the assistance of other professionals...; "Jess,
Dawn, did you guys find a SEC regulatory retention requirement for
Brokers Advice?"  You might reply "Yes, the SEC specified a minimum
regulatory requirement of 2 years (example)  based on 17 CFR XXX.xx." 
That assistance in research would benefit me.   It would not do me any
good to ask you how long your operational, fiscal, legal, or historic
values are for a particular record series, for reasons stated above.  

If there was no retention policy for software licenses for the Veterans
Administration, what NARA should have done is ask Dawn "How long do you
reference those records?"  Dawn probably would have said "I don't
reference these outside of a clarification.  However, I see a need to
retain them as long as we use the software on our servers/PCs."   Then
NARA continues to develop the policy by researching Fiscal, Legal,
Regulatory, and Historic retention factors, instead of asking her to
provide a recommendation.  It is not for Dawn to know and state that
"These software licenses are actually a contractual document defining
how the software can be used, and cannot shared."  That is a 'legal
retention factor' in the retention policy matrix; and for that
particular stakeholder (General Counsel's Office) to define.  Many RIM
professionals would probably know or figure that, and bring it up to
Legal.  

Amalgamation of best practices has no place in retention policies, and
can be extremely dangerous.  To do what ARMA did back in the '90s with
the common research of regulatory agency requirements by industry
provided a useful tool.  I forget the name of the project.  

Best regards, Steve
Steven D. Whitaker, CRM
Records Systems Manager; City of Reno

>>> [log in to unmask] 5/19/2009 2:18 PM >>>
>
> <snip>It is unsound business practice to ask others how long they
keep
> their records, and then adopt something similar.  That is not
defensible
> anywhere.  It also does not
> serve your organization because it does not account for your
systems,
> workflow, procedures, audits, practices, state reqs and local
> requirements, if any.  Your retention policy needs to serve your
> organization's needs, and protect your organization by satisfying
> federal, state, and local regulatory agency requirements.</snip>


Sorry, I can't agree, broadly and in this particular example. What are
the
workflows, procedures, audits, and practices associated with being able
to
prove you own software? There's a certain practical responsibility to
keep
them in the event you'd need to (and the software would allow you to)
reinstall or install on a different machine; while I haven't gone
through
the various fed recordkeeping requirements in detail in a while, and
notwithstanding Larry's example earlier that I don't think is exactly
right,
I don't believe there is any guidance that exactly pertains.

So. In the absence of fiscal, legal, regulatory, or historic
requirements to
keep software licenses and licensing keys, and while I don't claim to
know a
<snip>

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]

ATOM RSS1 RSS2