Irene Bodle

About Irene Bodle

I am an internationally experienced English lawyer with an LL.M in German law.

I am the founder of Bodle Law, a virtual law firm created in 2010, which provides specialist advice on SAAS, ASP and software agreements, IT law, Internet law and commercial contract law. The "legal cloud".

Prior to founding Bodle Law, I worked for 8 years as Corporate Counsel in a global Internet and software company, drafting and negotiating international software (ASP, SAAS, standard), hosting and outsourcing contracts, distribution, agency and software licence agreements for clients in EMEA, Asiapac and the USA.

I am also experienced in acquisitions/due diligence of software companies in EMEA and the USA, domain and trade mark portfolio management and disputes and the negoatiation and drafting of international commercial contracts.


IT law and contracts, in particular SAAS, ASP, software contracts, IPR law, company and commercial law.

Fluent German and English.

Social Media Contacts and Customer Lists – Ownership and Use Problems

If you actively encourage or allow your employees to use LinkedIn and Twitter to store or build up their business contacts you need to ensure that you have control over how this information will be used if the employee ceases to work for you, as most contacts will be your SaaS customers, other employees and SaaS suppliers.

In the last few years there have only been a handful of court cases in the UK (and the US) providing guidance on this issue and whether or not contacts in social media channels such as LinkedIn and Twitter can be used by ex-employees.



In October 2011 a US company, PhoneDog Media, sued a former employee for taking 17,000 Twitter followers with him when he left the company. PhoneDog claimed that the followers constituted their client list which was confidential.

The BBC also had a similar problem last year when an employee with 60,000 Twitter followers moved to a rival TV channel and took all of her followers with her by simply renaming her twitter account.



Back in 2008 the High Court ordered a former employee of Hays (the recruitment firm) to hand over all of his LinkedIn contacts when he left the company to set up his own consulting business. Hays claimed that the contacts were confidential information of the company and that the former employer had breached the terms of his employment contract by using this information for business purposes.


Social Media Issues for Employers

The above decisions highlight the dangers of encouraging employees to use social networking websites for work. The list of contacts of a SaaS sales consultant in LinkedIn will probably read like an A – Z of your SaaS customer base.  Once an employee leaves your employment you need to be able to deal efficiently with “ownership” or breach of confidentiality issues relating to the use of these contacts. This can only be achieved if you have already considered the “ownership” problems inherent in social media contacts and have agreed on what should happen if an individual leaves the company.


Who owns a Profile or Account

This will often depend upon who set up the account, why it was set up and who is paying for, and/or maintaining it.

Generally a LinkedIn profile or Twitter account belongs to the employee, even if you instructed the employee to create it – as it relates to an individual. It is “ownership” of the contacts in the profile that is important and this is what needs to be controlled to stop employees downloading SaaS customer contacts into their social media contacts database before leaving your employment.


Who owns Contacts or Followers

This is the wrong question to ask as no-one can “own” a contact. The question to ask is whether you have in place the correct safeguards to prevent employees from using the contacts including when they leave.

For example if you have non-solicitation or non-compete clauses in an employee’s contract of employment these could prevent the employee from using the contacts stored in their profile, as they will be confidential information.



In view of the uncertain legal status of social networking contacts it is advisable for companies to have employees sign a social media policy which sets out what use can be made of social media contacts once an employee leaves the company. Other measures that companies could consider taking are:


  • to simply ban all use of social media sites such as Facebook, LinkedIn and Twitter;
  • to ensure that relevant employees add all new LinkedIn contacts to the company’s CRM database;
  • to include non-competition and non-solicitation clause in employment contracts or other agreements;
  • to include social media clauses in all employment agreements.


By considering the risks and taking necessary measures to prevent these issues arising in the future you should be able to avoid costly litigation when key employees leave, potentially taking your SaaS customer contacts and followers with them.

SaaS Agreements – Online Sales – Terms and Conditions

Many SaaS suppliers now conclude sales of SaaS products with customers online, usually by having customers “click” acceptance of terms and conditions published on their website. SaaS suppliers need to ensure that their online terms and conditions include the following information, in order to create a legally enforceable SaaS agreement with the customer.

E-Commerce Regulations

These Regulations apply to all SaaS suppliers who sell or advertise SaaS services online. The Regulations apply BTB (business to business) and BTC (business to customer).

The SaaS supplier must provide the following information on its website:

  • legal name i.e. XYZ Ltd. If this is different from your trading name any differences should be explained;
  • geographical address,  which must be the registered office if you are a company;
  • which country your business is registered in;
  • the registration number of your company;
  • details of any supervisory body which regulates your business i.e. the FSA;
  • VAT number and where you are registered for VAT;
  • clear details of prices and whether or not delivery and/or tax is included.

It is advisable to include all of the above information (as applicable) in your online terms and conditions.

Incorporation of Terms

In order for a SaaS customer to be legally bound by your online terms and conditions, the content of the terms and conditions must be drawn to the customer’s attention before the SaaS products are purchased.

Customers should be required to:

  • “click” acceptance to your terms and conditions; or
  • read, or scroll through the terms and conditions;

before purchasing the SaaS products.

Changes to Terms and Conditions

If you want customers to be legally bound by future changes to your online terms and conditions, you must state this in your online terms and conditions. You should also make the terms and conditions available on your website at all times, so that they can be stored or reproduced by customers.

Customer Cancellation Rights

If you are selling SaaS products to consumers the provisions of the Distance Selling Regulations 2000 (as amended in 2005) will apply and from Autumn 2013 the new EU Consumer Rights Directive will also apply. These contain provisions about mandatory “cooling off” periods and customer cancellation rights, with limited exceptions. However, if you only sell SaaS products BTB, these rules do not apply.

Other Laws

In addition to the E-Commerce Regulations, depending on whether or not you supply SaaS products BTB or BTC, other laws such as the Unfair Contract Terms Act 1977, the Unfair Terms in Consumer Contracts Regulations 1999 and the Supply of Goods and Services Act 1982 will apply to your online terms and conditions.

SLAs – Terms to Include

The following issues should always be included in any SLA, regardless of the type of SaaS product and services being supplied.

Clearly define times for all of your actions. Business hours and days need to be carefully defined, particularly if you have customers outside of the UK, or your maintenance and support staff are located across the globe.

If your SaaS agreement includes non-English speaking customers specify in which languages you provide support.

Customers expect to be given a guarantee of the availability of the SaaS product and services. This usually ranges from 95 – 99.9%, depending on the type of services being provided. It will also largely depend upon the availability guaranteed by any third party data centre you use to host your SaaS products and services.
When stating the level of availability of the SaaS products and services specify how and when availability will be measured, remembering to exclude any down-times for maintenance from the calculation.

Customer Support
Provide a short description of the support that you will provide to customers. This should include details about how you can be contacted and the way in which you will respond to, and fix software problems. Specify severity levels and state times for responding to and fixing software problems, remembering to differentiate between problems (errors that can be reproduced) and bugs.

Set out the times and days when you will carry out maintenance. Distinguish between regular maintenance and emergency maintenance, as you may need to install emergency patches and carry out emergency repairs at any time. State whether or not any prior notice will be given. Any downtime caused by you carrying out scheduled or emergency maintenance should be excluded from the calculation of availability.
Specify whether or not upgrades are included in the services. Will they be free of charge, or are they only provided upon payment of an additional fee? Are upgrades mandatory or voluntary? Also identify what is actually included in an “upgrade”.

Briefly describe the security provisions that you have in place at your data centre and internally within your organisation. These should include:
• Details of data centre security structure and infrastructure;
• Details of the firewalls and cryptology you use;
• Any obligation to notify the customer of security breaches;
• Restrictions on access to passwords;
• Information about virus protection mechanisms.

Other Issues
Other provisions that you could consider including in your SLA are:
• Service credits;
• Backup of customer data;
• Disaster recovery provisions;
• Provision of reports.

Commercial Considerations
The above is a general guide to the terms to include in a SLA for a SaaS agreement. The degree of detail that you provide will largely depend upon the following:
• The type of SaaS products and services you are supplying;
• How much the customer pays for the SaaS product and services;
• Whether the SaaS product is business critical i.e. online banking;
• What is standard in that particular business area.

SaaS Agreements – Need for an Escrow Agreement

As a SaaS supplier you may want to consider offering escrow agreements to your customers, particularly if you run SaaS applications which are critical to your customer’s business.

What is Escrow

Escrow refers to a third party holding a copy of the SAAS software source code on behalf of the customer and the supplier.

What is an Escrow Agent

An escrow agent is a third party who stores a copy of the SaaS software source code. The escrow agent will release a copy of the source code to the customer if any of the events set out in the escrow agreement occur.

Why use Escrow

This is usually a customer driven requirement resulting from the fact that the source code for the SaaS software, the expertise to implement it and rights to the SaaS software are only licensed to, and not owned by, the customer for the term of the SaaS agreement.

Customers are concerned that the supplier may:

  • fail to maintain the software;
  • transfer ownership of intellectual property rights in the SaaS software;
  • become insolvent;
  • or become unable to carry on supporting and maintaining the software for some other reason.

By having an escrow agreement in place the customer has the right to continue to use the software, if the supplier is in default of its obligations under the SaaS agreement.

Advantages of an Escrow Agreement

Having an escrow agreement in place protects all parties involved in the development, supply and use of business critical SaaS applications. It provides customers with peace of mind for securing long-term availability of a critical SaaS application by enabling customers to update software and fix any bugs even if the supplier is no longer able to support them.

Disadvantages of an Escrow Agreement

Having the right to use the software under an escrow agreement is in reality of little use if the customer does not have the know-how and resources to actually use, maintain and support the source code itself.

Also, the costs of setting up an escrow agreement and maintaining it are relatively expensive. Escrow costs are usually paid for by the customer.

Is Your Website Cookie Compliant?

From the 26th of May 2012 the UK Information Commissioners Office (ICO) will start prosecuting companies for their failure to comply with the Privacy and Electronic Communications (Amendment) Regulations. This sets out new obligations with regard to the use of cookies or similar technologies for storing information such as flash cookies, web beacons or bugs.

What is a Cookie?

Cookies are small text files placed on a user’s computer which record online activity. Virtually all websites use cookies. Most use analytics cookies to measure visits and use of websites. Performance and functionality cookies are used to make repeated use of a website more comfortable for the user and advertising cookies are increasingly used to collect information about users for targeted marketing.


Users must consent to the use of cookies. Such consent must be:

  • freely given;
  • specific; and
  • informed.

This generally means that a user needs to “opt in” to the use of cookies.

The more specific the consent is the less likely it is that you will be in breach. For example if you obtain consent before a cookie is set you will have obtained specific consent. If you rely on implied consent you need to show that the user has taken some positive action to imply consent.

The International Chamber of Commerce UK office (ICC) provides some suggested wording that can be used to obtain consent via websites.

There is an exception to the need for consent, but only if the cookie is strictly necessary for the delivery of the service, for example the cookie takes the user from a product page to a payment page.

Cookie Notices

You must provide users with clear and comprehensive information about:

  • the type of cookies being set; and
  • the purposes for which the information is collected.

The ICC suggests categorising cookies into 4 groups – strictly necessary, performance, functionality and targeting/ or advertising cookies. The reason for collecting each type of cookie applicable should then be explained.

Who do the Rules Apply to?

The Regulations do not define who is responsible for complying with the rules, but this is probably the person/company setting the cookie. Where third party cookies are used both parties will be responsible for ensuring that users are clearly informed about cookies and obtaining consent.

How to Comply with the New Rules

The ICO has issued non-binding guidance suggesting ways in which consent to the setting of cookies can be obtained and the ICC guidance suggests various methods for complying with the notice requirements which include:

  • Popups;
  • Terms and Conditions;
  • Settings /Features;
  • Banners /Footers;
  • Icons.

How to Avoid Fines

A breach of the Regulations can result in a fine of up to £500,000. Therefore, if you have not already done so, you should carry out a cookie audit to review the use of cookies on your website. You need to assess what type of cookies you use, how long they are being used, why you are using them and remove any redundant or unnecessary cookies.

Thereafter you should update the information you provide about cookies in your privacy policy or create a separate cookie policy, ensuring that this information is easy to find on your website. You should state the type of cookies you use, why you use them and how users can opt out of you setting cookies.

You also need to consider how and when you will obtain consent to any cookies you use. Will the consent be implied or specific. Also do not forget to provide information about any third party cookies that are placed and provide links to information about these that the third parties may provide.

Enforcement by the ICO

By the 26th May 2012 you must comply with the new rules as the ICO will start taking formal action. The ICO has stated that they will be selective. For example they have clearly indicated that they are unlikely to prosecute companies who only use analytic cookies and will concentrate on websites where no steps have been taken towards collecting consent or where particularly intrusive cookies are used.


UPDATE – ICO guidance on new ‘cookie law’


As we have previously informed you via our Cache updates – the government gave organisations until last Friday to fully comply with the new ‘cookie law’ – i.e. that cookies (and other similar technologies) should only be used if a website owner provides users with clear and comprehensive information about cookies and gets their consent.

Previous guidance and commentary on the new law suggested that consent would have to be gained through an explicit, opt-in style consent (e.g. tick boxes). However, late in the day the ICO has now updated their guidance and expanded this significantly in relation to implied consent. Bearing in mind that guidance is guidance and the law is the law – and the law says that the user must have “given his or her consent”. The ICO guidance now explains that implied consent can still be compliant with the new law as long as users are clearly and actively advised that cookies are being used on the site. Therefore, this is not an excuse to ‘do nothing’ – as hiding away cookie information in website policies will not satisfy the requirements of the new law, however the idea that implied consent will be compliant does ease the practical difficulties that had been worrying many website owners. The updated ICO guidance is available by clicking here.

This bulletin contains a summary of complicated issues and should not be relied upon for specific matters. We have specialist advisers within the Intellectual Property and Technology Team who can assist you with ‘cookie law’ compliance and reviewing website policies. Please contact for further information.

If you feel the brief is useful, please feel free to forward this email to a friend or colleague.

SaaS Agreements – Software – Copyright Protection

SaaS Software with the same functionality can co-exist without there being an infringement of copyright, following the recent opinion of the Advocate General in SAS Institute and World Programming Ltd. The Advocate General advised that it is the methods used to create the means for the software to carry out its functions, not the functions of the software and the programming language which can be protected by copyright.

What is Copyright?

Copyright is the right to stop others from copying works without permission. Copyright in SaaS software derives from the software being an original literary work. Copyright protects the expressions of ideas in the SaaS software NOT the ideas themselves.

SAS Institute and World Programming Ltd

The High court referred this case to the European Court of Justice (ECJ). The SAS Institute claimed that World Programming Ltd infringed copyrights in its software by using information from the SAS Institute manuals (not the source code) to develop rival software. The SAS Institute argued that the functions of its software were copyright protected pursuant to the Computer Programs Directive. This Directive protects copyright in the expression in any form of a computer programme. It does not however cover ideas and principles which underlie any element of a computer programme, including those which underlie a computer programme interfaces.

Are Software Functionalities Protected by Copyright?

The Advocate General ruled that the functionalities of software are simply “the service which the user expects” from the computer programme. For example, when using software to book an airline ticket the functionalities of the booking process will be the same regardless of which company’s software you use. Such services cannot be protected by copyright. However, what can be protected by copyright, is the means by which the functionalities are achieved as this reflects the author’s own intellectual creation. Protection will depend upon the degree of originality in the writing of the software.

This is not the end of the matter, as the ECJ still has to make a ruling on this case. However the ECJ usually follows the opinion of the Advocate General. In which case, the ability of SaaS software suppliers to prevent the functionality of their software being replicated in the future will be limited, provided that the SaaS software source code is not replicated.


SaaS Agreements – Liability – Online Comments

New proposed UK defamation laws recommend that web hosts (SaaS suppliers) and ISPs should be allowed to keep allegedly defamatory comments online, as long as the author of the comment is identified and a notice of complaint is published next to the comment.

Current Law and Liability

Currently web hosts and ISPs must immediately remove online comments upon gaining actual knowledge that the comments are defamatory. Failure to remove defamatory comments exposes the web host/ISP to a claim for damages for defamation. Actual knowledge is deemed to occur once the web host/ISP is informed that the comments are defamatory or the web host/ISP moderates comments on the website.

Under the E-Commerce Regulations SaaS suppliers are usually exempt from liability for defamation if they merely act as conduit or cache or host material, provided that they:

  • do not initiate the transmission of defamatory comments;
  • do not select who receives the comments; or
  • do not select or modify information in the transmission of the comments.

New Proposed Rules

Currently most web hosts/ISPs do not moderate comments or content on websites in order to take advantage of the exclusion set out above. Thus they avoid having “actual knowledge” of any defamatory comments on websites that they host.

The proposed change to defamation laws aims to incentivise web hosts and ISPs to moderate comments and/or content. SaaS suppliers should comply with the rules set out below taking into account the new distinction between anonymous and identified author comments.

Anonymous Comments

Upon receipt of a complaint a SaaS supplier should immediately taken down anonymous comments unless;

  • the SaaS supplier believes that it is in the public interest for the material to remain on the website i.e. whistle blowing; or
  • the author promptly responds positively to a request to identify themselves, then a notice of complaint should be posted.

Identified Author Comments

Upon receipt of a complaint a SaaS supplier should;

  • publish a complaint notice beside the comment; and
  • then have a judge decide whether or not the comment should be removed.

Avoiding Liability

If a SaaS supplier complies with the above rules they should not be liable for online comments. However, if the SaaS supplier fails to comply with the above, they could be sued as publisher of the content or comment along with the anonymous author – who may not be identifiable.

Regardless of whether or not the proposed changes are implemented, SaaS suppliers should always include a clause in their SaaS agreement permitting them to remove content from customer websites they are hosting in order to enable them to minimise the risks of being pursued for a defamation claim.

Cloud Computing and the Legal Cloud

Everyone is talking about “cloud computing” but what is it?

What is Cloud Computing

Cloud computing is a new and rapidly expanding delivery model, often used to supply IT services to customers via the Internet. Cloud computing involves the sharing of resources, software and information on the Internet for users to use on their computers and other devices, on-demand.

Other Related Terms

Where software is supplied using the cloud you will hear people refer to SaaS, software as a service, ASP services and software on demand to describe the provision of the services.

Why refer to a “cloud”

The term “cloud” is used as a metaphor for the Internet, based on the cloud drawing used in the past to represent the telephone network, and later to depict the Internet. Typical cloud computing providers deliver business software applications online which are accessed from another web service or software i.e. a web browser while the software and customer data are stored on servers, hosted by the service provider.

The Legal Cloud

Most cloud computing infrastructures consists of services delivered through hosting centres. The service provided to users are usually set out in a service level agreement (SLA) and the software licence for use of the services and software will be set out in a SaaS agreement.


SAAS, ASP, software on demand – confused?

What is SAAS?

This is the abbreviation for “software as a service”.  You may know this under another name, for example ASP services (application service provider) or software on demand. These names all refer to the same thing – and simply mean that you are accessing and using software via the Internet.

How is SAAS different from a standard software licence?

A SAAS agreement differs from a standard software licence, as you will not usually receive a physical or installed copy of the software. Also no ownership in the software will be transferred to you.  You are simply given the legal right to access and use the software for the length of the software licence granted to you.

Is a service level agreement (SLA) a software licence?

No. A service level agreement sets out the services being provided in addition to the right to use the software, namely the hosting, support and maintenance services.

Due to the unique nature of SAAS agreements to seek specialist legal advice on the content of such agreements. This will ensure that your rights are adequately protected, particularly in the event of things going wrong.

New Consumer Rights for Online Sales

If you supply goods and services to consumers via the Internet you will need to change your terms and conditions of sale to incorporate the new EU Consumer Rights Directive before the end of 2013. The new directive harmonises consumer rights protection across the EU for all BTC (business to customer) online sales of goods and services. The directive must be implemented into UK law before the end of 2013 (probably in a Consumer Bill of Rights) which will result in the following compulsory rules applying to online sales.

Cooling-off Period

Customers will have 14 days (instead of the current 7 days) to cancel an online contract for no reason, free of charge. The 14 days will start on receipt of goods (where goods, or goods and services, are purchased) and on the date of the contract (where services are purchased). There is an exception for digital content – where the sale is deemed to be concluded from the moment that downloading begins, provided that:

  • you have obtained the customer’s prior express consent; and
  • the customer has acknowledged that there is no right to cancel.

Suppliers must inform customers of their right to withdraw from the contract within the cooling-off period, otherwise the customer’s right to withdraw will automatically extend to 12 months.

If a contract is cancelled during the cooling-off period, provided that the goods are returned within 14 days of the customer giving notice of cancellation, the supplier must refund:

  • the price within 14 days of the cancellation date; and
  • the postage costs for returning the goods, unless the supplier clearly informed the customer prior to the contract being concluded, that these costs would not be refunded.

Pre-Contract Information

The following minimum information must be provided to customers before online sales are concluded.

  • the name and full address of the supplier;
  • exactly what is being bought;
  • the price (including any additional charges or costs, such as taxes and delivery costs);

The above information must be provided in a way which allows the customer to store, access and reproduce the information for as long as may be necessary in connection with the online sale.

Also note that before the online sale is concluded the total price, including all charges should be made clear. The use of ‘pre-ticked boxes’ to conceal hidden charges will no longer be acceptable.

Delivery Date

Goods must be delivered without undue delay and in any case no later than 30 days from the conclusion of the contract.

Surcharges and ‘Hotlines’

Suppliers must not charge customers more for specific payment methods than they pay themselves i.e. fees for using a credit or charge card. In addition customer service telephone numbers must be charged at a basic NOT premium rate.

What to do Next

In preparation for the changes, you should review your current terms and conditions and customer policies now to adapt them to comply with the new rules.  Customers are more aware of their online rights and increasingly make complaints. Also, national regulators will be keen to enforce the new rules and make public examples of non-compliant companies.

Legal Clauses to Include in a SaaS Sales Proposal

SaaS suppliers often prepare sales proposals in order to win business from prospective clients. A few basic legal clauses should be included in the sales proposal to protect your business if you win the sale, but more importantly, if you don’t.


There can be a substantial time delay between sending a client a proposal and actually negotiating the terms of the SaaS agreement. The proposal may also include pricing for optional additional functionality that the client may want to order a later stage. The proposal should state dates for the validity of the various prices quoted, otherwise you could be obliged to provide functionality in 2012 for 2010 prices.

SaaS Agreement Terms and Conditions

The proposal should state that the software and services will be sold subject to the supplier’s standard terms and conditions. This is particularly important for SaaS applications. Often client’s – who are usually not software suppliers and who supply physical goods – will want to use their own standard terms and conditions. These will not work for a SaaS agreement as the software is not a physical good (and for many other reasons which will not be elaborated here). If the client’s terms and conditions are used – a situation which should be strongly resisted – they will need to be substantially amended, which will waste time and expense. If you already have suitable terms and conditions in place then it makes commercial sense for both parties to use these as the basis of the SaaS agreement.

More importantly – always specifically state in the proposal that your SLA (service level agreement) will apply. This sets out the hosting, maintenance and support services that you will be providing to the client. As you will usually be using a third party hosting centre to provide the majority of these services, the SLA must reflect the level of services that you yourself receive from the hosting centre. It makes no commercial sense to use an SLA provided by the customer, as you will not be able to comply with this.


It is imperative that you obtain the client’s undertaking to treat all information provided to them by you during the sales process – including any documents referred to in the proposal – as confidential.  You will probably have given the client copies of your price lists, functional descriptions of your software and other internal documents which you do not want third parties to see. This is particularly important if the proposal does not lead to a sale and the client is speaking to your competitors… The client should agree to keep all information confidential and to return all of your confidential information immediately, if no sale is agreed.

No Obligation to Supply

The proposal should state that it is not legally binding and does not create any obligation on your part to provide the software or services to the client. Often between the proposal stage and the actual terms of the SaaS agreement being negotiated, your client’s requirements will have changed. You do not want to be bound by the terms and prices, in the proposal if the client has changed the basic scope of the services or the functionality.

SaaS Agreements – FAQs

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 (for example, 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.


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 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 Switzerland, Canada, Argentina 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.


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 or have any rights to 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. This 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?
  • does 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.


SaaS, ASP Agreements – FAQs – 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.


SaaS Agreements – FAQs – Personal Data

What is personal data and how is it relevant in a SaaS Agreement?

What Data is Personal Data?

The Data Protection Act 1998 (DPA) defines personal data as:

  • Data which relates to a living individual; and
  • From which the individual can be identified.

This will include for example the name, email address, telephone number, date of birth, and the national insurance number of any living individual.

What Data is not Personal Data?

  • Data about individuals who are dead;
  • Data from which individuals cannot be identified;
  • Data about limited companies or plcs;
  • Anonymised data which cannot be traced back or lead to the identification of an individual.

Are IP Addresses Personal Data?

An IP address is the unique intellectual property address of a computer. There is uncertainty about whether or not an IP address is personal data, as the IP address identifies a computer and not always an individual. For example, the computer identified may be used by different people in an office, family, or Internet cafe. In such circumstances the IP address of the computer does not necessarily relate to an individual and will not always be considered to be personal data.

However, often a computer does identify the individual using it, for example, if the IP address is registered to an individual (this can be checked by doing a “whois” search). In this case the IP address does identify and relate to an individual, so the IP address is personal data.

One further point to note is, even if an IP address is “anonymised” before being passed on to a third party it can still be personal data. For example, if the anonymised data is used for behavioural advertising purposes, the IP address will still be personal data – as it is the behavioural advertiser’s intention and purpose in using the data to identify the individual behind the IP address in order to target advertisements at the identified “anonymised” individual.

Why Personal Data Matters

The DPA sets out the rules for processing personal data. The rules that apply to the processing of personal data differ depending upon whether you are a data processor or a data controller.

In a SaaS agreement, the customer will always be the data controller, as the customer collects data from clients and decides and controls the purposes for which the data will be processed. The SaaS supplier will always be the data processor in relation to the customer and the customer’s personal data.

Under the DPA, the SaaS supplier is obliged to:

  • Process data only in accordance with the SaaS customer’s instructions; and
  • Take appropriate technical and organisational measures to protect the personal data.

Contractual Obligations

The aforementioned duties of the SaaS supplier as a data processor must be included in the terms of the SaaS agreement, either in the data protection clauses or in a separate data processing agreement.

Additionally, SaaS suppliers should protect themselves against any liability to customers for breaches of the Data Protection Act which arise due to the supplier acting in accordance with the customer’s instructions.


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.


SaaS, ASP Agreements – FAQs – Confidential Information

What confidentiality provisions need to be included in a SaaS agreement?

Define Confidential Information

Parties will obtain and have access to the business critical information of each other as a result of entering into a SaaS Agreement. For example, they may have access to customer lists, banking information, IPR, source code and object code or business secrets and processes. Confidential information should be defined in the SaaS agreement to make clear what is, and what is not, confidential. Do not simply refer to documents which are “marked as confidential” or “which should be treated as confidential”. Not all confidential information exists in a physical format, particularly in a SaaS scenario – so do not restrict your definition to just documents.

Restrictions on Disclosure

Confidential information should not be passed on to third parties or used by either party for any purpose other than performing their duties under the SaaS agreement. However, under certain circumstance parties may be legally required to disclose confidential information to a third party and such disclosure must be permitted. Additionally, employees and agents of the parties (accountants, sub-contractors) may need access to the confidential information for the purposes of the SaaS agreement. Such disclosure should be permitted, but must be restricted to named or defined groups of sub-contractors i.e. the supplier’s hosting provider or the customer’s named IT outsourcing providers. Disclosure to competitors of either party should be specifically prohibited. If any third parties are to have access to a party’s confidential information they must be bound by the same confidentiality duties as the party disclosing the information to them.

Return or Destruction of Data

Once the SaaS agreement is terminated, or expires, all confidential information of each party should be returned or destroyed. Confirmation of destruction of data should be required in writing. This is particularly important in relation to any personal data, as under the Data Protection Act 1998 no personal data should be kept longer than necessary. The length for which such personal data may be stored will depend upon the type of data and the purposes for which it was collected and stored.

Freedom of Information Request – FOI

If the customer is a public authority or another body subject to FOIs, both the supplier and the customer will need to comply with any requests for releases of information within strict time limits. Provisions should be added to the SaaS agreement to give the supplier control over what is, and what is not, released to prevent third parties having access to its confidential information pursuant to such requests.

Subject Access Request – SAR

Similar provisions are contained in the Data Protection Act 1998 which allow data subjects to request a copy of the personal data held on them which the supplier is processing on behalf of the customer. The request is made to the customer, who will need to ensure that there are provisions in the SaaS agreement obliging the supplier to release appropriate data.

Audit Rights

Sometimes customer’s will have a regulatory duty (i.e. under the FSA) to check the supplier’s security structures and data storage systems. Any third parties used by the customer during the audit should be bound by the confidentiality provisions of the SaaS agreement before being permitted access to any confidential information.  This can be easily achieved by having the third party sign a non-disclosure agreement.


SaaS, ASP Agreements – FAQs – Disaster Recovery

Do I need disaster recovery provisions in a SaaS agreement?

Disaster Recovery

Disaster recovery sets out the processes and procedures to be followed in the event of SaaS software, or customer data, no longer being accessible due to a problem with the technology infrastructure at the supplier’s data centre.

For example if there is a power cut, flood or fire at the data centre, the server on which the software is running will no longer function and the customer will no longer have full access to the software and its data. If the customer is using the software for a live website, the website will cease to function correctly or possibly at all.

Supplier Obligations

The disaster recovery provisions of a SaaS agreements should be set out in the SLA and should as a minimum, include the following supplier obligations in the event of a disaster:

  • customers must be notified of the disaster
  • any third parties used for disaster recovery should be identified
  • the estimated time for restoring the servers and access to the software and services should be specified
  • details should be given about the suppliers testing procedures i.e. how often its disaster recovery processes are tested


The extent and speed of the disaster recovery offered by the supplier will depend upon the fee charged for this service. Suppliers often include the costs of basic disaster recovery in their licence fees. In addition, or as an alternative they may offer higher levels of disaster recovery for additional fees. The faster and more individual the disaster recovery process is, the higher the fees.

If the supplier does not provide any disaster recovery services, or the customer is not satisfied with disaster recovery offered, it should consider setting up its own disaster recovery procedure with a third party, particularly if a disaster would be business critical. i.e. for a customer providing online banking services.

Avoiding Disasters

The most common disaster recovery risks are power failure, physical damage to the data centre or data and insolvency.

Power Failure

To minimise the risk of a power failure causing the servers to fail, ensure that the data centre has a continuous power supply (UPS) and power regulators to prevent fluctuations or interruptions in the power supply.


If the SaaS agreement includes backup of customer data, the regularity, media used for backups and storage should be set out in the SLA.  Backups should not be stored at the same physical location as the servers on which the data is being processed.


The media on which customer data is backed up should be encrypted. Particularly, if backups are to be physically sent to the customer, or moved to another data centre in the event of a disaster.

Access to Data

In the event that the data centre or a third party making backups of customer data becomes insolvent, the customer usually has no rights to access its data and backups. Provisions should be included in the SLA to give the customer the right to access its data and backups in such circumstances.