Many IT projects continue to have an alarmingly high failure rate. In a previous blog post we discussed the importance of identifying requirements and specifications at the start of the project to help reduce the risks associated with “specification breakdown.”
In the second part of this blog series, we discuss steps that both the customer and service provider can take to help protect the confidential information, data and intellectual property that is used, exchanged or otherwise made available during the project.
Protection of Confidential Information and Data
Identifying the Information to be Protected
While it may go without saying, many different types or categories of information and data may be exchanged and produced in the course of an IT project. For example, a party may have access to another party’s proprietary business information, trade secrets, customer information, personal information, user analytics or other aggregated usage-based information.
As a result, an important initial step for both the customer and service provider is to identify:
- The specific types of information or data that will be made available to the other party during the course of the project, and
- The types of information and/or data that will be included in, processed through, or produced by the proposed IT solution.
Once this information is identified, the parties can then take steps to help ensure that their confidential, proprietary or sensitive business information is adequately protected. This is an important issue to which both the customer and service provider should turn their minds as early as possible in the relationship.
As we discuss below, there are often different business, security, legal and privacy-related considerations that will apply for different types of information, and the security measures and contractual protections should be indexed to the sensitivity and/or importance of the information.
Confidential Information at the Beginning of the Relationship
In some IT projects, the parties will negotiate and execute one or more definitive project agreements (such as a master services agreement, outsourcing agreement or subscription/licensing agreement) before confidential information is accessed or exchanged by the parties. These types of agreements will typically address the rights and obligations of the parties with respect to any confidential information that is exchanged or produced as part of the business arrangement.
However, where the parties start off the arrangement with the negotiation of a term sheet, or where the service provider is performing some services prior to the execution of the definitive project agreement (i.e. a proof of concept or early-start arrangement), then an additional layer of contractual protection for the confidential information should be considered.
A common approach in these situations is for the parties to enter into a Non-Disclosure Agreement (“NDA”), which sets the stage for the relationship and allows the parties to move forward in negotiating the term sheet or contract. The execution of an NDA can provide comfort to the party disclosing the information that the party receiving the information has made a contractual commitment to protect that information regardless of the outcome of the prospective business arrangement. An NDA is also an important tool to consider for startup companies or where new intellectual property is the subject of the business deal. In order to be effective, NDAs need to be tailored to fit the specific circumstances and the confidential information to which it relates.
Protection of Confidential Information During the Term
The project agreement will typically include provisions that set out what is considered to be “confidential information” as well as limiting the receiving party’s use of the confidential information for the purposes of carrying out their obligations under the contract. If the parties have previously entered into an NDA, then the provisions in the project agreement will often replace and override the arrangements contemplated in the NDA from and after the effective date of the project agreement.
Depending on the particular service offering and/or the nature of the arrangements between the parties, there are a number of other issues that may need to be considered. For example:
- Does the definition of “confidential information” accurately reflect the different types of information that will be used, exchanged or made available during the course of the project?
- What safeguards does the service provider have in place to protect the confidential information? Where the confidential information is of a particularly sensitive nature (i.e. where personal information is included), additional details on the service provider’s policies, practices and/or procedures may need to be identified in the contract. Depending on the nature of the project, the specific security standards and requirements that the service provider is expected to follow and adhere to may need to be addressed. (i.e. ISO 27001, NIST 800-53, etc.). In those situations, the contract will also address whether the customer has the right to audit the service provider’s security and data-protection practices.
- Where will the confidential information be stored (i.e. outside Canada)?
- What rights does the service provider have to use the confidential information? Can the service provider use aggregate information for purposes unrelated to the business deal, and does this raise any concerns?
- What obligations arise with respect to a data or cybersecurity breach? Does each party have an obligation to notify the other party in the event of a breach? Do they need to cooperate with each other if they are required to provide notification of the breach to certain individuals or the applicable regulators?
Protection of Confidential Information at the End of the Relationship
In addition to the above, the definitive project agreement should address how confidential information will be dealt with at the end of the business arrangement – or in the case of the NDA, if the term of the NDA expires or the parties cease discussions surrounding a potential business arrangement without entering into a definitive project agreement.
At the very least, the contract should contemplate that the confidential information of each party be returned or destroyed within a reasonable timeframe (i.e. 10 days) upon expiration or termination of the contract. To the extent it is not possible for a party to return or destroy certain information of the other party, or if one party needs to retain certain information of the other party for auditing or compliance purposes, then these issues should also be addressed in the contract.
Defining Intellectual Property Rights
The IP ownership provisions in a project agreement are critical for the protection of each party’s existing and future rights in IP. A customer or service provider that inadvertently grants rights or interests in their IP to others may cause significant harm to their organization. As a result, it is critically important to carefully review and draft IP provisions in a project agreement to ensure that the intentions of the parties are accurately set out.
At the Beginning of the Relationship
Many IT projects will require both the customer and the service provider to contribute their respective IP to the project. For example, the service provider may have proprietary software, or may have rights to third party software (as a reseller or otherwise) that will need to be extended to the customer as part of the solution. The customer may also have proprietary technology which the service provider is engaged to fix, further develop or support.
It is important for both parties to ensure that any such IP (which is commonly referred to as “Background IP”) is recognized by the other party and is protected under the contract. A common approach is for the parties to list and describe all of the software and, to the extent practicable, other applicable IP that will be used in connection with the project in a disclosure schedule that attaches to the contract. The act of developing and populating this disclosure schedule itself will often give rise to other technical or business issues that the parties had not previously considered.
After the Background IP of each party has been identified, the contract should address the rights of each party to use the other party’s Background IP. More specifically, to the extent that one party requires a license to the Background IP of the other party (or to any third party software), the rights, restrictions and any other terms of use relating to that license should be addressed in the contract.
During the Term of the Agreement
While the definitive agreement between the parties will often address the license of IP rights during the term, the scope of the license grant must still be carefully considered. In particular, the customer should ensure that it has a license to do all the things it needs or wants to do with the software or solution. This includes ensuring that the definition and scope of “use” is broad enough to cover the customer’s intended use, from the intended activities to the intended territory of use.
On the other hand, depending on the nature of the business arrangement, the service provider will typically take steps to ensure that the license granted to the customer does not negatively impact or even preclude the service provider from other business relationships or licensing opportunities.
Another important issue to address in the contract is the ownership of IP that is created during the project (this is often referred to as “Arising IP” or “Foreground IP”). In addition to addressing who will own the Arising IP, the non-owing party may require a license to use the Arising IP during the term of the agreement to the extent required to provide the services and/or to receive the benefit of such services, as the case may be.
At the End of the Relationship
Even at the beginning of the relationship the parties should consider what will happen at the end. Depending on the nature of the project, the customer may need a limited right to use certain Background IP of the service provider – even if the provider is no longer providing services or support to the customer.
On the other hand, if the nature of the arrangement is that the customer will be using the service provider’s multi-tenant SaaS solution for a specific period of time, then the customer should not need an ongoing license to the provider’s IP at the end of the term of the agreement (or, if applicable, at the end of the wind-down/transition period if the provider is providing soft-landing or transition support at the end of the term).
For these reasons, it is important for the contract to identify and define the rights, responsibilities and obligations of the parties at the end of the project or business arrangement with respect to Background IP and any Arising IP.
If you missed it, be sure to read part one of this blog series: Project Specifications.
Note: This article is of a general nature only and is not exhaustive of all possible legal rights or remedies. In addition, laws may change over time and should be interpreted only in the context of particular circumstances such that these materials are not intended to be relied upon or taken as legal advice or opinion. Readers should consult a legal professional for specific advice in any particular situation.