Australia: A Practical Guide To Effective Software/Hardware Contract Management – Comprehensive Advice For Vendors And Clients

Last Updated: 8 November 2006

On-going Support: Typical Contractual Issues and Best Practice Solutions


Issues of software support are usually addressed in a software support agreement (SSA), which is typically separate to the software license agreement itself. There may be some cross over between these two agreements, however the applicability and terms of both agreements are usually a matter of negotiation between the parties in each instance.

The paper is designed to give an overview of critical issues to be addressed in an SSA and the relevance of these issues to both the supplier and customer alike.

Software Support Agreements Generally

The terms "Support" and "maintenance" when used in the context of software, are often interchangeable and are not terms of art. "Support" and "maintenance" in this context refer to a wide gamut of services, from system performance levels, help desk and escalation, error correction to software updates and file maintenance.

Typically stand alone "maintenance" services will be charged by suppliers at a rate of between 15 and 20% of software licence fee annually. "Maintenance" will typically cover error correction, bug fixes, updates and new releases. Customers will remain current with access to the latest version of an application and have access to a product road map that identifies the future direction for the software.

"Support services" will usually be based around service availability using agreed service levels with proactive system monitoring, help desk and escalation for performance issues. It will be difficult to provide support without a customer also signing up for "maintenance" in the form of error correction, bug fixes and updates to the code.

The terms of every SSA will be unique and will depend on the nature and extent of the software itself, the capabilities of the supplier to supply support services, service levels, the longevity of the software itself and security issues.

It is important that the parties have a clear understanding of each others capabilities when negotiating an SSA so that they both get the maximum benefit possible from the services provided under the agreement and appropriately manage the expectations of one another.

A supplier should be aware of a customers hardware capacity; the availability and technical capabilities of in-house IT staff, if any; security of data processed by the software; remote access and disaster recovery practices.

A customer should enquire as to the effect of warranty periods on the provision of support services; costs for support and price protection; availability of support including: priority levels; response and restore times; the retention of the source code of the software in escrow; updates; new releases; and data recovery.

In the preliminary stages of the negotiation of an SSA, as in many commercial contractual negotiations, there may be a preliminary joust as to which party should draft the agreement. It is reasonable for a customer to want a document that suits and reflects the requirements of their particular project, rather than having to fit in with a standard form agreement, for example. However it is common for suppliers to draft the initial document so as to ensure it accurately reflects their own capabilities.

A mutual understanding of each partys capabilities and expectations from the outset of negotiations is an excellent means of ensuring that the SSA will be drafted in accordance with the understanding of both parties thereby avoiding any unnecessary argument as to why one party and not the other should draft the SSA.

Service Levels


Service levels are at the heart of any SSA and are the benchmark for the performance of the agreement by both parties. Unrealistic or disproportionate service levels will hinder the efficient operation of the agreement.

The scope of the service levels set in an SSA will usually be dependent on each project and the nature of the software. However generally speaking, the supplier has an obligation to maintain the software in substantial conformity with the descriptions and specifications disclosed to the customer.

Suppliers should pay specific attention to what level these obligations will be performed at. Will a missed service level constitute a breach of the SSA leading to a claim for damages and termination rights or will a performance credit be the sole remedy? Will the supplier use best or reasonable endeavours to maintain the software in this way? I discuss "Performance Credits as Sole Remedy" in the section below entitled "Risk Allocation".

The terms "best endeavours" and "reasonable endeavours" are interchangeable (in Australia at least). It may be argued by some that a best endeavours clause sets a high obligation on a party to do all it can to bring about the specified goal or purpose set out in an agreement, where as a reasonable endeavours clause gets a lower threshold as to what efforts a party should take to bring about the specified goal or purpose of an agreement.

There is Australian High Court authority that a best endeavours clause is a clause in a contract requiring a party to do what may be reasonably done in the circumstances, having regard to the nature, capacity, qualifications and responsibilities of the parties, to bring about a certain result.1 In any event, a best endeavours clause will normally be implied in commercial contracts.2 Therefore, it would seem that the threshold test for any such clause is a reasonable attempt by a party to bring about a desired outcome as contemplated in the agreement. This duty would apply to a suppliers efforts to meet service levels.

It is also prudent for a supplier to ensure that the SSA covers training of the customers personnel in the use of the software. The scope and extent of any such training will depend on factors such as whether the customer employs its own IT technicians, the complexity of the software and its use, the hardware on which the software is loaded and the instructions contained in the manual of specifications for the software. Poor training of a customers users will also result in an increased cost of supporting the software.

The intended scope of support services should always be clearly defined in an SSA. "Support" to the extent it has a generally accepted scope in the context of software has been defined to include3:

  1. explaining the functions and features of the software;
  2. clarifying documentation relating to the software;
  3. guiding the customer in the operation of the software;
  4. providing recommendations with respect to the customers hardware requirements;
  5. assisting customers when problems occur in their software, including systems crashes, incorrect results caused by improper use or software defects; and
  6. file maintenance, including correction of corrupted files or date.

Service Exclusions

The exclusions of the support services should also be clearly defined. It is only reasonable for suppliers to exclude support services for defects or errors in the software that are beyond their control for various reasons, including but not limited to:

  1. defects or errors resulting from any modification of the software by a person other than the supplier;
  2. defects or errors resulting from the use of the software in combination with equipment other than the equipment designated for use in the SSA;
  3. rectification of errors in the operating system of designated equipment;
  4. rectification of faults in the designated equipment;
  5. training the customers personnel;
  6. modification to the software which constitutes a departure from the description and specification of the software in the license agreement and any accompanying manuals of specification; and
  7. rectification of errors or defects which are the subject of a warranty under another agreement.

Such services can be supplied, but by agreement and for an extra charge.

Priority Levels and Response Times

To ensure the efficient execution of the obligations in a SSA, there should be a clear framework for priority levels and response times of the supplier.

Priority levels and response times should clearly define the following:

  1. hours during which support services and provision for after hours support, if available;
  2. classification of issues according to pre-determined criteria;
  3. the degrees of priority allocated and the type of support will rendered in respect of each priority level (ie. telephone support for low priority errors or defects and on-site support for high priority errors or defects); and
  4. documents and other materials the customer must provide to the supplier to assist it in reproducing the operating conditions giving rise to the error or defect.

It is especially important for the customer to ensure that priority levels, response times and target restore times are clearly defined as they will act as benchmarks which the suppliers support services must meet. A failure to adequately provide for priority levels and response times may lead to inefficiencies on the part of the supplier in providing the support services and may also give rise to the customer disputing support charges.

The classification of errors will be open to differing judgements as to severity. Typically, the higher the severity the faster the escalation and resolution of issues. It is the writers view that in the absence of agreement on classification of faults the customers view should guide the resolution path. The customer is in a better position to determine the impact of any fault on its business.

From the suppliers perspective, the negotiation of priority levels, response times and target restore times should reflect the capabilities of the supplier or the suppliers appointed contractor (in circumstances where the software supplier out-sources its support services).

From the customers perspective, the negotiation of these issues should reflect the needs of the customer so as to cause as little disruption to its business and to ensure defects and errors are rectified as quickly as possible.

Of course, as the needs and capabilities of both parties will very rarely be compatible there needs to be a reasonable negotiation of priority levels and response times. It is in the interests of both parties to ensure there is a degree of flexibility incorporated in the SSA so as to ensure the parties can manage priority levels, response and restore times and the customer gets the maximum benefit from the support services.

Risk Allocation

Performance Credits as Sole Remedy

Where the parties agree service levels appropriate for the application being supported, a missed service level should not constitute a breach of the SSA leading to a right to damages. A standard industry practice in the writers experience is to make performance credits the sole remedy for a breach of a service level.

If service levels are seriously breached for example: 3 months in a row or 5 months in any rolling 12 month period, it is reasonable to agree a termination right. The customer should have the right to seek an alternative provider with agreed levels of poor performance.

Most agreements exclude consequential damages. There may well be significant direct damage from a system outage or service level breach. Can the supplier take on the commercial risk of such outage? This will really be determined by the stability of the system (or likelihood of an outage) and the price charged for support services. Ordinarily the customer wears the business risks associated with any system and the supplier agrees to use its "best" or "reasonable" endeavours to ensure response and restore times are met. Apart from performance credits the risk of some unpredictable level of business harm is usually not priced into the cost of support services.

Warranty Period

The warranty period in respect of the software itself will usually be set out in the software license agreement, however it may sometimes be included in an SSA.

The effect of the warranty period is that the supplier agrees to rectify any defects in the software free of charge during the specified period.

Where the warranty period for the software is stipulated in the software license agreement, it would be prudent to reference or mirror that provision of the software license agreement in the SSA in the clauses dealing with payment for support services.

This may mean that Support charges are substantially reduced during the warranty period. Usually fixes during the warranty period have already been priced in to the licence fee.


In respect of the support services themselves, customers should seek express warranties from the supplier that the support services will be rendered with due skill and care and that any materials supplied in connection with those services (ie. documentation accompanying the software) are reasonably fit for the purpose for which they are supplied. Note this warranty may be implied by law, but only where the value of the services is less than $40,000 and the customer falls within the definition of "consumer".4

When negotiating warranties the supplier should always be mindful of the fact that it is virtually impossible to give warranties that the software will be, or can be rectified so that it will be, error free.

The following are examples of warranties that any be included in an SSA to address these issues:

"The supplier warrants that it shall perform the maintenance services in an efficient and professional manner and that it will observe standards generally observed in the industry for similar services.

The supplier warrants that it shall use its best endeavours to maintain the software in conformity with the specifications and to ensure the manual of specifications remains accurate. The customer acknowledges that the supplier does not warrant that the software can be rendered error free."

Exclusion Clauses

Considering the nature of the software and the scope for defects and errors, it is not unusual to see clauses which seek to exclude a condition or warranty that would otherwise be implied by law. As such, it is advised that where a supplier seeks to include an exclusion clause in an SSA, it should also include a clause capping its liability in the event that the supplier is in breach of the SSA and the exclusion clause is later held unenforceable.

The Trade Practices Act 1974 (Cth) (Act) provides for consumer protection. Where the Act applies to a consumer transaction, there are certain conditions and warranties which are not excludable from a contract, including:

  1. good title and right to quiet enjoyment of the goods;
  2. that the goods are fit for their specified purpose;
  3. that the services will be provided with due care and diligence; and
  4. that the services will be provided for an appropriate purpose.5

As noted above, the application of the Act will depend on the value of the transaction and the nature of the goods and services acquired under it.6

A supplier should always be mindful of the fact that exclusion clauses which are contrary to law will not be enforced by a court. For example, an exclusion clause which purports to avoid liability for a breach of an implied warranty, would not be enforced by a court. A court will not enforce an exclusion clause which on its face, appears to operate unreasonably. Where the exclusion clause is ambiguous, a court will construe the clause in favour of the non-breaching party.

Caps on Liability

Customers should be mindful not to agree to an exclusion clause that excludes liability for which the supplier should otherwise be responsible. For example, the supplier often accepts uncapped liability for infringement of third party intellectual property which is embedded in the software or any other materials provided to the customer under the SSA. Also, the supplier would accept uncapped liability for misuse of confidential information, wilful default, fraud and any death or personal injury which may result from the provision of the services under the SSA.

A cap on liability is extremely important from a suppliers perspective. If liability under the SSA is uncapped, the supplier effectively becomes an insurer for a customers business in the event the customer suffers loss arising from the provision of the support services. It is therefore recommended that the suppliers cap their liability. A usual practice is to set the overall cap at the level of all monies received by it under the SSA.

Larger customers may insist on a supplier taking a high level of liability in respect of any breach of the SSA. Whether or not a supplier agrees to allow access the cap more easily, a larger cap, or no cap at all, will require an assessment by the supplier of the actual level of risk versus the strategic importance of the customer. Suppliers should always be mindful of the fact that where a cap on liability is excessive or there is no cap at all, the suppliers liability, if realised, may have the effect of severely damaging its business.

Support Charges

Key to negotiation of an SSA will be the costs for the support services. Support charges should be clear and unambiguous and should specifically state inclusions and exclusions.

From the customers perspective, it is important to ensure that the SSA contains a performance credit or rebate mechanism so that support charges may be adjusted in the event of substandard performance by the supplier. A performance rebate should be calculated pursuant to a formula agreed by the parties. The inclusion of a performance rebate gives the customer comfort with regards to the quality of the support services and keeps the supplier accountable for the level at which those services are performed. Generally (other than a right to terminate) performance rebates are the sole remedy for the poor performance.

Performance credits or rebates are typically structured so that the supplier puts at risk the margin on support services delivered in a given month.

Where the software licensor does not provide software support services, but contracts those support services out to a third party, the software licensor needs to be mindful of third line forcing issues. Third line forcing is prohibited by the Act.7

In the case of a software license agreement, third line forcing may occur if the supplier agrees to license software to the customer on the condition that the customer acquires the software support services from a third party supplier. Obviously, where the software supplier, or a third party, is the only supplier of support services for that particular software product, then third and full line forcing may not be an issue.


A supplier, when negotiating support charges, should seek to have some level of certainty as to pricing, the ability to increase pricing over the term of the SSA and the ability to impose additional charges for services rendered which fall outside the scope of the agreement.

With respect to pricing, it is not uncommon to see clauses in SSAs allowing for an increase in support charges with the increase being referable to increases in the Consumer Price Index. The supplier should be required to give the customer reasonable notice of any such increase and the customer should be given the option to terminate the agreement should it not agree to the pricing increase.

Suppliers should also ensure the SSA allows them to impose reasonable additional charges referable to the suppliers standard rates, for services which are requested by the customer which are not specifically included or are excluded in the SSA. The supplier may also consider imposing additional charges in the event the supplier is asked, and takes steps, to supply support services which are not ultimately necessary (eg. Where a customer requests an on-site visit from the supplier for a defect or error which could otherwise have been rectified by telephone support).


Updates, New Releases and Supported Versions

Provisions as to updates and new releases of the software may be contained in either the software licence agreement itself, a maintenance agreement or the SSA.

A "new release" is designed primarily to extend, alter, improve or add functionality to the licensed software. An "update" is provided primarily to overcome errors and defects in the existing version of the software.8

It is often to the suppliers advantage if the customer implements updates and/or new releases as this then alleviates the need for the supplier to expend time, money and effort in supporting older and possibly redundant versions of the software. On the flip side, the customer may be reluctant to implement updates and/or new releases because they may be perfectly happy with the version of the software they use at that time.

In any event, the parties to an SSA should negotiate whether the client will have the right to decline to implement and update and /or new release and the consequences if a customer exercises that right to decline, including the issue of costs.

A supplier may choose to only extend updates and/or new releases to customers if they have a current SSA in place with the supplier. However, suppliers should be mindful of the fact that such a condition cannot be imposed where the purpose of the update or new release is to rectify defects which would otherwise expose the supplier to liability if they were not immediately rectified.9

In the event that a customer is not given the right to decline updates and new releases, the supplier should consider imposing obligations on the customer to maintain and upgrade hardware and install updates or new releases in a specified time frame so as to ensure that the customer always has the most up to date version of the software. This will ensure the software is operating as efficiently as possible and that the support services can be rendered quickly and accurately.

The preparedness of a supplier to support old versions of the software is a commercial matter for the supplier. In determining whether it will support older versions of the software, the supplier should ensure that any requirement that the customer upgrade the software so as to avoid a need for the supplier to support an older version, is reasonably necessary for the protection of the legitimate interests of the supplier.10


Another key issue affecting the currency of the software is the availability of the source code to the customer. Whilst suppliers usually give a customer the object code of the software, source code is usually retained by suppliers so as to protect its proprietary interest in the software.

As source code is required to maintain and/or modify the software itself, a customer should consider whether or not the source code should be placed in escrow so as to allow the customer to access the source code in situations where maintenance services are withdrawn for reasons of a dispute between the parties, or where the supplier becomes insolvent.

Again, the issue of placing the source code in escrow may be addressed in either the software license agreement itself, or in the SSA. In most cases, escrow provisions will be set out in the software license agreement or a separate escrow agreement.


Issues of security will be of great importance to both parties. A supplier will be concerned with the security of its software to ensure the protection of its intellectual property and may seek to impose a condition on the customer to protect the software from unauthorised access or use, misuse, damage or destruction. Usually, any such provisions are contained in the software license agreement.

A customer may however wish to impose certain obligations on a supplier to protect the information being processed by the software itself. For example, where the supplier is able to access the customers system remotely for the purposes of providing support services, the customer may wish to impose conditions to restrict which of the suppliers staff may access the customers system remotely.

The customer may also wish to negotiate arrangements as to the off-site storage of software that contains sensitive customer information as a means of disaster prevention. Such arrangements are usually negotiated under a separate software media storage agreement, however where the software supplier provides support services and is in a position to provide storage facilities, it may be more efficient and cost effective for the storage provisions to be included as part of the SSA.

The provisions with respect to storage will be largely dependent on the nature of the information, the access to the stored information required by the customer, and the suppliers storage facilities, and may require a delineation of responsibilities between the parties as to matters of storage.


The parties should ensure that the SSA contains adequate termination provisions to allow either party to terminate in circumstances where it is unwilling or unable to continue performing its obligations under the SSA. Typical termination events include:

  1. the breach or threatened breach by either party of its material obligations under the SSA; Page 10 of 11
  2. the appointment of any type of insolvency administrator in respect of the property or affairs of either party;
  3. the entry or proposed entry by either party into arrangements with any of its creditors;
  4. the permanent discontinuance of use of the software or any part of the software by the customer; or
  5. the merger with or the takeover of either party by another person.

Consideration to the exit strategy to be followed upon termination of the SSA should be given by both parties during negotiations. It is of no benefit to either party to terminate the agreement and then determine how the termination will be effected.

Reasonable notice of a partys intent to terminate should be given. In the event of termination for material breach, the breaching party should be given the opportunity to remedy the breach within a reasonable time frame before the SSA is terminated.

An example of a material breach would be where a supplier continuously provided substandard support or where a customer failed to acquire and maintain the hardware necessary to operate the software.

There should be adequate provision in the agreement for a termination to be effected with as little disruption to the customer and its systems as possible. The parties should consider a "ramp down" period in which the supplier will provide limited support services to assist the customer transitioning from its software to the systems or software of another supplier, if necessary.

A supplier should also ensure that the SSA contains adequate provision for the return or confidential destruction of the software and any manuals of specification or other documentation.

Supporting Open Source Code and Third Party Software

The parties should address support obligations for open source code used with or as a part of an application and any other third party software necessary for the application to operate.

Open source code can be supported by a supplier. Arguably there will be nowhere else to turn, so where use of open source is part of a solution it is often backed with vendor support obligations. Vendors who include open source code as a part of their solution need to decide:

  1. do we support open source code?;
  2. what are our processes to include open source code with our solution?;
  3. do we give an IP Warranty?; and
  4. what happens in the event of an IP breach or other need to replace the open source code?

For third party software, responsibility for the bug fixes, error correction or other defects with this software often passes to the third party under the escalation regime, with time taken to respond not included in restore times under SLAs. Customers usually dont want various vendors to point to each other and appreciate a single point of contact for support of an application. It is reasonable for a supplier to "manage" the resolution of faults with third party software so that the primary application is restored.


Software support is key to the operation and use of the software by a customer. It is therefore necessary that a customer is satisfied that the provision of support services is commensurate with the software itself and that the level of those services is within the capabilities of the supplier.

In order to enable the efficient performance by the parties to as SSA the issues addressed above should be worked through and negotiated by the parties prior to the execution of the SSA. This will ensure that the parties performance is referable to a clear framework and enable the parties to resolve any issues arising under the SSA in a reasonable manner.


1. See Transfield Pty Limited v Arlo International Ltd (1980) 144 CLR 83

2. See Camberwell v Camberwell Shopping Centre Pty Limited (1994) 1 VR 163

3. GEAC J & E Systems Ltd v Erickson Systems (1993) 26 IPR 643 at 653

4. Section 74(1) of the Trade Practices Act 1974 ("Act") stipulates that these warranties are implied in contracts for the supply of services, however the application of this section is confined to contracts between a corporation and a "consumer". A person or entity is classified as a consumer if the price of the services does not exceed $40,000, or, if the price exceeds that sum, the goods or services are of a kind ordinarily acquired for personal, domestic or household use or consumption.

5. Sections 69, 71, 74(1) and 74(2) of the Act.

6. See note 4 above.

7. Sections 47(6) and 47(7) of the Act.

8. Hughes & Sharpe "Computer Contracts Principles and Precedents", Law Book Company, at [1.205].

9. Hughes & Sharpe "Computer Contracts Principles and Precedents", Law Book Company, at [1.230].

10. See Section 51AC of the Act.

The content of this article is intended to provide a general guide to the subject matter. Specialist advice should be sought about your specific circumstances.

To print this article, all you need is to be registered on

Click to Login as an existing user or Register so you can print this article.

Some comments from our readers…
“The articles are extremely timely and highly applicable”
“I often find critical information not available elsewhere”
“As in-house counsel, Mondaq’s service is of great value”

Related Video
Up-coming Events Search
Font Size:
Mondaq on Twitter
Register for Access and our Free Biweekly Alert for
This service is completely free. Access 250,000 archived articles from 100+ countries and get a personalised email twice a week covering developments (and yes, our lawyers like to think you’ve read our Disclaimer).
Email Address
Company Name
Confirm Password
Mondaq Topics -- Select your Interests
 Law Performance
 Law Practice
 Media & IT
 Real Estate
 Wealth Mgt
Asia Pacific
European Union
Latin America
Middle East
United States
Worldwide Updates
Mondaq Ltd requires you to register and provide information that personally identifies you, including what sort of information you are interested in, for three primary purposes:
  • To allow you to personalize the Mondaq websites you are visiting.
  • To enable features such as password reminder, newsletter alerts, email a colleague, and linking from Mondaq (and its affiliate sites) to your website.
  • To produce demographic feedback for our information providers who provide information free for your use.
  • Mondaq (and its affiliate sites) do not sell or provide your details to third parties other than information providers. The reason we provide our information providers with this information is so that they can measure the response their articles are receiving and provide you with information about their products and services.
    If you do not want us to provide your name and email address you may opt out by clicking here
    If you do not wish to receive any future announcements of products and services offered by Mondaq you may opt out by clicking here

    Terms & Conditions and Privacy Statement (the Website) is owned and managed by Mondaq Ltd and as a user you are granted a non-exclusive, revocable license to access the Website under its terms and conditions of use. Your use of the Website constitutes your agreement to the following terms and conditions of use. Mondaq Ltd may terminate your use of the Website if you are in breach of these terms and conditions or if Mondaq Ltd decides to terminate your license of use for whatever reason.

    Use of

    You may use the Website but are required to register as a user if you wish to read the full text of the content and articles available (the Content). You may not modify, publish, transmit, transfer or sell, reproduce, create derivative works from, distribute, perform, link, display, or in any way exploit any of the Content, in whole or in part, except as expressly permitted in these terms & conditions or with the prior written consent of Mondaq Ltd. You may not use electronic or other means to extract details or information about’s content, users or contributors in order to offer them any services or products which compete directly or indirectly with Mondaq Ltd’s services and products.


    Mondaq Ltd and/or its respective suppliers make no representations about the suitability of the information contained in the documents and related graphics published on this server for any purpose. All such documents and related graphics are provided "as is" without warranty of any kind. Mondaq Ltd and/or its respective suppliers hereby disclaim all warranties and conditions with regard to this information, including all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement. In no event shall Mondaq Ltd and/or its respective suppliers be liable for any special, indirect or consequential damages or any damages whatsoever resulting from loss of use, data or profits, whether in an action of contract, negligence or other tortious action, arising out of or in connection with the use or performance of information available from this server.

    The documents and related graphics published on this server could include technical inaccuracies or typographical errors. Changes are periodically added to the information herein. Mondaq Ltd and/or its respective suppliers may make improvements and/or changes in the product(s) and/or the program(s) described herein at any time.


    Mondaq Ltd requires you to register and provide information that personally identifies you, including what sort of information you are interested in, for three primary purposes:

    • To allow you to personalize the Mondaq websites you are visiting.
    • To enable features such as password reminder, newsletter alerts, email a colleague, and linking from Mondaq (and its affiliate sites) to your website.
    • To produce demographic feedback for our information providers who provide information free for your use.

    Mondaq (and its affiliate sites) do not sell or provide your details to third parties other than information providers. The reason we provide our information providers with this information is so that they can measure the response their articles are receiving and provide you with information about their products and services.

    Information Collection and Use

    We require site users to register with Mondaq (and its affiliate sites) to view the free information on the site. We also collect information from our users at several different points on the websites: this is so that we can customise the sites according to individual usage, provide 'session-aware' functionality, and ensure that content is acquired and developed appropriately. This gives us an overall picture of our user profiles, which in turn shows to our Editorial Contributors the type of person they are reaching by posting articles on Mondaq (and its affiliate sites) – meaning more free content for registered users.

    We are only able to provide the material on the Mondaq (and its affiliate sites) site free to site visitors because we can pass on information about the pages that users are viewing and the personal information users provide to us (e.g. email addresses) to reputable contributing firms such as law firms who author those pages. We do not sell or rent information to anyone else other than the authors of those pages, who may change from time to time. Should you wish us not to disclose your details to any of these parties, please tick the box above or tick the box marked "Opt out of Registration Information Disclosure" on the Your Profile page. We and our author organisations may only contact you via email or other means if you allow us to do so. Users can opt out of contact when they register on the site, or send an email to with “no disclosure” in the subject heading

    Mondaq News Alerts

    In order to receive Mondaq News Alerts, users have to complete a separate registration form. This is a personalised service where users choose regions and topics of interest and we send it only to those users who have requested it. Users can stop receiving these Alerts by going to the Mondaq News Alerts page and deselecting all interest areas. In the same way users can amend their personal preferences to add or remove subject areas.


    A cookie is a small text file written to a user’s hard drive that contains an identifying user number. The cookies do not contain any personal information about users. We use the cookie so users do not have to log in every time they use the service and the cookie will automatically expire if you do not visit the Mondaq website (or its affiliate sites) for 12 months. We also use the cookie to personalise a user's experience of the site (for example to show information specific to a user's region). As the Mondaq sites are fully personalised and cookies are essential to its core technology the site will function unpredictably with browsers that do not support cookies - or where cookies are disabled (in these circumstances we advise you to attempt to locate the information you require elsewhere on the web). However if you are concerned about the presence of a Mondaq cookie on your machine you can also choose to expire the cookie immediately (remove it) by selecting the 'Log Off' menu option as the last thing you do when you use the site.

    Some of our business partners may use cookies on our site (for example, advertisers). However, we have no access to or control over these cookies and we are not aware of any at present that do so.

    Log Files

    We use IP addresses to analyse trends, administer the site, track movement, and gather broad demographic information for aggregate use. IP addresses are not linked to personally identifiable information.


    This web site contains links to other sites. Please be aware that Mondaq (or its affiliate sites) are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of these third party sites. This privacy statement applies solely to information collected by this Web site.

    Surveys & Contests

    From time-to-time our site requests information from users via surveys or contests. Participation in these surveys or contests is completely voluntary and the user therefore has a choice whether or not to disclose any information requested. Information requested may include contact information (such as name and delivery address), and demographic information (such as postcode, age level). Contact information will be used to notify the winners and award prizes. Survey information will be used for purposes of monitoring or improving the functionality of the site.


    If a user elects to use our referral service for informing a friend about our site, we ask them for the friend’s name and email address. Mondaq stores this information and may contact the friend to invite them to register with Mondaq, but they will not be contacted more than once. The friend may contact Mondaq to request the removal of this information from our database.


    From time to time Mondaq may send you emails promoting Mondaq services including new services. You may opt out of receiving such emails by clicking below.

    *** If you do not wish to receive any future announcements of services offered by Mondaq you may opt out by clicking here .


    This website takes every reasonable precaution to protect our users’ information. When users submit sensitive information via the website, your information is protected using firewalls and other security technology. If you have any questions about the security at our website, you can send an email to

    Correcting/Updating Personal Information

    If a user’s personally identifiable information changes (such as postcode), or if a user no longer desires our service, we will endeavour to provide a way to correct, update or remove that user’s personal data provided to us. This can usually be done at the “Your Profile” page or by sending an email to

    Notification of Changes

    If we decide to change our Terms & Conditions or Privacy Policy, we will post those changes on our site so our users are always aware of what information we collect, how we use it, and under what circumstances, if any, we disclose it. If at any point we decide to use personally identifiable information in a manner different from that stated at the time it was collected, we will notify users by way of an email. Users will have a choice as to whether or not we use their information in this different manner. We will use information in accordance with the privacy policy under which the information was collected.

    How to contact Mondaq

    You can contact us with comments or queries at

    If for some reason you believe Mondaq Ltd. has not adhered to these principles, please notify us by e-mail at and we will use commercially reasonable efforts to determine and correct the problem promptly.

    By clicking Register you state you have read and agree to our Terms and Conditions