Once upon a time, and long ago – in the mid 90’s – a client
of mine set up a software company. To me, then, very cutting edge, and I hoped
they didn’t ask me any questions.
But they did – their first customer was Slaughter & May,
a well-known law combo. Slaughter &
May asked for an escrow agreement. My clients didn’t know what one was. So they
asked me. I had no idea what they were
talking about, but they insisted I found out. So I did, and here we are.
Escrow Basics
Source code in computer programmes is, of course, often
regarded as the crown jewels of software vendors – this is where their creative
effort and money has been invested, and what vendors are anxious to protect. Open source evangelists regard proprietary
source code as an abuse of human rights, of course; that’s another
argument. But in the world of
proprietary software, you don’t want your competitors and imitators looking
under the bonnet. Let them create their own
product, without piggy-backing an existing one.
Some customers, like Slaughter & May in 1996, have a
concern that if a vendor fails in its obligation, or goes out of business, they
won’t be able to maintain or use the software. This is where software escrow
comes into play. In a non-SaaS
application, the approach generally is to involve NCC Escrow or another escrow
agent, and enter into a tripartite agreement involving them, the vendor and the
customer. In summary, this means that a copy of the source code is lodged with
NCC, and kept updated. If the vendor is
in breach of its obligations to the customer, or disappears, the customer can
apply to NCC for access to the source code. There is a procedure to allow the
vendor to dispute the application, but if the source code is released, it is
released for specific limited upkeep purposes, and does not give the customer
ownership. Nonetheless – from a vendor’s
point of view, the source code is seen.
SCL readers will be familiar with this process, and to dealing with NCC
who have substantial credibility, and who, when involved, move quickly and effectively.
There is a common variant on this, where there is a
multiparty arrangement, so the agreement is just between NCC and the vendor,
but allows multiple customers to add themselves to the agreement.
There is of course a significant cost to this, for the
vendor and the customer, and the cost depends on the role NCC performs; this
can include different levels of verification of the code, and different
intervals for the deposit of source code. Sometimes bespoke provisions are needed and
can be negotiated. It’s an important, valuable service for which NCC is highly
trusted. There are other escrow agents, but NCC are regarded as being the
default choice, and their agreements the base standard. We’ve had clients using them, too, since
1996.
SaaS Challenges
SaaS though provides different challenges, because it’s not
just the source code which the customers don’t have; they also don’t hold their
own data. There are many advantages to
this; but the vulnerability is different. NCC have developed a SaaS Assured
approach https://www.nccgroup.trust/uk/our-services/software-escrow-and-verification/saas-assured/ which they describe this way:
Your SaaS provider will be paying a regular fee to their
Information-as-a-Service (IaaS) provider for hosting services. Through SaaS
Assured, NCC Group will monitor these payments for any irregularity. Should
this happen, a copy of your data and/or production environment is securely
stored in escrow for your use if further failure occurs. This enables you to
minimise any downtime or disruption by having a clear and prepared continuity
plan secured by an independent third party.
We had a need to consider this in the context of a client
working in a regulated environment where the regulator became unusually
involved in the area of resilience. The
regulator wanted to know that, if our client vendor didn’t maintain the hosted
environment, the customers would have uninterrupted access to their data. In
effect, business continuity needed to be pretty well seamless. The NCC process
involves monitoring payment irregularities, and if those occur, then the
storing of static data if/when failure, or further failure, occurs. Actually
the regulator didn’t spell it out as clearly as that, but working with our
client, we thought we needed to anticipate the requirements and gold plate
them.
Our first discussion was with NCC, to understand what SaaS
Assured provided. It became apparent
that what NCC cannot do is have a dynamic, always-on mirror of the whole
production environment; they will hold a snapshot at a particular time,
updated. Reading their summary above,
this is clear. To expect them to have a live mirror of the
service at all times would be unrealistic, but it means the service is
necessarily something short of a provision for business continuity/disaster recovery.
In this instance, and by extension in many instances, the customers need
uninterrupted access both to the program, including its source code, and the
live data. If SaaS Assured cannot
provide that, then a different approach is needed, building on the base Escrow
arrangement.
An Escrow-like Solution for an Saas World
Working with NCC and the vendor client, we devised a
structure involving not just contractual arrangements with the hosting
providers, the customers and NCC themselves, but physical and financial
arrangements so that there is a strong safeguard not just to cover what happens
if the lights go out but to prevent the lights going out at all; we aimed to achieve
barely a flicker.
In this structure there are five parties. The obvious ones
are the vendor, the customer, NCC and the host.
The fifth one, in our case, and the crucial and novel one, was a third
party developer familiar with the platform on which the product was based.
The key agreement is with this fifth party, because they
will be the continuity partner. This
means that if the vendor fails to perform, in specified circumstances, they are
able to step into the shoes of the vendor, and have rights to do so both under
the vendor/customer contract, and under the agreement with the hosting
provider. They are paid a retainer to
hold that position, and of course have a licence to hold the source code. In effect they, potentially, will inherit the
vendor’s customers, and its revenue stream; there would though be provisions to
allow the vendor to step back in if the default were cured. To be clear also – the continuity partner
isn’t an alternative cloud provider – the continuity partner replaces the
vendor, not the cloud provider.
The hosts are tied in by an addendum to the standard hosting
agreement which involves the host, the vendor and, importantly, the continuity
partner. For the host, the benefit is that it holds, in effect, a deposit
against a number of months’ hosting fees, so that it will keep the lights on;
and it allows the continuity partner immediate access to the platform and the
data when the continuity agreement comes into in effect.
The switch would therefore be seamless.
There is a standard escrow agreement with NCC where the
customer is the continuity partner, and all the fees are paid by the vendor. This secures the rights to the source code,
whilst the addendum to the hosting agreement secures the rights to the data and
the operating program and platform.
All this needs to be reflected in the customer contract,
with the customer acknowledging the rights of the continuity partner – including
the right to receive data when the continuity agreement kicks in. And
throughout, there need to be specific third-party rights granted to make sure
the arrangement hangs together.
We think this works – though it hasn’t been tested in
extremis. There are a number of costs
and, because of the number of parties and the costs, the circumstances where
this can work will be specific. There
also has to be a suitable continuity partner, and a compliant host (but why
wouldn’t they – in this case, it was a well-known international hosting
provider). But NCC are happy with it, and the regulators are happy with it. The drafting implications are a little
intricate, but largely to make sure all the jigsaw pieces fit. The documents involved are:
- the licence and continuity agreement, which is a piece of
green-field drafting; - the addendum to the hosting agreement, which we were able to
keep tight and which the hosts liked from the outset; - the customer licence, which involved additional provisions
to a normal SaaS arrangement; and - a standard NCC
tripartite Escrow agreement.
In our view SaaS for escrow is a problem, and this feels
like a solution which, in a number of circumstances, works – and not like
anything we’ve seen. It may also be a way of addressing wider BCDR issues. What
has anyone else seen?
Paul Berwin is senior partner at Berwins, and heads its Leeds-based
Berwins Digital division: PaulBerwin@berwin.co.uk
