I've been on both sides of this equation (service provider and customer)
and there is seldom a simple answer. It is important, however, to address
this early in the contract process.

One of the first things to consider is ownership of records. Whose record
is it? A good example of this are call center recordings. The provider will
argue that the recordings are the provider's record because the recording
is used for evaluation of their employees. The customer will argue that
some transactions are completed by phone and they need the ability to
confirm what was discussed if there is a dispute. The firm I worked for
regularly got contracts specifying that employee time records and certain
financial records (all considered as provider records) be kept for
remarkably odd periods of time, all in conflict with the firm's retention
schedule. We uniformly rejected that language. There's virtually no way for
a provider to parse that information to separate retention periods for each
client -- and still meet its own obligations. It's even worse for a
provider that uses lots of internal shared services and the shared services
don't necessarily bill back time to a particular client. Email is yet
another consideration. Whose email system will be used for communications
and who retains ownership for those communications? I know in certain cases
like HR outsourcing, the client wants its employees to not have awareness
that certain HR services are being performed by a third party. Therefore,
they specify that the provider use the client's email system to communicate
with employees. Who owns that email? Who sets the retention period? Can
both the client and provider retain the email?

The second consideration is the capability of the recordkeeping system to
actually purge data to your schedule. In the example of the call recording
system, the company I worked for had many client teams attached to the call
recording system. While the calls for a single client could be accessed
fairly easily, the system design allowed for only one retention period to
be implemented. You couldn't have client A retained for 30 days and client
B for one year and so on... Likewise, many provider database applications
aren't set up to purge data over the course of the contract.

This issue will be a major source of legal wrangling and WILL impact the
cost of the deal. Simply attaching your retention schedule to the contract
as an addendum and specifying that the retention schedule is followed is a
non-starter.

The third consideration (and the one which is somewhat easier to agree
upon) is what happens to information after the term of the contract. There
is some wrangling here as well. On the one hand, the provider doesn't want
to hang on to data any longer than necessary (because it costs money and
the provider isn't being paid anymore), BUT the provider may also feel it
necessary to have records which can be audited either by the client or by
its own auditors. I saw consulting engagements where the client demanded
that we destroy all records relating to the engagement immediately (because
the engagement had to do with due diligence for a deal never consummated),
then the client turned around and audited us, asking us to prove what work
was performed. Those were fun. Lots of heads exploding.

You also need to specify what happens to paper records that are imaged
(again, a potential source of additional cost). The best option here is if
you want the paper retained, you should set up an account with a (local to
the provider) commercial records center for the provider. That way the
paper goes back to your care and control right away. Otherwise, you might
end up wrangling boxes between records centers at the end of the deal.

The nice thing about most cloud computing deals is that you retain all
rights and control over the data. When you engage a provider for some sort
of outsourcing, all bets are off.

Patrick Cunningham, FAI

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]