Table of contents of the article:
There is a little known aspect for both the customer and the suppliers inherent to the rights that a customer has when, for example, the site is hacked, compromised, offline, or even irretrievably lost.
While for the first three cases, the occurrence is quite frequent based on the type of maintenance, for example, and the type of connectivity, the total loss of the site in an irreparable way is fortunately rather rare, although not impossible as we have for example seen with the sad OVH fire several months ago, which somehow opened and closed just as quickly a debate on what would be the compensation for those millions of users who have lost their sites irretrievably.
Between those who invoked criminal convictions for the CEO, and those who showed improbable exercises in style in the field of law by bringing up the consumer code and the GDPR, in the end it was evident that all unofficial and official efforts were liquidated, postponing to a slow and effective reading and understanding of the contract signed in all parts that did not offer any reimbursement or compensation for damages.
Beyond the speech of OVH which had the sole purpose of introducing an itchy topic, little treated by both customers and suppliers, it is good to say that in this article we will not talk about a supplier or a particular case, but to understand what it is. the logic behind that "arm wrestling" between customer and supplier, of which the first tries at all costs to obtain forms of protection, guarantee and recovery of the greatest possible damage and while the supplier tries in turn to indemnify himself from all civil and criminal liability.
In fact, we are faced with a blame game, where any legal expert would beat the definition just given "blame", which would not find acceptance in any courtroom, but which lends itself well to the introduction of the argument of the responsibilities of Hosting provider as a result of damage to its customer.
What does SLA or Service Level Agreement mean?
I service level agreement (in Italian: service level agreement), in initials SLA, are contractual tools through which service metrics are defined (e.g. quality of service) that must be respected by a service provider (provider) towards its customers / users. In fact, once the contract is stipulated, they take on the meaning of contractual obligations.
A service level commitment (SLC) is a broader and more generalized form of SLA. The two differ because an SLA is two-way and involves two teams. Conversely, an SLC is a one-way obligation that sets out what a group can guarantee its customers at any given time.
Why are SLAs important?
Service providers need SLAs to help them manage customer expectations and define severity levels and circumstances under which they are not responsible for outages or performance issues. Customers can also benefit from SLAs because the contract describes the service performance characteristics, which can be compared with other vendors' SLAs, and establishes the means to resolve service issues.
SLA is typically one of the two fundamental agreements that service providers have with their customers. Many service providers establish a master service contract to establish the general terms and conditions under which they will work with customers.
The SLA is often incorporated by reference into the service provider's primary SLA. Between the two SLAs, the SLA adds greater specificity regarding the services provided and the metrics that will be used to measure their performance. Service commitments define the services included in the service offering.
When IT outsourcing emerged in the late 80s, SLAs evolved as a mechanism for governing those relationships. Service level agreements set expectations for a service provider's performance and establish penalties for failing to achieve goals and, in some cases, bonuses for exceeding them. Since outsourcing projects were often tailored to a particular client, outsourcing SLAs were often drafted to govern and regulate a specific project.
Who needs a service contract?
SLAs are thought to have originated with network service providers, but are now widely used in a wide range of IT-related fields. Some examples of industries that establish SLAs include IT service providers and managed service providers, as well as Internet service providers and cloud computing.
Key components of an SLA
Key components of an SLA include:
Agreement overview. This first section sets out the basics of the agreement, including the parties involved, the start date and a general introduction to the services provided.
Description of the services. The SLA requires detailed descriptions of each service offered, in all possible circumstances, with delivery times included. Service definitions should include how services are provided, whether maintenance service is offered, what are the hours of operation, where dependencies exist, a process scheme, and a list of all technologies and applications used.
Exclusions. Specific services that are not offered should also be clearly defined to avoid confusion and eliminate room for other parties' assumptions.
Performance of service. Performance metrics and performance levels are defined. The customer and the service provider should agree on a list of all metrics they will use to measure the provider's service levels.
Repair. Compensation or payment should be defined if a supplier is unable to adequately meet their SLA.
Stakeholders. It clearly defines the parties involved in the agreement and establishes their responsibilities.
Safety. All the security measures that will be adopted by the service provider are defined. Typically, this includes drafting and consenting to anti-poaching, IT security, and nondisclosure agreements.
Risk management and disaster recovery. Risk management processes and a disaster recovery plan are clearly established and communicated.
Service monitoring and reporting. This section defines the reporting structure, monitoring intervals and stakeholders involved in the agreement.
Periodic review and change processes. The SLA and all established key performance indicators (KPIs) should be reviewed regularly. This process is referred to as the appropriate process for making changes.
Termination process. The SLA should define the circumstances under which the agreement can be terminated or will expire. The notice period for both parties should also be established.
Firm. Finally, all interested parties and authorized participants from both sides must sign the document to demonstrate their approval of every detail and process.
What are the three types of SLAs?
There are three basic types of SLAs: Customer Service Level Agreement, Internal, and Multi-level.
A customer service level agreement is between a service provider and its external customers. It is sometimes called an external service contract.
In a customer-based SLA, the customer and the service provider reach a negotiated agreement on the services that will be provided. For example, a company may negotiate with the IT service provider who manages its Accounts Payable system to detail its specific relationships and expectations.
A customer service level agreement includes:
- the exact details of the service provided by the customer;
- provisions of the availability of the service;
- standards for each level of service;
- the responsibilities of each party;
- escalation procedures; And
- terms for cancellation.
An internal SLA is between an organization and its internal customer - it could be another organization, department, or site.
This means that while a company may have an open SLA with each of its customers, it may also have a separate SLA between its marketing and sales departments.
For example, a company's sales department has nearly € 10.000 in sales each month, with each sale worth € 500. If the sales team's average close rate is 20%, sales know that marketing needs to provide at least 100 qualified leads every month.
Therefore, the head of the marketing department of the organization can work with the head of the sales department on an SLA that stipulates that the marketing department will send 100 qualified leads to the sales manager by a specific date each month.
This service level agreement could include four weekly status reports each month sent by marketing to sales to ensure that the leads the sales team is getting will enable them to meet their monthly sales goal.
A multi-level SLA will divide the agreement into various levels specific to a range of customers using the service. For example, a software-as-a-service (SaaS) vendor might offer basic services and support to all customers using a product, but might also offer different price ranges when purchasing the product that result in different service levels. These different levels of service will be layered into the multilevel SLA.
Examples of SLAs
A specific example of an SLA is a data center service level agreement. This SLA will include:
- An uptime guarantee indicating the percentage of time the system is available. Anything less than 99,99% uptime should be considered acceptable for modern enterprise-grade data centers.
- A definition of suitable environmental conditions. This should include supervision and maintenance practices as well as heating and cooling standards.
- The promise of technical support. Customers need to be confident that data center personnel will respond quickly and effectively to any problem and be available at any time to resolve it.
- Detailed safety precautions that will keep the customer's assets safe. This could include cybersecurity measures that protect against cyber attacks, as well as physical security measures that restrict access to the data center to authorized personnel. Physical security features might include authenticationtwo-factor , gated entries, cameras and biometric authentication.
Another specific example of an SLA is an ISP's SLA. This SLA will include an uptime guarantee, but will also define packet delivery expectations and latency. Packet delivery refers to the percentage of data packets received out of the total number of data packets sent. Latency is the amount of time it takes for a packet to travel between client and server.
How to validate the SLA levels
Verification of the vendor's service delivery levels is required for the application of a service contract. If the SLA is not properly fulfilled, the customer may be able to claim the compensation agreed in the contract.
Most service providers make their service level statistics available through an online portal. This allows customers to monitor whether the correct level of service is being maintained. If they find that it is not, the portal also allows customers to see if they are entitled to compensation.
These systems and processes are often controlled by specialized third party companies. If so, the third party must also be included in the SLA negotiations. This will provide them with clarity on the service levels that should be monitored and explanations on how to track them down.
There are also tools that automate the capture and display of service-level performance data.
SLA and indemnity clauses
Indemnification is a contractual obligation assumed by one party - indemnification - to compensate for damages, losses and liabilities suffered by another party - indemnification - or a third party. Within an SLA, an indemnity clause will require the service provider to acknowledge that the customer is not liable for any costs incurred for breach of contractual warranties. The compensation clause will also require the service provider to pay the customer any litigation costs by third parties resulting from the breach of contract.
To limit the scope of compensation, a service provider can:
- consult a lawyer;
- limit the number of indemnities;
- establish monetary limits for the clause;
- create time limits;
- define where the liability for compensation begins.
SLA performance metrics
SLAs include metrics to measure the performance of the service provider. As it can be difficult to select the right metrics for the customer and the service provider, it is important that the metrics are under the control of the service provider. If the service provider is unable to control whether a metric is behaving as specified, it is incorrect to hold the provider accountable for that metric.
And it should be easy to accurately collect data for metrics - automatic data capture would be best. Additionally, the SLA should specify a reasonable baseline for the metrics, which can be refined as more data is available on each metric.
SLAs establish customer expectations regarding the performance and quality of the service provider in several ways. Some metrics that SLAs can specify include:
- Availability e percentage of uptime. The amount of time the services are running and accessible to the customer. Uptime is typically tracked and reported by calendar month or billing cycle.
- specific performance benchmarks.Actual performance will be periodically compared against these benchmarks.
- Response time of the service provider. The time taken by the service provider to respond to a customer's problem or request. A larger service provider can manage a service desk to respond to customer inquiries.
- Resolution time. The time it takes to resolve a problem once it is logged by the service provider.
- Dropout rate. The percentage of queued calls that customers leave waiting for a response.
- Business results. Using KPIs to determine how contributions from service providers affect business performance.
- Error rate. The percentage of errors in a service, such as coding errors and missed deadlines.
- First call resolution. The percentage of incoming customer calls that are resolved without needing to be called back by the help desk.
- Average recovery time. The time it takes to recover after a service outage.
- Safety. The number of unknown vulnerabilities, for example. If an accident occurs, service providers must demonstrate that they have taken preventive measures.
- Time service factor. The percentage of queued calls that customer service representatives answer within a given time frame.
- Delivery time. The time it takes a service provider to resolve a specific problem once it is received.
Other metrics include planning for advance notification of network changes that may affect users and general statistics on service usage.
An SLA can specify availability, performance, and other metrics for different types of customer infrastructure, including internal networks, servers, and infrastructure components, such as uninterruptible power supplies.
What happens if the agreed service levels are not met?
Service level agreements include agreed penalties in the event that a service provider does not meet agreed service levels. Such remedies could be fee reductions or service credits for the fees incurred by the customer, as well as the termination of the contract for repeated bankruptcies.
Customers can enforce these service credits when service providers fail to meet agreed performance standards. Typically, the customer and the service provider agree to put a certain percentage of the monthly fee at risk. Service credits are taken from those risky fees when the seller fails to meet SLAs.
The SLA should detail how the service credits will be calculated. For example, the customer and seller might develop a formula that provides service credits based on the amount of downtime that exceeds the terms of the SLA. A service provider may limit performance penalties to a maximum dollar amount to limit exposure.
The SLA will also include a section detailing the exclusions, i.e. situations where the warranties of an SLA - and the penalties for failing to comply with them - do not apply. The list could include events such as natural disasters or terrorist acts. This section is sometimes referred to as the major force, which aims to exempt the service provider from events beyond its reasonable control.
Sanctions
SLA penalties are disciplinary measures that exist to ensure that the terms of the contract are maintained. These penalties differ from contract to contract. Are the following:
- Service availability. It includes factors such as network uptime, data center resources, and database availability. Sanctions should be added as a deterrent to service downtime, which could adversely affect business.
- Quality of service. It includes performance assurance, the number of errors allowed in a product or service, process gaps, and other quality-related issues.
In addition to service credits, there may be:
- Financial penalties. Request the seller to reimburse the customer for the amount of damage agreed in the contract.
- License Extension or Support. Requires the vendor to extend the license term or offer the customer free additional support. This could include development and maintenance.
These sanctions must be specified in the language of the SLA or they will not be enforceable. Additionally, some customers may not think that service credit or license extension penalties are adequate compensation as they may question the value of continuing to receive the services of a provider who is unable to meet its own. quality levels.
As a result, it may be worth considering a combination of penalties, as well as including an incentive, such as a monetary bonus, for more than satisfying work.
SLA Metrics Considerations
When choosing which performance metrics to include in the SLA, a company should consider the following factors.
Measurements should motivate correct behavior. When defining the metrics, both parties should remember that the goal of the metrics is to motivate the appropriate behavior on behalf of the service provider and the customer.
Metrics should reflect only those factors that are within the reasonable control of the service provider. Measurements should also be easy to collect. Also, both sides should resist choosing excessive amounts of metrics or measurements that produce large amounts of data. However, including too few metrics can also be a problem, as missing one could make it seem like the contract has been breached.
In order for the established metrics to be useful, an adequate baseline must be established with the measurements set to reasonable and achievable levels of performance. This baseline will likely be redefined during the parties' involvement in the agreement, using the processes specified in the periodic review and modification section of the SLA.
Earn Back or Earn Back
Un earn back is a provision that can be included in the SLA that allows vendors to regain service level credits if they perform at or above the standard service level for a specified period of time. Return earnings are a response to the standardization and popularity of service-level credits.
Service level credits, or simply service credits, should be the one and only remedy available to customers to compensate for service level failures. A service credit subtracts a sum of money from the total amount payable under the contract if the service provider does not meet service performance and performance standards.
If both parties agree to include the return earnings in the SLA, the process should be carefully defined at the start of the negotiation and integrated into the service level methodology.
When to review an SLA
An SLA is not a static document. Rather, an SLA should be updated and reviewed regularly with new information. Most companies review their SLAs annually or semi-annually. However, the faster an organization grows, the more often it should review and revise its SLAs.
Knowing when and when not to make changes to an SLA is a key part of managing the customer / service provider relationship. The two parties should meet at a set schedule to review their SLA and make sure it still meets both parties' requirements.
An SLA should be reviewed:
- when the customer's business requirements have changed, for example, their availability requirements increase because they have created an e-commerce site that sells a lot more;
- if there is a change in workloads;
- whether the measurement tools, processes and metrics have improved;
- when the service provider stops offering an existing service or adds a new service;
- when the technical capabilities of the service provider change, for example, new technologies or more reliable equipment allow the seller to provide faster response times; however, the service provider should review its SLA every 18-24 months even if its capabilities or services have not changed much to reduce inaccurate or outdated content.
Contractual compensation clauses for damages in Hosting contracts.
Normally the proposal of damages clauses in Hosting contracts are to be understood as unfair clauses or contractual clauses which - despite good faith (i.e. regardless of intention) - determine a significant burden on the consumer imbalance of rights and obligations deriving from the contract.
Failure to comply with an SLA does not automatically give the right to any compensation for damage, especially where the contract explicitly mentions the hosting provider's indemnity.
This is why the SLA is certainly an excellent starting point that could prove to be absolutely in vain if it is then not possible to access compensation in the case of the violation of the same, compensation that obviously the supplier in its most evident and explicit and legitimate interest will try to avoid through appropriate indemnity clauses that have their reasons and in any case denotes the seriousness and professionalism of a supplier who does not throw himself headlong into contracts that see him with excessive responsibility, especially if compared to market standards, where no hosting or almost is willing to pay damages and not indemnify.
What should a customer expect when he sees a supplier always saying yes even to very dangerous compensation clauses that could undermine the entrepreneurial future of the company? Always saying yes is in no way synonymous with professionalism, just as the extreme compliance of a supplier denotes approximation and inexperience, or a clear alarm bell that questions the hosting provider itself on all fronts.
For example, let's imagine that the family-run little bar under the house with a turnover of 100 thousand euros a year, and a profit of just 20 thousand decided to let us host their site costing 1000 euros, at a cost of 100 € a year, and in the contractual phase they demanded the acceptance of a vexatious clause in which in the event of a hacker attack we would compensate 50 thousand euros as compensation for damages.
It is immediately clear how this request is unbalanced in the classic bonus / malus formula that we see for example in insurance policies (especially American ones). We know that the price of car insurance for a novice driver is higher than that of a 50 year old belonging to the minimum risk class being a model driver, and that especially in the event of an accident, the insurance refers to superpartes tables and references. to assess the damage to be compensated. If the FIAT 500 of '48 in which you met your wife, in short, has an unparalleled symbolic and emotional value, your request for moral damages for 100 euros will be liquidated by the liquidator with the tables in force on Quattroruote, with 5 or 6. euro in short. Regardless of your reasons, there are unquestionable values to be respected.
A premium as opposed to a ceiling within an insurance proposal, in short, allows you to evaluate a risk, the probability of the same, the real impact on the customer's business, and from there formulate a fee that includes in addition to the out-of-pocket costs of exercise, the mark-up that constitutes the merger, also the premium for the hosting company that decides to meet these contractual commitments.
A customer who does not expect anything that the best effort service (as we have proposed it in our offer) will have the cost of the operating fee. A customer who, on the other hand, demands MORE, will have the cost of the operating fee plus the cost to be able to supply MORE.
Taking the example above of the little bar under the house, in which compensation for damages of 50 thousand euros is requested in the event of a hacker attack, it is perfectly normal that the hosting provider will specify his responsibilities and those of the customer. Where did the attacker come from? From the linux system managed by the hosting or from an outdated WordPress plugin managed by the webmaster? And here is a series of clauses that begin to be extremely meticulous and specific to put in black and white the cases that see hosting responsible and therefore responsible for compensating the customer.
Which hosting provider would accept to expose itself for 50 euros in compensation, for a fee of 100 euros per year? Obviously none.
It is different to expose yourself for 50 thousand euros against a rent of 5 thousand euros per year. Although it may seem nonsense, it is true that by changing the type of technology and management of the system, by installing additional precautions, file hashing systems and notification of changes, etc ... etc .., hosting can statistically and probabilistically calculate that the event that would result in a compensation of 50 thousand euros, has a probability of 0,5% and therefore it makes sense to accept and take the risk against an annual fee of € 5000, not € 100.
In fact, there would be a counter-proposal in which the hosting provider accepts the compensation clause by proposing the new hosting fee, which however becomes absolutely unacceptable and too expensive for the customer.
What is the customer trying to achieve?
At this point we must necessarily ask ourselves the question of what the customer is looking for. How can, for example, a site of a little bar that bills a little claim a compensation of 50 thousand euros for a website that cost just 2000? For example, why not ask for compensation for the out-of-pocket costs of building the site plus any, for an amount of 5000 euros and not 50?
Is there perhaps recklessness? Are you faced with a speculator who is laying the foundations to be able to proceed legally for damages, perhaps for a site attacked by a friend of his?
These are alarm bells that must always be considered and evaluated thinking badly. In the business world, kindness is a purely formal but not substantial aspect.
So let's see the standard alarm bells that a Hosting provider should evaluate when the customer rejects the standard contract but integrates it with compensation and vexatious clauses of this kind.
Compensation for general damage.
In fact, the customer writes in the contract in a vexatious clause that in the event of the supplier's liability (or presumed such, there will always be a CTU who will cost absurd figures and who in theory will pay the loser), will have the right to claim damages. It does not explain what type, related to which areas, loss of earnings, loss of profit, material damage, moral damage, or other, it specifies an amount that is in fact a ceiling.
The customer actually demands a blank check that he can fill at will with support pieces (even real ones) in the face of a well-defined and outlined service fee.
In short, the proportionality of the premium on the basis of the ceiling which is in fact indefinite is no longer valid. It is possible that the compensation will reach one million euros, or one billion, against 100 euros of monthly fee.
Lack of delineation of responsibilities.
The customer does not specify in an extremely precise way the domains and contexts of competence, but tends to place all the responsibilities on the supplier even for consequences not attributable to him.
The customer who, for example, claims compensation for damage in the face of hacking, not having the intellectual honesty to specify which attacks he will see as the cause of the application (outdated plugins, and the like) and that by turning the responsibility to the supplier, not only it does not worry about keeping the installation at the application level up-to-date, but perhaps demands a compensation of 10 thousand euros for damage to the image in the event of hacking.
In short, the responsibilities and areas of competence must always be clearly delineated in an explicit and eloquent way, reiterating that anything that is not explicitly the responsibility of the supplier indemnifies him directly and indirectly from the relative consequences.
What is the supplier trying to achieve instead?
The Hosting Provider tries to sell a Hosting service, minimizing costs and maximizing profits on the basis of operational research. In this regard, it tends to relieve itself of civil liability in an explicit and eloquent way at the contractual level, also to immediately stop any legal initiative that would still cost large amounts and not proportionate to the rental fee.
In short, the game must be worth the candle.
A vendor rarely has an interest in exposing itself if the risk is not extremely calculated and the SLAs are extremely beneficial.
The guaranteed uptime in the face of compensation for damages will inevitably drop from 99,99% to 99,8% on an annual basis which in fact means 17 hours of downtime per year.
Depending on the type of refundable ceiling and the type of damage type, the operating fee can increase very significantly and, as a rule, NEVER less than 20% of the covered ceiling.
For example, behind a cover for a maximum of 50 thousand euros, the provider can apply an extra to the agreed standard hosting cost of between 5000 and 10000 euros per year.
Obviously, in no way does the supplier have obligations to accept clauses of this type, considering that not always taking a risk can be a good thing at an entrepreneurial level and therefore the supplier simply uses the standard model of contract in its possession which is in fact a contract of best effort type without compensation for damage except for malicious reasons.
Finding a balance between the needs of the customer and those of the supplier.
The best way to find a balance between the needs of the customer and those of the supplier is to establish the financial conditions for a win - win relationship in which everyone wins.
The customer ascertains the supplier's maximum commitment in achieving the maintenance of the customer's site in an absolutely virtuous and paranoid way for all areas of competence and services of the supplier's responsibility.
The supplier ensures that in the face of its commitment to avoid a risk, tending to zero but never zero, there is an economic premium (which in turn could, for example, also be used to take out an insurance policy with a specific deductible for the customer and discharge the risk).
How is this equilibrium reached by taking as a case the example above of the little bar that demanded compensation for damages of 50 euros in the event of a hacking?
- The compensation ceiling is lowered from 50 euros to 5000 euros.
- It is specified that any attack originating from application layer attacks indemnifies the vendor.
- It is specified that any systemic 0day type attack indemnifies the supplier
- The annual fee is increased from € 100 to € 500
This, for example, in our case could be a good balance, not optimal, but certainly worthy of evaluation for a subsequent probable acceptance.
Probably for another supplier it might not be acceptable, and it would still be his legitimate choice.
