Legal
Issues for Dealing with Application Service Providers
(ASPs)
By
Jay Hollander
Jay Hollander, Esq. is the principal of Hollander and Company LLC, www.hollanderco.com, a New York City law firm concentrating its efforts in the protection and development of property interests relating to real property, intellectual property and commercial interests, as well as related litigation.
The content of this article is intended to provide general information relating to its subject matter. Providing it does not establish any attorney-client relationship and does not constitute legal advice. Personal advice in the context of a mutually agreed attorney-client relationship should be sought about your specific circumstances. Summary: Using
application service providers, or "ASPs," is an increasingly
popular way to host, manage and deliver computer applications
from an offsite location. But ASPs raise special legal
issues that any business should address before signing
up for service. This article explains some of the common
legal issues to discuss with any ASP.
Introduction
Try
to figure this information technology industry.
First,
they wanted you to buy computers to join the information
revolution. Then, you had to buy more powerful computers
to run ever-more-capable software programs. Then, you had
to keep upgrading the software, which would do more and
more, especially on these increasingly powerful computers.
And, as your business grew, you had to hire an IT professional
or even a staff to supervise the inevitable repair and
upgrade issues. Before you know it, you've created your
own little information services division right in your
own company.
Now,
after years of hearing "buy, buy buy," what's the next
mantra of software and hardware implementation? "Rent,
rent, rent."
Improvements
in Internet technologies and the growing availability of
high bandwidth at lower prices has created the latest "must
have" in the industry" application service providers.
Just
who and what are these "ASPs"? What are the benefits of
dealing with them? How should you evaluate and ensure you
get what you need from them while protecting your data?
Let's tackle these issues one at a time.
What
are ASPs?
Simply,
ASPs are companies that remotely host, manage and deliver
computer applications from an offsite location. ASPs exist
to reduce or replace the ever-growing IT infrastructure
that has taken up substantial resources at larger companies
and has created a gulf between them and smaller companies
that don't have the same resources.
But,
whether your company is large or small, the main draws
of ASPs are that they become a company's outsourced IT
department, providing all necessary hardware and delivering
applications remotely, thus saving customers substantial
time, effort and, due to the presumed efficiencies of the
ASP, money. Further, since the ASP assumes all these functions,
the risk associated with them is transferred to the ASP
as well.
Since
an ASP essentially becomes the software delivery system,
the software is kept up to date, with all modifications,
patches and new features usually integrated, as they become
available. And since the applications as well as the data
are stored on the ASP's servers, employees can access the
application and the data anywhere they have Internet access.
Using
an ASP to its fullest potential also minimizes the need
for in-house IT staff, since software support is performed
at the remote location where the application is housed.
More
and more, an ASP can provide a wider assortment of applications
and services, everything from e-mail hosting to customer-relationship
management to data warehousing and even traditional "desktop" applications
such as calendaring, word processing and spreadsheets.
Some
ASPs cover everything from soup to nuts, providing your
Internet connection, hardware and application service,
while other ASPs themselves rely on partners to fulfill
one or more of the functions. So, one ASP could deliver
your "always on" connection together with your e-mail software,
or your ASP could contract with another service provider
to provide the connection, while it hosts the application.
In this way, the ASP acronym is shorthand for reference
to various types of service providers such as network service
providers, management service providers and even storage
service providers, among others.
Whichever
flavor of ASP you pick, there are certain fundamental legal
protections that will need to be addressed.
Service
Level Agreements
The
contractual relationship between your company and your
ASP will be contained in a document called a "Service Level
Agreement," an agreement that typically lasts for one to
three years.
It
is in such an "SLA" that you will cover all the main legal
issues that need to be resolved, such as specific services
to be provided, data security and financial consequences
of breach of the agreement.
Before
discussing the most common and important issues, however,
be aware that, just as there is more than one kind of ASP,
there is also more than one kind of SLA. In fact, the same
ASP can offer different kinds of SLA for different customers
and situations. So, the very first question to be asked
when presented with a particular ASP's SLA is whether the
offered agreement is the only one available and whether
it is negotiable.
Since,
at its core, a service level agreement is a contract about
usage of an ASP's services, it is typical to have different
grades of available service as well. Essentially, you can
contract for as little or as much service as you need.
Keep in mind that the more comprehensive the services your
ASP provides, the more you will need to ensure that the
provider has the skills, funding and expertise in the areas
involved.
Core
Contract Issues
Since
there are an ever-growing variety of types of service providers,
each with some issues all their own, let's confine this
discussion to the basic issues that are central to an SLA.
Description
of Deliverables
The
most basic involves agreement on the description of services
to be provided. Here is where extreme care needs to be
exercised to make sure that no misunderstandings in jargon
cause problems. There is nothing more basic to an SLA than
agreeing precisely and comprehensively on what the ASP
will be -- and won't be -- responsible for under the agreement.
Hand in hand with this is making sure you have a clear
understanding of how much of the promised services to be
delivered by the ASP will actually be delivered by the
ASP itself, as opposed to other providers with whom your
ASP may have relationships.
Since
the whole point behind entering into an ASP arrangement
is to avoid doing things yourself, make sure your agreement
spells out the hardware, software and connectivity required
for proper performance and who is responsible to ensure
that this infrastructure is provided and operational.
Build
Out
If
a certain infrastructure is required, and it usually is,
the technical specifications, as well as the due date for
the system to go live, must be adequately spelled out in
the SLA. Here, an astute customer will want to include
monitoring and progress reporting and testing to provide
adequate safeguards that the project is proceeding apace.
If
the hosted application will be interacting with legacy
applications at the user's site, representations about
interoperability, and responsibility for ensuring it, must
be properly set forth in the agreement.
Also,
since one of the main points of going to a hosted application
model is to allow growth without involvement of the user's
resources, assurances regarding scalability of the application
also must be addressed. Here, a customer will want to be
concerned with issues such as the ability of the ASP servers
to handle the company's anticipated growth in data and
users, as well as whether the growth will affect the hosted
application's performance.
Proper
Performance
When
an ASP hosts a critical business application, there must
be a clear description of what constitutes acceptable performance
in terms of speed, accessibility and guaranteed "uptime." In
a typical SLA, agreed-upon levels of uptime are at least
99%, with separate specified levels of user-perceived response
time, known as latency.
But
the inquiry cannot simply end there, because a guarantee
of performance doesn't mean much unless it's backed up
by similar guarantees on the things that provide such performance.
That means customers must pay attention to getting an acceptable
comfort level on the components that allow performance,
such as power backup, server redundancy and network capacity.
The SLA also must provide for how the ASP will monitor
these systems and what lengths it will go to in order to
redress and resolve any discovered problems.
Pricing
The
pricing model in the typical ASP SLA has been modified
somewhat since this type of service began a few years ago.
What began as a predictable pricing policy based on the
number of users has sometimes been giving way to pricing
structures based upon the actual amount of usage. This
can be measured in several ways, only one of which is actual
time spent. Predictability of usage cost is the flip side
of the savings engendered by having your application hosted
remotely by an ASP, and no SLA should be entered into unless
both parties understand and have comfort about the usage
costs of the service, particularly as they may be affected
by growth in data and users within the customer organization.
Maintenance
and Support
Just
because an application is hosted by an ASP, it doesn't
mean there can't or won't be the same types of problems
that customers likely encountered with applications previously
maintained themselves. For this reason, the SLA should
spell out clearly the level and response time for service
and support in the event of a malfunction or system problem.
Customers also will need specific representations regarding
the nature and extent of data back up at the host site
and the available degree of redundancy made available to
ensure smooth operation in case any component suffers a
breakdown.
Technical
support is one of the areas where extreme care needs to
be taken, since most ASP contracts don't include telephone
support as part of the standard fee, but rely instead on
e-mail. What's more, if your business operates "24 x 7" and
requires the same type of support, you'll likely have to
pay an additional fee. Either way, getting the specific
parameters about the type and responsiveness of technical
support can be critical to the usefulness of a hosted application.
Security
Although
the importance of security cannot be overstated, the ways
in which security must be provided for in an ASP contract
are often not well-understood. The threats to data security
are multi-faceted and must all be provided for in any well-written
ASP contract -- things such as viruses, denial-of-service
attacks and other hacker attacks.
While
virtually all ASPs understand the importance of the security
issue and have taken elaborate steps to deal with the most
likely sources of attack, the protection needed by particular
businesses goes far beyond this. For data that is not only
mission-critical but possibly proprietary or trade secret,
provisions are needed to provide for acceptable confidentiality
and for the nature and extent of efforts an ASP must take
to recover wrongfully obtained confidential information.
Clauses like these are extremely context dependent and,
before entering into any ASP contract, care must be taken
to identify the most likely avenues of data loss and what
preventative steps will be taken to recover any lost data.
Data
Ownership
Speaking
of data, those entering into an ASP SLA can't forget whose
data will be entered into the hosted application. Strict
provisions governing non-disclosure of sensitive end-user
company data must be a priority in negotiating an SLA.
Part and parcel of this is a specific understanding regarding
where data will be stored, who will have access to it,
what the password-protection architecture is, as well as
a number of other concerns. Clauses regarding data ownership
also must confront the consequences of breach of the provision
and what the relative responsibilities of each party will
be with respect to sensitive data that is lost or stolen.
Termination
and Penalties
When
you license a software program or purchase hardware for
installation on-site, you can always decide you made a
mistake if you don't like it and either return it to the
vendor or absorb the cost and replace it. But what happens
if you're unhappy with your ASP? Since the ASP not only
hosts your application but has control over your data as
well, termination provisions need to be thought through
carefully. Care must be taken to ensure that terminations
for cause are adequately defined and financial consequences
of early termination are agreed upon. Further, provision
must be made so that customer data cannot be held hostage
in the event of dispute and that the ASP does not keep
any copies of any data returned.
In
the event of a breach, calculation of damages to data can
be difficult to discern. Moreover, courts often frown on
damages provisions that appear punitive in nature and,
therefore, it is common to include "liquidated damages" provisions
(for predetermining the cost of potential damages) in an
ASP SLA. As the customer, you must determine whether this
adequately protects your interests. For some, ASP insistence
on this alone may be enough to dissuade the customer from
the ASP model.
As
you can see, while there are many perceived benefits to
the increasing use of the ASP model for running applications
for one's company, the devil is in the details when it
comes to understanding and negotiating for the specific
terms and conditions that will help you make a reality
of those perceived benefits while still giving you the
protections you need at a cost you can afford. Contracts
for ASP services should be viewed the same way that substantial
software licensing or integration services are viewed.
As such, consultation with a knowledgeable professional
is highly recommended. Copyright © Jay Hollander, 2007. All Rights Reserved.
![]()
![]()
|
