Paul Berwin suggests an innovative solution to a long-standing problem that has been given a tricky new twist
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.
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 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:
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