20 / 07 / 2021
Standard IT agreement: A jungle without LAN cables
If you work in the IT industry or buy services from it, you have probably come into contact with a standard IT agreement. Either because you yourself have found an agreement that is somewhat suitable for what you are to deliver, or because a customer has asked you to sign. These are agreements that appear similar and are built around the same form. Your challenge is to know if it is the right agreement for you and your customer, and what really should be included in such an agreement. Is a standard IT deal really good enough? We will go through three different types of agreement. What is typically included in these, which clauses should you make sure to include in contract negotiations and how can you make the standard agreement better.
What is a standard IT agreement?
Standard agreements for IT are intended to suit many different types of deliveries and services, without those who need them having to reinvent the wheel every time. The intention is good. IT suppliers and their customers can get started with what they are going to produce or deliver, without spending time making new agreements about what has been agreed between parties so many times before. Nevertheless, there are three important challenges with standard agreements:
- They do not necessarily cover the services well enough.
- The standard agreements fail to keep up with technological development.
- The agreement is under constant pressure to update. What was initially a saving by choosing a "standard", can in reality create a continuous need for revision of a long agreement.
We will consider the three most important standard agreements, namely IT operating agreements, maintenance agreements and service agreements. There are many more, but this represents the "big three". The advantages and disadvantages that we explain here are not exhaustive and only shed light on certain problem areas.
IT agreement for operation: When others are responsible for uptime and security
The operating agreement is used when a supplier is to operate all or parts of a customer's IT system. The operating agreement may include, for example, the operation of hardware, operating system and operation-related software, but it may also include the operation of information security, including necessary security updates, troubleshooting, handling of adverse events and user support. There are several suppliers of standard agreements associated with the operation of IT services in Norway, including ICT-Norway, the Norwegian Data Association and Difi (the Directorate for ICT and Public Administration) now renamed the Directorate for Digitization. In order not to offend anyone's work, we should not mention the standards explicitly by name, but rather concentrate on common denominators that are problematic and that one should pay special attention to.
The benefits of a standard agreement for IT operations
The service level is determined in additional appendices
The biggest advantage of the operating agreements is that these can be expanded in the appendices attached to the standard agreements. This will basically result in you agreeing away from the wording of the individual clauses, and getting a more adapted agreement for the service you actually undertake to provide. Many of these standards are governed by an SLA (Service Level Agreement). This means that a supplementary agreement is entered into in the form of vouchers that govern the level of service for the service provided. For example, clauses that deal with response time in the event of errors and uptime.
The supplier decides when to upgrade
Most operating agreements give the supplier the right to decide when upgrades will occur. This can be considered both an advantage and a disadvantage, depending on which side of the table one is sitting on. For the customer, this can be unfortunate if the update means that certain functions disappear from the service and therefore does not create predictability. For the supplier, on the other hand, this will be positive, especially with regard to cases where the supplier also uses deliveries from third parties, such as cloud services. If the supplier has the right to make updates when needed, it means that third parties can also do this, without the customer being able to protest.
Limits the customer's opportunity for change
Several of the standards limit the possibility of changes on the part of the customer. This is also to be regarded as both an advantage and a disadvantage depending on whether you are a supplier or a customer. For the customer, this could be considered unfortunate as the customer does not necessarily have the opportunity to instruct the supplier to make changes. For the supplier, this will be considered an advantage because a change may mean that the supplier's service must be changed extensively, and the supplier's other customers will also have their service delivery changed. In addition, this could mean that the supplier must develop N number of versions of the same platform for all its customers. This would fall on its own unreasonableness if this were not regulated.
The problems with standard IT agreement for operation
What is the advantage and disadvantage, usually depends on which side of the table you are sitting on. And it can be said with certainty that a completely fair deal is rarely the case. Here are the three most important issues with standard agreements for IT operations.
Failure to regulate liability in connection with third parties can create conflict
There is a general lack of regulation of third-party deliveries in standard agreements for IT operations. Especially of cloud services as part of the operational delivery. This means, for example, that the supplier uses cloud services together with in-house developed operational services. As long as everything works as it should, this is not problematic. The problem arises, of course, when things go wrong. For example, when the cloud service provider updates and this results in either downtime or lack of access for the customer. without the agreement saying anything about the relationship of responsibility between customer and supplier. when a cloud service is involved as well. If this is not regulated in the agreement, it in reality entails a disclaimer. For who is to blame for deficiencies or downtime towards the customer when it is a third party that triggers the problem?
Omitting this definition could create unnecessary conflict and problems between you as a supplier and your customer. Such a clause must be precise. For example, it is not sufficient to write that "the supplier's liability is limited to following up the agreement with the third party supplier, including information security". Nor: "the customer accepts the delimitation of the Supplier's responsibility for standard third-party deliveries that are included as part of the operating service, but with which the Supplier has entered into the agreement". The reason for this is that the customer is also bound to the possible cloud service provider, and thus this can be interpreted as meaning that no consent from the customer is required for such a delimitation of the supplier's responsibility to be present already. For the same reason, questions may arise as to whether the service provider has entered into an agreement with the third-party provider (the cloud service) when the customer in many cases also enters into this agreement, and therefore becomes liable. There may also be ambiguities, also related to information security, regarding who is to blame for a possible breach of contract. What may make sense is to include a clear demarcation of the supplier's responsibility, which borders on circumstances due to the customer and results in a lack of service delivery.
It has been agreed that you cannot change the IT agreement
It is a recurring problem that several of the standard agreements in their original form cannot be changed, either without it having any intellectual property effects or that the organizations impose on the customer a duty not to make changes in the sense of contract law. In practice, this means that:
- The agreement may be unfair to one party.
- That the agreement is not sufficiently comprehensive for the service
- That the agreement does not regulate necessary rights and obligations.
Several of the IT agreements have included standard appendices that allow changes to be made to the general wording. However, these changes cannot be made in the wording of the main agreement and must be included in such an appendix as mentioned. This can be quite impractical, especially if there are many changes that need to be made and you end up rewriting the entire agreement in one document. Then the utility value of the agreement disappears.
IT agreement for maintenance: When the server is no longer in the basement
The maintenance agreement shall be used when purchasing maintenance services. The agreements usually regulate normal maintenance and troubleshooting of the customer's IT system. In addition, it often also includes preventive maintenance, replacement of parts, patches and installation of new versions, as well as training / user support and documentation. The agreements also regulate ongoing maintenance, monitoring of IT systems, extension of licenses, etc.
What is the benefit of choosing standard maintenance agreements?
The benefits of using a standard IT agreement for maintenance are the same as for operation. You get an agreement that covers a lot and can be expanded with additional attachments. This will mean that clearer requirements for the delivery are defined and the parties are given predictable rights and obligations according to the agreement.
Is there a need for maintenance agreements today?
The short answer is yes. But with a fairly large reservation and in a somewhat different form. The traditional maintenance agreement mainly required "on-premise" solutions for the customer, popularly referred to as "servers in the basement".
In today's market, more and more customers have switched to cloud-based solutions and this means that the traditional maintenance agreement is being replaced by an SLA. An SLA will essentially regulate the same conditions as a maintenance agreement would do and to a greater extent.
In addition, cloud-based solutions will mean that the need for a maintenance agreement will be less relevant as the cloud services have already implemented maintenance upon their delivery. The third party has mao. already promised to keep the lights on. This can involve a "double maintenance" and potentially create conflict. Either because the service is completely unnecessary or because the maintenance agreements have conflicting premises.
IT agreement for services: Service agreements as a service
The category "service agreements" can be quite extensive and include both the purchase of ongoing services, development and adaptation agreements, Agile agreements (flexible agreements), purchase agreements and ordering system. Purchases of ongoing services are usually offered to a very large extent by customers. In order to be able to offer services to such an extent, cloud services are usually associated.
In the cloud there is everything as a service - PaaS, SaaS and laaS
Cloud services are divided into the following three models:
- Platform as a service (PaaS)
This means that the customer uses applications developed for him / her by the customer in the supplier's cloud infrastructure by using programming languages and tools supported by the supplier. The customer has control over their own applications, but does not have control over networks, servers, operating systems or storage options. - Software as a service (SaaS)
This is a model for delivery over a network where the customer uses the supplier's application (s) on a cloud infrastructure. The customer basically has no control over either applications, networks, servers, operating systems or storage options. - Infrastructure as a service (IaaS)
This applies to the delivery of data infrastructure as a service over a network. The customer has control over relevant applications, servers, operating systems and storage options, as well as in some cases certain elements of the network (for example on the firewall side).
A cloud is not just a cloud, but divided
To regulate conditions around a cloud service with an IT agreement, one must be aware that here too there are divisions that make things complicated. Cloud services are divided into delivery models as follows:
- Public cloud: Here the cloud services are made available by the supplier to all customers.
- Private accessible cloud (private cloud): Here the cloud services are only made available to the companies for which the cloud services are to apply. The environment / environments from which the cloud service is delivered will typically be dedicated to the individual customer or a defined customer group. This scheme allows for a greater degree of specific customer adaptations than is the case with the model for publicly available clouds.
Benefits of using cloud services.
From the cloud you can make your service delivery available anywhere and is not limited by server rooms and the like. There will therefore be fewer restrictions when it comes to physical restrictions such as space and location. Another important benefit is scaling. In reality, this means that you only pay for the use that you use. In addition, it is easier to connect with new businesses and implement new IT tools. There is also no need to invest in new IT equipment in the form of server rooms and hardware associated with data computing.
Standard IT agreements for services are static
In the main, standard agreements for ongoing services are far too static. This is mainly related to the use of terms such as "throughout the period" and "if agreed functionality is not present". The purpose of cloud services is the dynamic aspect, such as scaling after use as well as the possibility of constant updating. By using terms such as the above, the IT agreement will not contribute to a dynamic service, but rather to a static one. In addition, it will actually be difficult for a supplier to maintain the same "agreed ["] functionality "" throughout the period ". The reason for this will be that the provider is dependent on the cloud service to deliver its service. This will in reality mean that the functionality will control the cloud service in addition to the supplier.
The supplier is blamed for what the customer has done
In addition, several of the cloud services reserve the right to also bind the supplier's customer and its end users. This means, among other things, that the customer must follow the guidelines for using the cloud service. If these are not followed, the cloud service reserves the right to suspend access to the cloud service. In practice, this will mean that the supplier is in default towards the customer in the agreement with this, while in reality it is the customer himself who is responsible for the default. The standard agreements do not regulate this further and thus problems regarding functionality may arise. Furthermore, uncertainty may arise regarding both privacy and other information security when using standard agreements where the cloud service is implemented. This is because the cloud service has its own policies and guidelines for information security and privacy, and several of the cloud services store data in third countries. It is thus important that one's own security policy and data processor agreement reflect these and one takes the necessary reservations.
What is the problem with standard agreements?
As mentioned in the introduction, the biggest problem is that we are facing a standardized agreement that will capture as many services as possible. This is problematic due to the fact that technological development takes place on a large scale and the agreements will by their own nature not be able to "keep up" with the development.
Standard appointments are left in the server room in the basement
Many of the standard agreements are often reserved for a technology that was relevant in the 90s, where companies had a server room in the basement. There are fewer and fewer of these and therefore more and more questions arise regarding the relevance of such agreements. Due to stricter requirements for information security and privacy, problems arise if these agreements are in line with current regulations. Although both tailor-made agreements and standard agreements cost money, everyone will benefit more from having tailor-made agreements that can regulate the parties' rights and obligations.
John E. Nilsen
Associate
