Hi Larry,

A clarification. I am not outsourcing a service I provide to my clients,
let's say for example that the company I work for decides to outsource the
payroll department.  I need to make sure the vendor follows my requirements,
including all the items you mention in your email. What I am trying to
formulate, in a paragraph, is some basic language that I can start
incorporating into contracts to cover record retention issues.


On 7/16/08, Larry Medina <[log in to unmask]> wrote:
>
> >
> > I am looking for ideas for boilerplate contract language for vendors that
> > maintain client records on their systems.  Does anyone work for an
> > organization that has outsourced one of its functions and the records for
> > that function now reside on the vendor's systems and are accessed via a
> web
> > portal by the client?
>
>
> So let me see if I understand this... you have a client who has contracted
> with you to provide them a service, and then you've outsourced it to
> someone
> else and the client will be accessing things directly from them?   My first
> question here is how long will it take before the client realizes they
> don't
> need you and can work directly with the third party?   Obviously, if you're
> being paid and then vending the service, it's profitable enough for TWO
> firms to make money on what they're paying.
>
>
> >  If so, how did you negotiate record retention with
> > the vendor?  Is this spelled out in the contract?  Do you use standard
> > language in your contracts in regards to the vendor's responsibilities in
> > the maintenance and disposition of records they hold for your
> organization?
>
>
> I would be more concerned with how the content is being stored and managed.
>
>
> First, if any of it is subject to privacy concerns (PHI,. PII, financial or
> other sensitive data)  WHO at the vendor's firm has the ability to access
> it
> and are they bonded?
>
> Is the data being stored discretely on an independent server or commingled
> with that of others?
>
> What about backups?  Are they streamed from the server serially to a tape
> or
> transmitted electronically to a third site and how is that service
> provided/protected?
>
> If another one of their clients gets involved in a legal action and the
> data
> is subpoenaed, will YOUR client's data be subject to exposure?
>
> What is their disaster recovery plan and is their site above a 100 year
> flood plain?
>
> What about fire protection?  Physical security of facility? Proximity to an
> earthquake fault? Adjacent tenant risks?
>
> What is the standard practice for these records?
>
>
> What are the liabilities and terms and conditions in YOUR Contract with
> your
> vendor and does your contract with the third party exceed those?  Who is
> financially responsible in the event of loss or exposure of data?
>
>
> > Do you require records to
> > be returned to you at some point in the lifecycle, or do you require the
> > vendor to destroy records following your retention schedule and sign-off?
> >  How does the vendor provide proof of destruction?
>
>
> Why would your client allow you to contract this?  The records are theirs,
> and unless YOUR contract allows YOU to disposition the records without
> their
> direct approval, how do you show chain of custody and provide a destruction
> certificate?    And does this include destruction of backups as well?  Are
> they discretely stored in a manner that allows this to happen?
>
>
> > Are the records backed
> > up on the client's systems periodically?
>
>
> One would hope this would be a requirement... see notes above about how you
> would possibly want this done.
>
>
> >  Do you require the vendor to
> > maintain inactive records to the point of migrating records to ensure
> they
> > are readable over time?
>
>
> Your client would require YOU to , why wouldn't you require THEM to?  And
> as
> far as migration and or conversion when required goes, if it's in your
> contract that your client expects you to do it, then it would need to be in
> the contract with your third party vendor, or you would have to take all
> the
> records back periodically and do this yourself.
>
>
> >  What happens to the records if the vendor – client
> > relationship ends?
>
>
> Better address this in your contract... along with the other concerns
> regarding loss and/or damage to the data.  My personal opinion is the data
> would need to be returned to you, after you are provide sufficient notice
> to
> determine how you would handle it.
>
>
> > What is your experience with vendors when they sunset
> > their systems and your electronic records are no longer readable?
>
>
> This is another item you need to address in the contract...  any changes to
> systems or potential for systems to 'go stale' would need to be discussed
> prior to a migration taking place,
>
> The answers aren't in here, but there is a lot of guidance about things you
> would need to consider above and beyond what's already been discussed here.
>
> http://www.arma.org/bookstore/productdetail.cfm?ProductID=2220
>
> DISCLAIMER:  I was one of the project managers for the development of this
> publication and am the ARMA SDC Chair, so my opinion on the value of the
> document may be a bit biased, but I would recommend this to anyone who is
> either running their own record center or considering outsourcing the
> storage and management of records to a third party to perform a gap
> analysis
> of needs to capabilities.
>
> 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
> 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]