Conditionalities definition, contractualisation and quality assurance

1. Contractualising conditionalities

This chapter identifies the key elements in contractualisation the relationship resulting from the procurement exercise. Each section in this chapter will address a topic that is the subject of one or more contractual terms, indicating why the matter may need to be discussed and what the impact on the execution of the contract may be.

1.1 Four corners clause – exclusion of general terms & conditions

Regarding contractualisation, it is important to have a mutual understanding of what shall constitute (part of) the contractual documentation. The so-called “four corners” clause ensures that anything and everything that pertains to the contractual relationship is to be expressly included in the set of documents that the parties agree to be the contract between them. There can be no conditions that apply (other than by law) other than those agreed in writing.

The most important consequence of that clause, which is often explicitly included, is that any deviant general terms and conditions of a party, such as those typically found on the backside of invoices or attached to an offer, shall not apply within the contractual relationship.

The devil is – as always – in the detail. It is most valuable to allow separate documents to be included only by reference, especially in complex contractual settings. This facilitates reference to e.g. industry standards, but the contracting authority (CA) should be vigilant in accepting references to documents from the vendor.

Moreover, it is key for the CA to be cautious where a solution may require the acquisition of right of use to intellectual property rights (IPR) of a third party. Such license, if not obtained through the vendor and within the boundaries of the contractual relationship with the vendor, inevitably requires a separate contractual arrangement with the owner of the relevant IPR. The terms of the agreement with the vendor will not control such an arrangement. The four corners clause will not apply either and the CA may find itself in a quagmire of licensor terms and conditions of the nature it was trying to avoid through that clause.

1.2 Core buyer responsibilities

Enumerating the core responsibilities of the CA is beneficial, as it delineates a clear boundary around those duties. By meticulously detailing the obligations that the CA will undertake and incorporating language that unequivocally characterises that list as restrictive, CAs can prevent disputes during execution regarding responsibility allocation.

This is specifically important in complex arrangements where a high interdependency exists between the parties. Such interdependency should never be allowed to serve as an excuse for non-performance. If the CA is responsible for performing a particular action, then the contract should provide for such action to be triggered by a written request from the vendor.

1.3 Core supplier responsibilities

Similar to listing the obligations of the CAs, it makes sense to list the obligations of the supplier. The list of supplier obligations should, however, be of a different nature. Where a technology-related contract usually is aimed at a result to be achieved (i.e. a solution to be developed and implemented), the list of obligations cannot be limitative. It is up to the supplier to achieve a result by performing the duties as may be set out in a list, as well as everything implied by the overall duty to deliver the desired result.

Therefore, the list of supplier obligations is intended to ensure that certain specific duties are not overlooked rather than offering a comprehensive overview.

1.4 Invoicing & payment

When defining the invoicing and payment conditions, several topics require the CA's attention.

First, the clause must clearly define when the supplier is entitled to invoice the CA. The question is, what triggers the right to invoice? Is it the mere passing of time, e.g. in a licence agreement, or is it the acceptance by the CA of work performed? Links to contract language on acceptance may be incorporated here to ensure parties know the conditions for an invoice to be submitted and paid.

In the event of a license or subscription requiring a repetitive payment of fees, it is important to note whether payments will be made before or after the covered period. Especially where such payments cover an annuity, the difference between the two may be material.

The clause should define the information to be contained in the invoice and the format used, e.g. defining whether an electronic invoicing is to be used.

The clause will define a payment term and may include a term for verification, i.e. a term for the CA to assess the correctness of the invoice.

The clause may also provide the conditions for price revisions, the formula to be applied, and the price references to be used in the formula.

Finally, it is essential to specify in the contract that all invoicing shall be conducted electronically, in compliance with PEPPOL standards 1 , as this is mandatory for public contracts.

1.5 Intellectual Property Rights (IPR)

There is hardly any contractual relationship that addresses technology, which does not, to some extent, involve an allocation of rights to intellectual property. IPR is the major element of the economic relationship in technology contracts.

Given the manifold of relations about intellectual property, it is strongly advised to address the matter expressly.

In doing so, CAs should seek to reserve sufficient rights for the purposes pursued while refraining from excessive claims that bring no real added value but increase cost and/or reduce the willingness of vendors to offer. This section is intended to provide some guidance.

Defining the IPR framework

Whenever a contractual relationship will involve (i) the development of hard- and/or software, (ii) the use of software and/or data, or (iii) access to XaaS services aimed at storage and/or creation of data, arrangements relating to intellectual property are required. In editing such contractual arrangements, it is common practice to differentiate between “background information” and “foreground information”, whereby background information is the information that pre-exists the execution of the contract and/or is developed independently from the contract. In contrast, foreground information is the information that results from the execution of the contract. A further distinction is made based on origin: information can originate with the vendor, with the CA or with both 2 .

Regarding background information, the default arrangement is for ownership to remain with the original owner, i.e. vendor background information remains in the ownership of the vendor, and CA-owned background information remains in the ownership of the CA. Where there is a need for the CA to use the vendor's background information, such use will involve right-of-use arrangements.

Ownership of foreground information is to be established in the contract, as this involves information created as a result of the performance of the contract.

Contractual arrangements regarding foreground information will entail the allocation of ownership rights and the granting of rights of use as required for the purposes of the contract.

Drafting the appropriate position on IPR

For the CA, it is key to ensure that the contract allocates rights to the CA (and, where applicable, to users, other contractors, etc) that allow all uses that were intended in issuing the tender. At the same time, the CA should refrain from asking for more than needed, as the procurement of rights that are not required and never will be of any use is too expensive.

A straightforward IPR clause could be structured as follows:

• Retention of IPR ownership to background information by the initial owner
• Allocation of IPR ownership to foreground information
• Granting of necessary rights of use

While the logic of dealing with the matter along these lines is appealing, one should bear in mind that the subject matter of the contract may involve the development and implementation of an application, where the latter is a combination of vendor and/or third-party background information, pasted together with vendor created foreground information. A typical IPR clause in such a setting may encompass the allocation of ownership to the foreground information developed under the terms of the agreement, combined with a right to use regarding the vendor background information that allows the CA the full and unencumbered use of the application as developed.

Vendors will be reluctant to cede ownership of background information to a CA, as this background information will typically consist of building blocks and bits of code that they have used before and wish to reuse in other projects. Therefore, a CA seeking to obtain full ownership of the development may find vendors unwilling to contract or do so only at a higher price. Unless the CA seeks to commercialise the solution developed by the vendor and procured under the contract, full ownership of the code is usually not required.

As for the rights of use to be granted, CAs need to consider what they want to do with it.

If a third party is to use the application, then a right for the CA to sublicense such right to use the application should be included. This is also important for future support and maintenance of the application. Especially in a public procurement setting, a tender for continued support should not be constrained by third parties not having the right to step in and support.
“Use” should be clear in terms of the limitations imposed. Is there a limitation on the number of users? The amount of data? Such limitations are uncommon if the agreement involves a custom development, but the CA would better make sure.

The use of platform applications

A particular situation occurs when the solution offered is built around a platform application, i.e. a pre-built software environment, usually cloud-based, that provides functionalities that can be integrated by a vendor as part of a customised solution.

The use of these platform applications requires a separate time-limited license to use the applications that are embedded in the customised solution. That means that the CA will not only pay for the development and a perpetual right to use it but also, on top of that, will have to pay regular license fees.

There are clear advantages to the use of such platform applications. The development time is usually shorter, and the upfront cost of development is lower. The power behind these platform applications and the myriads of functionalities they offer are enormous.

The disadvantages are equally clear, however, and when allowing platform applications to be part of the desired solution, the CA should be vigilant.

First of all, there is the matter of the standard terms that apply to the use of these applications, the contents and variability of which are very hard to reconcile with public procurement laws. A solution to this is to leave the contractual relationship regarding the platform application with the vendor, the latter thus being an intermediary between the CA and the platform application vendor, shielding the CA from the license terms of the latter and granting a subsequent right to use the platform application as embedded in the developed solution.

Secondly, there is the exposure to a cost that is difficult to control as license fees, support costs, etc., may increase over time, while new releases of the platform application will not only offer more and better functionality but will require adaptation of the customised software that the vendor built around that platform application. Addressing this disadvantage is a matter beyond this guideline as it involves fundamental choices regarding the nature of the solution envisaged and the acceptable level of platform application-specific customisation.

Thirdly, it is evident that building a solution around a platform application enhances the risk of vendor lock-in, as it creates such lock-in at a secondary level. Not only should the CA ensure that the vendor is not the only one capable of supporting and maintaining the solution, but it should also seek to reduce the dependency on the chosen platform application. Measures to address the latter should be in the delivery part of the contract.

1.6 Adherence to standards and industry practices & compatibility

The CA must ensure that the vendor complies with industry standards and industry practices. Apart from such requirements often being necessary to ensure that the desired solution will effectively work and interact with the environment, it is a keystone in avoiding a vendor lock-in. While adherence does not guarantee a way out of lock-in, non-adherence will most likely secure such lock-in for the vendor.

It is imperative that the CA does its homework here and ensures that the list of standards the supplier and the solution must comply with is complete and clear.

Compatibility is a requirement to ensure that the solution will interact with the digital environment already installed, read and write data in the chosen format, and – by looking at compatibility with existing, widely used applications – contribute to the portability of the resulting data.

1.5 Liability

General

No contractual clause has been the subject of more debate and negotiation than the liability clause. Terms like fault and liability carry a moral connotation that sometimes seems to stand in the way of a rational allocation of risk, which is precisely what it is.

Rather than a liability clause, it is actually a limitation of liability clause. Contractual liability is laid down in contract laws across the EU and needs no clause for it to apply to a contract. However, it is common for parties to agree on a limitation of that liability, both in terms of scope and compensation due.

While it is good practice for a limitation of liability clause to work two ways, the party seemingly most benefitting from it is the vendor, as in most cases, the duties of the CA are little more than paying the invoices.

The rationale for the vendor is to limit the exposure to liability to foreseeable, limited amounts, which assurance policies can easily cover.

The rationale for the CA is to know to what extent risk is absorbed by the vendor and at what (extra) cost, to understand what risk remains with the CA and to avoid what would boil down to having the same risk insured twice.

Limitation of scope

What is the scope of the damage to be compensated according to law? International contracting has led to a practice of expressly restricting the liability under the terms of a contract to direct damage, excluding a myriad of “other” damages that originate predominantly from US case law, some of which are simply meaningless in a civil law context.

The core concept is, however, clear: parties agree that they shall only be liable towards one another under the contract for damage that is a direct consequence of the fault or omission committed.

An example may clarify this. If a communication system is installed to switch off transformers in the event of an electricity network failure and such failure is attributable to the vendor having installed that communication system, he will be liable for the direct damage, which may consist of a transformer having exploded. That damage is a direct consequence and thus foreseeable for that vendor. With a clause excluding indirect damage (assuming that the applicable law would foresee a liability for indirect damage), the vendor will not be liable for the ensuing production loss of a nearby factory caused by the sustained loss of power.

The latter damage is a matter between the electricity company and the factory, and the allocation will be the subject matter of the contract between those two entities.

Limitation of amount

Limitation of liability clauses will not only limit the scope of damage, but also the amount of compensation to be paid. The rationale behind that is to align the risk to be covered with the value of the contract.

Suppose we take the previous example and imagine the communication system vendor having a contract worth a hundred thousand Euros per year. If the risk to be covered were to be the value of, e.g. transformers that might blow up in the event of a system failure, then the corresponding assurance premium could be prohibitively high, thereby making the contract economically non-viable.

Reducing the exposure means lowering the assurance premium for the vendor. As for the electricity company, it should have assurance coverage for its network anyhow, so the part of the risk-shifting towards it by limiting the compensation that can be obtained from the vendor is likely to be insured for a lesser increase of the assurance premium.

Limitations of the compensation payable come in various shapes and sizes. In its simplest format, it consists in a clause stating that liability under the contract will be capped at an amount X. Variants may cap liability at an amount per annum or combine a limit per annum and a total liability cap for the contract. Amounts may be fixed or set forth as a percentage of the amounts invoiced and paid 3 .

Boundaries to the limitations

Most liability clauses will exclude the applicability of the limitations they offer in the cases of gross negligence or wilful misconduct. More than reconnecting with the moral aspect of the liability for fault, it is a necessary statement for the clause as such to survive, as a clause that limits liability for gross negligence or wilful misconduct will, in many jurisdictions, be struck with nullity.

For clarity, it is advised to expressly exclude the hold harmless clause from the limitation of liability. Refer to Chapter 1.9 for more information on the hold harmless clause.

Capturing the limitation of liability in the tender documents

The advantage of being a CA in a public procurement process is holding the pen and providing for the applicable contractual terms and conditions.

It may seem counterintuitive for a CA to provide for a limitation of liability clause in a tender document, but there are plenty of good reasons to do so. Most importantly, participants in a tendering process will calculate their prices based on what the tender documents provide. If the liability risk is not contained in those documents, they will include a corresponding premium in their pricing.

Drafting the clause in the tender documents provides for a clear position from the start and may reduce the time spent negotiating as well as reducing cost. Moreover, where specific concerns exist, those may find adequate translation in the liability clause thus provided.

1.8 Assurance

The corollary to having a liability clause that considers the assurance of the liability risk is an assurance clause that requires the vendor to take out the necessary assurance commensurate to that risk.

The assurance clause will typically put the obligation upon the vendor to have adequate assurance in place covering a number of risks which are not necessarily related to the contractual liability towards the CA119, and may require the vendor to provide evidence of such assurance by presenting the policies to the CA upon coming into force of the contract and/or on an annual basis.

1.9 Hold harmless

The hold harmless clause protects the parties from the effects of an infringement of (amongst others) the IPR of third parties.

Looking at it from a CA perspective, the hold harmless clause is there to ensure the undisturbed use of the solution delivered by the vendor. Should a third party claim that such use infringes its IPR, then the clause will provide for the vendor to step in and take up the defence of the CA. Where such defence fails, or if the vendor chooses to settle, the clause will provide the vendor with a duty to procure such undisturbed use by the CA. If all of the above fails, the vendor will be obligated to remedy the infringement and provide a solution to the CA that does not infringe the third-party IPR.

From the vendor's perspective, the clause reciprocates the obligations listed above when the infringement is caused by unintended use by the CA or use in an undisclosed combination, which makes that use infringing.

The clause does not come with a cap or a limit and it is important to safeguard this, e.g. by explicitly carving it out of any limitation or cap foreseen in the contract.

The above focuses on the hold harmless regarding IPR, but as indicated above, there are other fields of application. A hold harmless for, e.g. tax debts may, in certain contracts, be relevant. It is important to ensure that the hold harmless clause is written so that it cannot be interpreted as implicitly voiding any hold harmless provisions provided by law.

Application of the hold harmless clause can be problematic since it requires the party invoking the clause to rely on the other party properly handling the claim, seeking adequate legal support and – if necessary – conducting effective negotiations towards such third-party license as may be required. Taking an approach that offers the CA more control may be worthwhile, especially where a technical workaround is likely difficult to achieve or the solution is critical.

1.10 Modifications

Within the boundaries of what is allowed under public procurement regulations, there is always the possibility that parties experience a need to amend the terms of the contract to achieve the desired outcome.

Such changes can roughly be divided into two categories, i.e. changes to the technical specifications on the one hand and changes to the contract terms on the other.

Adapting technical specifications during the performance of the contract is quite common as it is in the process of creating a deliverable in which flaws in the initial concept occur, or better approaches to achieve the desired outcome become apparent. To address these – often frequent changes, it makes sense to foresee a change process aimed at a decision embedded in the governance proceedings (infra). Such a process will identify how a change request is created and channelled through the relevant governance bodies towards a mutually agreed approval.

Amending the contract term should be a far less frequent occurrence and will require a formal agreement at the appropriately mandated managerial level following the negotiation of the envisaged change.

Initiating the amendment may happen through a process similar to the one above, but if and when the parties agree to the amendment, it will only come into effect upon execution of a formal amendment.

As pointed out, public procurement laws will restrict the playing field for amending the contract. The overriding concern in public procurement is the preservation of a level playing field amongst competitors and allowing the CA to walk away from requirements formerly identified as minimal requirements or terms that have a crucial impact on the contractual relationship would open the door to practices where a post-award softening of terms gives an unfair advantage to the participant that was in a position to anticipate such changes 4 .

1.11 Expiry – Termination

Governs the end of the contract, either by reaching its term or true termination by mutual consent or for cause by one of the parties, detailing the conditions for such early termination and listing the parties' duties in each end-of-contract scenario.

1.12 Dispute resolution

Dispute resolution clauses can encompass three elements:

• An obligation upon the parties to seek reconciliation before going to court
• A choice of law
• A choice of competent forum to give judgment

In private contracts, this clause tends to be used by parties for forum shopping and leads to debate as to which exotic venue will be the scene for a potential dispute resolution, including it in tender documents, which serves to provide clarity.

Reconciliation

It is not unusual for a dispute resolution clause to include an obligation upon the parties to try and settle a dispute through bona fide discussions between them prior to engaging in legal proceedings. Such a clause may be limited to establishing the principle without much ado about the process towards reaching an amicable settlement. However, it makes sense to provide a minimum process, especially in high-value, complex technology contracts. This may include a definition of the communication triggering such amicable settlement discussions, terms for reply, agreed duration of such discussions, etc.

A useful element in defining the process towards achieving a settlement lies in the use of the escalation mechanisms as laid down in the governance of the contract (infra). As the dispute escalates up the management chains, it may be looked upon from a broader perspective, making it easier to arrive at a mutually agreeable settlement.

Choice of law - competent court

In stating clearly in the tender documents that the laws of the state in which the CA operates shall apply, the CA takes away any ambiguity that might exist regarding the matter, even when dealing with foreign entities.

Similarly, stating that the court that is competent within the jurisdiction in which the CA operates shall be the competent forum to render judgment in case of a dispute being brought to court and settle the matter, irrespective of the jurisdiction where the vendor might be established.

1.13 Security

Security requirements in technology contracts are required to address compliance with the legal framework regarding the matter 5 .

Generally, a CA must include terms regarding authentication and access control, data protection, system integrity, and operational and supply chain security that guarantee a level of security commensurate with the application's criticality and its use.

Security-by-design should be the standard approach, and the contract should contain provisions that allow the auditing, inspection, and testing of security measures.

Security should be embedded in the SLAs and KPIs so that performance in this subject matter can be closely monitored.

1.14 GDPR

Implementing the General Data Protection Regulation (EU) 2016/679 adds an extra dimension to the overall security requirements if a solution is to be used for the processing of personal data.

While this guideline is not the place to elaborate on the many implications of the GCPR and the way it may impact a CA, there are a number of topics that need to be addressed in the tender documents to ensure that a lawful operation of the envisaged solution is possible to start with.

Privacy by design and by default

Needless to say, the obligation to implement technical and organisational measures ensuring data protection principles must be passed on to the developer, as such technical measures will have to be implemented in the solution.

Attention should be drawn here to the DIY approach CAs might face when procuring a platform application-based solution. What that means is that the platform application provider may offer a solution that can be configured in such a way that the solution operates in a compliant way, leaving it to the vendor – and quite often to the CA – to figure out and apply the correct settings for achieving that result. Applying these settings or adding the available means of protection offered may then materially impact the use, the latter most often not guaranteed by the platform application provider.

Therefore, achieving privacy by design and by default is not simply a matter of careful contractualising of this topic but requires close cooperation with technical experts to align contract language and technical requirements towards compliance.

Encryption and access control

A solution intended to employ the processing of personal data will require robust encryption protocols for data in transit and at rest, along with role-based access controls. This will have to be described in the requirements and will again need collaboration with technical experts to complement the contractual provisions.

International data transfers

A specific topic that requires attention lies with the restrictions that GDPR imposes on international data transfers, which are there to guarantee that personal data does not transfer towards jurisdictions that offer an inferior level of protection.

Using a cloud-based solution may imply the international transfer of (personal) data, as “the cloud” is merely an abstraction of the actual physical location of servers. If the servers of the cloud provider are outside the EEA, a CA should check if there exists an adequacy decision by the European Commission which confirms that data protection in that country is essentially equivalent to the level of protection offered by the application of the GDPR. Even if the servers are physically located within the EEA but are under the control of a multinational entity grouping entities both inside and outside the EEA, the risk of an international transfer is present, and precautions need to be taken 6 .

International data transfers may also occur within the performance of support and maintenance of the solution. Especially where second-level support may require the precise reconstruction of the situation in which an incident occurred to find the root cause, such reconstruction may employ an exposure to (personal) data being processed as the incident occurred. If such a situation cannot be excluded, it may affect the nature of the services included in the contract. Typically, a “follow-the-sun” type of support might be problematic, as it would require operators based on various continents to access the data.

Data Processor Agreement

If the vendor, at any stage of the performance of the contract, is to process personal data, a Data Processing Agreement (DPA) must be included as an annex to the contract123.

1.15 Specifications of service/product

The contract will need to specify what the CA seeks to procure. It is important to define the specifications that the service or product needs to meet. Typically, in technology contracts, this clause will refer to annexes listing all of the requirements (cf. infra)

2. Contractualising performance in delivery

2.1 Software development requirements

The following sections are key in managing the performance of the contract by the supplier.

Software development requirements in a technology contract define the expectations, responsibilities, and deliverables for the CA and the supplier. Typically, these requirements will include a detailed description of the scope of work, a description of the functionality and features of the desired software solution, and the specific technologies to be used.

The software development requirements will include performance, compatibility, and security.

These requirements may require more detail if a waterfall type of development is preferred, while an agile development path will be more high-level.

2.2 Quality of Service

A Quality of Service (QoS) annex will outline the performance standards a supplier must meet and the metrics involved in measuring that performance. It ensures alignment of expectations between the supplier and the CA.

2.3 Service Delivery Management

A Service Delivery Management Document reflects the processes, governance, and oversight necessary to ensure that services outlined in a service contract are delivered effectively and consistently. It establishes management practices to monitor, evaluate, and improve service delivery. Typical elements in defining service delivery are incident and problem management.

2.4 Acceptance procedure

Whatever deliverable the contracting authority expects from the supplier will have to be accepted. With regard to a technical product, one should foresee documentation that describes the process, such as determining the sort of testing that acceptance will require, the process of getting the supplier, the CA and – if needed – some technical experts together for the testing, the different stages (provisional acceptance – final acceptance), the process if testing fails and the consequences of various outcomes.

2.4 Governance

Any technology agreement that requires a prolonged cooperation between a CA and a supplier, will benefit from adding an annex that defines a governance structure and rules of engagement for the management of that prolonged relationship.

Traditionally, three levels of governance should be foreseen, i.e. operational, tactical and strategic, where the operational level will typically deal with the day-to-day management, potentially with more than one governance body at this level to allow attention to operational detail. The tactical level will address topics at a project or programme level, amongst others, the periodical review of SLAs and KPIs, change requests and escalations from the operational level. The strategic level typically will bring together a management level above the project/programme management level and will, at a relatively low frequency, come together to discuss strategic topics related to the project or programme, as well as escalations from the tactical level.

Having this sort of structure in place allows the parties to discuss matters and escalate issues within the boundaries of the relationship.

2.6 SLA/KPI

A supplier's performance in a services contract is usually measured through SLAs and/or KPIs. If there is an extended service aspect to the envisaged contract, adding SLAs/KPIs will allow the CA to assess whether the performance of the supplier is according to the contractual requirements.
SLAs specify the minimum acceptable standards for service performance. In comparison, KPIs are measurable metrics used to evaluate the effectiveness and efficiency of the service delivery. The document can list any number of either SLAs or KPIs and have the performance reviewed through the established governance process. Penalties can be applied with reference to SLAs and/or KPIs.

2.7 Exit plan / Transferability

Providing for an exit plan as part of the contractual arrangements is a key precaution against vendor lock-in. The plan should be available in a skeleton sort of way at the outset. The contract should require the supplier to update the exit plan throughout the contract lifetime, such that at the expiry of the contract, there is a plan, with roles and responsibilities determining what the exit should look like, what obligations remain with the supplier in a transition phase and what deliverables, in what format need to be made available to the CA and/or the next service provider. Control over the exit plan should be covered in the Governance.

• 1https://peppol.org/
• 2The latter situation is highly theoretical insofar background information is concerned, and this hypothetical possibility will not be addressed in these guidelines. Insofar the joint ownership would apply to foreground information, the situation is more realistic.
• 3Contracting authorities should be careful in accepting this sort of limit and define a minimum cap, so as to avoid being left empty handed if damage would occur early in the contract term.
• 4Reference to specific provisions / cases
• 5Aside from the GDPR, Directive (EU) 2016/1148 (NIS Directive), Cybersecurity Act (Regulation (EU) 2019/881), eIDAS Regulation (EU 910/2014) and the AI Act (Regulation (EU) 2024/1689) may be relevant, as well as national regulation.
• 6Should the use of that particular cloud service would imply a transfer to a non-EEA country for which no adequacy decision exists, a contracting authority could seek to protect the data through what is called appropriate safeguards, i.e. a variety of mechanisms. Taking into account the way ECJ rulings have evolved since the coming into force of GDPR, it is fair to say that the construction of such “appropriate safeguards” is of a specialist nature that goes beyond the scope of these guidelines and indeed beyond the contractualisation of the relationship with the technology vendor. The adequacy of the protection obtained through such measures, moreover, may be affected by future rulings.