Archive for April, 2010

SaaS, ASP Agreements – FAQs – Security

What data security provisions need to be included in a SaaS agreement?

Customer’s Security Obligations

These should be set out in the software licence. Access to the software and services should not be permitted to third parties without prior authorisation from the supplier. The customer should provide the following warranties:

  • existence of adequate security measure to ensure access to the software and services does not breach the terms of the SaaS agreement
  • relevant confidentiality provisions relating to the use and access to passwords required for accessing the software and services
  • the obligation to notify the supplier of all security breaches, unauthorised access to the software and services and misuse of passwords
  • provision of indemnities for breaches of the above warranties

Supplier’s Security Obligations

These should be set out in the software licence and in the service level agreement (SLA). The supplier’s obligations will be more extensive than the customer’s obligations due to the nature of a SaaS agreement and the inherent risks of operating over the Internet. The following provisions should be included:

  • details of the firewalls and cryptology used
  • obligation of the supplier to notify the customer of security breaches or data loss
  • details of the data centre security structure
  • restrictions on access to passwords
  • information about virus protection mechanisms

Additionally the supplier should reserve the right to suspend access to the software and services if there is a security breach in order to ensure the integrity or security of the software and services.

Audit Rights

Sometimes customer’s will have a regulatory duty (i.e. under the FSA) to check the supplier’s security structures and systems and that the supplier is complying with its contractual security obligations. If an audit right is granted the following issues should be covered in the SaaS agreement:

  • frequency of the audits
  • payment for the supplier’s time and assistance with audits
  • the supplier’s right to be given copies of audit reports
  • confidentiality provisions relating to access to the supplier’s IPRs, data and infrastructures and disclosure of such to third parties
  • whether or not the supplier has any obligation to make changes to the software and services following an audit


For assistance with any security issues, SaaS, ASP, software on demand contracts or any other IT legal issues contact me at:

To register for my newsletter click here


Other related articles:


SaaS, ASP Agreements – FAQs – Software Licence

The software licence to be included in a SaaS agreement is very different from the standard software licence found in non-SaaS agreements for the following reasons.


Access to the software is provided together with support and maintenance services. Without support and maintenance there can be no licence and vice versa. This is because  the  customer has no copy (physical or intangible) of the source code or object code. The software is installed on the supplier’s server and accessed by the customer via the Internet.

The customer therefore does not own any software licence. The customer simply has the right to access the software and the services together for the term of the SaaS agreement. Unlike a standard software licence, no perpetual licence is granted. The term of the licence is the same as the term of the support and maintenance services and both cease to exist when the SaaS agreement is terminated or expires.

NB/It is possible to have  perpetual licence in a more complicated SaaS agreement but this is the exception rather than the norm, and is not dealt with here.

Use of the Software

The software should only be used for the specific purposes set out in the SaaS agreement. Issues such as territory, number of users, who the users are (i.e. the customer, the customer’s users, the customer’s subsidiaries and identified third parties).  No right to copy, distribute, resell or lease the software should be granted to the customer.

Intellectual Property Rights – IPR

The customer needs to be granted the right to use the software for the term, however no rights in the software, source code or support and maintenance services  should be transferred to the customer. No rights in any developed or customised software should , or can be transferred to the customer – as there will be no developed or customised software created in a standard SaaS agreement.


No right to copy, decompile or create derivative works from the software should be granted to the customer. However, under the Copyright, Designs and Patents Act 1988 the customer has a mandatory right to decompile the software in limited circumstances, which should be referred to in the SaaS agreement, as such rights cannot be contractually excluded.


If you are providing business critical software to customers (i.e. online banking) it is usual to offer customers the possibility of entering into an escrow agreement to hold the source code, or data in escrow. However, if the software is not business critical (to your customers) this should be an optional clause that can be added to the SaaS agreement later at the request of the customer, as most customers will not want to incur the additional cost of an escrow agent.


For assistance with any software licence matters, in particular SaaS, ASP, software on demand contracts or any other IT legal issues contact me at:

To register for my newsletter click here


Other related articles:


SaaS, ASP Agreements – FAQs – Escrow

When negotiating a SaaS agreement you may come across the term escrow. What is  escrow and is an escrow agreement necessary?

SaaS and Escrow

Under the terms of a SaaS agreement you do not own and only have very limited rights to use the software (which includes the source code) that you are accessing. This is usually not an issue until technical problems arise, i.e. unexpected service interruptions, downtime, loss of application functionality and loss of data. Such problems can add significant costs to your business and you are dependent upon the supplier to resolve these issues, unless you have an escrow agreement in place.

Escrow Agreement

An escrow agreement sets out the terms on which the  software source code will be held by a third party – an escrow agent – on behalf of the customer and the supplier. The escrow agent stores a copy of the software source code and will release this to the customer if any of the events set out in the escrow agreement occur (e.g. the supplier fails to maintain the software, there is a transfer of intellectual property rights in the software or the supplier becomes insolvent). Thus the customer has the right to continue to use the software if the supplier is in default. However, having the right to use the software and actually being able to use the source code are very different.

Limitations of Escrow Agreements

The following should be considered by customers before entering into an escrow agreement:

  • is the software business critical, if not, do you really need an escrow agreement?
  • the cost of setting up the escrow agreement and the ongoing renewal fees;
  • do you have the technical know-how to understand and use the source code in the event of an escrow release?
  • do you have programmers who can in the long term update and enhance the software to stop it becoming outdated?
  • will you need to engage a specialist software consultant to deal with the source code?
  • is there alternative SaaS software which could simply be used instead?

There is no point having access to the source code if you cannot actually use  and understand it, as access alone will not ensure business continuity.

Types of Escrow Agreement

If you decide to enter into an escrow agreement you will need to choose between a multi-licence or a single licence agreement.

Many suppliers have multi-licence escrow agreements for their source code already in place with recognised escrow agents. The customer can quickly be added to pre-existing agreement as a licensee. The advantage of multi-licence agreements is that they are relatively inexpensive (compared to a single licence agreement). The customer simply pays a fee to join the existing multi-licence agreement and usually an annual renewal fee. The disadvantage of a multi-licence agreement is that only the basic source code will be held in escrow, no customisations will be stored.

If the customer has any source code customisation that they are accessing it is worth considering having a single licence escrow agreement. This will ensure that the customer’s source code version is held in escrow. The disadvantage of this is that the single licence agreement will need to be set up and the fees are much higher.


For assistance with any escrow matters, SaaS, ASP, software on demand contracts or any other IT legal issues contact me at:

To register for my newsletter click here


Other related articles:


SaaS, ASP Agreements – Source Code and Object Code

When negotiating a SaaS agreement you will come across the terms source code and object code. What is the difference between source code and object code?

Source Code

Source code is the version of a computer programme that exists prior to the software being ready to compile and run on a computer. The source code consists of a number of statements created in a text form by a programmer. These statements are saved in a named file which is the source code. This file is human-readable but cannot be executed directly by a computer. The source code needs to be translated into object code by compiling it into a format the computer can interpret.

However, modern source code can often be the same as the object code with no compilation required. An example of such code is HTML which is used to build most web sites.

Object Code

Object code is the version of a computer programme that is created by the source code being translated and compiled by a special programme. The object code file contains a sequence of  instructions that can be executed directly by a computer. The  object code is difficult for a human to read or modify.

Importance of the Source Code

When the source code is translated into the object code, a lot of information is lost. Therefore the object code cannot be used to fully reconstruct the original source code. The source code is the most permanent form of the programme. Accordingly it is advisable to have the source code held by a third party in escrow, to ensure that you have access to the source code in the event of the insolvency, or access and maintenance issues with the software supplier.


For assistance with any SaaS, ASP, software on demand contracts or any other IT legal issues contact me at:

To register for my newsletter click here


Other related articles:


SaaS, ASP Agreements – FAQs – Data Protection

Data protection issues must be adequately covered in any SaaS agreement to protect both the supplier and the customer.

Data Protection Act 1998

The Act applies to the processing of personal data, for example name/email addresses, dates of birth, national insurance number of any living individual. In a SaaS agreement, the customer will always be the data controller, as the customer is collecting data from its clients and deciding and controlling the purposes for which the data will be processed.

Supplier – Duties as Data Processor

The supplier is obliged to process data in accordance with the customer’s instructions and to take appropriate technical and organisational measures to protect the data. These duties must be included in the SaaS agreement, either in the data protection clauses or in a separate data processing agreement. The supplier should protect itself against liability to the customer for breaches of the data Protection Act which  arise due to the supplier  simply processing  data in accordance with the customer’s instructions.

Customer – Duties as Data Controller

The Customer must register as a data controller under the Data Protection Act if it collects personal data. Failure to register is a criminal offence.

The customer must also comply with the following 8 data protection principles:
Data must be,

  • fairly and lawfully processed;
  • processed for limited purposes;
  • adequate, relevant and not excessive;
  • kept for no longer than necessary;
  • processed in accordance with the data subject’s rights;
  • secure; and
  • transferred outside of the EEA only if there is adequate protection in that country.

The customer will be liable to its clients whose data it collects and processes (data subjects) for any breaches of the above principles. As the supplier will be carrying out the processing on behalf of the customer, the customer must ensure that adequate clauses are contained in the SaaS agreement to protect itself against data protection breaches, caused by the supplier.

Subject Access Request

Data subjects have the right to make a subject access request to find out what personal information is being held on them and to obtain a copy of this. This information must be provided within strict time limits and at a minimal cost to the data subject. The request is made to the data controller (the customer) as they are obliged to respond. However it may well be the supplier who needs to actually provide the information. The SaaS agreement needs to cover how and when such information will be released and to whom.

Data Transfers Outside of the EEA

If data is to be transferred outside of the EEA the specific consent of the data subject concerned must be obtained before the transfer takes place OR the transfer is permitted if the non-EEA country to which the data is being transferred has equivalent data protection legislation.

The European Economic Area means the 27 EU member states plus Norway, Iceland and Liechtenstein. Currently only Andorra, Argentina, Canada, the Faroe Islands, Guernsey, the Isle of Man, Israel, Jersey and Switzerland are recognised as countries having adequate protection. In addition companies registered under the Safe Harbor regime in the USA are also recognised.

Consent from data subjects can be obtained by the customer including relevant information in its privacy policy and ensuring that its clients actively consent to transfers of their data outside of the EEA when they register to use the customer’s products or services.

Any transfer of data to any other country or without the data subject’s consent will be illegal.


For assistance with data protection issues, SaaS, ASP, software on demand contracts or any other IT legal issues contact me at:

To register for my newsletter click here



Other related articles:


SaaS Agreements – Essential Elements

The following legal issues should be included in any SaaS agreement, whether you are a SaaS supplier or a SaaS customer.

Software Licence

Access to the software should be limited to the term of the SaaS agreement. Once the SaaS agreement expires or terminates the software licence should automatically terminate.

If the SaaS customer is a global entity, specify which companies or entities may access the SaaS software, in which territories and the number of users. Identify the specific purposes for which the software may be accessed. Name any third parties who will be permitted access to the SaaS software i.e. outsourcing providers or clients of the SaaS customer.

Intellectual Property Rights – IPR

The SaaS supplier should retain ownership of all IPR in the software and services it provides. The SaaS customer should retain ownership of all IPR in its systems and data. The SaaS agreement should specifically state that the source code remains owned by the SaaS supplier. The SaaS customer should grant the SaaS supplier the right to use its IPRs for the term of the SaaS agreement i.e. display its logos and copyrighted information.

Applicable Law, Jurisdiction & Language

State which law applies to the SaaS agreement and which courts will deal with any disputes arising from it. In international SaaS agreements make sure that you specify in which language the dispute will be dealt with, and if the SaaS agreement is in more than one language, which language prevails if there is a discrepancy between the two versions.

Return of Data

At the end of the SssS agreement the SaaS customer’s data should be returned. The format in which the data is to be returned and payment for this service should be agreed in advance.  Additionally the parties can agree that the Saas supplier will provide assistance in transferring SaaS customer data to a new supplier – in return for payment for this service.

Data Protection

The SaaS supplier is the data processor and the SaaS customer is the data controller. Under UK data protection law different rules apply to the data controller and the data processor. The SaaS supplier is obliged to process data in accordance with the SaaS customer’s instructions and should protect itself against claims from third parties that such processing was illegal. Likewise, the SaaS customer will also need to protect itself against claims from third parties caused by the SaaS supplier not processing data in accordance with its instructions or the terms of the SaaS agreement.

Service Level Agreement (SLA)

This sets out the hosting, support and maintenance services being provided to the SaaS customer by the SaaS supplier. The SLA should specify where the data centre is located, who is operating it, what security, backup and disaster recovery procedures are in place. Support hours and support services for dealing with hosting problems and software problems should be identified and documented and the procedure for dealing with with upgrades and maintenance to the software should be specified. The particular details will depend on the amount being paid for the hosting, support and maintenance and the purpose for which the software is being used.


Specify who the owner of the source code is, as it may not be the supplier i.e. the holding company of the supplier. State whether or not the customer can enter into an  agreement with a third party to hold the source code in escrow.  Include the name of the escrow agent and who will be responsible for the costs of the escrow agreement and any annual renewals.


Irene Bodle is an IT lawyer specialising in SaaS, with over 14 years experience dealing with SaaS, cloud computing matters and IT law issues. If you require assistance with any SaaS agreements, cloud computing matters or any other IT legal issues please contact me at:

To register for my newsletter click here


Other related articles:

Website Legal Requirements – Ecommerce

Does your website comply with the various legal requirements in the UK?

Below, I have set out the main legal requirements (including some optional recommendations) that you should be complying with.

Mandatory Requirements

About Us/Contact Information

You must provide the following information in an easily accessible position on your website:

  • your legal name i.e. XYZ Ltd
  • your geographical address
  • contact details i.e. telephone number, fax number and email address
  • which country your business is registered in and the registration number
  • details of any supervisory body which regulates your business i.e. the FSA. For regulated bodies more detailed information is required.
  • where you are registered for VAT and your VAT number
  • clear details of prices and whether or not delivery and/or tax is included

Registration under the Data Protection Act

If you collect any personal data on your website – i.e. email address, name or address of a living individual, you will be processing personal data and must register as a data controller under the Data Protection Act. It is a criminal offence not to register.

Privacy Policy

If you are collecting, storing or processing personal data you need to set out how and why you are doing this to comply with the 8 principles of the Data Protection Act. In particular if you are sending marketing emails to potential customers you need to ensure that you have obtained specific consent, BEFORE such emails are sent. Consent should be covered in your privacy policy and the registration process on your website.

Disabled Access to your Web Site

If you offer goods or services on your website you need to make your website accessible to disabled users. Level 1 compliance with the WC3 standard will usually suffice.

click here for further details on WC3 compliance

Trade Marks and Logos

Do not use other people’s trade marks or logos without their consent on your website or you could be liable to pay damages for trade mark infringements.


Do not use other people’s content without their consent on your website, or you could be liable to pay damages for copyright infringements. If you have links to other people’s content, make sure that this is permitted in their terms of use and ensure that the information opens in a new frame.

Online Payment

If you accept online payment for goods or services you must provide customers with specific information about their right to cancel, VAT and prices, refunds and defective goods PRIOR to the sale being concluded.

Recommended Requirements

In addition to the above mandatory rules it is advisable to have the following, in addition.

Terms of Use/Disclaimer

You should set out the rules applicable to persons using and accessing the goods and services on your website. For example state who may access the website i.e. consumers, businesses, over 18s. You should also aim to limit your liability for information on the web site. For example state which law applies, your limits on liability etc. However, please note that you cannot exclude or limit certain liabilities in particular circumstances  – particularly in relation to consumer, injuries caused by goods and services, or defects in your goods and services.

Copyright Notice

Protect the information on your website by inserting a copyright notice “© company name 2010.  All rights reserved.” Without this notice,  it may be difficult in some countries to take any action against a copyright infringement.

The above are examples of the main legal requirements for websites. This is a very complicated area of law and the specific rules that apply to you will depend on what goods and services you are offering, whether you are acting BTB (business to business) or BTC (business to customer), where you are based, where your customers are located and many other factors.


If you would like to have your website reviewed for compliance with English law or have any queries about compliance please contact:

To register for my newsletter click here


Other related articles:

Bodle Law
Assign a menu in the Left Menu options.
Assign a menu in the Right Menu options.

This website uses cookies. You may not use this website, unless you agree to our use of cookies. For further details about the cookies we use please visit our Cookie Policy

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.