On 10 September 2022, the new Arbit (General Government Conditions of IT Procurement) terms and conditions came into force. These Arbit 2022 replace the earlier version from 2018. These terms and conditions are used by the central government, such as ministries, independent administrative bodies and regulators as well as other public authorities for the procurement of IT services and IT products. The development and management of the Arbit terms and conditions are in the hands of the interdepartmental Committee on Business Legal Advice (CBA).
Before proceeding with adaptation, the CBA consults the market to assess which topics require review and adaptation. In particular, for this version, the topics Agile, Cloud Services and Artificial Intelligence (AI) are mentioned that should be reflected in the Arbit 2022 and its model agreements. In addition, the Arbit 2022 contains several other changes ranging from the correction of errors and inconsistencies to adaptation to changed laws and regulations.
Besides the general terms and conditions themselves, the Arbit consists of a number of model agreements:
- Model Agreement: this agreement sets out the conditions for individual assignments, such as object, duration, remuneration, acceptance and special conditions.
- Model Framework Agreement: the framework agreement provides a framework under which several contracts can be laid down in further agreements. This framework agreement can be concluded with several parties so that the most suitable candidate for each contract can be chosen via a so-called mini-competition. However, if the maximum value mentioned in the tender documents is reached, the framework agreement is no longer valid and a new call for tenders must be issued.
- Model Further Agreement: this agreement is in force for a specific contract under the framework agreement and sets out the terms and conditions for that specific contract.
- Model Processor Agreement: this processor agreement sets out the conditions under which the IT supplier may process personal data as a processor in a specific assignment. Generic topics such as liability and confidentiality are contained in the model (further) agreement and/or the Arbit 2022.
- Model Credit Institution Guarantee: this agreement is effectively a bank guarantee that the IT supplier must issue in certain cases as a guarantee of performance of its obligations.
- Model Agile Agreement: this agreement is new and contains provisions for the implementation of custom software based on the Agile methodology. This is a new model agreement.
Below, we discuss the main substantive changes in Arbit 2022 and also look at the extent to which the topics of Agile, cloud services and AI are reflected in Arbit 2022.
Quality assurance, information provision and audits
‘Provision of information’ and ‘audits’ have been added to Article 5 Arbit, in addition to quality assurance.
In terms of quality assurance, the IT supplier must be able to demonstrate that its quality management system is in order so that it can comply with the performance of the agreement. This could be in the area of information security, but also the set-up of the management organisation. In practice, this will mean that IT suppliers have the necessary ISO or similar standards.
What is new is that the client has the right to carry out (or have carried out) an audit of the IT supplier and, based on the results of that audit, to propose necessary measures to the IT supplier. The question is why such a right was not included in earlier versions, but we can imagine that this is related to the increasing use of cloud services, where the importance of monitoring security and continuity by or on behalf of the client has further increased.
Processing (personal) data
A new paragraph has been added to Article 18 that deals with the processing of data in general, and therefore not specifically personal data. Use of data provided by the client or generated in the context of an order may only be used by the IT provider for the performance of the service, unless there are legal requirements that allow for a wider use. This article thus anticipates the (upcoming) European regulations such as, for example, the Data Regulation, the Data Governance Regulation and the Open Data Directive, which, in addition to the General Data Protection Regulation, lay down rules for the use of data. However, the article is somewhat at odds with the rationale behind these new (partial draft) regulations, which actually try to expand the use of data by and from the government, where this article actually restricts that use.
The second paragraph of Article 18 has been revamped. In the previous version, it was apparently assumed that an IT supplier processing personal data on instructions always does so as a ‘processor’. This version of Arbit 2022 has moved away from that (because, of course, an IT supplier can also be considered a ‘controller’ in appropriate cases). This paragraph now only reports that the IT supplier will comply with the current regulations for processing personal data when processing personal data, if at all (which is thus broader than the ‘General Data Protection Regulation’ referred to in the previous version).
Information security
Article 19, which was still called ‘security procedures and house rules’ in the 2018 version, has now been changed to ‘security procedures and information security’. The list of definitions indicates what is to be understood by information security (‘the required reliability of information systems in terms of confidentiality, availability and integrity as well as the establishment, maintenance and control of a coherent set of associated measures.’)
Four paragraphs dealing with information security have been added to the article. The IT supplier is expected to ensure a level of information security that can be expected of a reasonably acting and competent IT supplier. The question is what this provision adds to the duty of care the IT supplier already has under the law anyway (other than making the IT supplier even more aware of it).
Furthermore, Article 19 contains additional provisions dealing with the reporting and information obligations surrounding a security breach. It is notable here that the definition of breach does not only cover personal data but includes all types of data. This also seems to already take into account the obligations that will apply under the NIS-2 guidelines for the security of essential services.
Liability
The article dealing with liability changes in an important respect. To the categories of claims to which the IT provider’s limitation of liability does not apply, claims also apply in respect of violations of personal data protection laws and regulations or acting contrary to the lawful instructions of the controller. This includes fines that may be imposed by supervisory authorities.
Since many IT projects involve personal data, this significantly increases the IT supplier’s risk. Question is also why no limitation of liability could apply, legally there is nothing to prevent this (claims by data subjects perhaps excepted).
Exit
A number of paragraphs have been added to the provision on exit in Article 32 Arbit, dealing in particular with the handling of data around an exit. Data should be returned by the IT supplier to the client immediately after the agreement ends or should be destroyed, at the client’s discretion. The client must also ensure (and provide evidence of) that all the client’s data have been removed from the IT supplier’s systems or the systems of its subcontractors. Finally, during a transition to another supplier or a re-transition, the IT supplier must continue to provide inspection or access to the client’s data.
These changes seem particularly intended for those cases where an IT supplier provides cloud services. After all, in that case a lot of data is stored in systems of the IT suppliers or subcontractors (think Hosting parties) that the IT supplier engages for that purpose. These provisions should provide the client with some certainty and control over its data in the event of an exit.
However, other forms of control and security over data that are also important for the purchase of cloud services are as yet lacking in Arbit 2022. The escrow in Article 47 Arbit is a classic escrow arrangement for ‘on premise software’ that is of little use in the case of a cloud or SaaS environment. There are no provisions on backup and restore provisions that can certainly prevent or mitigate data loss in the event of a (temporary) system failure.
Compliance Service levels
Finally , new is also that it has been added to Article 76 Arbit that in case of failure to meet the agreed availability, the IT provider is immediately and without notice of default in default. Availability is obviously important for the provision of cloud services. As a client, you want the solution to be available without interruption. However, the definition of availability is curiously worded. Namely, availability is defined as the period when the performance is free of defects, which really seems to be different from the availability of the performance. This is an important point for IT vendors to watch out for in contracting and especially using its own SLA.
The IT supplier’s immediate default if it fails to meet availability levels is also open to question. In many cases, there may well be factors on the client’s side that cause availability levels not to be met (systems used, non-functioning links). The IT supplier should also pay close attention to this when contracting.
Conclusions
As we indicated in the introduction, the amendments to the Arbit aimed in particular to add the topics of Agile, cloud services and Artificial Intelligence to the Arbit terms and conditions.
With regard to agile, this has certainly been achieved with the advent of a separate model agreement for the development of custom software according to the Agile methodology. However, we wonder why the model agreement is limited to that. Agile has become an important form of implementation, but in addition there are other forms of implementation (standard software/cloud environment) that are equally important for the practice. Why not a separate model agreement for implementation in general, where Agile could then have been one of the forms of implementation?
A number of articles have been adapted to make them more suitable for the use of cloud services, think of information security, audit and exit. On a number of topics important for cloud services, however, no adjustment has taken place. One can mention the regulation of escrow, subcontracting, backup and restore and ownership of data. Together with the other topics, these could have been included in a separate regulation under special assignments (besides consultancy, customised development and secondment). A missed opportunity.
We could not find anything about Artificial Intelligence in the Arbit, except an empty annex to the model agreement and the model further agreement.
What certainly has not changed is that Arbit 2022 is still unilaterally in favour of the principal, and provisions have been added that only reinforce that (think of the immediate default in case of unavailability). Therefore, and perhaps even more so than under the previous Arbit 2018 terms, the IT supplier seeking to contract with the central government or any other under Arbit 2022 will have to look critically at these terms.
