What should be considered by the software house when signing a contract with a subcontractor? Selected questions. Part II

The terms of a contract with a subcontractor engaged by a software house should take into account the terms of cooperation and the restrictions that apply to the relationship with the client for whom the work is performed.

Specific client requirements

If a particular client has a contract based on its own template or has introduced a set of customised terms of cooperation, e.g. compliance obligations, when negotiating a contract with a software house, we should take these into account when deciding whether to subcontract such a project. It is worth making sure that they are binding on the subcontractor, even if we have a permanent, long-term agreement with the company in question and work together on a number of projects for other clients.

Subcontracting Agreement – selected questions. Part II

1. If the work performed by a subcontractor is part of the software house’s work for a particular client, it is necessary to take into account the contract with the client, as well as the arrangements and manner of cooperation thereunder.
2. First of all, we should make sure that the contract with the customer allows the use of subcontractors at all and what the procedure applies in this respect, e.g. do we have to obtain the customer’s prior consent, or do we have to inform the customer in advance about the use of a subcontractor and do we have to submit a subcontractor agreement for client’s review. If a software house regularly uses personnel with whom it cooperates on the basis of B2B contracts in the execution of projects, it is worth stipulating explicitly in contracts with individual customers that such persons are not recognized by the parties as subcontractors and that contractual restrictions on the use of subcontractors do not apply.
3. It is not uncommon for client contracts, especially when we work with larger companies, to include procedures and requirements such as an obligation to familiarise ourselves with and comply with specific client’s policies, such as anti-corruption, anti-money laundering and anti-terrorist financing, or social responsibility. We should also impose such requirements on our subcontractor. If we are working with a subcontractor on a wider basis and the cooperation agreement has been entered into in the past, it is worth reviewing it in the light of such requirements and adjusting it where necessary.
4. Providing a service to a client that involves the processing of personal data of which the client is the controller, e.g. the data of its customers, often requires the conclusion of a personal data processing agreement. In such a case, when we engage a subcontractor to process such personal data, we must also take into account the content of the data processing agreement concluded with the client, as well as the requirements of Article 28 of the General Data Protection Regulation (GDPR). According to this provision, the so-called further subprocessing of data is only permitted if the data controller (the customer) has accepted the subcontractor in question (a specific consent) or has given its general consent to the use of subcontractors (in which case we should notify the customer of the intention to use a subcontractor and give the customer the opportunity to object). In addition, the sub-processing agreement with our subcontractor should be analogous to the data processing agreement concluded with the client, and any limitations and restrictions, e.g., the prohibition on transferring data outside the European Economic Area provided for in such a contract, must be imposed on the sub-processor. In most cases, the data processing agreement concluded with the client will specify the necessary procedures in this respect.
5. Another important issue to address in the subcontractor agreement is the subcontractor’s personnel involved in the project and the possibility of using further subcontractors. It is worth considering whether the agreement with our subcontractor should exclude the possibility of using further subcontractors and, where this would be impossible or unreasonable, provide procedures for doing so, also taking into account the requirements that bind us in our relationship with the client. An example of this could be the requirement for the software house’s prior consent to the engagement of further subcontractors or personnel other than employees and the relevant requirements for the relationship with such further subcontractor. In particular, we should ensure that the sub-contractor only uses suitably qualified personnel who are also bound by appropriate agreements, including those ensuring the transfer of intellectual property rights, the non-exercise of moral rights by such developers and the maintenance of confidentiality. If we cannot verify the contracts with the personnel or further subcontractors ourselves (which is often impossible for organisational, legal or commercial reasons), we can at least require assurances and guarantees and safeguards in case it turns out that the rights are nevertheless incomplete. A software house cannot effectively transfer rights to its client that it has not first acquired from its subcontractor. I am particularly referring to the limitation of liability of the subcontractor in the subcontractor agreement. The limitation of liability itself is rather standard, but it should not apply to legal defects. In the relationship with the customer, it is the software house that is liable for such legal defects in the delivered software. At the same time, if such an ineffective acquisition has occurred in the relationship between a subcontractor and a further subcontractor, in practice only the subcontractor will have the opportunity to remedy such an infringement and to acquire additional rights.
6. We should also require our subcontractor to implement specific procedures to ensure the security of confidential information and products created by the software house and its customers. It is the responsibility of the subcontractor to ensure that specific security measures are implemented and to verify and control that the work product does not contain harmful or malicious software, including viruses, worms, time bombs or other hidden content. It may be appropriate for the software house to have the right to audit the implementation of these requirements, which should also be secured in the subcontractor agreement.
The points raised above are, of course, only examples. Other topics, such as contract termination or settlement procedures, warranty of work results, or procedures in the event of non-performance or improper performance of the contract, will also be very important from the perspective of a software house engaging a subcontractor. We will return to these issues in future blog posts.