Desislava Stankova's Master Thesis
Desislava Stankova's Master Thesis
Desislava Stankova's Master Thesis
Master Thesis
ANR: 434659
E-mail: [email protected]
ABSTRACT ........................................................................................................................................................ 4
5. CONCLUSION ......................................................................................................................................... 56
APPENDIX 1 .................................................................................................................................................... 60
REFERENCES ................................................................................................................................................... 66
3|P a g e
ABSTRACT
Lately, IT Outsourcing (ITO) has become a key business strategy and market trends such as
multisourcing and globalization, have made the outsourcing relationship even more
complex. Considering the growing strategic value of the ITO projects for the customer
organization, the need to identify and manage all risks endangering the outsourcing
relationship and to take the necessary measures for ensuring business continuity, becomes
indisputable.
The intent of the present study was to research contractual instruments to ensuring service
and business continuity of the customer in an ITO project, as the general legal framework
currently does not provide specific ITO continuity related solutions. This thesis endeavors to
show that tools such as Back-up and Disaster Recovery provisions, Software Escrow
Agreements, Step-in Rights and Exit Provisions, complemented by an evolutionary IT project
management, are among the key efficient measures, applicable when continuity is targeted.
It was concluded however, that, due to numerous legal or practical limitations, none of the
abovementioned instruments is able to fully guarantee continuity. This gives reasons to
recommend that in certain circumstances, when continuity is of top priority for
organizations, the decision to outsource should be carefully evaluated against all possible
risks, and subsequently keeping IT services in house should be considered.
4|P a g e
LIST OF ABBREVIATIONS
ARD = Acquired Rights Directive
BPO = Business Process Outsourcing
BC = Business Continuity
BCP = Business Continuity Planning
CAPEX = Capital Expenditure
COBIT = Control Objectives for Information and Related Technologies
CPU = Central Processing Unit
DoS attack = Denial of Service attack
DR = Disaster Recovery
DRP = Disaster Recovery Plan
DRT = Data Retention Time
EU = European Union
EUR = Euros
FM = Force Majeure
IP = Intellectual Property
IPR = Intellectual Property Right
ISO = International Organization for Standardization
IT = Information Technology
ITO = Information Technology Outsourcing
LoL = Limitation of Liability
MTDL = Maximum Tolerable Data Loss
MTPD = Maximum Tolerable Period of Disruption
OPEX = Operational Expenditure
RFP = Request for Proposal
RPO = Recovery Point Objective
RTO = Recovery Time Objective
SaaS = Software as a Service
SC = Service Continuity
SLA = Service Level Agreement
SoW = Statement of Work
SP = Service Provider
SPoC = Single Point of Contact
TUPE = Transfer of Undertakings (Protection of Employment)
USA = United States of America
5|P a g e
Introduction
Outsourcing is not a new practice, yet many different understandings exist about what
outsourcing exactly is. It is often compared to a marriage relationship and just as
approximately half of all marriages fail, outsourcing failure rate tends to be considerably
high too. Since it is the focus of other scientific and practical fields to explain the reasons and
mechanism of outsourcing relationship failure, this study is aiming at bringing into light the
available tools and instruments for dealing with failure in such a way that business and
service continuity is achieved.
ITO is historically the earlier form of outsourcing and officially dates back to the 1960-s
service bureau arrangements. It generally includes outsourcing activities such as: data center
and systems infrastructure, voice and data networks, telecommunications, applications
development, applications support and maintenance, server and desktop environments, IT
project management, contract and vendor management, support, help desk and call center,
IT training, disaster recovery and business continuity, as well as IT procurement.1 Lately the
scope of ITO goes even broader by including new services such as Software as a Service
(SaaS) delivered through Cloud Computing infrastructure, website/e-commerce systems, etc.
1
Mark Lewis, Computer Law: The Law and Regulation of Information Technology. Information Technology Outsourcing and
services arrangements (6th edn, OUP, 2007) pp.139-182.
6|P a g e
BPO is defined by Gartner as “the delegation of one or more IT intensive business processes
to an external provider that, in turn, owns, administers and manages the selected
2
processes, based on defined and measurable performance metrics”. BPO is sometimes
considered to be the outsourcing form that is more tailored to customer`s needs, compared
to ITO, which can be comoditisized to a certain extent for a broader range of customers.3
Although BPO is showing significant growth in terms of numbers and significance, the
present study will focus only on ITO within the scope described above, because only typical
IT aspects related to continuity are targeted due to the length limitation of the study.
2
Gartner on outsourcing.
3
Bharat Vagadia, Outsourcing to India – a legal handbook (Springer-Verlag, Berlin Heidelberg, 2007), pp. 1-9.
4
Capital Expenditure – the expenditures used by organizations to buy fixed assets (such as IT hardware, office furniture,
etc) or to add value to fixed assets.
5
Operational Expenditure – the expenditures used by organizations to run and maintain their business (such as office
expenses and utilities, maintenance fees, IT hardware supplies, transportation, etc.)
6
Depending on the type of IT function outsourced.
7
AMR Research 2009 Outsourcing statistics, <http://www.rttsweb.com/outsourcing/statistics/>
8
SearchCIO.com, Feb 2010.
7|P a g e
However, despite the optimistic hopes, the majority of outsourcing projects do not fulfill the
initial expectations conferred on them. The two main indications of failure include
premature termination of outsourcing contracts and dissatisfaction with outsourcing results,
even when contracts are not terminated.9 According to statistics over 50% of outsourcing
contracts are prematurely terminated10 and approximately the same percentage is
applicable to the number of customers dissatisfied with the project results.
With the development of the outsourcing market, ITO has evolved to a second and third
generation of outsourcing.11 Nowadays, outsourcing has become a key business strategy and
market trends such as multisourcing12 and globalization, have made the outsourcing
relationship even more complex to manage and maintain. Considering the growing strategic
value of the outsourcing projects for the customer organization, the need to identify and
manage all foreseeable risks endangering the outsourcing relationship and to take the
necessary measures for ensuring business continuity, becomes indisputable.
Generally, the outsourcing projects encounter the following type of practical problems such
as loss of everyday management control over IT processes and infrastructure, high costs for
managing the outsourcing relationship, security vulnerability (especially in terms of
confidential information), transfer and subsequent loss of key expert employees, customer
dependency on crucial business service performance, quality problems, cultural differences
and incompatibility between customer and provider, insourcing13 complications, etc.
Furthermore, incidents such as loss of important data, natural disasters or unresolved
communication problems between the parties, even though not always followed by
premature contract termination, can introduce significant risks for the service continuity of
the customer.
9
Achim Hecker, Hendrik Kohleick, ‘Explaining Outsourcing Failure’ (October 27, 2006). <http://ssrn.com/abstract=939411>
10
DiamondCluster International, ‘2005 Global IT Outsourcing Study’, (2005)
<http://www.diamondconsultants.com/PublicSite/ideas/perspectives/downloads/Diamond2005OutsourcingStudy.pdf> ,
accessed 22.04.2010.
11
Compared to the first generation, which characterized with cost reduction being the main reason to outsource and the
services to be outsourced were only non-core day to day IT functions, assigned to a single provider
12
Multisourcing defined as breaking the outsourced functions into multiple providers, as well as keeping some of them in-
house as a strategic decision. Companies like General Motors and ABN Amro have currently switched to multisourcing
model.
13
Assuming back in house responsibility for the outsourced activities
8|P a g e
Along with the practical problems, a number of legal problems regarding continuity in IT
outsourcing are observed, such as IPR ownership and protection, insolvency complications,
etc. The outsourcing activities are not statutory regulated as such by legislative acts that
reflect the specifics of the process, and normative regulations are rather spread across
multiple generic acts covering different aspects of outsourcing relationship. There is further
lack of court practice about outsourcing disputes, since parties are relating the dispute to
the court when the relationship is fully derailed. Additionally, courts are hesitant in deciding
about the complexity of the case and even more specifically, they are cautious in issuing
injunctions ordering the parties to perform what is due according to the contract (unlike
ordering them not to do something)14. Many legal problems, such as the execution of foreign
judgments occur with offshoring, where both parties are located in distant parts of the world
and their legislation and case law applicable to outsourcing activities differ significantly.
It must be noted that statutory framework as such does not offer adequate legal solutions to
the specific outsourcing problems, thus additional tools and instruments, ensuring business
and service continuity in ITO, should be used. Such tools are incorporated in the outsourcing
contract, seen as the instrument for day-to-day managements of the relationship and the
most efficient tool for protection of the interests of both parties. The term “outsourcing
contract” used in the present study includes not only the master contract, concluded by the
parties, but also all the schedules, attachments and agreement that cover different aspects
of the outsourcing relationship.
The IT outsourcing continuity topic is current due to the fact that outsourcing projects are
growing in number and complexity by involving more than one service providers, as well as
acquiring strategic value for the organization. It is relevant because outsourcing is facing a
lot of risks and challenges and a high failure rate, as demonstrated above, therefore the
need to ensure service and business continuity is significant. At the same time only a limited
number of in-depth researches on this topic have been conducted, leaving a vast number of
practical and legal issues that are not exhaustively studied. It is perspective because, as
outsourcing projects are expected to further diversify and develop and the high complexity
14
Richard Hawtin, ‘No-one ever sues on an outsourcing contract’ (2007) C.T.L.R., 13(3), 88-90.
9|P a g e
and failure rate to continue growing, a detailed review of the contractual relations covering
continuity would be undoubtedly necessary.
Subject of the present research are the contractual means of ensuring continuity in IT
outsourcing projects. The goal of the study is to analyze the existing tools and instruments
able to provide continuity in case of incidents and disruptions of the IT outsourcing
relationship and to offer the most effective continuity solutions. Conformity with statutory
provisions, high level of protection of the parties and reflection of the current state of art by
the outsourcing contract are considered when analyzing the contractual outsourcing
relationship. The study is conducted generally from customer perspective, yet keeping in
mind possible implications for the continuity of the suppler as well.
The research methodology strategy is based on the goal of the study, i.e. to analyze the
existing tools and instruments able to provide continuity in ITO and to recommend most
effective solutions, and it mainly includes use of qualitative data, as analysis and efficiency of
continuity solutions in respect to outsourcing projects could not be successfully measured in
numbers. The main research technique used is documentary research (including legal
research documents, operational and technical studies, as well as real life outsourcing
contracts), combined with discussing relevant aspects of the topic with professionals in the
field. While semi-structured discussions with outsourcing professionals have been used
mainly to validate the reliability of the collected data, the documentary research has been
the primary source of collecting information.
Chapter 1 deals with the background of ICT outsourcing continuity topic and focuses on
general types of risks and the most common reasons for failure of the ITO projects. It further
explains the process of business continuity planning, including risk assessment practices,
business impact review, contingency considerations and recovery strategies. It also outlines
the characteristics of the outsourcing contract generally applicable for ITO. Chapter 2 offers
a general review of the non-IT specific legal measures for risk allocation incorporated in the
outsourcing agreement, including limitation of liability and indemnification clauses, force
majeure, insurance requirements, insolvency provisions and others. Chapter 3 focuses on
generic measures for ITO project control, available to the parties before the incident
occurrence, such as detailed scope of work of the project, service level agreement, clear and
10 | P a g e
comprehensive project management plan, etc. Chapter 4 provides an in-depth analysis of
contractual tools that deal with specific ITO continuity problems, such as back up and
disaster recovery agreements, escrow agreements, step-in rights and exit provisions.
11 | P a g e
1. Background and theoretical framework
As outlined in the Introduction, although progressively growing in scope and business
significance, outsourcing bears a number of risks, both operational and legal, which create
the need of adoption of effective risk management strategies in order to provide business
and service continuity for the customer. The most common risks for an outsourcing project,
general and IT specific, will be presented in this chapter, together with an overview of a risk
management approach. The characteristics of the outsourcing contract, as the most practical
legal solution to avoid and mitigate the risks, will be outlined briefly, together with an
overview of the applicable legislation and the literature on the subject.
Business continuity is often defined as the process of ensuring that organization`s business
critical functions and activities will be available to their customers, partners, vendors and all
other stakeholders. It is a methodology used throughout the entire organization and is based
on development and use of a set of standards, policies and procedures, needed to ensure
15
the service, consistency and recoverability. Although often mistaken with disaster
recovery, BC is the broader notion that includes disaster recovery. IT service continuity is a
part of business continuity that refers to ensuring availability of IT functions and IT
departments in an organization.16 It can be reactive, in case of an incident, but also
proactive, i.e. preventing risks from occurring. Business continuity planning is drafting of a
plan of recovery and restoration of an organization`s business critical functions in case of an
interruption within a certain time limit after an incident or disaster.17
The first step in BCP is Business Impact Analysis. It consists of identifying all business
functions of the organization and assigning a certain level of importance to each one, by
defining them as business critical and non-critical functions. A function can be determined as
15
Business Continuity, <http://en.wikipedia.org/wiki/Business_continuity> accessed 11.04.2010
16
ITIL Service continuity.
17
Business Continuity Planning, <http://en.wikipedia.org/wiki/Business_continuity_planning> accessed 11.04.2010
12 | P a g e
critical if its loss or temporary disruption or delay is unacceptable for the relevant
stakeholders. Criteria for acceptability could be the cost of recovery solutions, legal
requirements, business reputation, etc. Recovery point objective (RPO) and Recovery time
objective (RTO), meaning respectively the acceptable latency of data to be recovered and
the acceptable time needed to recover the function, are usually defined and Maximum
tolerable data loss (MTDL) and Maximum tolerable period of disruption (MTPD) are
assigned. This BCP finishes with an analysis of the recovery requirements for each business
critical function.18
Further step in business continuity planning is risk identification and assessment. Risk
assessment is part of risk management and consists of determining risk probability and the
magnitude of the adverse effects. In terms of business continuity it means identifying all
possible incidents that could result in loss or delay of a business critical function and
activity.19 A company can use different casual or formal risk assessment methods, including
specialized software. Results of risk assessment must be documented and need to receive
the support of company management and all relevant organization levels, in order to create
an adequate business continuity plan.
Identification of recovery strategies is another crucial step in BCP. This phase is based on the
information gathered and analyzed in the business impact analysis and the contingency
considerations. The recovery strategies should offer a temporary complete or almost
complete solution to the problem and the choice of the most suitable strategies is a
18
Ibid: Business Continuity Planning (n 17)
19
PACE, ‘Business Continuity Planning Guide’, <http://www.ogc.gov.uk/documents/PACE_-_BCPG.pdf> accessed
12.04.2010.
13 | P a g e
consideration of cost, speed and level of recovery20 - the faster the recovery, the more
expensive the solution.
The process ends up with drafting the BC plan, testing, reviewing and revising it on a regular
basis.
20
Ibid: Business continuity planning guide (n 17)
21
Ibid: Explaining outsourcing failure (n 9)
22
Hunton & Williams, Marsh, ‘Risk Management in Next Generation Outsourcing’ (2008),
<http://www.hunton.com/files/tbl_s47Details%5CFileUpload265%5C2125%5COutsourcing_white_paper_2.22.08.pdf>
accessesd 11.04.2010.
14 | P a g e
possible service disruption should be further evaluated. It is also of a great importance to
assess customer`s own experience with outsourcing – the function to be outsourced, the
technology or the process. Lack of customer experience with outsourcing bears risks for the
continuity of both the customer and the provider. Further problems at the stage of the
lifecycle include the overall availability of a service provider on the respective market that
could successfully perform the outsourced activities, thus a selection strategy needs to be
adopted. Additionally, legal compliance issues should be evaluated - therefore the failure
probability, if not involving a legal counsel at that initial stage of the outsourcing process, is
much higher. Finally, a strategic decision should be taken as to the risks of not outsourcing
the activity, especially concerning customer`s qualification and expertise to perform the
service in house if it is business critical, against the possible drawbacks of the positive
decision.
15 | P a g e
insolvency, total lack of experience, dependency on failing or badly managed subcontractors,
etc. In cases of software development outsourcing for example, insolvency of the provider
and subsequent failure to provide, may result in significant business and support problems
for the customer, if they are left without a service and without the software source code
needed to either continue performing the service itself or transfer it to another provider.
Contingency plans, escrow agreements and relevant contractual insolvency provisions are
proper instruments to address the abovementioned risks.
Furthermore, even in case of the contractor providing the service, quality issues, as well as
inability to determine and monitor the quality of the activities performed need to be
properly addressed, thus strict SLA and performance metrics should be elaborated. Over-
dependency of the customer and loss of control over business critical functions are also
among the operational risks. Lack of working change management procedure is another
problem factor.
Furthermore, certain types of ITO, such as cloud computing for example, bear their very
specific risks23 like strict dependency on high speed internet connection, single points of
failure for data transmission, processing and storage, interruptions in data transmission and
uncontrolled environments leading to delays in data restoration, as well as the common risk
of guessing passwords based on social networking, thus they require further security and
redundancy measures.
23
Bierce & Kenerson ‘Case Study for Legal Risk Management for "CloudComputing": Data Loss for T-Mobile Sidekick
Customers’, Published: 29.10.2009, <http://www.outsourcing-law.com/2009/10/case-study-for-legal-risk-management-
for-cloud-computing-data-loss-for-t-mobile-sidekick-customers/> accessed 18.04.2010.
16 | P a g e
1.2.1.4. Termination and exit risks
The lack of well defined and clear exit strategy may unnecessarily complicate the intrinsically
complex exit process and put business continuity upon great risk. It is thus crucial for the
parties to elaborate on a detailed Exit Plan and procedure even before the incident has
occurred. Temporary or final step-in rights in case of inability of the provider to perform
should be included in the outsourcing contract to ensure maintenance of service provision
either by the customer or by an alternative provider.
Traditional IT projects risks can be addresses with series of measures, such as development
of detailed Scope of Work and Service Level Agreement, drafting of comprehensive Project
Management Plan and other measures that will be outlined in the next chapters. However,
the focus of the present study will be more concentrated around continuity specific ITO
problems and the contractual instruments to prevent or solve them.
24
L. Kappelman, ‘Early warning of IT Project Failure: The dominant dozen’ (2006), Information Systems Management
2006/23, p.31-36.
17 | P a g e
take the necessary contractual and operational measures to mitigate their occurrence and
consequences when service continuity is a priority.
Such risk events usually include natural disasters like flooding, fires, earthquakes, etc.,
financial disaster of the provider leading to insolvency, social risks such as loosing key IT staff
and any other complications connected with technology, such as computer viruses for
example. They can be addressed by a number of specific IT continuity measures such as
back-up and disaster recovery provisions, source code escrow agreement, temporary step-in
rights or the right to acquire certain assets. Detailed analysis of those measures will be
provided in the next chapters
From a legal perspective offshore projects might face some challenges in respect of
execution of foreign judgments or foreign arbitral awards, IP rights protection, selection of
governing law, non-compete contractual clauses, liability of the parties, staffing issues, data
protection, etc., which most probably will be regulated in a different way in the national
legislations of the customer and provider, or even not regulated at all in one of them.
25
Indian Civil Procedure Code 1908 for example limits the enforcement options to reciprocal territories, which are a very
limited number and exclude countries like the USA or the Netherlands. In non-reciprocal territories cases, the foreign
judgment must fulfill the requirements of section 13 of the Civil Procedure Code 1908, which can be quite restrictive.
18 | P a g e
not be a simple and speedy process in typical offshoring countries26, which undeniably
affects customer`s options of maintaining service provision or replacing the provider.
Special attention should be also paid to the IP rights allocation, as sharing and creating IP
during the term of the project is very probable. It is of fundamental importance to identify
all IP rights and to set clearly in the outsourcing agreement the rules regarding IP ownership
between the parties, taking into account the different national legal regimes protecting IP.27
Although India for example has better IP protection than other offshoring territories such as
China and Mexico, it is member of international IP conventions such as the Berne
Convention, and has a Copyright Act, its IP legal protection is still considered relatively low
compared to the EU or the USA.
26
Taking again India as an example, it should be noted that the Indian Civil Procedure Code 1908 allows foreign arbitration
awards enforcement, but subject to satisfying certain criteria, such as the “public policy criterion”, which is very wide in
interpretation, thus very restrictive.
27
Shalini Agarwal, Sakate Khaitan, Satyendra Shrivastava, Matthew Banks `Destination India: offshore outsourcing and its
implications` (2005) C.T.L.R. 2005, 11(8), 246-262.
28
The average contract duration for ITO contracts was 4.7 years in 1995 and increased to 6.2 years in 2003, HI Europe, The
UK IT and Business Process Outsourcing Report, <http://exactsearch.com/ipi/IPI.nsf/LookupPDF/trui/$file/trui.pdf>,
accessed 11.05.2010.
19 | P a g e
The standard ITO contract consists of a master contract and a set of agreements. The
contract composing strategy could be of a decentralized contract, where the parent
company of the customer concludes the master agreement (which includes mostly
principles) with the parent company of the provider and the local agreements are
subsequently negotiated and drafted by the local offices, covering specific topics such as
scope and pricing; or a centralized contract, in which case the master agreement includes all
principle and specific topics and the local offices are only allowed to adjust the local
contracts to particular local legal requirements, such as for example labor regulations.29
Although clear and comprehensive outsourcing contract in its entirety is a key to ensuring
the success of the ITO project, when it comes to continuity, specific contractual provisions or
agreements play the major role. Different legal remedies to target potential problems with
outsourcing may be used by both parties30, including claims for damages, liquidated
damages, relationship termination rights in case of partial or total failure to perform,
insurances, insolvency clauses, etc. None of them however, would be able to successfully
prevent service continuity disruption, but merely provide a certain kind of compensation for
the service loss or delay and serve as a basis for ending the relationship between the parties.
For the purpose of the topic of this study, i.e. effectively ensuring continuity in IT
outsourcing projects, the following contractual instruments will be examined in detail: back-
up and disaster recovery agreements, software escrow agreement, step-in rights, exit plans.
29
Ibid: Vagadia (n 3), pp. 15-22
30
Pinsent Masons, ‘User`s Guide to Outsourcing’ (2008), pp. 3-8, <http://www.out-law.com/page-364> accessed
11.04.2010.
20 | P a g e
1.4. Relevant legislation and literature
Defining the applicable legislation varies significantly depending on specific national legal
regimes of the parties, a situation that becomes even more complex when they are located
in different countries. A basic differentiation can be made between the countries within the
Common law system and the Civil law system.31 This difference should be specifically taken
into account when the ITO project involves an organization from a European civil law
country and a provider from a typical offshoring destination country, such as India for
example, whose legal system is based on the UK common law. However European
companies, according to the Rome convention (1980), are free to choose the national state
law they wish to govern their contractual relationship. Generally, relevant legislation in
reference to outsourcing projects in the EU includes EU transnational legal sources such as
Directives and the national legislation of the states concerned. Civil and civil procedure
codes, Privacy and data protection acts, IPR acts, Commercial codes and some specific IT
laws such as E-commerce acts, E-signature acts are typically the regulatory framework for
ITO projects.
Relevant literature is fragmented and limited number of research and practical studies focus
on ensuring continuity with legal measures. The available literature is mostly in the form of
short articles explaining ITO process, risks and failure or providing practical tips on drafting
ITO contracts in general. Most of the literature focuses on offshore projects, assuming they
bear the most risks, especially considering the cultural and legal differences between the
parties. More in depth studies on legal aspects of outsourcing materialized in books are
scarce. Comprehensive and reliable researches focusing on practical legal aspects of
ensuring ITO service continuity hardly exist.
31
Jurisprudence being the main source of legal norms in Common law, while codification and statutes - the main source of
legal norms in Civil law.
21 | P a g e
2. Non-IT specific tools of risk allocation and sharing in the ITO
contract
As outlined in the previous chapter, a significant step towards ensuring service and business
continuity includes risks identification and assessment. After the risks have been defined and
analyzed, proper risk management strategies should be incorporated in the contract. The
following are the most typical and effective measures applied to ITO contracts, regardless
the technology or services outsourced.32
32
Ibid: Vagadia (n 3), pp.55-67.
22 | P a g e
Nevertheless, as outsourcing projects tend to be complex in nature, the provider usually
subcontracts part of the services they are not specialized in to third party contractors, such
as hardware or software maintenance and support, software development, web-hosting,
etc. In such cases, the contract should include a clause that provides liability for the supplier
for the acts or omissions of their subcontractors.
2.5. Disclaimers
Furthermore, disclaimers are usually used in ITO contracts, especially for protection of the
provider. Providers usually tend to disclaim the accuracy of advices, reports and data,
provided by them, or a failure of business results. However, it is recommended for the
customer to resist such clauses, in view of ensuring business continuity. Additionally, a
provider may try to avoid providing warranties for the uninterrupted performance of a
system or a network, as well as that software is free of bugs or viruses for example, but it is
33
Liquidated damages represent a contractually fixed amount to be paid by the party in breach of the contract as a
compensation for the damages suffered by the other party. This amount is the entire final amount to be paid regarding the
damages incurred as a result of the breach.
23 | P a g e
strongly recommended that customer denies such clauses and rather negotiates strict
service levels in a detailed Service Level Agreement.
2.6. Insurance
Additional instrument for risk management in ITO projects is the inclusion of insurance
provisions in the contract as a classic risk transfer tool. Standard types of insurances
required for the supplier include property insurance for any equipment to be delivered,
professional indemnity, errors and omissions insurance, public liability insurance, employer`s
liability insurance, etc. and insurance covers amounts can be fixed in the contract.
34
Norton Rose Group, `Satyam: what are the consequences for offshore outsourcing?` Published 16.01.2009,
<http://www.nortonrose.com/knowledge/publications/2009/pub19079.aspx?lang=en-gb&page=all>, accessed 12.05.2010.
24 | P a g e
a considerably expensive solution, because of the high termination fees usually associated
with its activation.
A more reasonable solution to the insolvency problem in ITO projects would be the inclusion
of “early warning termination triggers” 35 in the outsourcing agreement that can allow the
customer to terminate and replace at an earlier stage, when certain signs indicate the
insolvency probability, before even the provider has already disrupted the provision of the
services. Such indications may include certain low credit ratings of the provider, or any other
event that gives rise to a reasonable doubt that the provider will be able to maintain their
financial stability or continue performing under the agreed contract requirements. Although
very promising, a specific weakness of this approach is that many IT service providers do not
have official credit ratings, while further subjective criteria might be strongly opposed by the
supplier. Still, if early warning insolvency criteria can be negotiated between the parties,
such a termination option will enable the customer with a valuable tool.
Another concern with insolvent providers is related to the provision of transition services
and assistance. As much as most customers will be tempted to require such assistance free
of charge, it could be again opposed by the trustee, who can attempt to decline the services
at all due to the lack of any compensatory return. In order for the customer to receive such a
crucial assistance without any disturbances, it might be wiser to provide payment for it.
Moreover, several other key concerns regarding continuity should be considered and
reflected in the agreement in case of a provider going insolvent, such as how to protect the
customer from a trustee trying to prevent it from using intellectual property products
licensed by the supplier, any problems with enforcing a source code escrow agreement, or
the existence of certain legal obstacles for purchasing back any assets needed from the
supplier. Going into the details of insolvency provisions however, would mean exploring a
way too broad topic, which is not the focus of the current thesis, especially considering that
resolution options are significantly dependent on the specific national insolvency legislation
governing the contract, and therefore, the main insolvency issues are only sketched.
35
John Beardwood, ‘Bankruptcy & Insolvency Risks in Outsourcing Transactions: A Wake-Up Call’ (2008),
<http://www.fasken.com/files/Publication/e9cc8578-6707-4514-a86c-
59b4b806b358/Presentation/PublicationAttachment/2d93dd77-ea7f-4bc9-a8aa-
0e6078f63b8a/Bankruptcy_and_Insolvency_Risks_in_Outsourcing_Transactions.pdf> accessed 24.05.2010.
25 | P a g e
Those and other contractual clauses - if enforced - provide effective means for risk
management in the ITO relationship in terms of rights and obligations allocation, as well as
financial compensations. For the customer being financially compensated for service loss or
delay is better than suffering all the consequences of such failure, however, it doesn`t
provide continuity as understood within the BC definition provided in the previous chapter.
More specific strategies and tools, aiming at ensuring service continuity for all business
critical functions, should be contractually agreed. Next chapters are dealing with specific ITO
risks able to undermine continuity and the respective contractual instruments for risk
management.
26 | P a g e
3. Generic measures for ITO project control
As already outlined in the previous chapter, a number of general tools for risk allocation are
available to the parties, when they enter into an agreement. The discussed instruments
however, are applicable to most commercial projects and do not reflect the specifics of the
IT field. In this chapter further measures to control the quality and reliability
of the IT-project will be dealt with, which although not always directly related to continuity,
create the basis for a successful project and thus contribute to it.
The SoW may include detailed description of the outsourcing activities, as well as the main
deliverables, together with a description of the project sites, equipment or software to be
delivered, and an outline of activities that both parties agree to be out of scope. In case of
interrelated activities, trigger activities36 and milestones should be also defined. Clear
demarcation line should be put between the rights and obligations of both customer and
provider by stating what activity is expected by each one of them in order to fulfill project
goals.
36
Such a trigger activity for the provider to perform an IT service might be the preceding transfer of network
equipment or software licenses by the customer. In this case, customer`s delay in performing the trigger
activity, will, under certain circumstances, waive provider`s liability for the delay of the respective inter-related
activity.
27 | P a g e
Nevertheless, even with the most clearly defined scope, life is dynamic as is business, and in
the 5 to 10-year duration of the standard ITO project, changes will inevitably occur. Including
a simple yet unambiguous change management procedure, provides means for dealing with
change and adds the needed flexibility that eventually reduces to a great extent the chances
for project failure.
3.1.2. SLA
SLA is usually a schedule to the ITO contract, which defines minimum levels of services
performance and realistic performance metrics. It should be in line with the business
objectives and priorities of the organization, instead of only focusing on technical details. It
is important to remember that if a service is not included in the SLA, it practically does not
exist in the project.
Performance metrics can be specified based on either subjective or objective criteria. Typical
subjective criteria for performance include “reasonable efforts”, “best efforts”, “professional
manner” etc. that are preferred by providers, but are not able to provide customers with the
high level of comfort needed, especially regarding business critical services. Objective
criteria, however, are based on specifications, baseline performance metrics, service levels
the customer has already achieved and benchmarked service levels.37
The specific form of minimum service levels depends largely on the type of function
outsourced. In IT support projects for example, service levels can be measured with
parameters such as reaction time, resolution time, hardware replacement time, etc. Fault
prioritization is often made in the SLA, where different priority types of faults are assigned
different reaction and/or resolution time. In web-hosting services and electronic commerce,
the service levels can be measured as a percentage of website availability for a period of
time, as a 100% uptime might not be achievable.38
37
Ibid: Vagadia (n 3), pp. 93-103.
38
Jagvinder Kang, ‘Service Level Basics’, Technology Law Alliance.
28 | P a g e
objective criteria for measurement; ensuring that the customer is able to measure and verify
the service levels independently from the provider.39 Additionally, the selected levels should
be reasonable and achievable and metrics should be easily collected.40 Moreover, the SLA
should define precisely the service levels, so that it is clear for both parties what exactly is to
be measured, i.e. in case of computer system availability for example, would the service
level be attained if the operating system is working, but the application program failed.
A SLA for application services, such as SharePoint services for example, should set the
service levels of data availability during normal operations, as well as in case of failure
(software/hardware).41 The agreement should further include provisions regarding all types
of faults and restore options, such as entire “server farm” breakdown, single server failure,
lost document or emergency access to documents. Historical data availability should also be
included as a service requirement, if needed.
Another example of typical SLA refers to IT hardware maintenance and support projects. The
agreement should differentiate between warranty maintenance and extended support
services. Furthermore, clear contact points should be established, preferably a single point
of contact (SPoC), such as help desk contact. To be clearly defined, SLA parameters shall
include the reaction, resolution and hardware replacement time frames, management
escalation procedure, optional support services, such as on site-services, network audits,
software upgrade, and development of network design documents.
39
Ibid: Kang (n 38)
40
Ibid: Vagadia (n 3), pp.93-103.
41
‘What’s the Service Level Agreement?’, Published 17.09.2007, <http://blog.sharepoint-recovery.com/2007/09/17/whats-
the-service-level-agreement/> accessed 23.02.2010
42
Application Brownout refers to a stage of application performance where the application is still working, but poorly
performing.
43
Andrew Hiles, E-business Service Level Agreements, Strategies for service providers, e-commerce and outsourcing (The
Rothstein catalog on service level books, 2002), pp.1-28.
29 | P a g e
3.1.2.2. Service credits regime
Service credits regime refers to the consequences in case of service levels not met by the
provider, mostly in terms of service credits payable to the customer, as a percentage of the
fees due for the respective period. However, they are usually capped at a certain percentage
(i.e. 10% of the total charges for the project), thus leaving the customer with the risks of
service failure, therefore, their more important function in terms of continuity is to prevent
the provider from failing, rather than resolving the problem when a failure occurs.
The amount of the service credits can be set as a fixed sum or a mathematical formula to be
applied that is defined in advance, with the mathematical formula being the more precise
approach. It should be taken into account, however, that service credits are pre-estimates of
the actual losses as a result of the service failure, and thus, they cannot be unreasonably
high because of the risk of not being enforceable.
In order to stimulate the service provider to perform to their best, service debits can be
agreed upon for provider`s performance in excess to the service levels. In case of service
credits already accumulated, after exceeding service levels, the amount of the debits can be
respectively deducted from the credit due amount.
However, in order to provide service continuity, a clause stating that parties should continue
performing their obligations (payment, services) while any disputes over service level
performance are pending, should be included.
30 | P a g e
establishing good customer-supplier relationship. The communication rules and the general
importance of good communication grow exponentially with increasing the number of
providers in the multisourcing approach. Applying evolutionary projects management by
drafting and following Project Management Plan as part of the entire agreement, especially
the Communication Management Plan, would decrease the likelihood of incidents, will
increase the overall project quality, will further establish the basis for clear communication
and good coordination of provider/s and will ultimately diminish the probability of continuity
disrupting events.
In addition to the abovementioned tools, further less continuity specific instruments could
be mentioned such as drafting confidentiality agreements or requiring a bank guarantee for
performance to be provided by the supplier. Although confidentiality requirements can be a
priority issue for specific organizations such as banks, drafting and implementing a thorough
confidentiality agreements related to the ITO project is an efficient way to mitigate
confidentiality risks, and as such to contribute to continuity. Furthermore, although
performance guarantees are usually perceived as mainly focusing on financial problems,
their connection to continuity can still be traced, particularly in the perspective of
maintaining financial resources to “buy” replacement services when service provision by
current supplier is discontinued.
44
The notion of security understood as physical, technological and procedural security.
45
Sam De Silva, ‘A contractual approach to manage security risks when outsourcing’ (2009) C.T.L.R. 2009, 15(3), 51-57.
31 | P a g e
In conclusion, it must be considered that drafting an optimal SLA, Project Management Plan
or any of the other outlined instruments, is a smart way to set up a working ITO relationship
and to provide a certain level of comfort of both parties that project quality will be kept and
expectations are matching. All of the tools discussed above are greatly reducing the risk of
dissatisfaction of the results and a subsequent premature termination of the relationship -
the two main criteria of ITO projects failure, as outlined in the introduction. However, SLAs
and the other measures as such are not directly targeted at ensuring service continuity,
rather than defining performance expectations and establishing good project management,
therefore more continuity specific contractual instruments, will be presented in the
following chapter.
32 | P a g e
4. Specific ITO continuity measures
Establishing a working relationship between customer and provider in an outsourcing
project, based on clear communication, methodological project management and unification
of expectations, is crucial for the project sustainability and success, as argued in the previous
chapter. In this chapter, however, the focus will be narrowed down to very specific
continuity instruments applicable to ITO projects from a legal perspective.
Further to just temporary financial losses, a disaster event reflecting on the IT infrastructure
and services of an organization, can significantly affect their market share, their competitive
advantage, not to mention the perception of their reliability by the public, in case of wider
disaster publicity.
46
Ibid: Hiles (n 43), pp. 1-29
33 | P a g e
Disaster is any event than can cause disruption or negatively affect the normal operations of
the organization.47 Typical disasters as to the IT infrastructure and services can be divided
into three main categories: natural disasters (earthquakes, floods, etc.), technical disasters
(e.g. computer viruses, DoS attack, hacking) and human activities (e.g. incidental or
intentional disruption caused by current or past employees, etc.).48 For business critical
infrastructure, technology and processes, a plan should be implemented to recover from a
disaster (Disaster Recovery Plan), which should focus on both prevention of a disaster and
operations continuity.
In terms of IT functions and services, the following continuity objects could be distinguished:
47
Michael Wallace, Lawrence Webber, The disaster recovery handbook. A step-by-step plan to ensure Business Continuity
and protect vital operations, facilities, and assets (AMACOM, New York, 2004), pp.1-29.
48
B. Rike, ‘Prepared or Not…That is the Vital Question’ (2003) Information Management Journal, Lemexa: Vol. 37, Iss. 3;
p.25.
49
Dorian J. Coigias, E.L. Heibelger, Karsten Koop, The backup book. Disaster recovery from desktop to data centers (3rd edn,
Schaser-Vartan Books, Lecanto, 2003), pp.1-34.
50
Ibid: Coigias (n49), pp.7-34
34 | P a g e
as spear parts, cluster server-duplicates, etc. It is most often combined with duplication
(data) and mirroring (hardware) which consists of creating and maintaining an exact copy
(replica) of the initial object. It is also called replication and again serves as a quick fix in case
of a disaster. The archived backups represent snapshots of data kept in safe locations and
provide historical information and record of the data to be protected.
The disaster recovery plan, reflected in the contract, should provide for three types of
measures in connection to the IT infrastructure and services – preventive, detective and
corrective. Typical obligations of the service provider to be set in the agreement include:
• To take the necessary steps towards service restoration according to the plan
• To successfully restore all services within the service levels agreed
• To ensure the operational continuity of the services during the disaster situation and
invocation of the DRP
• To ensure that services that are indirectly affected by the disaster, continue
performance after the core services restoration
• To ensure all services that are in any way affected by the disaster are fully available
51
Disaster Recovery Plan, 02.02.2009, <https://online.penson.com/PensonBusinessContinuityPlan.pdf> accessed
11.04.2010
35 | P a g e
The DRP should include provisions related to the following issues: 52
• Objectives
• General principles and requirements – how the invocation of the DRP will affect
normal operations of the services, the SP to ensure their disaster recovery services
liaison to the customer or to other providers in terms of DR.
• Key personnel information – the personnel to be in charge for general disaster
recovery activities and specifically if an incident occurs.
• Third party contact details – subcontractors and other providers
• Key IT processes and backup strategy
• Risk management plan – identification of risks related to business critical IT functions
such as failure and disruption scenarios, single point of failure, identification of risks
linked to the interaction with the services provided by other service providers,
business impact analysis
• Service levels – including RPO, RTO, Data Retention Time (DRT), etc.
• Service levels exemptions – events such as scheduled maintenance, as result of the
acts of the customer, failure of the customer to grant access to facilities and
equipment.
• Emergency response provisions – including trigger events, invoking the plan and
activating the emergency response, emergency alert and escalation, etc.
• Recovery provisions – processes and sequence of events
• Insurances – to be made as part of the organization`s continuity strategy
• Consequences if SP fails to meet service levels and objectives – service credits, other
remedies
• Specific disaster recovery plans as to the different types of technologies to be
recovered
Once drafted and accepted, the DRP has to be continuously reviewed and updated as
business needs and requirements will most likely change in the 5 to 10-year course of the
outsourcing project. Additionally, the plan may contain a requirement for the provider to
52
IT disaster recovery (DR) plan template: A free download and sample plan, Published: 13.10.2009,
<http://searchdisasterrecovery.techtarget.com/generic/0,295582,sid190_gci1370683,00.html> accessed 13.04.2010
36 | P a g e
possess and follow certain security standards, such as the ISO/IEC17799:200053.
Furthermore, the service provider should be required to carry out disaster recovery testing
according to DRP. The requirements regarding the testing methods and results should be
part of the DRP.
4.1.4. Limitations
When reflecting on service continuity in ITO projects, a special attention should be paid to
the interconnection between DR and Force Majeure (FM) clauses of the contract. In some
cases, disaster recovery provisions may be combined with the FM clauses and a key
objective of the customer should be to prevent the provider from invoking the FM provision
as an excuse for not fulfilling their disaster recovery obligations. It is very important to draft
the FM clause in a way that it does not prevent the disaster recovery provisions from
activating, since an FM clause may generally excuse the provider from performing all
obligations under a contract, including the DR ones.54 In the best case scenario, when
disaster recovery is concerned, a customer might want the FM clause to state that in case of
a disaster, the provider will still have to perform and will not be able to invoke the FM
option, however, many suppliers will seriously try to resist this attempt.
A proper drafting of the FM clauses will focus on excusing provider`s inability to perform
only for acts that are unforeseeable and genuinely outside of their control. The definition,
however, should not be too broad, especially if the provider is based in typical outsourcing
destinations, where interruptions of power supply, of infrastructural outages are common.
The customer should make sure such events are not included in the FM provisions, which
should only cover incidents and acts that are indeed out of the control of the provider.
In connection with the FM clauses, the provider`s obligations as to disaster recovery should
be clearly described in the DRP, as outlined above. There should be no uncertainty about the
specific business critical services to be protected and the specific types of incidents covered,
in order to make sure all such events fall outside the FM scope.
In addition, several practical limitations regarding the efficiency of this instrument in terms
of continuity must be mentioned, such as provider`s technical inability to restore all lost or
53
Standards for information security management.
54
Matt Karlyn, ‘The Essential Lawyer: Force Majeure Meets Disaster Recovery’, CIO Decisions Magazine Archives,
<http://searchcio-midmarket.techtarget.com/magItem/0,291266,sid19_gci1213262,00.html> accessed 20.04.2010.
37 | P a g e
corrupted data or provider`s own continuity disruption. Naturally, back-up and disaster
recovery planning will not be able to reach its all goals, if important relevant risks are not
taken into account and respectively, the applicable response strategies are not drafted. Last
but not least, back-up and disaster recovery services are usually connected with high direct
and indirect costs for the customer organization, and therefore, financial and strategic
prioritization might often exclude them as unviable options.
55
Jonathan L Mezrich, ‘Source code escrow: an exercise in futility’ (2001), <https://litigation-
essentials.lexisnexis.com/webcd/app?action=DocumentDisplay&crawlid=1&doctype=cite&docid=5+Marq.+Intell.+Prop.+L.+
Rev.+117&srctype=smi&srcid=3B15&key=5627984601f8c2492c7dfe99ec454a06> accessed 15.05.2010.
38 | P a g e
said software for the customer. Thus, a source code escrow is an attractive continuity option
for the customer, while at the same time minimizing confidentiality or competition risks for
the provider.
The software escrow agreement is concluded between three parties – the software provider,
the customer and the escrow agent. Its scope and subject commonly includes an obligation
for the vendor to deposit the software source code within the agent, together with any
subsequent updates, enhancements and modifications. However, since the probability of the
customer not having the necessary knowledge and skills to confirm the deposited code
corresponds to the object code provided is considerably high, the agent could also provide
verification services in respect of the software. Additionally, the agreements can also allow
the customer to perform regular audits with validation purposes. Moreover, it is essential to
provide a clear definition in the agreement of what constitutes “source code” in order to
56
In specific services like SaaS, the continuity needs of the customer will also include object code escrow, because, unlike
the typical ITO where the object code is also run on the customer`s machines, with SaaS the object code is stored with the
provider only.
57
Periklis A Pappous, ‘The software escrow: the court favorite and bankruptcy law’, (1985), Santa Clara Computer&High
Tech L.J. 309.
39 | P a g e
cover all possible documents and modifications vital for the customer.58 Besides, the term of
the contract should be set up for the same period as the software license.
The agreement further obliges the escrow agent to keep the code deposited safe and
confidential and to make it available to the customer in case a release event occurs,
according to the list of trigger events negotiated. The release events agreed in the contract
are usually subject to extensive negotiations and it has to be noted that customers should
insist on including not only events of financial disaster of the provider such as bankruptcy,
which under certain circumstances are hard to enforce, but also provider`s failure to provide
software support or other related services. In any case careful consideration of the trigger
events will protect the software proprietor as well against a premature or abusive release of
their source code. When any of the trigger events occurs, the agreement can provide for the
customer the duty to send proper notification to the agent explaining the reasons for
requesting the release of the code.
When bankruptcy, insolvency or the provider going out of business are among the reasons
for the customer to request the release of the code, the agent usually is able to easily verify
it, thus is not expected to object to the release. In cases however, when the customer claims
provider`s failure to provide proper software maintenance as a release event, the escrow
agent might need to wait for a court decision to validate this fact. In order to make the
procedure faster and the agreement more efficient as a continuity provision tool, the parties
can agree to an arbitration procedure for resolving the problem out of court.59
In relation to the release grounds and the release procedure strategies considered in the
escrow agreement, parties can adopt a first-call approach, where the provider will
immediately allow the source code release upon the inquiry of the customer. However, most
suppliers will be highly reluctant to agree on such a release procedure and they would rather
negotiate the trigger event to be an extreme circumstance, communicated by a notice,
followed by a certain period for consideration and in case of lack of mutual consent as to the
release event, the dispute would have to be taken to court or arbitration. In this situation
58
‘Source Code Escrow - A "Win Win" Solution’, Published: 18.12.2006 - Manitoba, Canada,
<http://www.hg.org/articles/article_1652.html> accessed 17.05.2010.
59
Eric S Freibrun, ‘Source Code Escrow Agreements - Balancing the Interests of Users and Vendors’ (1995),
<www.innovasafe.com/doc/freibrun.doc>, accessed 15.05.2010.
40 | P a g e
the whole procedure can take up months, which might turn to be unacceptable from a
continuity perspective.
Furthermore, the agreements should include a provision obliging the software proprietor to
submit any updates or modifications to the escrow agent that clearly correspond to the
software versions provided to the customer. Fulfilling this task is crucial, as the customer will
be practically unable to use the source code of version e.g. 1.1 in a meaningful way, if the
current software version they use is 5.1., and in reality as many as 80-90% of software
providers fail to submit the latest source code versions to the escrow agent.60 Moreover,
accessing the source code and all accompanying documentation including the latest updates,
does not necessarily provide the customer with the full opportunity to ensure software
continuity as they might not be able to operate or modify the software without certain
assistance from the provider, thus it is advisable to include an agreement provision in this
respect, obliging the software vendor to provide additional consultancy services to the
customer after the release.
Another clause typically contained in the escrow agreement relates to paying the fees to the
agent. The final decision about who pays the fees is left to the discretion of the parties – the
costs can be borne by the customer, the provider, or split between them. However, the
agreement may entitle the agent to destroy or release the code to the customer, should the
fees are not paid on time, when it is agreed that the provider is responsible for paying them,
thus providing a strong incentive for payment.
Furthermore, the parties should include extra care when drafting the limitation of liability
and indemnities provisions of the agreement. Many times limitations of liability clauses will
exclude agent`s liability for their negligent actions, as well as for any special or consequential
damages. 61 Considering the idea of the escrow aiming to provide the customer with the
necessary safeguards against losing the latest versions of the software, it is advisable for the
customer, as well as the provider, to insist that the agent assumes broad liability for their
own negligent actions. The agent should be obliged to indemnify the other parties for any
damages resulting from their acts of negligence, misconduct or material breach of the
60
Iron Mountain study, <http://www.ironmountain.com/ipm/>, accessed 24.05.2010.
61
Ibid: Mezrich (n 55)
41 | P a g e
agreement, as well as for breach of any warranties they have provided. The idea of broader
agent liability, is further supported by the fact that software escrow agents are usually not
part of a regulated profession, as for example are other types of escrow providers such as
lawyers and banks, and no specific regulations, codes of conducts or requirements (e.g.
holding an insurance) are applicable to them.
The software escrow agreement might further contain provisions regarding the use of the
source code after release. It should provide the customer with the license to use the
software for purposes of modification, corrections and other needed activities, because of
otherwise running into the danger of acquiring access to the code, but not being legally
entitled to use it for the continuity enhancing purposes. However, the contract should state
that the use of the code after the release will be still in accordance with the license provided
and any requirements should be fulfilled by the customer, including strict confidentiality.
As to the termination of the software escrow agreement, both parties should have the right
to terminate it in case the original software license has expired. If it is still valid however, the
agreement must stay in force, should the customer objects to its termination.
4.2.3. Limitations
Even though the software source code escrow is in general a good strategy when service
continuity related to the use of software is targeted, several factors can negatively influence
the efficiency and execution of the contract.
Bankruptcy of the software developer is seen as one of the main reasons for complications
for enforcement of the agreement, as bankruptcy law often regulates such contracts in a
way that puts the agreement execution at risk. Commonly the trustee for a bankrupt
company will have the authority to protect the estate of the bankrupt provider that can
reach to include the software licenses and escrow agreements. Specific insolvency and
bankruptcy rules are regulated in a different manner depending on the national legislations.
However, when comparing the bankruptcy legislation of the USA, the UK and Germany for
example, a certain tendency is observed towards trying to hold property in place, including
software, in order to maximize the proprietor`s estate. US bankruptcy law for example
provides three means of limiting access to source code: first, in case the escrow agreement
is confirmed as an “executory contract” by the court, which practically means the trustee
42 | P a g e
can decide on whether to accept or reject the contract; second, it is the situation in which
the source code submitted to the escrow agent is considered part of the developer`s estate
and as such cannot be transferred; and third – the automatic stay provision of the code,
which may not allow the access by the user62. The analysis of the UK Bankruptcy Act and
Companies Act, as well as German`s Bankruptcy Act shows that similar provisions are
contained there putting at risk the execution of the contract. Those problems might be
partially alleviated by structuring the escrow agreement in a way that aims at differentiating
it from any continuous software maintenance agreements, as well as not setting up the
position of the escrow agent as a custodian or agent of the software provider.
Further risk factors for the escrow agreement enforcement and its efficiency as a continuity
tool include escrow agent`s long term viability, the short life of software and the transition
to open source software, the customer`s lack of technical knowledge that can actually
position him in a situation of having the source code, yet not knowing how to use it for
continuity purposes, the loss or accidental destruction of the deposited source code by the
agent, the lack of any industry and professional standards applicable to software escrow
agents and the risk of not being able to actually activate the release of the code due to
unclear trigger events definition and procedures. It should be additionally noted that the
actual percentage of source code escrow releases actually occurring is very low, usually less
than 0.5% of all escrow agreements63, which clearly indicates that at this stage of
development of software escrow services, this specific tool might not be unproblematic, yet
with a diligently selected escrow agent and properly drafted agreement, it can provide at
least some level of continuity guarantee.
62
John M Conley, Robert M Bryan, ‘Software escrow in bankruptcy: an international perspective’ (1985), 10 N.C. J. INT'L &
CoM. REc,. 579.
63
Ibid: Mezrich (n 55)
43 | P a g e
or painlessly walking out of the project. Step-in rights for the customer are seen as an
instrument for ensuring continuity, focused on the situation when the provider is unable to
perform the services. The 2009 scandal with one of the largest Indian software companies
Satyam for example, have practically demonstrated the strong need of contractual step-in
rights and exit clauses as strategic tools targeting continuity.
It should be noted however that very little literature exists on step-in rights in outsourcing
projects, and even when present, it does not provide an in-depth legal analysis of this
instrument. Thus, the analysis given in this study is generally a personal interpretation,
based on experience and the scarce literature that is available.
The standard trigger events for execution of the step-in rights include insolvency of the
provider, breach of the service levels, material breach of the contract, force majeure events,
but they can also reach to include any other emergency situations or complaints from end
users, for example call center users.
For the successful drafting of step-in provisions of the agreement, several key aspects should
be considered so that the clauses are tailored as to the specific needs of the projects.64
Among the most important issues to be taken into account by the customer are: the
definition of the critical processes and services that will need to be prioritized when
stepping-in, the exact scope of the outsourced services, as well as whether the IT systems
are owned and hosted by the provider and the number of outsourcing providers engaged in
the provision of services. Furthermore, the customer needs to consider if they possess the
necessary expertise to successfully take over the services or a third party will need to be
involved. Additional questions such as what intellectual property rights are involved in the
project and who owns them should be answered. Finally, possible complications related to
trans-border projects and specifically to offshore outsourcing need to be taken into account.
In most agreements, the providers will consent to facilitate the assignment or novation to
the customer or third party representatives of software licenses, key-subcontracts or other
relevant agreements. It should be considered, however, that such assignment or novation
can be performed in accordance with the conditions of the relevant agreement and the
consent of the respective subcontractor or licensor should be obtained, thus, the role of the
provider often will be more of a facilitator of this transition.
The customer should be further entitled to step-in the rights of the provider in using specific
premises for the provision of outsourcing services. This can take the form in stepping into a
lease or rent agreement. The commercial and other specific terms, upon which such
premises shall be made available, need to be outlined in agreement and further detailed,
should a trigger event occur.
Moreover, the customer might have the right to acquire assets, such as software and
hardware that the provider has been using in the service provision. In this respect two types
of assets can be differentiated – sole use assets, being the assets that belong to the provider
64
Jill Stabler, ‘Step-in rights – It`s the plan, not the provision that really counts’, 25.03.2009
<http://www.alsbridge.eu/knowledge/articles.html?id=161> accessed 23.05.2010.
45 | P a g e
and shared use assets that are rented or partly owned by the provider that are both used to
support IT service continuity management, within the scope of the project. Regarding the
sole use assets, the customer should negotiate the right to require the transfer of ownership
to them following a notice submitted certain period in advance. The method of defining the
price payable of the assets might be set in the agreements, for example their Net Book Value
by the time of stepping in. In connection with the shared use assets, the customer should
have the right to rent the shared use assets or to be licensed for their use or where the
provider owns the intellectual property rights in any software, to be entitled to receive
continued support or maintenance in order to be able to assume responsibility for carrying
out the part or the whole project being currently affected by the disaster event.
This option differs from traditional exit provisions, which allow the customer to acquire only
certain provider`s assets such as IPR, by entitling the customer to buy the entire service
provisions facility. A special risk with this option however is the transfer process, which is
undeniably very complicated due to the transfer of multiple types of assets, therefore the
transition rules and procedures must be thoroughly defined in the contract.
46 | P a g e
customer to negotiate the waiving of provider`s fees during the step-in, as well as to recover
their own and any third parties` costs incurred in connection with the step-in. Moreover, the
provider would have to be obliged to assist for the smooth step-in by submitting information
about the services performed, the assets used and in general to provide access to their
documentation and resources, as well as to assist in case the assets need to be relocated.
4.3.5. Limitations
It must be noted, however, that step-in rights are not very often exercised for a number of
practical and legal reasons.65
First, in case the customer outsources their entire service provision, e.g. in full call center
outsourcing, there will usually be no available staff with respective expertise to assume the
provision of the service, thus, no practical applicability in terms of continuity is feasible.
Second, when no skilled staff and knowledge are available to the customer, they might want
a specialized third party representative to step-in and undertake the services. In this case,
the agreement should have been drafted in such a way as to allow third parties to step-in
and no additional limitations on this particular party entering the project should be present.
This is explicitly sensitive topic in highly specialized IT fields, where the companies with the
necessary know-how might be direct competitors to the service provider, therefore making
their involvement into provider`s work and information highly undesirable.
Third, in shared infrastructure and environment, used by the provider to carry on services
for multiple customers, confidentiality requirements might prevent the customer from
obtaining access to the infrastructure.
Furthermore, in shared infrastructure model, the provider might be highly reluctant to agree
on the customer having the right to acquire assets, would affect or even prevent him from
the opportunity to further provide their services to other customers. Moreover, in
multisouring projects, when services are outsourced to different providers, exercising step-in
rights in respect to some or all of them would undoubtedly require excessive efforts and
costs, or it can even turn out to be inapplicable for lack of know-how and resources.
65
Jagvinder Kang, ‘Outsourcing contracts: step-in rights’, <http://www.tlawa.co.uk/docs/tla-outsourcing-2.pdf> accessed
23.05.2010.
47 | P a g e
Another motivation for the provider to make their best to resist invocation of step-in rights,
are the cost implications. The situation of discontinued payment of service fees, while
customer is using their premises and assets, together with the obligation of paying any
additional costs of the step-in, would undoubtedly create a strong incentive for the provider
to dismiss certain step-in rights.
Furthermore, a difficulty with enforcing step-in rights comes from the duration of the step-
in, as most customers would want to continue exercising step-in rights for a long period of
time until the situation is resolved. From a provider`s perspective this situation would be
hardly acceptable, especially having in mind the abovementioned cost implications during
the step-in period.
Moreover, it is not only difficult to negotiate step-in rights and later invoke them due to the
expected resistance by the provider, but in reality there is a high probability that the
customer is not completely prepared how to deal with the step-in situation. In this respect, it
is not only the inclusion of the step-in provision that is important, but also the plan that the
customer has created for dealing with the crisis period.
Finally, when assessing step-in rights` efficiency and its enforcement potential, the
emotional resistance factor should be also considered. Since stepping into another
companies` doings is rather an aggressive tactics, a significant level of reluctance to assist
and facilitate this process by the provider and their employees can be expected.
Based on the abovementioned shortcomings of the step-in rights concept in ITO projects,
several alternatives can be mentioned66, such as addressing the disaster by escalation
meetings between the parties that aim at elaborating a less intrusive plan for remedying the
situation, using service credits, exercising the right to terminate the contract and claim
damages or temporarily suspend the provision of the services. Although they have some
level of remedial effect and provide a certain form of compensation, those measures are not
completely efficient in outsourcing business critical IT processes and services, when speedy
restoration of the services is crucial for the business continuity of the organization.
66
Ibid: Kang (n 65)
48 | P a g e
4.4. Exit Provisions
Just as step-in rights, exit provisions need to be negotiated at the offset of the outsourcing
project, when customer`s bargaining power is stronger. In order to preserve the service
continuity, customers needs to have negotiated provider`s assistance with assuming back in-
house of the services or transferring them to an alternative provider.
The outsourcing agreement will usually contain the following type of exit provisions: an
obligation for both parties to develop and agree upon an Exit Plan, an obligation for the
provider to submit information in the exit transition period and assist, an obligation to
transfer ownership of the IPRs and assets used for the provision of services and contracts,
arrangements covering transfer of personnel, as well as an option to extend the exit period
to face any unexpected delays.67
67
Ibid: Pinsent Masons (n 30), pp. 54-61.
49 | P a g e
provided under the same charging conditions, as well as the service levels should be met,
although the provider might not accept fulfilling certain requirements, such as providing
improvements and enhancements.68
4.4.3. IPR
Both parties must agree on who will own the IPRs at the exit of the contract. Regarding the
foreground69 IPRs, it is best for the costumer to negotiate that they own all IPRs created
during the term of the contract (e.g. bespoke software). In any case, they would need to
have the right to manufacture the product created and to outsource it to alternative
providers. Additionally, the right to use certain third party background70 rights on which the
foreground IPRs owned by the customer depend, should be negotiated.
Furthermore, the project might involve IPRs owned by the service provider or by third
parties and used by him in the provision of services. If continuity depends on such IPRs, it is
advisable that the outsourcing agreement contains clauses providing the customer with the
right to use those products. It is important in the first place to be able to identify those IPRs
and to prioritize them from the continuity perspective. Should the provider be reluctant to
grant broad license for certain proprietary products, the customer might consider limiting
the scope of the access and use of such products to the really continuity critical ones, or for
a limited period of time. Regarding third party IPRs, the customer will be in best position to
negotiate continuity of licenses before even the project starts to avoid unnecessary
obstacles during exit or unreasonably high charges for them.
On exit customers should also decide whether to grant licenses in their foreground IPRs to
the provider or restrict them. When providing the licenses, it is desirable to include certain
conditions such as limiting provider`s right to sub-license to direct competitors, if of course,
direct competitors can be clearly defined.71
68
C. Reed, J. Angel, Computer Law: The law and regulation of information technology, (OUP 2007), pp.139-193.
69
Foreground IPR – IP created during the term of the project.
70
Background IPR – IP created before the start of the project.
71
‘Protecting IP rights throughout an outsourcing project’,
<http://www.brownjacobson,.co.uk/press_office/articles/protecting_ip_rights_through_o.aspx> accessed 23.05.2010.
50 | P a g e
4.4.4. Transfer of assets
The provider should be obliged to return all assets previously owned by the customer, as
well as to provide the customer with the option to acquire from him other necessary assets
in order to ensure smooth transition and avoidance of service disruption.
The contract must include provisions defining a procedure for identifying the assets and
establishing their purchase price. For assets identification purposes, it is the optimal solution
if the provider is obliged to keep an asset register during the term of the agreement. The
register will typically contain information on all assets used in the service provision, such as
software, hardware, premises, licenses, data, etc. and should be regularly updated by the
provider to include the most current releases and versions. A copy of the register must be
handed to the customer on exit to enable him to choose from the list. In relations to the
asset transfer, it should be mentioned that, when the provider is using the same platform or
environment to render services to multiple customers, they will not be able to transfer most
of the assets to the customer without a disruption to their own service provision, thus they
will most probably try to resist such obligations.
72
Ibid: Pinsent Masons (n 30), pp.54-61.
51 | P a g e
Since such transfer is dependent on the third parties` position however, it is possible that
the supplier will not be able to successfully transfer them. Again, it is a matter of customer`s
strategic decision whether to outsource those IT services, if their continuous performance is
business critical for the organization.
The idea of the ARD is that in case of transfer of undertakings the employees` rights will be
safeguarded with the new employer and they will be given the same or similar employment
terms as with the previous employer. The TUPE regulations apply when there is a “relevant
transfer” and the new 2006 TUPE extend the transfer definition75 compared to the initial
1981 Regulations to be applicable to “service provision change” in the circumstances set in
the act76. Those circumstances, applied to the scope of the current study, cover initial ITO,
subsequent ITO to another provider and insourcing. In addition, according to TUPE 3(3)(a)(i)
prior to the service provisions change there must have been “an organized grouping of
73
Transfer of Undertakings (Protection of Employment) Regulations 2006
74
Council Directive 2001/23/EC on the approximation of the laws of the Member States relating to the
safeguarding of employees' rights in the event of transfers of undertakings, businesses or parts of undertakings
or businesses.
75
John Mcmullen, ‘An Analysis of the Transfer of Undertakings (Protection of Employment) Regulations 2006’
(2006) Industrial Law Journal, Vol. 35, No. 2
76
Art. 3(1)(b) TUPE :
(i) activities cease to be carried out by a person ("a client") on his own behalf and are carried out instead by
another person on the client's behalf ("a contractor");
(ii) activities cease to be carried out by a contractor on a client's behalf (whether or not those activities had
previously been carried out by the client on his own behalf) and are carried out instead by another person ("a
subsequent contractor") on the client's behalf; or
(iii) activities cease to be carried out by a contractor or a subsequent contractor on a client's behalf (whether or
not those activities had previously been carried out by the client on his own behalf) and are carried out instead
by the client on his own behalf. “
52 | P a g e
employees with principal purpose the carrying out of the activities on behalf of the client”. In
this situation, except for some specific cases77, the transfer of personnel is mandatory and
the employer cannot opt out of it. The personnel would have to be transferred together with
all rights and obligations under the employment contract (except for pensions) and they
cannot be dismissed only based on the transfer itself. Such a dismissal, or change of the
employment terms, will be automatically unfair, unless it is based on ETO (economic,
technical or organizational) reasons.
Since the employees would be transferred together with all liabilities, it is crucial for the
transferee to request that the transferor provides all the information in connection with
them. In this respect the contract should include warranties by the transferor that all the
information is provided and is correct and no other employees, other than those listed, will
be transferred.78 The Regulations provide for a complaint procedure, should a transferor fail
to provide the necessary information. Furthermore, it is also mandatory to inform and
consult employees` representatives about the transfer, for the failure of which, TUPE
provides joint and several liability for both employers.79
Although the customer might not want to accept the transfer of personnel they deem
unnecessary for the project, it would be mandatory to accept all the staff assigned to the
transferred service, as outlined above, thus, the main remedy applicable would be a
contractually agreed right to claim compensation from the provider for the personnel
transferred. Additionally, the customer might seek indemnities for claims brought by
employees in connection with the transfer or based on employment terms prior to the
transfer, such as unpaid salary.
Another staff related risk is the difficulty in keeping all key people, as many of them might
become de-motivated by the transition and might not agree to be transferred to the
customer80, all that leading to loss of important expertise.
77
TUPE 3(3)(a) (ii)”the client intends that the activities will, following the service provision change, be carried
out by the transferee other than in connection with a single specific event or task of short-term duration;
and
(b) the activities concerned do not consist wholly or mainly of the supply of goods for the client's use.”
78
Ibid: Vagadia (n 3), pp. 147-151
79
C. Reed, J. Angel, Computer Law: The law and regulation of information technology, (OUP 2007), pp.188-189.
80
TUPE and ARD allow the employees to opt out of the transfer.
53 | P a g e
4.4.7. Exit assistance and consulting
The truth is that smooth transition can hardly be achieved without the assistance of the
service provider. A well arranged contract will include provisions ensuring that customer
receives assistance, which consists of: exit planning, provisions of information about the
assets, processes used, details of key personnel, logistics assistance in transportation of the
transferred assets, trainings of customer`s staff or new provider`s experts, provision of
documentation, and any other assistance reasonably required as to ensure the successful
transition. The customer might also want to have the option of receiving provider`s
consultancy in selecting an alternative service supplier.
Regarding the first type, the customer will usually prefer to receive provider`s assistance at
no additional cost. However, requiring the provider to dedicate time and resources to the
smooth exit for free might not always be the most efficient approach to obtaining the
needed assistance, as they will try to not focus on that, since no payment is received. Thus,
for continuity reasons, more viable tactics could be for the customer to invest some money
in the exit, ensuring the proper performance of the exit obligations by the provider. In order
to further motivate the provider to really do their best, an exit assistance fee might be only
payable upon a successful transition.
As to the second type of costs, the provider might want to be compensated for the
terminations of the services, but as this is mostly applicable when the agreement is
terminated by the customer for convenience and not in disaster or provider failure cases, its
practical significance for continuity is not of great importance.
4.4.9. Limitations
Carefully drafted exit provisions are essential from a customer continuity perspective.
However, several typical problems regarding their applicability and enforceability must be
outlined.
Detailed Exit Plan is often not drafted until a very late stage of the project, many times until
a certain incident happens. As already mentioned above, it not only puts the customer in
54 | P a g e
considerably weaker bargaining position compared to the initial phase of the project, but the
late incident based composition of the Exit Plan also implies the risk of missing out important
details. Another common problem with the timing is the case of drafting detailed provision
way too early and failing to update them with the progress of the project, so that finally they
reflect only the initial state of affairs between the parties, which might have changed
significantly during the long outsourcing duration.
Furthermore, the invocation of exit provisions is closely related to the termination of the
contract. In this respect, clear termination rights for the customer should be negotiated, in
such a way that non-performance of the provider unlocks those rights, which subsequently
provides a reason to use the exit conditions.
In addition, since the assistance of the provider during exit is crucial as already mentioned
above, the customer should try to avoid any lack of motivation of the supplier during the exit
period, thus trying to stimulate it by both positive measures, such as payment for those
services, or negative ones, including claiming damages for example.
In conclusion, a key concern regarding unproblematic exit is related to not only having the
drafted exit provisions, but also a further idea and a plan as to the specific steps to be taken
after exit. In this respect, it is in best customer`s interest to take all efforts to be practically
prepared for exit, and especially for the post-exit period.
55 | P a g e
5. Conclusion
This thesis has outlined the main contractual instruments, applicable for maintaining
business and service continuity of the customer in traditional, as well as in several types of
novel ITO projects, in the light of the growing significance of ITO for organizations in terms of
number and scale of outsourcing activities, and moreover considering its strategic impact on
organizations as part of their key business strategy. Considering the central goal of the study,
i.e. to analyze available legal tools and to offer effective solutions, a selection and analysis of
general means for ITO project control and specific ITO continuity instruments has been
provided. It has been observed however that statutory legal framework relevant to ITO
projects offers generic regulation of mostly non-ITO specific matters like IPR, data
protection, insolvency, contracting in general, etc., and /is fragmented in multiple acts,
hence, specific contractual tools for ensuring continuity have been offered.
Although measures for maintaining project quality and control are considered crucial for the
success of the ITO endeavor, and as such are inevitably related to continuity, an even more
comprehensive analysis of specific IT continuity tools, including back-up and disaster
recovery plans and provisions, source code escrow agreements, step-in rights for the
customer, as well as exit provisions, has been offered. The analysis comprises the main
reasons to use each of the instruments, its essence, practical recommendations regarding its
drafting, and an outline of the main limitations or drawbacks for its efficiency and
enforcement.
Back-up and disaster recovery provisions and planning, being the first presented instrument,
have been considered as key tools for prevention and correction of negative consequences
of natural, technical, social or even financial disasters. As the timing and scale of disasters
are by definition unexpected, it is highly recommended for an organization which relies on IT
as strategic function, to include back-up and recovery measures in the hotlist of contractual
topics when outsourcing. Furthermore, up-to-date storage and data replication technology
allows continuous data protection, which can back-up all the data almost immediately, thus
providing a high level of safety for customer`s data. However, this instrument might not be
fully efficient if for technical reasons data cannot be restored or is restored with errors, or
the service provider itself has suffered service disruption. Additionally, contract drafting
56 | P a g e
deficiencies such as Force Majeure clauses which allow service provider to deny
performance on force majeure grounds can make the disaster recovery tool useless in
certain situations.
Regarding business critical software, a Source Code Escrow solution has been analyzed. From
continuity point of view, having an access to key custom software source code, stored with a
third party agent if the provider is no longer able or wishing to render their services, is
practically the best next thing to developing the software in-house. Nevertheless, risks such
as the escrow agent own viability problems, loss or destruction of the deposited source code
or the lack of deposited latest versions and updates are seen as considerable obstacles for
the efficiency of the tool. Furthermore, even if successfully released, the source code might
be unable to serve the customer in maintainingtheiroperation and services, if specific
technical knowledge as to what to do with the source code is missing. A significant problem
with enforceability from a legal perspective is connected with supplier`s insolvency, when
trustees might logically try to dismiss the escrow agreement in their endeavors to maximize
provider`s estate.
Another useful tool relevant when the provider has, for some reasons, ceased to perform, is
the provision in the outsourcing contract of step-in rights for the customer. It indeed could
be a very effective instrument, if the customer has the resources and know-how needed to
perform the services or a well prepared third party is allowed to step-in. Moreover, this
approach can be applicable if the outsourcing model is based on single prime provider, not
using the same platform to provide services to other customers. In shared environments
however, the supplier will be unwilling to allow stepping-in or buying as this could
compromise the confidentiality in respect to other customers and might further
damagetheirentire service provision capability.
Furthermore, the significance of clear and comprehensive exit provisions has been analyzed
as a key step towards providing continuity. Such provisions would usually include the rules
for transferring from provider to customer of assets (e.g. hardware used for the IT services),
contracts (e.g. software licenses) and people, as well as it might additionally require the
supplier to continue performing the services for a certain period of time and/or to provide
exit assistance. In order for exit provisions to serve as an effective continuity tool, they
57 | P a g e
should be exhaustively drafted at an initial project stage, when the customer still has a
stronger bargaining power and should be regularly updated. Again, if the suppler is using
certain assets or employees to provide services to multiple customers, provisions ensuring
their transfer to customer might be resisted. From a practical perspective, in some cases like
offshoring, such transfer will not be even possible, for example the transfer of all service-
dedicated employees from India to the country of the customer.
It has been also outlined, that in addition to the general outsourcing and IT risks, further ITO
complications can be expected in offshoring, stemming from the cultural, organizational and
legislative differences between the parties. Difficulties with enforcing foreign judicial or
arbitral decisions, together with the decreased operational control and management of the
projects, as well as the lower infrastructure and power reliability of typical offshore
destinations, turn offshoring into a riskier endeavor, when continuity is essential.
58 | P a g e
As mentioned in the Introduction, the literature providing a comprehensive legal analysis of
ITO continuity instruments is very limited or even missing. Available articles usually
introduce one or just some of the tools, sometimes ignoring important legal aspect, while
focusing on the technical side, therefore, not providing a complete overview of the
continuity topic in its integrity. In this respect, the academic and practical contribution of the
present study is seen as providing specific legal analysis of a complete set of the most typical
ITO continuity instruments, combined with practical drafting recommendations.
Finally, based on the above conclusions, successfully ensuring continuity in ITO could be
seen as a combination of evolutionary IT project management and coordination to provide
the overall project quality, together with comprehensive legal and practical consideration of
risks, reflected in an exhaustive outsourcing agreement, supported by an updated legal
framework, which addresses specific outsourcing continuity problems.
59 | P a g e
APPENDIX 1
ITO Risk Matrix
ITO Risk Matrix
№ Continuity
Risk Category IT Specific tool
Risk Description specific risk Preventive tools Risk Response measures
(legal/practical) (yes/no)
(yes/no)
1 Lack of IPR protection Legal No No Initial contractual definition Clear identification of all IP
of background and and respective ownership
foreground IPR
2 Unclear IPR ownership Legal No No Initial contractual definition Clear identification of all IP
of background and and respective ownership
foreground IPR ownership
3 Insolvency of provider – inability Legal Yes No Early warning contractual Termination based on
to terminate before provider`s termination triggers trigger events
default
4 Unclear obligations and Legal No No/yes Definition of specific result Periodical measurement
performance metrics obligations and service levels and assessment
(instead of “best efforts”)
5 Unrealistic long term contract – Legal No No Termination rights, Termination
lock-in termination for convenience
6 Lack of specific statutory Legal No Yes Drafting of specific (Statutory changes)
regulation contractual instruments
7 Difficulties in timely and properly Legal No No Carefully selecting contract (Accepting the risk)
enforcing foreign judicial or governing law
arbitral acts Carefully selecting
outsourcing locations
8 Exit chaos Legal/practical Yes No Clear Exit provisions Activation of exit provisions
Detailed Exit Plan
9 Unavailability of specific software Legal/practical Yes Yes Exit provisions providing for Assignment or novation of
licenses after contract termination assignment or novation of software licenses
software licenses
10 Lack of contract flexibility Legal/practical No No Change management Contract updates based on
change management
procedures
11 Lack of access to key data (loss or Practical Yes Yes Back-up arrangements for Data restoration according
corruption of key data) data storage and replication. to the agreed service levels
12 Unexpected change of Project Practical No No Statement of Work (SoW) Contract changes.
scope Change Management Plan Update of the Project Plan.
13 Unclear expectations and Practical No No SoW as part of the master SoW to be made available
requirements outsourcing agreement to the respective
Clear communication stakeholders
Clear communication at all
levels
Periodic project reports
14 Natural, technical or social Practical Yes Yes Back-up and Disaster Activation of disaster
disasters Recovery provisions recovery provisions.
Restoration of data,
platforms, applications or
facilities.
15 Communication problems Practical No No Clear and mutually agreed Re-consideration of project
between parties communication plan communication plan.
Regular and clear project
61 | P a g e
progress reports.
16 Coordination problems with Practical No No Clear Project Management Update of Project Plan
multiple providers Plan. Reduction of number of
providers
17 Loss of key expert staff Practical Yes No Periodical coordination Assignment of new team
between team members; members
keeping them informed Involvement of external
about project progress. experts
Incentive and motivation
measures
18 Software provider discontinue Practical Yes Yes Source Code Escrow Source Code release
supplying software or software
maintenance
19 Extortion or commercial Practical No No Confidentiality Agreement Damages, injunction
espionage
20 Shared environments Practical No No Security audit rights Damages, injunction
confidentiality risks
21 Unavailability of specific physical Practical Yes No Exit provisions providing for Transfer of assets
assets after contract termination transfer of assets Purchasing of new
replacement assets
22 Security vulnerability Practical No No/yes NDA, security audit rights, Damages, injunction
security standards
23 Insolvency of provider – Practical Yes No Termination and exit Activation of exit assistance
discontinue service provision and assistance clauses. clauses
assistance Financial incentives for exit
and termination assistance
24 Service provision disruption in Practical Yes No Continuous service provision Service provisions
case of disputes obligations for the provider continuance based on the
62 | P a g e
until dispute resolution contractual obligations
63 | P a g e
Appendix 2 Figures from the literature review
2.1. Potential Types of Exposure
Source Rike, B. “Prepared or Not…That is the Vital Question”, Information Management Journal.
Lemexa: Vol. 37, Iss. 3; pg.25.
64 | P a g e
2.2. Percentage of organizations that use outside service providers
Books:
1. Andrew Hiles, Business Continuity: Best Practice, (2nd edn, Rothstein Associates,
2004).
2. Andrew Hiles, E-business Service Level Agreements, Strategies for service providers, e-
commerce and outsourcing (The Rothstein catalog on service level books, 2002),
pp.1-28.
3. Angel Kalaydjiev, Law on Obligations. General Part (Sibi Publishing, Sofia, 2001).
5. C. Reed, J. Angel, Computer Law: The law and regulation of information technology,
(OUP 2007), pp.139-193.
7. Dorian J. Coigias, E.L. Heibelger, Karsten Koop, The backup book. Disaster recovery
from desktop to data centers (3rd edn, Schaser-Vartan Books, Lecanto, 2003), pp.1-34.
8. Mark Lewis, Computer Law: The Law and Regulation of Information Technology.
Information Technology Outsourcing and services arrangements (6th edn, OUP, 2007)
pp.139-182.
Articles:
10. Achim Hecker, Hendrik Kohleick, ‘Explaining Outsourcing Failure’ (October 27, 2006).
<http://ssrn.com/abstract=939411>
11. Ann H. Spiotto, James E. Spiotto, ‘The Ultimate Downside of Outsourcing: Bankruptcy
of the Service Provider’(2003) 11 Am. Bankr. Inst. L. Rev. 47 at 62.
16. David Fitoussi, Vijay Gurbaxani, ‘IT Outsourcing Contracts and Performance
Measurement’ (2010). <http://www.crito.uci.edu/projectsMIS04papers.asp>
accessed 19.04.2010.
18. Eric S. Freibrun, ‘Source Code Escrow Agreements - Balancing the Interests of Users
and Vendors’ (1995), <www.innovasafe.com/doc/freibrun.doc>, accessed
15.05.2010.
19. H. Ward Classen, ‘Fundamentals of software licensing’ (1996), IDEA – The journal of
Law and Technology. <http://euro.ecom.cmu.edu/program/law/08-
732/Transactions/Fundamentals.pdf>, accessed 3.05.2010.
20. Hunton & Williams, Marsh, `Risk Management in Next Generation Outsourcing`
(2008),
67 | P a g e
<http://www.hunton.com/files/tbl_s47Details%5CFileUpload265%5C2125%5COutso
urcing_white_paper_2.22.08.pdf> accesses 11.04.2010.
23. Jahyun Goo, ‘Structure of service level agreements (SLA) in IT outsourcing: The
construct and its measurement’, Published: 13 February 2008,
<http://sce.uhcl.edu/cs/pub/Kim_C35.pdf> accessed 17.03.2010.
24. Jill Stabler, ‘Step-in rights – It`s the plan, not the provision that really counts’,
25.03.2009 <http://www.alsbridge.eu/knowledge/articles.html?id=161> accessed
23.05.2010.
68 | P a g e
30. Kate Phizackerley, ‘Outsourcing Exit Strategy - Planning Ahead For the Full Contract
Life Cycle’, <http://ezinearticles.com/?Outsourcing-Exit-Strategy---Planning-Ahead-
For-the-Full-Contract-Life-Cycle&id=2726556> accessed 15.04.2010.
31. L. Kappelman, ‘Early warning of IT Project Failure: The dominant dozen’ (2006),
Information Systems Management 2006/23, p.31-36.
32. Li-jie Jin, Vijay Machiraju, Akhil Sahai, ‘Analysis on Service Level Agreement of Web
Services’, Software Technology Laboratory, HP Laboratories Palo Alto, HPL-2002-180,
Published: June 21st , 2002, <http://www.hpl.hp.com/techreports/2002/HPL-2002-
180.pdf> accessed 12.04.2010.
33. Linda Markus Daniels, ‘Does Your Source Code Escrow Agreement Achieve Its
Objectives?’ (2007),
<http://www.innovasafe.com/pdf/Does%20Your%20Source%20Code%20Escrow%20
Agreement%20Achieve%20Its%20Objectives_Linda%20Markus%20Daniels.pdf>,
accessed 20.05.2010.
35. Matt Karlyn, ‘The Essential Lawyer: Force Majeure Meets Disaster Recovery’, CIO
Decisions Magazine Archives, <http://searchcio-
midmarket.techtarget.com/magItem/0,291266,sid19_gci1213262,00.html> accessed
20.04.2010.
36. Matthew K. O. Lee, ‘IT Outsourcing Contracts: Practical Issues for Management’
(1996), Industrial Management & Data Systems, Vol. 96, 1, pp.15-20.
37. Nabarro LLP, ‘What are step-in rights?’, RICS Construction Journal, February 2009,
<http://www.nabarro.com/Downloads/what-are-step-in-rights.PDF> accessed
05.02.2010.
38. Norton Rose Group, `Satyam: what are the consequences for offshore outsourcing?`
Published 16.01.2009,
69 | P a g e
<http://www.nortonrose.com/knowledge/publications/2009/pub19079.aspx?lang=e
n-gb&page=all>, accessed 12.05.2010.
41. Periklis A Pappous, ‘The software escrow: the court favorite and bankruptcy law’,
(1985), Santa Clara Computer&High Tech L.J. 309.
42. Pinsent Masons, ‘User`s Guide to Outsourcing’ (2008), <http://www.out-
law.com/page-364> accessed 11.04.2010.
44. Protiviti. APICS. ‘Managing the risks of outsourcing: a survey of current practices and
their effectiveness’, <http://www.protiviti.com/en-
US/Insights/Surveys/Pages/Managing-Outsourcing-Risks-Survey.aspx> accessed
22.03.2010.
70 | P a g e
48. Sam De Silva, ‘A contractual approach to manage security risks when outsourcing’
(2009) C.T.L.R. 2009, 15(3), 51-57.
49. Sam De Silva, ‘Best Practice for Contract Management’, Published: 30.10.2008,
<http://www.it-director.com/business/content.php?cid=10828>, accessed
15.03.2010.
50. Sam De Silva, ‘Lessons Learned - Contract Renewals and Exit Management’,
Published: 07.04. 2009, <http://www.it-
director.com/business/content.php?cid=11186>, accessed 15.03.2010.
52. Sam De Silva, ‘Smart Outsourcing: Avoiding the Pitfalls’, Published: 19.01.2010,
<http://www.it-director.com/business/content.php?cid=11830> accessed
15.03.2010.
53. Samitha De Silva, ‘FSA operational risk systems and control: guidelines for
outsourcing’ (2003) C.T.L.R., 9(8), 217-225.
54. Shalini Agarwal, Sakate Khaitan, Satyendra Shrivastava, Matthew Banks `Destination
India: offshore outsourcing and its implications` (2005) C.T.L.R. 2005, 11(8), 246-262.
55. Shalley Dash, ‘The Economic Implications of Outsourcing’, Institute of Integrated
Learning and Management.
56. Simon Colvin, Garfield Smith, ‘An introduction to IT outsourcing’, last updated
February 2008, <http://www.out-law.com/page-501> accessed 21.02.2010.
57. ‘Source Code Escrow - A "Win Win" Solution’, Published: 18.12.2006 - Manitoba,
Canada, <http://www.hg.org/articles/article_1652.html> accessed 17.05.2010.
58. Treasury inspector general for tax administration, ‘Better Emergency Preparedness
Planning Could Improve Business Continuity Efforts’, 13.02. 2009, Reference Number:
2009-20-038, <http://www.tigta.gov> accessed 15.03.2010.
71 | P a g e
Other sources:
7. Council Directive 2001/23/EC on the approximation of the laws of the Member States
relating to the safeguarding of employees' rights in the event of transfers of
undertakings, businesses or parts of undertakings or businesses.
13. IT disaster recovery (DR) plan template: A free download and sample plan, Published:
13.10.2009,
<http://searchdisasterrecovery.techtarget.com/generic/0,295582,sid190_gci137068
3,00.html> accessed 13.04.2010
14. ITIL Service Continuity Management,
<http://www.itlibrary.org/index.php?page=IT_Service_Continuity_Management>
accessed 15.04.2010
15. PACE, ‘Business Continuity Planning Guide’,
<http://www.ogc.gov.uk/documents/PACE_-_BCPG.pdf> accessed 12.04.2010.
17. Short Survey of the Principles of European Contract Law: Introduction to the
Principles of European Contract Law Prepared by The Commission on European
Contract Law,
<http://frontpage.cbs.dk/law/commission_on_european_contract_law/survey_pecl.
htm> accessed 23.04.2010.
73 | P a g e