Category Archives: DocNinja

The Building Blocks of a Contract

Building Blocks of a Contract

In this article, we have a look at the main building blocks of a contract

Start building

Introduction

Contracts can be daunting. In fact, a report by World Commerce and Contracting association reveals that almost 90% of businesspeople find contracts hard or impossible to understand.

So, before diving into the world of contracts, it’s important to get one thing straight –

When drafting a contract, your aim must be to create clarity. If your aim is to screw over the other party, the DocNinja guides are not for you. 

In an article published in Harvard Business Review written by Shawn Burton, the general counsel for GE Aviation’s Business & General Aviation, Shawn writes –

However, I believe it is indeed possible—as a three-plus-year effort to promote plain-language contracts at GE Aviation’s digital-services business has demonstrated. Since this initiative began, in 2014, that unit has signed more than 100 such contracts. Those agreements took a whopping 60% less time to negotiate than their previous legalese-laden versions did. Some customers have even signed plain-language contracts without a single change. Customer feedback has been universally positive, and there hasn’t been a single customer dispute over the wording of a plain-language contract.

Main blocks

Building Blocks of a Contract

Agreement specific

The Agreement specific blocks contain information specific to the transaction, for example, the parties, the background to the transaction, definitions and the scope of the Agreement.

The core legal provisions are those where the respective legal teams like flexing their muscles.

 

These provisions essentially address various risks relating to the transaction.

 

The core legal provision blocks include limitation of liability, indemnities, term and termination, warranties, intellectual property and confidentiality.

 

When looking at the WCC data on most negotiated terms, it is clear that these provisions require careful consideration -

 

WCC rankingBlocks
1Limitation of liabilities block
3Indemnities block
5Termination block
8Warranties block
10Intellectual property block
15Confidentiality and non-disclosure block

 

Boilerplate

It is often said that the devil is in the details - When you have been working with contracts for a while you will know this idiom rings true when building your boilerplate clause.

 

Boilerplate provisions are used to regulate various miscellaneous aspects of the transaction.

 

Often labelled as "just boilerplate" or "less important" clauses, these clauses still requires careful consideration and generally includes clauses dealing with insurance, adherence to policies, regulatory compliance, information access and management, applicable law and jurisdiction, force majeure, entire agreement and dispute resolution.

Schedules

Contract schedules generally contain information requiring additional input from non-legal business teams within the business.

 

For example, take a software development agreement; the first schedule may contain technical and functional specifications relating to the development, deliverables, milestones, dependencies etc. These schedules are likely the most important aspect of a contract when considering that the WCC data indicates that Scope and Goals / Specifications are considered the most important terms when negotiating a contract.

 

Schedules often forming part of an Agreement include schedules relating to the services / products, fees and costs, data, SLAs and change control. 

Agreement specific

Building Blocks of a Contract - Agreement specific

Parties

The block containing the Parties to the Agreement needs to detail the registered name of the contracting Parties, registration number, address, and jurisdiction within which the party is registered/incorporated in.

Background

The background block is also sometimes referred to as the recitals.

 

Background / recitals are not a legal requirement and do have a direct legal effect on the obligations of the Parties under the contract.


Despite the above, the background / recitals may become important when interpreting the the agreement.

 

Definitions

The purpose of the definition block is to provide certain assigned meanings to a specific word or phrase. 

 

Whenever the word or phrase is used in the Contract, the first letter of the word is capitalized.

 

Definitions therefore assist in creating clarity in contracts. That being said, sometimes the "over use" of definitions can cause more ambiguity than clarity.  As a rule of thumb, if the ordinary meaning of a word clearly conveys the meaning that you require, don't create a definition for that word. 

Scope

The scope block contains the nuts and bolds of the specific transactions. Without these provisions, the contract will not make sense.

 

Each contract will have a different scope. For example, the scope of a Software Development Agreement differs from the scope of Software License Agreement.

 

More information on the different scopes for different contracts -

  • Software Development Agreement
  • Software Licence Agreement
  • Services Agreement
  • Reseller and Distributor Agreements
  • Service Level Agreement / Schedule
  • Data Privacy and Security Agreement / Schedule
  • Cloud Services Agreement
  • API Agreement
  • Software Escrow Agreement
  • Purchasing Agreement
  • Non Disclosure Agreement
  • Subcontractor Agreement

Core legal provisions

Building Blocks of a Contract - Core legal provision

Limitations

Part of the legal team's responsibilities is to limit the risks of the business.

 

With contracts, this is done by limiting certain claims or excluding certain claims that may arise that relate to the contract.

 

The limitation block contains -

  • the types of losses and damages that a Party will not be able to claim from the other party; and
  • limitations places on certain types of claims.

 

Clauses relating to the limitation of liability are also some of the most negotiated clauses among legal teams and require careful consideration.

 

Learn how to build a limitation of liability clause.

Indemnities

Indemnities are used to ensure a party is not held responsible for something the other party causes.

 

As an example, if you licence software, you don't want to be sued for copyright infringement when using the software.

 

To address the concern about being sued for something that is not your problem, you can use an indemnity block, which provides that the other party must indemnify you against claims of a certain nature.

 

Learn how to build an indemnity clause.

Termination

When a Party does not honour the contract terms, you must have a way out of the contract.

 

On the other hand, you don't want a Party to walk away from a contract if they no longer want to be bound by the contract.

 

The termination block determines when a Party can terminate a contract.

 

Generally, if there is a material breach of the contract, the Party who is in default (in other words, the Party who committed the breach) will be provided with a number of days to fix the breach. If the breach is not fixed, the aggrieved Party's right to terminate becomes available.

 

Then, there are other situations where the right to terminate may become available. For example, the Party files for bankruptcy or fails to meet a certain service level.

 

It is also possible to terminate a contract where nothing has gone wrong. This type of termination is commonly referred to as termination for convenience.

 

Learn how to a build termination clause.

Warranties

When you buy a product or ask someone to do something for you, you want to be sure the product meets certain standards or that good and proper service is provided.

 

In contracts, warranties ensure the product meets the requirements or the service is provided as required.

 

Learn how to build a warranties clause.

Intellectual property

Intellectual property is not limited to the usual suspects like copyright, patents and designs.

 

Intellectual property considerations are at play with every product supplied or service rendered.

 

The intellectual property blok generally comprises provisions relating to who owns which intellectual property.

 

For some businesses, their intellectual property is the most valuable asset of the business, and for this reason, careful consideration must be given when drafting intellectual property provisions.

Confidentiality

For certain types of intellectual property (for example, trade secrets) to enjoy protection under the law, efforts must be made to protect it, for example, by concluding contracts with confidentiality provisions.

 

The confidentiality block contains various provisions addressing what information constitutes confidential information when it can and cannot such information be disclosed to any other parties, and what happens if someone breaches the confidentiality provisions.

 

Learn how to build a confidentiality clause.

Boilerplate

Building Blocks of a Contract - Boilerplate

Boilerplate blocks

Schedules

Building Blocks of a Contract - Schedules

Is the SLA a stand alone agreement?

SLA's will generally be incorporated as Schedule to a Main Agreement (for example, a SaaS Agreement) if the document is negotiated. 

_

It is, however, also possible that a SLA takes the form of a policy that is published on the Provider's website. In such a case, the Customer may likely agree to the SLA by way of clickwrap when subscribing to, for example, the SaaS.

FAQs

Which styles or fonts must I use?

Well, whatever floats your boat. However, keep in mind that more and more people view and sign contracts on mobile devices.

Articles, sections and subsections, what's the difference?

What’s the difference? Well, it depends on which jurisdiction you are based in. Clauses, articles, sections, and subsections refer to a specific place in an Agreement.

 

There are various numbering methodologies used in contracts. For example, some Agreements will use numerals, others will use letters, and some will use numerals, roman numerals, and letters. There is no right or wrong.

The Author

Martin Kotze

Martin Kotze is a commercial lawyer with over 10 years of experience. He specialises in transactional work within the Tech, Financial Services and Property industries. 

He is also one of the co-founders at DocNinja and regularly advises companies on how to contract better with their customers and vendors. 

Linkedin Envelope
Talk to Martin

This is a free 30min consultation to better understand your business and your needs.

Table of Contents

Building a Service Level Agreement (SLA)

Building a Service Level Agreement (SLA)

In this article, we have a look at some of the important aspects that must be kept in mind when drafting a Software / SaaS / API SLA.

Start building

Table of Contents

Most disputed terms WCC ranking: 

3

Most important terms WCC ranking: 

4

Most negotiated terms WCC ranking: 

14

Introduction

Time and time again, WCC data shows Service Levels rank within the top 5 most important and disputed terms.

However, when looking at where Service Levels rank when it comes to Most Negotiated Terms, Service Levels are not even within the top 10 of ranked terms.

The WCC Contracting Principles provide sound guidance when dealing with Service Levels and recommend:

  1. While suppliers intend to provide high quality services, SLA Failures can occur over time given the complex nature of technology services. SLA Failures should not be deemed to rise to the level of a breach of contract.
  2. SLAs are intended to underscore supplier’s efforts to maintain the service, proactively identify potential problems, and quickly resolve any SLA Failures.
  3. SLA targets and SLA Credits should be set at levels that drive high performance but do not create financial windfalls for customers or unreasonable financial exposure for suppliers.
  4. SLA performance targets should be measurable and verifiable and should reflect minimum acceptable levels of supplier performance, focusing on critical service elements that are essential to the value of the service being provided.

What is a Support SLA?

A Support SLA may substantially differ from Provider to Provider and may sometimes even contain aspects that relate to the correction of Errors and general assistance to Customer.

_

For purposes of this article, Support Service mainly relate to those services a Provider provides to the Customers to help them use the Product. 

_

A Support SLA is therefore a document that details what is required (in terms resources and turnaround times) from the Provider if a user requires assistance with the Product.

What is a Error Correction SLA?

When providing Software, SaaS or an API ("Product"), there is always the possibility that there may be a couple of problems ("Errors") that may only come to light once the Customer starts using the Product.

_

For the above reason, a Provider will provide the Product "as is" with a disclaimer that no warranties are made that the Product is error-free.

_

From a Customer's perspective, the above may be problematic. What if the Product plays a vital role in the Customer's business? In such a case, the Customer wants to be assured that if they come across any Errors, they will be sorted out (and sorted out quickly if they are severe) so the business can carry on with operations.

_

A Technical Support SLA is then used to provide certain timeframes within which any reported Errors must be acknowledged and fixed by the Provider.

What is an Uptime SLA?

Uptime SLAs usually relate to SaaS and APIs.  If the Provider is required to give an Uptime service level, it means that the Provider must ensure the SaaS / API is working for a certain percentage time over a certain measuring period. For example, if a 99% uptime service level is given for SaaS, the Provider must ensure that the SaaS is working 99% of the time during a measurement period.

What is System Response SLA?

These days, businesses are relying heavily on external APIs and Cloud Services. As technology advances and new systems get introduced, the speed which systems need to function becomes vital. These APIs and Cloud Services may be an important cog in their business process, and the optimal functioning thereof is vital.

_

For the above reasons, businesses generally seek to impose service levels relating to the speed of the APIs and Cloud Services. A System Response SLA is therefore used to provide the service levels at which the API / Cloud Service need to respond once a System Request (for example, an API call) is made.

Building blocks

Building blocks of a SLA (Software _ SaaS _ API) (1)

Process Block

When configuring the Process Block, the following will need to be considered -

  • How must the Requests for services under the SLA be submitted? Email, telephone, customer portal?
  • Who will be able to submit Requests for services under the SLA? Only the Customer's Technical Contacts?
  • What information must be provided when submitting a Request?

Service Levels Block

The Service Levels Block is the most important Block forming part of the SLA and contains the quantifiable performance standards.

 

Important aspects that must be configured as part of the Service Levels Block -

_

Support SLA:

  • Available Support Services (for example, assisting users with general non-technical questions)
  • Time timeframes within which these Support Services must be provided
  • The exclusions (i.e. the situations where the Provider will not be required to provide the Support Services - for example, if the user is using the Product in a manner inconsistent with the Product's Documentation).

_

Error Correction SLA:

  • Types of Errors (for example, Critical Errors, Urgent Errors and Service Impacting Errors)
  • Timeframes within which a Response must be provided if a Request is submitted to Remedy a specific type of Error
  • Timeframes within which a Remedy must be provided if a Request is submitted to Remedy a specific type of Error
  • The exclusions (i.e. situations where the Provider will not be required to provide the Error Correction Service - for example, if the Product is combined with a Third Party Product that the Provider has not approved)
  • The exclusions (i.e. the situations where the Provider will not be required to provide the Support Services - for example, if the user is using the Product in a manner inconsistent with the Product's Documentation)
  • The Customer obligations (for example, the Customer must provide the Provider with Remote access to the extent required to Remedy the Error.)

_

Uptime SLA:

  • The Downtime brackets (for example, bracket 1 - where Downtime is between 95% and 99.99%)
  • The Measuring Period (i.e. over which period will Downtime be measured?)
  • The exclusions (for example, Scheduled Maintenance, Downtime caused by the Customer etc.)

_

System Response Time SLA:

  • The System being measured (for example, a third party applications to which API calls are made)
  • How will the process be measured (i.e. the technical description of the process and related metrics)
  • The Target System Response Time
  • The Measuring Period (i.e. over which period the System Responses be measured?)

Fees Block

There will not necessary be any fees for SLAs.

 

However, there are situations where a Provider would attach a fee to a "upgraded" SLA especially where there are certain Support Services that take up resources.

 

In such a case, the Provider may provide a certain number of "free hours". Anything above the provided "free hours", will then be billed at the relevant rates.

 

Important aspects to be configured as part of the Fees Block include:

  • The Fee amount
  • The frequency of payment of the Fee (for example, monthly or yearly?)
  • Is the Fee payable in advance or in arrears?
  • Are there any escalations that will apply to the Fee?
  • Will any escalation on the Fee be capped if there is a renewal?

Monitoring & Reporting Block

Import aspects that need to be configured as part of the Monitoring Block include:

  • Who is responsible for monitoring the Service Levels?
  • How will reporting work?
  • Within how many days after each Measurement Period must the report be provided? 

Credits Block

Generally, the go-to remedy if the Service Levels are not complied with are Credits.

 

Important aspects to configure as part of the Credits Block include:

  • Is there a process that must be followed before Credits are issued?
  • Must Credits be requested within a provided timeframe?
  • How will the Credits be calculated?
  • Will Credits be the sole remedy?
  • Will there be any cap placed on the Credits?
  • Will Credits be forfeited on termination of the Main Agreement?
  • Which exclusions apply to the issuance of Credits? For example, Credits will not be issued if the Service Levels are not complied with in the situation where the service under the SLA was provided as a result of the Customer that was negligent.

Termination Rights Block

Hand-in-hand with the Credits Block is the Termination Rights Block.

 

From a Customer's perspective, if there is constant failure of the service levels, the Customer would want to be able to terminate the Main Agreement without penalty.

 

Aspects that need to be configured as part of the Terminations Right Block include:

  •  When will the termination right be available? For example, if the SLA is not complied with over 3 consecutive Measurement Periods.

Escalation Block

What if the Customer does not get any joy from the support desk? Will there be an escalation procedure where the Customer can escalate the Support Request to a more senior person?

 

From a Provider's perspective, access to more senior support personnel must only be available in extreme cases and cases where the Customer has opted for a better SLA. 

Out-of-scope Services Block

From a Provider's perspective, the scope of the services available under the SLA must be as narrow as possible.

 

The aspects to be configured as part of the Out-of-scope Service Block include:

  • Which services will be regarded as Out-of-scope Service? Services outside Support Hours? 
  • Will Services provided as the result of a Customer Cause also be regarded as Out-of-scope Service?

FAQs

Is the SLA a stand alone agreement?

SLA's will be generally be incorporated as Schedule to a Main Agreement (for example, a SaaS Agreement) if the document is negotiated. 

_

It is, however, also possible that a SLA takes the form of a policy that is published on the Provider's website. In such a case, the Customer may likely agree to the SLA by way of clickwrap when subscribing to, for example, the SaaS.

Will Software Maintenance Services also be addressed in the SLA?

Software Maintenance aspects related to Updates and New Releases is generally addressed in a separate Agreement.

The Author

Martin Kotze

Martin Kotze is a commercial lawyer with over 10 years of experience. He specialises in transactional work within the Tech, Financial Services and Property industries. 

He is also one of the co-founders at DocNinja and regularly advises companies on how to contract better with their customers and vendors. 

Linkedin Envelope
Talk to Martin

This is a free 30min consultation to better understand your business and your needs.

Table of Contents

The building blocks of an API Licence Agreement

The building blocks of a API Licence Agreement

In this article, we have a look at some of the important aspects that must be kept in mind when drafting an API Licence Agreement

Start building

What is an API Licence Agreement?

When you want different systems or applications to communicate and interact with each other you would generally use an Application Programming Interface (API). APIs typically provide a set of tools, documentation, protocols, and specifications.

 

For example, take Software as a Service Providers. The Provider may add additional functionality to their offering by incorporating software from a different vendor as part of their offering. To enable the SaaS Provider to use the software of the other vendor as part of their SaaS, an API will be required. The terms and conditions relating to the use of the API is then determined by the API Licence Agreement.

Building blocks

Building blocks of a API Licence Agreement

API Licence Block

Key Components

_

Licence grant

The licence grant is the most important provision of the Agreement. Careful consideration should therefore be given whether or not the licence granted is subject to the payment of the Fees and compliance with other terms and conditions. Consideration should also be given to whether or not the licence is:

  • also provided to affiliates;
  • provided on an exclusive basis; and
  • is territory bound.

_

Typical rights provided to the Licensee are:

  • use the API solely for the purposes of internally developing the Applications that will communicate and interoperate with the Licensor Offering; and
  • display certain Licensor Marks in compliance with usage guidelines that the Licensor may specify from time to time solely in connection with the use of the API and the Applications and not in connection with the advertising, promotion, distribution, or sale of any other products or services.

These rights, however, need to be configured specifically for the transaction at hand.

_

Restrictions

Next, consideration should be given to the restrictions imposed on the Licencee. The typical restriction you whould encounter are:

  • copy, modify, or create derivative works of the API, in whole or in part;
  • rent, lease, lend, sell, sublicense, assign, distribute, publish, transfer, or otherwise make available the API;
  • reverse engineer, disassemble, decompile, decode, adapt, or otherwise attempt toderive or gain access to any software component of the API, in whole or in part;
  • remove any proprietary notices from the API;
  • use the API in any manner or for any purpose that infringes, misappropriates, or otherwise violates any intellectual property right or other right of any person,or that violates any applicable law;
  • combine or integrate the API with any software, technology, services, or materials not authorsed by the Licensor;
  • design or permit the Applications to disable, override, or otherwise interfere with any of the Licensor-implemented communications to endusers, consent screens, user settings, alerts, warning, or the like;
  • use the API in any of the Applications to replicate or attempt to replace the user experience of the Licensor Offering; or
  • attempt to cloak or conceal the Licensee's identity or the identity of the Applications when requesting authorization to use the API.

These restrictions must be configured to suit the particular transaction at hand.

_

Marks

Often a Licensee of an API would want to use and include some of the Licensor's Marks, for example, to increase the credibility of their offering and marketing purposes. If this is the case, provisions must be added to regulate using the Licensor's Marks.

_

Other Components

Additional components that may be added include provisions relating to:

  • end-user responsibility
  • API keys
  • API standards

 

Configuration

Provider friendly

Customer friendly

Licence grant is subject to payment of Fees and compliance with the Agreement

Licence may only be revoked if Agreement is terminated

Non-exclusive

Exclusive

Various restrictions on use of the API

No restriction relating to the use of the API

Support and Maintenance Block

The Provider may provide support and training to the Customer's Users. If this is the case, the terms of the support and training must be detailed in this section.

 

If training services are included as part of the Software Licence Agreement, ensure that the commercials relating to these services are unambiguously stipulated within the Agreement.

Fees & Payment Blocks

The payment provisions will detail payment terms, overdue amounts, method of payment, setoff, taxes, payment disputes etc.

 

Read more on payment clauses.

Intellectual property

Generally, the Parties will retain their intellectual property rights and the Provider will own any new Intellectual Property Rights relating to the Software.

 

An aspect that will, however, need to be addressed in the Software Licence Agreement is feedback rights. In other words, if the Customer provides the Provider with feedback relating to the Software, will the Provider be able to use the feedback to improve the Software and make these improvements available to other Customers?

 

The default position is usually that the Provider may use all feedback freely without restriction or obligation.

 

Read more on building intellectual property clauses.

Confidentiality

Both Parties would generally want to protect such sensitive information, which, if disclosed to certain third parties, will be detrimental to their business. The confidentiality provisions provide which information must be regarded as confidential, obligations relating to handling confidential information, and what happens if there are unauthorised disclosures.

 

Read more on confidentiality clauses.

Limitation of liability

Unrecoverable losses and maximum liability are generally dealt with under the limitation of liability provisions. Unrecoverable losses may include, for example, consequential losses, and claims relating to breach of data protection provisions may be limited under the maximum liability amount to a fixed amount.

 

Read more on the limitation of liability clauses.

Reps & Warranties

The Customer and Provider will usually provide certain mutual warranties. These may include, for example, that they have the legal capacity to enter into the Agreement and that they have not offered unlawful or prohibited inducements to the other Party or any other person in connection with the Agreement.

Then there will also be warranties related to the Cloud Services that will be provided.

 

Typical warranties will include that no viruses will be introduced into the Cloud Services, the Cloud Services does not and will not infringe on any third party intellectual property rights, the Cloud Services will be updated as necessary to comply with applicable laws etc.

 

Breach of the warranties will also need to be addressed, and the disclaimers that relate to the warranties.

 

Read more on warranty clauses.

Indemnities

An indemnity often found in a Software Licence Agreement is an indemnity relating to Intellectual Property infringement claims that a third party may institute against the Customer.

 

The indemnity provisions need to identify what will be regarded as indemnified losses (what will be covered), what will trigger the indemnity and the claims procedure.

 

Read more on indemnity clauses.

Audit rights

Where the licence is limited to, for example, the number of users, the Provider would want to have the right to conduct audits on the Customer's use of the Software.

 

With the audit clause, aspects often addressed include notices of audits, the number of allowed audits, confidentiality and what happens if there is an adverse finding.

Term and termination

The Parties may conclude the Software Licence Agreement for a fixed term or it may be a perpetual licence. If it is a fixed-term period licence, there may also be auto-renewal of the Term, which must also be detailed within this section.

 

The termination provisions detail when a Party can terminate the Agreement before the Term ends and may also provide for termination assistance the Provider must provide if the Agreement is terminated.

 

Read more on term and termination clauses.

Disputes

How will the Parties deal with disputes? Through a Court process or alternative dispute resolution? Are there different processes for different disputes - For example, expert determination for disputes relating to technical aspects of the Cloud Services?

 

Read more on dispute resolution clauses.

Boilerplate provisions

The boilerplate clauses will include the provisions relating to public disclosure, third-party beneficiaries, how amendments will be dealt with, how notices under the Agreement must be provided, assignment etc.

 

Read more on boilerplate clauses.

FAQs

Will an API Agreement be in the form of a clickwrap agreement?

Cloud Services are usually provided under a subscription-based model where access to the Software is provided to the Customer through an online login. No copy of the Software is provided to the Customer, and there is no need for a licence.

 

Read more about Cloud Services Agreements. 

 

When it comes to a Software Licence, the Software is installed on the Customer's computers.

What is the difference between a Software Development Agreement and a Software Licence Agreement?

With a Software Licence Agreement, there may be small modifications as part of the support and maintenance services.

 

If new Software or extensive changes to existing Software is required, a Software Development Agreement will be a more appropriate agreement.

 

Read more about Software Development Agreements.

What is the difference between a End-User Licence Agreement (EULA) and a Software Licence Agreement?

A End User Licence Agreement (EULA) is for licensing a commercial or off-the-shelf (that is, without modification or customization) Software. The term "EULA" commonly refers to an agreement that is not negotiated or signed by the parties.

Must Acceptance Testing provisions be included in the Software Licence Agreement?

Generally, Software Licence Agreements do not include any Acceptance Testing provisions.

 

However, there are situations where a Customer may require changes to the Software. In such cases, it may be appropriate to include Acceptance Testing provisions.

Must Software Escrow provisions be included in the Software Licence Agreement?

There may be a situations where the Software is "mission critical" to the Customer. In such cases, it may be appropriate to provide for certain escrow arrangements.

The Author

Martin Kotze

Martin Kotze is a commercial lawyer with over 10 years of experience. He specialises in transactional work within the Tech, Financial Services and Property industries. 

He is also one of the co-founders at DocNinja and regularly advises companies on how to contract better with their customers and vendors. 

Linkedin Envelope
Talk to Martin

This is a free 30min consultation to better understand your business and your needs.

Table of Contents

The building blocks of a Software Licence Agreement

The building blocks of a Software Licence Agreement

In this article, we have a look at some of the important aspects that must be kept in mind when drafting a Software Licence Agreement

Start building

What is a Software Licence Agreement?

A Software Licence Agreement is, in essence, a copyright licence. The bundle of rights associated with this type of copyright generally includes the exclusive rights to:

  • use, copy and reproduce the Software;
  • distribute the Software;
  • modify, translate or create derivative works of any part of the Software; and
  • display, or perform in any media and through any technology the Software.

 

The Software Licence Agreement, therefore, provides the Customer with the right to do the above (subject to the restrictions as per the Software Licence Agreement).

Building blocks

Building blocks of a Software Licence Agreement

Scope of Software Licence

To learn more about the specific building blocks of a Software Licence grant clause follow this link. 

 

The Provider would want to have the narrowest grant of rights. The Customer, on the other hand, would typically want broad licence. As a result, the scope of the license is among the most commonly negotiated provisions.

 

Another aspect often the subject of negotiation is whether the Licence grant is subject to the payment of the license fees under the Agreement. Furthermore, the Provider may also want to make the licence grant subject to the Customer's compliance with all terms and conditions as per the Agreement.  

Support and training

The Provider may provide support and training to the Customer's Users. If this is the case, the terms of the support and training must be detailed in this section.

 

If training services are included as part of the Software Licence Agreement, ensure that the commercials relating to these services are unambiguously stipulated within the Agreement.

Intellectual property

Generally, the Parties will retain their intellectual property rights and the Provider will own any new Intellectual Property Rights relating to the Software.

 

An aspect that will, however, need to be addressed in the Software Licence Agreement is feedback rights. In other words, if the Customer provides the Provider with feedback relating to the Software, will the Provider be able to use the feedback to improve the Software and make these improvements available to other Customers?

 

The default position is usually that the Provider may use all feedback freely without restriction or obligation.

 

Read more on building intellectual property clauses.

Payment

The payment provisions will detail payment terms, overdue amounts, method of payment, setoff, taxes, payment disputes etc.

 

Read more on payment clauses.

Confidentiality

Both Parties would generally want to protect such sensitive information, which, if disclosed to certain third parties, will be detrimental to their business. The confidentiality provisions provide which information must be regarded as confidential, obligations relating to handling confidential information, and what happens if there are unauthorised disclosures.

 

Read more on confidentiality clauses.

Limitation of liability

Unrecoverable losses and maximum liability are generally dealt with under the limitation of liability provisions. Unrecoverable losses may include, for example, consequential losses, and claims relating to breach of data protection provisions may be limited under the maximum liability amount to a fixed amount.

 

Read more on the limitation of liability clauses.

Reps & Warranties

The Customer and Provider will usually provide certain mutual warranties. These may include, for example, that they have the legal capacity to enter into the Agreement and that they have not offered unlawful or prohibited inducements to the other Party or any other person in connection with the Agreement.

Then there will also be warranties related to the Cloud Services that will be provided.

 

Typical warranties will include that no viruses will be introduced into the Cloud Services, the Cloud Services does not and will not infringe on any third party intellectual property rights, the Cloud Services will be updated as necessary to comply with applicable laws etc.

 

Breach of the warranties will also need to be addressed, and the disclaimers that relate to the warranties.

 

Read more on warranty clauses.

Indemnities

An indemnity often found in a Software Licence Agreement is an indemnity relating to Intellectual Property infringement claims that a third party may institute against the Customer.

 

The indemnity provisions need to identify what will be regarded as indemnified losses (what will be covered), what will trigger the indemnity and the claims procedure.

 

Read more on indemnity clauses.

Audit rights

Where the licence is limited to, for example, the number of users, the Provider would want to have the right to conduct audits on the Customer's use of the Software.

 

With the audit clause, aspects often addressed include notices of audits, the number of allowed audits, confidentiality and what happens if there is an adverse finding.

Term and termination

The Parties may conclude the Software Licence Agreement for a fixed term or it may be a perpetual licence. If it is a fixed-term period licence, there may also be auto-renewal of the Term, which must also be detailed within this section.

 

The termination provisions detail when a Party can terminate the Agreement before the Term ends and may also provide for termination assistance the Provider must provide if the Agreement is terminated.

 

Read more on term and termination clauses.

Disputes

How will the Parties deal with disputes? Through a Court process or alternative dispute resolution? Are there different processes for different disputes - For example, expert determination for disputes relating to technical aspects of the Cloud Services?

 

Read more on dispute resolution clauses.

Boilerplate provisions

The boilerplate clauses will include the provisions relating to public disclosure, third-party beneficiaries, how amendments will be dealt with, how notices under the Agreement must be provided, assignment etc.

 

Read more on boilerplate clauses.

FAQs

What is the difference between a Cloud Services Agreement and a Software Licence Agreement?

Cloud Services are usually provided under a subscription-based model where access to the Software is provided to the Customer through an online login. No copy of the Software is provided to the Customer, and there is no need for a licence.

 

Read more about Cloud Services Agreements. 

 

When it comes to a Software Licence, the Software is installed on the Customer's computers.

What is the difference between a Software Development Agreement and a Software Licence Agreement?

With a Software Licence Agreement, there may be small modifications as part of the support and maintenance services.

 

If new Software or extensive changes to existing Software is required, a Software Development Agreement will be a more appropriate agreement.

 

Read more about Software Development Agreements.

What is the difference between a End-User Licence Agreement (EULA) and a Software Licence Agreement?

A End User Licence Agreement (EULA) is for licensing a commercial or off-the-shelf (that is, without modification or customization) Software. The term "EULA" commonly refers to an agreement that is not negotiated or signed by the parties.

Must Acceptance Testing provisions be included in the Software Licence Agreement?

Generally, Software Licence Agreements do not include any Acceptance Testing provisions.

 

However, there are situations where a Customer may require changes to the Software. In such cases, it may be appropriate to include Acceptance Testing provisions.

Must Software Escrow provisions be included in the Software Licence Agreement?

There may be a situations where the Software is "mission critical" to the Customer. In such cases, it may be appropriate to provide for certain escrow arrangements.

The Author

Martin Kotze

Martin Kotze is a commercial lawyer with over 10 years of experience. He specialises in transactional work within the Tech, Financial Services and Property industries. 

He is also one of the co-founders at DocNinja and regularly advises companies on how to contract better with their customers and vendors. 

Linkedin Envelope
Talk to Martin

This is a free 30min consultation to better understand your business and your needs.

Table of Contents

The building blocks of a Software Development Agreement

Software Development Agreements

In this article, we have a look at some of the important aspects that must be kept in mind when drafting a Software Development Agreement

Start building

Introduction

What is a Software Development Agreement?

A Software Development Agreement is a legal contract that provides the terms and conditions between a customer and a software developer when creating a new software product.

 

It is important to have this agreement in place to ensure that both parties clearly understand their roles, responsibilities, and the services to be provided.

 

The agreement typically includes details on the project's scope, timelines, payment terms, intellectual property ownership, warranties, confidentiality etc.

 

Having a Software Development Agreement can help prevent misunderstandings and disputes that may arise during the project. It provides a clear path forward for both Parties and helps ensure that the project is completed successfully and to the satisfaction of both the customer and the developer.

What are the different types of Software Development Agreements?

There are several types of software development agreements, each with its own set of terms and conditions. However, here are some common types of software development agreements:

 

  1. Time and Materials Agreement: This type of agreement is based on an hourly or daily rate, and the client is charged for the time spent on the project, along with any materials or expenses incurred.
  2. Fixed-Price Agreement: In a fixed-price agreement, the development firm agrees to complete the project for a specific price, regardless of the time or resources required.

 

For larger projects, it is common to have both Statements of Work, which are mainly time and materials-based, and Statements of Work, which are fixed-priced.

 

Ultimately, the specific type of software development agreement best suited for a particular project will depend on the nature of the project, the client's goals, and the development firm's capabilities.

What are the main Software Development methodologies?

Various methodologies are adopted for software development, each with its own principles, practices, and approaches. Here are some common methodologies:

 

  1. Waterfall Model: This is a linear sequential approach to software development, where each phase of the development process is completed before moving on to the next one. It is a highly structured methodology for projects with well-defined requirements and a fixed budget.
  2. Agile Methodology: Agile is an iterative software development approach emphasising collaboration, flexibility, and constant feedback. It involves breaking down the project into smaller tasks and delivering them in short sprints, with each sprint building on the previous one.

 

The specific methodology best suited for a particular project will depend on the nature of the project, the customer's goals, and the development team's capabilities.

Agreement blocks

Building blocks of a Master Software Development Agreement (1)

Transaction blocks

Engagement

The typical Software Development engagement will be a work-for-hire engagement in which the Developer provides certain software development services to the Customer.

 

The scope of engagement can be A-Z. For example, the Developer must design, develop, create, test, deliver, install, configure, integrate, customise, and otherwise provide and make fully operational Software.

 

Alternatively, the Developer must integrate Software XYZ with Software DEF.

 

The "engagement block" creates the primary engagement. The details of what needs to be done are then added to the Schedule - Services.

Service standards

When you, as a Customer, engage a Developer, you want to be certain the Developer will do a good job.

 

You also want to be sure the Developer will work efficiently, especially when you engage the Developer on a time and materials basis.

 

Therefore, the "services standards" block is core to the engagement.

 

A way to further "strengthen" the Customer's rights is to provide that the Developer will perform the services following Good Industry Practices.

 

What constitutes "Good Industry Practice" is often a defined term. Here's an example -

Good Industry Practice means the exercise of that degree of skill, diligence, and operating practice which would ordinarily be expected from a skilled and experienced person engaged in the same or a similar business.

 

Hand-in-hand with the "services standards" block is the Schedule - Personnel. This schedule will often detail the minimum qualifications of the personnel engaged with the project. 

Documentation

The purpose of the "Documentation block" is to create an obligation on the Developer to ensure good and proper Documentation is delivered with the Software. 

 

Software Documentation plays an important role in Software Development and details how the Software works (or, more importantly, how the Software is supposed to work).

 

Once a project is complete, the Developer must deliver, together with the Software, Documentation, which provides a comprehensive and detailed record of a Software's design, functionality, and operation.

 

The Documentation must align with the agreed Specifications, and the Developer is generally required to warrant that the delivered Software performs per the Documentation.

 

In addition, this Documentation serves as a reference for software developers, testers, and end-users throughout the software development lifecycle.

 

Here are some specific purposes of Software Documentation:

  1. Facilitate software development: Documentation helps software developers to understand the codebase and make changes, bug fixes or add new features effectively.
  2. Enable maintenance and support: Documentation provides clear instructions on how to maintain and support the Software after deployment.
  3. Promote collaboration: Documentation enables efficient communication and collaboration among team members, stakeholders, and end-users, facilitating a smoother development process.
  4. Enhance the Software's usability: Documentation provides guidance and instructions on how to use the Software, which can improve its usability and make it more accessible to end-users.
  5. Ensure compliance: Documentation is often required to meet regulatory and compliance standards in industries such as healthcare, finance, and government.

 

Overall, software documentation is essential for ensuring that Software is well-designed, well-maintained, and meets the needs of all stakeholders involved in its development, deployment, and use.

 

Third-party materials

If you have been involved with Software Development before, You will know there are various resources, libraries, and APIs available than can significantly speed up the Software Development process.

 

However, these resources, libraries, and APIs may be a two-edged sword. Firstly, there may be cost implications for the Customer. Secondly, and more importantly, there may be licence restrictions when using these Third-Party Materials (for example, you cannot use an API for commercial purposes).

 

Imagine spending months developing Software on top of an API to realise that the licence terms of the API do not allow you to sell your Software in the open market. That's money down the drain and why Third Party Materials must be addressed within your Software Development Agreement.

 

It is important to define Third-Party Materials clearly. Here is an example - 

 

Third-Party Materials means any materials and information, including documents, data, know-how, ideas, methodologies, specifications, Software, content, and technology, in any form or media in which any person other than the Customer or Developer owns any Intellectual Property Right, but specifically excluding Open Source Components.

 

If Third-Party Materials are allowed, ensure that the Developer will be required to secure, at its sole cost and expense, all necessary rights for You, the Customer, to use perpetually and throughout the world Approved Third-Party Materials.

Open-source components

The purpose of the "open-source components" block is to regulate various aspects surrounding using open-source components as part of the Software. 

 

There is a general misconception that open-source is "free" and "we can use it as we like". Although this is true to some extent, adopting this attitude can have disastrous consequences down the line.

 

From a Customer's perspective, it is wise to provide that only approved open-source components may be used as part of the Software.

 

While open-source components can offer many advantages, there are also valid reasons not to use them in a software development project. Some of these reasons include:

 

  1. License compatibility issues: Different open-source projects have different licenses, which may not be compatible with each other or with the intended licensing of your Software. Incompatibilities can lead to legal and intellectual property issues.
  2. Lack of support and documentation: Open source projects vary greatly in terms of the level of support and documentation they provide. Some projects may have limited or outdated documentation, making it harder to understand and implement the components.
  3. Security concerns: Open source components can have vulnerabilities that expose your Software to potential security risks. Ensuring the security of open-source components may require additional time and resources.
  4. Limited control and customization: While open-source projects can be modified, you may not have complete control over the development or direction of the project. This can make it difficult to customize or adapt the component to fit your specific needs.
  5. Maintenance burden: Open source components may not be maintained or updated regularly. If a project becomes abandoned or moves in a direction that no longer suits your needs, you may need to take on the responsibility of maintaining or forking the project yourself.
  6. Quality and stability: The quality and stability of open-source components can vary greatly. Some projects may have high-quality code and robust development processes, while others might be less mature or have a smaller community, leading to less reliable code and potential issues.
  7. Integration challenges: Integrating open-source components with your existing Software or other third-party components can be challenging, as compatibility issues may arise, requiring additional development work.
  8. Potential performance issues: Some open source components may not be optimized for performance, potentially leading to slower response times or higher resource usage than desired.
  9. Legal liability: If an open source component infringes on a third party's intellectual property, you might be held legally liable for damages, depending on the specific circumstances and the terms of the open source license.
  10. Reputation and branding: Using open-source components can sometimes lead to a perception that your Software is less polished or professional, especially if the open-source project has a negative reputation or if it is not well-maintained.

 

When deciding whether to use open-source components in your software development project, it's essential to carefully weigh these potential downsides against the benefits and consider your project's specific needs and goals.

Sub-contracting

A "subcontracting" block details the conditions and limitations of subcontracting work to a third party. 

 

The key components of a subcontracting clause typically include:

 

  1. Permission: The subcontracting clause should state whether or not subcontracting is allowed and under what conditions it is permissible.
  2. Notification: The subcontracting clause should specify whether the prime contractor is required to notify the client or the other party to the contract of any subcontracting arrangements and if so, when and how.
  3. Approval: The subcontracting clause should specify whether the client or the other party to the contract needs to approve any subcontracting arrangements and, if so, the criteria for approval.
  4. Subcontractor qualifications: The subcontracting clause should specify the qualifications required for a subcontractor to perform the work, including the skills, experience, certifications, and licenses needed.
  5. Liability: The subcontracting clause should specify the liability of the prime contractor and the subcontractor in case of any breaches, damages, or delays.
  6. Confidentiality: The subcontracting clause should specify the confidentiality requirements for the subcontractor, including protecting any proprietary or sensitive information.

 

Financial stability

On a big software development project, especially when dealing with a newly formed dev house, you want to avoid being caught with your pants down if the dev house cannot pay their devs.

 

On the flip side, if the Customer's financial position deteriorates, the Developer would want to be able to "walk away" from the contract as soon as possible to ensure resources are not used where the Developer will likely not be paid.

 

A financial stability block, therefore, assists with "a way out" if a Party's financial position goes south.

 

The key components of a financial stability block include:

 

  1. Reviews: A Party's right to review the other Party's books to asses their financial position.
  2. Termination right: If the financial position deteriorates, the Party's right to terminate the Agreement.
  3. Confidentiality: Provisions that stipulate that any information provided as part of the financial stability assessment should be subject to confidentiality provisions.

Audits

An audit rights block gives the Customer the right to audit the Developer's compliance with the Agreement.

 

Think about a situation where you, the Customer, are paying the Customer on a time and materials basis. You want to ensure the Developer only charges you for the actual work done and that full, accurate and detailed timesheets are available for inspection.

 

 The key components of an audit rights clause typically include the following:

 

  1. Scope of the Audit: This section defines the types of records the auditing party is entitled to examine.
  2. Notice and Timing: This section stipulates the procedures for initiating an audit and the timeframes for completing it.
  3. Confidentiality: This section addresses the information disclosed during the audit. It may require the auditor to keep the information confidential and limit the use of the information to the purpose of the audit.
  4. Cost and Expenses: This section addresses the costs and expenses associated with the audit. It may specify who will bear the costs and whether the auditing party will be responsible for any costs incurred by the other Party.

Benchmarking

An outsourced development team can become quite entrenched in a business. A situation where outsourced development teams become core to the operations of a business may have positives but may also hold some risks.

 

On the one hand, an outsourced development team can develop a unique understanding of the business; however, the business may also become particularly reliant on the dev team.

 

From a financial perspective, the hourly rates can go through the roof, but the output may not necessarily align with the increased rates of the outsourced development team.

 

A benchmarking clause can be useful in the above situation.

 

In general, including a benchmarking clause in a software development agreement can help the Parties set clear expectations, identify areas for improvement, and ensure that the Software remains competitive and meets industry standards.

 

However, the specifics of the benchmarking clause should be carefully negotiated and drafted to ensure that it is fair and reasonable to both Parties and provide a clear framework for the benchmarking process.

 

Key components forming part of a benchmarking block include:

 

  1. Definition of benchmarking: This section defines the benchmarking process and outlines the specific metrics that will be used to evaluate performance. It may also include a reference to industry standards and best practices that will be used for comparison.
  2. Data collection and reporting: This section establishes the procedures for collecting and reporting data in the benchmarking process. It may specify the frequency of data collection, the methods for data collection, and the format for reporting the data.
  3. Confidentiality: This section addresses the information disclosed during the benchmarking process. It may require the parties to keep the information confidential and limit the use of the information to the purpose of benchmarking.
  4. Scope and limitations: This section outlines the scope and limitations of the benchmarking clause. It may clarify which business areas will be subject to benchmarking and which areas will be excluded.
  5. Consequences of benchmarking: This section may outline the consequences of benchmarking, such as the requirement to implement improvements or to pay penalties if performance falls below industry standards.

Insurance

An insurance block in a software development agreement provides the insurance requirements for the Parties. The key components of an insurance block in a software development agreement typically include the following:

 

  1. Types of insurance: This section specifies the types of insurance required for the software development project, such as general liability insurance, professional liability insurance, and cyber liability insurance.
  2. Coverage limits: This section specifies the minimum coverage limits the Parties must maintain for each type of insurance. It may also specify the minimum required duration of the insurance coverage.
  3. Additional insured: This section specifies whether one party requires the other party to name it as an additional insured on their insurance policies. It may also specify any specific requirements for the additional insured coverage.
  4. Proof of insurance: This section specifies the procedures for providing proof of insurance, such as certificates of insurance or endorsements, and the timeframe for providing such proof.
  5. Claims handling: This section specifies the procedures for reporting and handling insurance claims, including each party's obligations to cooperate with the insurance company in the event of a claim.
  6. Waivers and releases: This section specifies any waivers or releases of liability that the Parties agree to as part of the insurance clause. For example, the Parties may agree to waive their rights to sue each other for any claims covered by insurance.

 

An insurance block is an important component of a Software Development Agreement as it can help protect both Parties in unforeseen circumstances. 

Core legal provisions blocks

Boilerplate blocks

FAQs

Master Software Development Agreement vs. "standard" Software Development Agreement

A Master Software Development Agreement is a framework agreement that goes hand-in-hand with Statements of Work (SoW).

 

The Master Software Development Agreement contains general terms and conditions applicable to the transactions. On the other hand, the SoW contains more specific information relating to the Software that must be developed. For example, the technical and functional specifications, timeframes, fees etc.

 

A Master Software Development Agreement allows for a more agile process where various "sprints" are undertaken to complete a project. Each "sprint" with its respective milestones and dates are agreed and documented as separate SoWs.

 

With a "standard" Software Development Agreement, the specifications of the project is fixed at the signing of the Agreement or agreed during a "consultation phase" preceding the start of the project.  

What is the difference between Source Code and Object Code?

"Source Code" is the code that a developer writes to program an application/website. This code is "human readable" and this is the code that you want to protect.

 

"Object Code" is "machine-readable". In other words, it is numeric code made of binary numbers such as 0s and 1s and is understood by a machine. 

 

For a more detailed explanation on Source Code vs. Object Code, have a look at this article. 

The Author

Martin Kotze

Martin Kotze is a commercial lawyer with over 10 years of experience. He specialises in transactional work within the Tech, Financial Services and Property industries. 

He is also one of the co-founders at DocNinja and regularly advises companies on how to contract better with their customers and vendors. 

Linkedin Envelope
Talk to Martin

This is a free 30min consultation to better understand your business and your needs.

Table of Contents

Building data privacy and data security clauses

How to build a data protection clause

In this article, we have a look at some of the important aspects that must be kept in mind when drafting data privacy and data protection provisions.

Start building

Most disputed terms WCC ranking: 

Data privacy: 28

Data security: 26

Most important terms WCC ranking: 

Data privacy: 8

Data security: 7

Most negotiated terms WCC ranking: 

Data privacy: 17

Data security: 19

What is a Data Privacy clause?

Data Privacy clauses will generally deal with the way in which data (usually Personal Information) must be handled.

What is a Data Security clause?

Data Security clauses usually provide what the Provider must do to protect the Protected Data against unauthorised third-party access and malicious attacks.

What is a Data Protection clause then?

Data protection clauses are in a way a combination of data privacy and data protection clauses.

Building blocks of Data Privacy and Data Security clauses

building blocks of data privacy and data security provisions

What is Protected Data?

Defining Protected Data is important to ensuring balanced and fair data privacy and security provisions.

Generally, Protected Data will be personal information as defined by applicable data privacy and security laws. The aforementioned, however, does not mean that the definition of Protected Data should be limited to Personal Information. The Customer may want a much broader definition of Protected Data that includes all the data that the Customer provides to the Provider. For example:

Protected Data means all information processed or stored through the System by Customer or on Customer’s behalf, and includes, without limitation, information provided by Customer’s customers, employees, and other users and by other third parties, other information generated through use of the System by or on Customer’s behalf, and copies of all such information rendered onto paper or other non-electronic media.

If you are the Provider, you want to use a narrow definition and may even consider carving out certain types of data from the definition. For example:

Excluded Data means personal tax numbers, financial account data, and credit card and other payment card numbers;

Protected Data means personal information as contemplated under applicable data privacy and security laws, but specifically excludes Excluded Data;

If you are the Provider, you don’t want a situation where there is a Data Incident and, for example, credit card data is exposed and there was no need for you in the first place to process any such credit card data. 

If you follow the approach where certain data is excluded, make sure that a warranty is included in the Data Protection Schedule where the Customer warrants that they will not provide any Excluded Data to the Provider.

It may be that you want Protected Data to be regarded as Confidential Information. If you decide to go this route make sure that you address the situation where there is a conflict between the Data Protection Schedule and the confidentiality provisions.

Handling of Protected Data - Authorised Persons

A narrow definition of Authorised Persons may favour the Customer. On the other hand, the Provider would want to make sure the definition of Authorised Persons is wide enough to include sub-contractors so that there is no need to obtain written approvals for each sub-contractor.

Authorised Persons should, however, be limited to people who need to handle the data to fulfil the Provider’s obligations under the Agreement.

Handling of Protected Data - Aggregated and anonymised data

A Provider may want to use the Protected Data for its own purposes. Generally, if the Provider wants to use the Protected Data, it needs to be anonymised first. If you are the Customer, you would want to make sure that if the Protected Data is anonymised, such a process must and cannot be reversed.

Handling of Protected Data - Personal Information requests

Privacy legislation generally provides certain rights to data subjects when it comes to their Personal Information. For example, the “right to know,” delete, or the “right to be forgotten”. As a Customer, you may want to impose certain obligations on the Provider if a personal information request is directed at the Provider.

Access, location and deletion of Protected Data

If you are the Customer, you want to control the access, location and deletion of Protected Data.

Data privacy laws may determine certain requirements if Protected Data is moved cross-border. As a Customer, you do not want to be exposed to a situation where Protected Data is moved cross-border to a jurisdiction with less stringent data privacy and data security laws than those applicable within the current jurisdiction.

As a Customer, you can also consider specifying certain data centres within the current jurisdiction where data can be stored.

As Provider, the commercials of the transaction must be kept in mind when considering access, location and deletion of Protected Data. It may be useful to reserve a right to charge fees and costs for time spent assisting the Customer with providing access, deleting and moving Protected Data.  

Data security audits & certifications

Generally, the two standards that will be considered will be ISO 27001 and SOC 2.

A difference between ISO 27001 and SOC 2 is that SOC 2 is not a certification. If you pass the ISO 27001 requirements, then your business is ISO 27001 certified. However, in the case of SOC 2, the auditor issues a formal report, confirming whether or not you met the relevant criteria. 

ISO 27001 is a common European procurement requirement and is internationally recognized as the highest standard in information security. In the US market, many Customers will want the reassurance that the Provider is SOC 2 compliant.

Minimum safeguards

If you acting for the Customer, especially in the situation where the Provider is not required to produce an ISO 27001 certificate or an SOC2 report, you want to place certain contractual obligations on the Provider regarding data security.

Or, if there is a requirement that the Provider produces a ISO 27001 certificate or an SOC2 report, there are situations where the Customer may require further measures to be put in place that goes beyond what is required under ISO 27001/ SOC2.

Data incidents & deletion of data

Data Incidents

When considering provisions relating to Data Incidents, the definition of a Data Incident is a good point of departure.

Generally, Data Incidents include the unauthorised disclosure of, access to, or use of Protected Data. 

As Provider, you may want to consider narrowing the above broad and general definition to more specific scenarios where, for example, an unauthorised third-party obtains and threatens the distributions of Protected Data.

The obligations placed on the Provider relating to Data Incidents require detailed consideration. Examples of these obligations include:

  • Notifying the Customer
  • Cooperation with law enforcement
  • Assistance with notifying third parties whose data may have been exposed

 

Most of these obligations are generally aimed at damage control. However, a Customer may want to add obligations that require compensation, in some form, as a result of the Data Incident. 

As a Customer, you want to be in control of whatever happens after the occurrence of a Data Incident. As Provider, you do not want to be subjected to obligations that will be detrimental to your business financially.

 

Deletion of data

As a Customer, you want to have certain rights regarding the deletion of Protected Data.

Making sure that erasure leaves no data readable, decipherable, or recoverable may be expensive. Therefore, as Provider, you may want to consider adding provisions that the data deletion will be done using commercially feasible methods.

Data protection indemnity

The remedies and relief for breach of the Data Protection Schedule or the Data Protection Laws are usually addressed by an indemnity (see How to build an indemnity clause).

Breach & equitable relief

A Customer may also want to include a provision stipulating that a breach of the Data Protection Schedule will be deemed material with the hope that this will help them terminate the Agreement for cause if there is a breach.

Example schedule

Customer friendly

SCHEDULE – DATA PROTECTION

 

1.1.       Handling of Protected Data: 

(a)          Standard of care:  The Provider must keep and maintain all Protected Data in strict confidence, using such degree of care as is appropriate to avoid unauthorised access, use or disclosure.

(b)          Usage of Protected Data:  The Provider must use and disclose Protected Data solely and exclusively for the purposes for which the Protected Data, or access to it, is provided pursuant to the terms and conditions of the Agreement, and not use, sell, rent, transfer, distribute, or otherwise disclose or make available Protected Data for the Customer’s own purposes or for the benefit of anyone other than the Customer, in each case, without Customer’s prior written consent.

(c)          Disclosure:  The Provider must not, directly or indirectly, disclose Protected Data to any person other than Authorised Persons, without express written consent from the Customer, unless and to the extent required by government authorities or as otherwise, to the extent expressly required, by applicable law, in which case, the Provider must use reasonable efforts to notify the Customer before such disclosure or as soon thereafter as reasonably possible.

(d)          Responsibility for Authorised Persons:  The Provider is responsible for and remain liable to the Customer for the actions and omissions of such Authorised Persons concerning the treatment of such Protected Data as if they were the Provider’s own actions and omissions.

(e)          Written undertaking required from Authorised Persons:  The Provider must require the Authorised Persons that has access to Protected Data to execute a written undertaking to comply with this Schedule.

1.2.       Confidential information:  All Protected Data provided by the Customer to the Provider or to which the Provider may be exposed or acquire in terms of this Agreement, constitutes Confidential Information.

1.3.       Conflicts:  If there is a conflict or inconsistency between this Schedule and the confidentiality within the main body of the Agreement, the terms in this Schedule governs and controls.

1.4.       Cross border transfer:  The Provider must not transfer Protected Data (or allow Authorised Persons to transfer Protected Data) outside Republic of South Africa unless it receives the Customer’s prior written consent.

1.5.       Additional charges:  The Provider may charge additional fees at their standard rates for activities required by the Customer to assist them to comply with Data Protection Laws.

1.6.       Access rights:  The Customer may access and copy any Protected Data in the Provider’s possession or control at any time and the Provider:

(a)          must provide reasonable assistance to the Customer to access and copy the Protected Data.

(b)          may charge their reasonable then-standard fees for any assistance provided under 1.6.

1.7.       Protected data requests:  If the Provider receives a consumer “right to know,” deletion, “right to be forgotten,” or similar request related to Protected Data within Protected Data (the “Consumer Requests”), the Provider must not reply without the Customers written authorisation and shall, at the Customer’s expense, comply with the Customer’s reasonable written instructions for Consumer Requests (if any), subject to Data Protection Laws.

1.8.       Audits and certifications: 

(a)          The Provider must maintain annually updated reports and certifications (as may be applicable) of compliance with the following:

(i)           ISO 27001;

(ii)          SOC 2 Type II; and

(iii)         PCI Level 2.

(b)          The Provider must:

(i)           provide the Customer a copy of the most current certifications and reports (as may be applicable) within 30 days of request and thereafter annually within 30 days of completion of thereof; and

(ii)          if there are any deficiencies identified or changes suggested relating to the provisions of the Services under the Agreement, the Provider must exercise reasonable efforts to promptly address such deficiencies and changes.

(c)          Notwithstanding anything in this Schedule, the Provider is not required to permit any audit that may compromise the security of the Provider’ other customers’ data.

(d)          Any report provided under this Schedule must be regarded as confidential information.

1.9.       Inspections: 

(a)          If requested by the Customer, the Provider must permit inspection and security review by the Customer of systems processing Protected Data and on the Provider’s policies and procedures relating to data security.

(b)          The Customer may request an inspection contemplated in 1.9, every half-yearly starting from the date that this Agreement becomes effective.

(c)          Notwithstanding anything in this Schedule, the Provider is not required to permit any inspection that may compromise the security of the Provider’ other customers’ data.

1.10.    Data Incidents:  If there is a Data Incident, or if Provider suspects a Data Incident, the Provider must:

(a)          promptly, and in any case within 24 hours, give notification by telephone, in person, or by other real-time, in-person communication;

(b)          cooperate with law enforcement agencies, where applicable, to investigate and resolve the Data Incident;

(c)          provide reasonable assistance in notifying applicable third parties;

(d)          comply with applicable laws governing data breach notification and response;

(e)          if the Data Incident results from their breach of this Agreement or negligent or unauthorised act or omission of an Authorised Person, compensate the other Party for any reasonable expense related to notification of consumers;

(f)           give the other Party prompt access to such records related to a Data Incident as may reasonably be requested (such records will be regarded as confidential information and there will be no obligation to provide access to records that might compromise the security of the other customers); and

(g)          provide the name and contact information for an employee who shall serve as primary security contact and must be available to assist 24 hours per day,  7 days per week as a contact in resolving obligations associated with a Data Incident.

1.11.    Third-parties and Data Incidents: 

(a)          The Provider must not inform any third party of any Data Incident without first obtaining the Customer’s prior written consent, other than to inform a complainant that the matter has been forwarded to the Customer’s legal counsel. The Customer has the sole right to determine:

(i)           whether notice of the Data Incident is to be provided to any individuals, regulators, law enforcement agencies, consumer reporting agencies or others as required by law or regulation, or otherwise in the Customer’s discretion; and

(ii)          the contents of such notice, whether any type of remediation may be offered to affected persons, and the nature and extent of any such remediation.

(b)          The Provider must reasonably cooperate at its own expense with the Customer in any litigation or other formal action deemed reasonably necessary by the Customer to protect their rights relating to the use, disclosure, protection and maintenance of Protected Data.

(c)          If there is a Data Incident, the Provider must use their reasonable efforts to prevent a recurrence of any such Data Incident.

(d)          Nothing in this Schedule limits other rights or remedies of the Customer, if any, resulting from a Data Incident.

1.12.    Deletion of Protected Date:  Except as required by Data Protection Laws or authorised pursuant to a data deletion policy accepted in writing by each party, the Provider must not erase Protected Data or any copy thereof without the Customer’s prior written consent. The Provider must:

(a)          on request promptly erase all Protected Data from all systems under Provider’s control and direct and ensure erasure by any and all of its subcontractors that have access to Protected Data;

(b)          within 30 days of termination of this Agreement, erase all Protected Data in Provider’s possession or control, including without limitation in the possession or control of its subcontractors;

(c)          after erasure leave no data readable, decipherable, or recoverable on its computers or other media or those of its subcontractors, using the best erasure methods commercially feasible; and

(d)          promptly after any erasure of Protected Data or any part of it, certify such erasure.

1.13.    Minimum safeguards:  In addition to any other safeguards contemplated in this Schedule, the Provider must ensure at minimum that that:

(a)          their Personnel each have a unique user ID assigned to them, subject to strict confidentiality undertakings in terms of a password and confidentiality policy;

(b)          there are passwords required for any access to Data in line with its password policy;

(c)          its operating systems are secure and that the security settings in respect thereof are aligned with good industry practice;

(d)          its administrator accounts (and records of usage in relation thereto) are stored securely and can be accessed in the event of any service restoration or fault determination;

(e)          access to Data be limited to Personnel on a “need to know” basis, which Personal shall strictly utilise their unique user ID and applicable passwords to access same (the access to such Data shall be subject to a two-step authorisation/authentication process);

(f)           all Data is backed-up regularly, and to ensure that back up testing is conducted regularly in order to ensure that Data can be recovered in the event that such Data is lost, damaged or destroyed;

(g)          its environment has comprehensive malware protection software employed, which software is specifically designed to protect against the most recent malware infections;

(h)          frequent vulnerability scanning is conducted in order to assess whether any computers, networks or applications have any vulnerabilities to cyber-attacks; and

(i)           all designated networks, employ intrusion detection systems and intrusion prevention systems, and record any security incidents.

1.14.    IT network infrastructure diagram:  Upon the Customer’s written request, the Customer must provide the Customer with a network diagram that outlines the Provider’s information technology network infrastructure and all equipment used in relation to fulfilling of its obligations under the Agreement, including:

(a)          connectivity to the Customer’s and all third parties who may access the Provider’s network to the extent the network contains Protected Data;

(b)          all network connections including remote access services and wireless connectivity;

(c)          all access control devices (for example, firewall, packet filters, intrusion detection and access-list routers);

(d)          all back-up or redundant servers; and

(e)          permitted access through each network connection.

1.15.    Material breach:  Any breach of the obligations under this Schedule, is deemed a material breach of the Agreement.

1.16.    Equitable relief: 

(a)          The Provider acknowledges that:

(i)           no adequate remedy exists at law if it fails to perform or breaches any of its obligations under this Schedule;

(ii)          it would be difficult to determine the damages resulting from a breach of this Schedule, and such breach would cause irreparable harm to the Customer; and

(iii)         a grant of injunctive relief provides the best remedy for any such breach, without any requirement that the Customer prove actual damage or post a bond or other security.

(b)          To the extent permitted under Data Protection Laws, the Provider waives any opposition to such injunctive relief contemplated in Section 1.16 or any right to such proof, bond, or other security.

(c)          The Provider’s obligations in this Schedule apply likewise to the Provider’s successors, including without limitation to any trustee in bankruptcy.

 

Provider friendly

SCHEDULE – DATA PROTECTION

 

1.1.       Handling of Protected Data: 

(a)          Standard of care:  The Provider must keep and maintain all Protected Data in strict confidence, using such degree of care as is appropriate to avoid unauthorised access, use or disclosure.

(b)          Usage of Protected Data:  The Provider must use and disclose Protected Data solely and exclusively for the purposes for which the Protected Data, or access to it, is provided pursuant to the terms and conditions of the Agreement, and not use, sell, rent, transfer, distribute, or otherwise disclose or make available Protected Data for the Customer’s own purposes or for the benefit of anyone other than the Customer, in each case, without Customer’s prior written consent.

(c)          Disclosure:  The Provider must not, directly or indirectly, disclose Protected Data to any person other than Authorised Persons, without express written consent from the Customer, unless and to the extent required by government authorities or as otherwise, to the extent expressly required, by applicable law, in which case, the Provider must use reasonable efforts to notify the Customer before such disclosure or as soon thereafter as reasonably possible.

(d)          Responsibility for Authorised Persons:  The Provider is responsible for and remain liable to the Customer for the actions and omissions of such Authorised Persons concerning the treatment of such Protected Data as if they were the Provider’s own actions and omissions.

(e)          Written undertaking required from Authorised Persons:  The Provider must require the Authorised Persons that has access to Protected Data to execute a written undertaking to comply with this Schedule.

1.2.       Additional charges:  The Provider may charge additional fees at their standard rates for activities required by the Customer to assist them to comply with Data Protection Laws.

1.3.       Aggregated and anonymized data:  The Customer hereby authorises the Provider to:

(a)          Anonymize Customer Data and to combine it with data from other customers into a new aggregate dataset; and

(b)          use such Anonymized Customer Data as a component of such new aggregate dataset for any legal business purpose, including without limitation for distribution to third-parties.

1.4.       Minimum safeguards:  In addition to any other safeguards contemplated in this Schedule, the Provider must ensure at minimum that that:

(a)          their Personnel each have a unique user ID assigned to them, subject to strict confidentiality undertakings in terms of a password and confidentiality policy;

(b)          there are passwords required for any access to Data in line with its password policy;

(c)          its operating systems are secure and that the security settings in respect thereof are aligned with good industry practice;

(d)          its administrator accounts (and records of usage in relation thereto) are stored securely and can be accessed in the event of any service restoration or fault determination;

(e)          access to Data be limited to Personnel on a “need to know” basis, which Personal shall strictly utilise their unique user ID and applicable passwords to access same (the access to such Data shall be subject to a two-step authorisation/authentication process);

(f)           all Data is backed-up regularly, and to ensure that back up testing is conducted regularly in order to ensure that Data can be recovered in the event that such Data is lost, damaged or destroyed;

(g)          its environment has comprehensive malware protection software employed, which software is specifically designed to protect against the most recent malware infections;

(h)          frequent vulnerability scanning is conducted in order to assess whether any computers, networks or applications have any vulnerabilities to cyber-attacks; and

(i)           all designated networks, employ intrusion detection systems and intrusion prevention systems, and record any security incidents.

Table of Contents

The Author

Martin Kotze is a commercial lawyer with over 10 years of experience. He specialises in transactional work within the Tech, Financial Services and Property industries. 

He is also one of the co-founders at DocNinja and regularly advises listed companies to small and medium enterprises on how to contract better with their customers. 

Martin Kotze
Linkedin Envelope
Talk to Martin

This is a free 30min consultation to better understand your business and your needs.

Building a force majeure clause

How to build a force majeure clause

In this article, we have a look at some of the important aspects that must be kept in mind when drafting a force majeure clause.

Start building

Most disputed terms WCC ranking: 

10

Most important terms WCC ranking: 

22

Most negotiated terms WCC ranking: 

29

What is the purpose of a force majeure clause?

A force majeure clause is used to determine what happens when an event or circumstance arises that is beyond the reasonable control of a party and this event or circumstance impacts on the ability of a party to perform under the agreement. 

Building blocks of a Force Majeure Clause

building a force majeure clause

Qualifiers

Sometimes force majeure events are qualified by the foreseeability thereof. In other words, if the event or circumstance was foreseeable on the date the agreement was concluded, this event or circumstance will not be regarded as a force majeure event.

On the face of it, it appears fine.  However, there are industries where the probability of disruptions is high and the costs to overcome this disruption will be disproportionate to the commercials of the transaction. In these situations, excluding the foreseeability qualifier may be required.

Other qualifiers that are important relates to whether or not the default or delay was caused by the party claiming force majeure and whether the party claiming the force majeure could have prevented the default or delay by taking reasonable precautions.

Laundry list items

Following the definition of what constitutes force majeure in your agreement, you may want to consider including a laundry list of items that will be regarded as force majeure events. These events are usually specific to the transaction and the industry and may not typically be classified as force majeure.

The purpose of this laundry list is to provide clarity. Here are a couple of examples of the laundry list items:

  • acts of God, natural disasters, earthquakes, fire, explosions, floods, hurricanes, storms or other severe or extraordinary weather conditions, natural disasters
  • sabotage, contamination, nuclear incidents, epidemics
  • war (civil or other and whether declared or not), military or other hostilities, terrorist acts or similar, riot, rebellion, insurrection, revolution, civil disturbance, or usurped authority
  • strikes or other industrial disputes that affect an essential portion of the supplies or works, except with respect to workers under the control of the party asking for relief due to this event
  • non-availability or loss of export permit or license for the products or services to be delivered, or of visas or permits for the party’s personnel
  • requisition or compulsory acquisition by any governmental or competent authority, embargo, or other sanctions
  • currency restrictions, shortage of transport means, general shortage of materials, restrictions on the use of or unavailability or shortage of power or other utilities.

 

When acting for the party that will likely have to claim force majeure, make sure that when adding to the laundry list, stipulate the effects of the event, not simply the specific events. Focusing on the effects of an event may assist in broadening the definition of a force majeure event.

Notification requirements & obligations

Generally, you want a party claiming force majeure to notify the other party as soon as reasonably possible and provide all relevant information describing the circumstances and the performance affected at a reasonable level of detail.

If you are the party that will most likely have to resist force majeure claims, you may want to consider imposing express obligations on the party that will likely be claiming force majeure. For example, you can include an express obligation on the party claiming force majeure to use reasonable endeavors to overcome the force majeure and to continue performing under the agreement as far as reasonably possible.

The notification requirements and obligations will not disqualify a claim under force majeure but if these express obligations are not met, the party resisting the force majeure claim may consider instituting a claim for breach of contract.

Termination rights

It may happen that the force majeure event continues for an unsustainable period. Your force majeure clause needs to stipulate the parties’ obligations to meet and discuss and also what happens if a resolution cannot be obtained.

Generally, if the parties cannot agree on the next steps, a right is included (usually for both parties) to terminate the agreement.

Example clauses

Customer friendly

1.           FORCE MAJEURE

1.1         Qualifying events or acts:  Neither Party is liable for failure or delay to perform their obligations under the Agreement to the extent caused by events or acts beyond their control which could not have been reasonably foreseeable when the Agreement was concluded and includes events or acts of:

(a)         acts of God, natural disasters, earthquakes, fire, explosions, floods, hurricanes, storms or other severe or extraordinary weather conditions, natural disasters, and

(b)         war (civil or other and whether declared or not), military or other hostilities, terrorist acts or similar, riot, rebellion, insurrection, revolution, civil disturbance, or usurped authority.

1.2         Exclusions:  The relief in Section 1.1 will not apply to the extent that:

(a)         the default or the delay was caused by the non-performing Party; or

(b)         such default or delay could have been prevented by precautions and could have been circumvented by the non-performing Party using alternate sources, workaround plans, or other means.

1.3         Obligations:  If an event or act as contemplated in Section 1.1 occurs:

(a)         the non-performing Party must as soon as practical notify the other Party provide all relevant information, describing at a reasonable level of detail the circumstances and the performance that is affected;

(b)         the non-performing Party must use reasonable endeavours to overcome the event; and

(c)         the non-performing Party must continue to perform their obligations as far as practicable.

1.4         Process:  Should either Party be prevented from carrying on their contractual obligations due to an event above lasting continuously for 30 days, the Parties will consult each other on the future implementation of the Agreement.

1.5         Termination:  If the Parties don’t mutually arrive at an acceptable arrangement within 30 days after that, the Customer can terminate the Agreement immediately on written notice.

 

Provider friendly