Vaak voorkomende IT-contracten
In de voorgaande hoofdstukken hebben we benadrukt dat een goede basiskennis van het verbintenissenrecht onontbeerlijk is voor een goed begrip van IT-contracten, aangevuld met inzicht in de belangrijkste en meest voorkomende clausules.
In dit hoofdstuk gaan we een stapje verder en wordt dieper ingegaan op de eigenschappen van bepaalde specifieke IT contracten:4
– koop- en verkoop van hardware;
– softwarelicentieovereenkomsten;
– softwareontwikkeling;
– onderhoud en support;
– cloudservice;
– IT-consultancy;
– IT-outsourcing;
– servicelevelagreements (SLA);
– escrow;
– verwerkersovereenkomsten.
1 Koop en verkoop van hardware
De eenvoudigste contractvorm is de koop-verkoopovereenkomst, waarbij men de volgende vragen moet stellen om de rechten en plichten van partijen correct in kaart te brengen.
1.1 In welke hoedanigheid handelen de partijen?
We moeten een fundamenteel onderscheid maken tussen ondernemers en consumenten. De contractbepalingen, garantievoorwaarden en dergelijke zijn immers voor beide partijen verschillend. Consumenten worden als ‘juridisch zwakkere partij’ op diverse vlakken beschermd:
– garantiebepalingen (van dwingend recht);
– specifieke rechten bij online aankopen, zoals het herroepingsrecht;
–
Voor die topics verwijzen we graag naar het hoofdstuk ‘E-commerce’ in dit handboek.
Ondernemers daarentegen zijn vrijer in de toepassing van de beschermingsregels, maar in de praktijk maken heel wat ondernemers/verkopers in hun algemene voorwaarden om commerciële of louter praktische redenen geen onderscheid op basis van dat statuut, zodat voor ondernemers conventioneel in een gelijk beschermingsniveau wordt voorzien. Het blijft echter een belangrijk aandachtspunt, want als niets specifieks is bepaald zal een ondernemer slechts aanspraak kunnen maken op de
4 Voor een meer diepgaande, juridisch-academische bespreking: M. Taeymans en E. Jacobs, IT-contracten in Recht en Praktijk, Kluwer, 2020, 222 p.
aangeboden commerciële garantie van de ondernemer of de fabrikant (de zogenaamde fabrieksgarantie) en de vrijwaring voor verborgen gebreken.
1.2 Zijn specifieke afspraken van belang?
Een eenvoudige fysieke of online aankoop zal een dergelijke vraag niet oproepen, een meer omvangrijke overeenkomst uiteraard wel. De meest essentiële afspraak daarbij is de prijs die de koper zal betalen en hoe hij die zal betalen. Het betreft vooral een praktische regeling, afhankelijk van de omvang van de deal, de hoedanigheid van de partijen en hun onderlinge verhoudingen. Er kan zo sprake zijn van een eenvoudige betaling tegen een bepaalde datum of een gespreide betaling, betaling in schijven, bijvoorbeeld rekening houdend met bepaalde contractonderdelen zoals levering, installatie, opleiding of bijstand.
In dat kader kan men eveneens onderhandelen over de tijdslijn, met specifieke afspraken rond levering, aanvaarding, eventuele wijzigingen en conflictoplossing.5 Bijlagen met meer technische afspraken of in te vullen – en op het ogenblik van de sluiting van het contract onbekende – factoren zijn uiteraard steeds mogelijk.
2 Softwarelicentieovereenkomsten
2.1
Situering en definitie
Een softwarelicentieovereenkomst is een overeenkomst tussen een licentiegever (vaak de eigenaar of ontwikkelaar van de software, in ieder geval de houder van bepaalde rechten) en een licentienemer (de gebruiker van de software) waarbij de licentiegever aan de licentienemer het recht verleent om de software te gebruiken
Dat recht is meestal beperkt door bepaalde voorwaarden en beperkingen, zoals: – het aantal gebruikers dat toegang heeft tot de software;
– de duur van het gebruik; – de specifieke manieren waarop de software mag worden gebruikt.
De overeenkomst omvat vaak ook bepalingen met betrekking tot de intellectuele eigendomsrechten, waarbij de licentiegever de eigendom van de software behoudt, terwijl de licentienemer slechts beperkte rechten krijgt voor het gebruik ervan, doorgaans in ruil voor een bepaalde vergoeding.
Er zijn twee hoofdtypes licentiecontracten: – voor bestaande software (softwarelicentieovereenkomsten); – voor nog te ontwikkelen software (softwareontwikkelingsovereenkomsten).
Geïndividualiseerde software, gericht op individuele afnemers, verhandelt men meestal via licentieovereenkomsten met uitgebreide beschermingsbedingen rond intellectuele eigendomsrechten. Softwarelicenties beschouwt men als een unieke overeenkomst, verwant aan andere technologie-exploitatieovereenkomsten.
5 M. Taeymans en E. Jacobs, IT-contracten in Recht en Praktijk, Kluwer, 2020, 98 e.v.
De licentieovereenkomst beschermt de eigenaar van intellectuele eigendomsrechten en de licentienemer tegen inbreukclaims, op voorwaarde dat de activiteiten binnen de grenzen van de licentie blijven. Er bestaat enige discussie of licentieverlening gelijkstaat aan verkoop, vooral in de context van materiële dragers zoals cd-roms of dvd’s. Een materiële drager geeft daarbij geen rechten op het immateriële werk zelf.
Het Hof van Justitie van de Europese Unie heeft bepaald dat de verkoop van een softwarekopie, die onbeperkt in de tijd is en tegen een vergoeding die de economische waarde reflecteert, leidt tot uitputting van het distributierecht binnen de EER. Dit betekent dat de kopie doorverkocht mag worden, ongeacht of dat online of op een materiële drager is. Tijdelijke licenties of abonnementen vallen echter niet onder dat principe.6
2.2 Op grote schaal verspreide software
Voor software die op grote(re) schaal wordt verspreid moeten we een onderscheid maken tussen closed- en open-sourcesoftware, waar de broncode beschikbaar is voor aanpassingen door de gebruiker (zie ook de hoofdstukken ‘Algemeen’, ‘Auteursrechten en software’ en ‘Octrooien en ITinnovatie’). Hier behandelen we de licenties die gegeven worden op closed-sourcesoftware.
De wijze waarop de gebruiker of licentienemer die verkrijgt is in de loop van de voorbije jaren snel en sterk geëvolueerd:
– van de aankoop van een fysieke drager via tussenpersonen (winkels) waarbij het openen van de softwareverpakking impliceert dat de gebruiker de licentievoorwaarden accepteert;
– naar online aankopen waarbij in eerste instantie de regels gelden voor verkoop op afstand, waar we een onderscheid moeten maken tussen de beschermingsregels ten aanzien van consumenten en ondernemers en gebruikers die licentievoorwaarden aanvaarden door op een akkoordknop te klikken, wat een directe(re) relatie met de softwareproducent creëert en minder ruimte laat voor betwisting van de aanvaarding.
2.3 Software op maat
Software op maat stemt men doorgaans af op de specifieke behoeften van de klant, wat resulteert in een meer gepersonaliseerde aanpak, een directere relatie tussen klant en leverancier en ipso facto de noodzaak van een in detail gereguleerde overeenkomst:
– De overeenkomst specificeert daarbij de duur van de licentie, die kan variëren van bepaalde tot eeuwigdurende termijnen. Bij tijdelijke overeenkomsten zijn periodieke betalingen gebruikelijk, terwijl eeuwigdurende licenties vaak een eenmalige vergoeding vereisen.
– Belangrijk is het duidelijk omschrijven van de software en de licentie. De omschrijving omvat niet alleen de naam van de software, maar ook de vereiste functionaliteiten, de compatibele apparatuur en besturingssystemen. Bij complexe software kan men dat uiteraard eventueel detailleren in een bijlage.
–
Gebruikers krijgen meestal niet-exclusieve rechten, vaak met beperkingen zoals het aantal gebruikers of specifieke installatie-eisen. De overeenkomst kan ook voorwaarden bevatten over reproductie, reservekopieën, aanpassingen en het recht op softwareoverdracht (zie punt 3.8.1 van het hoofdstuk ‘Auteursrechten en software’).
6 https://curia.europa.eu/juris/document/document.jsf?docid=124564
– De betalingswijze varieert; sommige overeenkomsten vereisen een eenmalig forfaitair bedrag, terwijl andere periodieke vergoedingen hanteren. Dat moet in lijn zijn met de marktwaarde en kan gefaseerd worden om de belangen van de klant te beschermen.
– Op maat gemaakte software vereist vaak een complexere installatie, waarbij de leverancier nauw betrokken is. Na installatie volgen aanvaardingstests die bepalen of de software aan de gestelde eisen voldoet.
Hoewel strikt foutloze software zelden haalbaar is, is de leverancier verantwoordelijk voor het corrigeren van significante problemen. Onderhoud vormt een cruciale component van de overeenkomst en dat moet men duidelijk afbakenen. De overeenkomst beperkt vaak de mogelijkheid van de klant om zelfstandig wijzigingen aan te brengen in de software. Ook is er vaak een nadrukkelijke verplichting tot geheimhouding , gezien de uitwisseling van gevoelige informatie tussen de partijen.
In ieder geval moet de licentiegever rekening houden met de exacte omvang van de eigen licentie zodat voorkomen wordt dat die grenzen overschreden zouden worden door meer rechten te verlenen dan vervat in de eigen licentie, bijvoorbeeld het verlenen van een volwaardige licentie op basis van een sublicentie.
3 Softwareontwikkeling
3.1 Situering en definitie
Verwant met de softwarelicentie maar heel wat verregaander qua toepassingsgebied en inhoud is de softwareontwikkelingsovereenkomst.
Een softwareontwikkelingsovereenkomst is een contractuele afspraak tussen twee partijen, waarbij de ene partij – de opdrachtgever – een andere partij – de softwareontwikkelaar of opdrachtnemer –de opdracht geeft om specifieke software te ontwikkelen.
Die overeenkomst heeft betrekking op de ontwikkeling van maatwerksoftware die is afgestemd op de unieke behoeften en specificaties van de opdrachtgever. Ze dient zowel als leidraad voor het ontwikkelproces en als bescherming van de rechten en belangen van beide partijen en omvat doorgaans specifieke elementen zoals:
– de reikwijdte van het project;
– tijdschema’s;
– kosten;
– betalingsvoorwaarden;
– eigendomsrechten op de software;
– eventuele garanties (zie uitgebreider punt 3.3 van het hoofdstuk ‘IT-contracten: gebruikelijke clausules, juridische uitdagingen en aandachtspunten’) of onderhoudsafspraken na voltooiing.
3.2 Belangrijkste aspecten
De selectie van een geschikte softwareontwikkelaar is cruciaal. Die keuze wordt beïnvloed door diverse criteria zoals financiële, technische, communicatieve en contractuele aspecten. Het proces begint idealiter met een offerteaanvraag en een voorselectie van potentiële ontwikkelaars. Een voorbereidend contract is zonder meer nuttig om de voorwaarden zoals tijdlijn, kosten en intellectuele eigendomsrechten vast te leggen, in combinatie met een geheimhoudingsovereenkomst.
Het ontwikkelproces bestaat meestal uit verschillende fases: – analyse; – ontwerp; – programmering; – implementatie.
Die fases moeten duidelijk worden afgebakend in het contract, met termijnen en verantwoordelijkheden. In het licht van de voorgaande alinea stelt men vaak een voorafgaande analyseovereenkomst op die moet nagaan wat de werkelijke behoeften van de klant zijn. Afhankelijk van de betrokkenheid van een IT-deskundige of IT-afdeling van de klant bij het project is een onderzoek naar die behoeften van het uiterste belang om te voorkomen dat het project te vaag of gewoon met de foutieve doeleinden een aanvang zou nemen, een recept voor discussies, conflicten en afwijkingen van het overeengekomen tijdskader. Zo’n analyse kan immers aan het licht brengen dat de oplossing die de klant zelf voorstelde – of om te beginnen de analyse van het probleem en de eigen behoeften van die klant – niet correct is, zodat men vrij snel een andere of afwijkende oplossing kan voorstellen.
Het contract moet ook de prijs, de betalingsvoorwaarden en afleverings- en installatieprocedures omvatten. De hierboven aangehaalde analyse is ook daarbij van belang om op basis van de effectieve behoeften van de klant een goede tijdslijn op te stellen met aanduiding van oplevering van het geheel en eventueel ook deelaspecten van de software (het betreft immers een aannemingsovereenkomst – zie punt 3.2 in het hoofdstuk 'IT-contracten'). Nu het vaak een complex gegeven is dat men – soms op vraag van de klant herhaaldelijk – moet bijsturen, is het nuttig om in de overeenkomst of de onderliggende eigen voorwaarden een extra marge te voorzien, enerzijds qua tijd, zodat men de aangegeven deadlines kan opschuiven of minstens ruim kan interpreteren en anderzijds wat de vergoeding betreft zodat men niet steeds extra vragen/verzoeken van de klant moet onderhandelen.
Specifieke waarborgen en het recht op intellectuele eigendom van de ontwikkelde software zijn zoals gebruikelijk eveneens cruciale onderdelen van de overeenkomst (zie het hoofdstuk 'Intellectuele eigendom'). De mogelijkheid tot terbeschikkingstelling van de broncode aan de opdrachtgever moet men duidelijk in het contract specificeren, aangezien er geen automatische rechten zijn voor de opdrachtgever op de broncode, tenzij men dat expliciet overeenkomt (zie punt 9).
4 Onderhoud- en support
Soms apart, maar specifiek vaak verbonden aan de softwareontwikkelingsovereenkomst zijn de onderhoudscontracten, die (1) automatisch in werking treden na de oplevering van de ontwikkelde software of (2) die men apart kan afsluiten met een derde partij.
Het doel van een onderhoudscontract is om de goede werking en levensduur van de uitrusting te garanderen door regelmatige controles, aanpassingen en reparaties.
Een duidelijke opleveringsclausule na een ontwikkelingsfase kan daarbij heel wat discussie en tijden middelenverlies voorkomen. Al te vaak blijven softwareontwikkelaars immers al eens hangen in de fase van de oplevering (of net ervoor) omdat de klant opmerkingen blijft maken, vaak met goede bedoelingen maar soms ook met de intentie om de inwerkingtreding van het betalende onderhoudscontract bewust zo lang mogelijk uit te stellen. Bij de ontwikkeling van software zijn in het kader van support of garantie wel vaker kleine wijzigingen noodzakelijk of zelfs onvermijdelijk (bv. bij een koppeling aan een extern apparaat van een andere leverancier, zoals een smartphone, waar men softwarewijzigingen niet steeds kan voorzien). Het betreft dan geen gebrek in de ontwikkelde software
maar wel degelijk een item in de supportfase, waarvoor men een ticket moet aanmaken en een oplossing moet zoeken en bieden.
De overeenkomst moet in ieder geval duidelijk omschrijven: – de te onderhouden apparatuur; – de aard van het onderhoud; – inclusief preventieve maatregelen; – correcties van defecten; – eventuele aanpassingen aan technologische evoluties.
De prijs en betalingsvoorwaarden, de duur van het contract, en de aansprakelijkheid en beperkingen van de onderhoudsdienstverlener moet men nauwkeurig specificeren. In essentie biedt een onderhoudscontract een gestructureerde aanpak om de continuïteit en efficiëntie van informatica-uitrustingen te waarborgen, waarbij men zowel routinematig als incidenteel onderhoud afdekt.
5 Cloudservices
5.1 Situering en definitie
Een cloudserviceovereenkomst is een contractuele afspraak tussen een aanbieder van cloudservices en een gebruiker, waarbij de aanbieder zich verbindt tot het leveren van bepaalde computingdiensten zoals dataopslag, servers, netwerkcapaciteit, softwareapplicaties en/of andere IT-bronnen via het internet.
De gebruiker krijgt daardoor toegang tot en gebruik van die IT-middelen op een flexibele, schaalbare en vaak kostefficiënte wijze, zonder noodzakelijk fysieke infrastructuur of gespecialiseerd ITpersoneel in eigen beheer te hebben.
De overeenkomst bepaalt doorgaans de omvang van de dienstverlening en de kwaliteitsnormen zoals beschikbaarheid en beveiliging, de kostenstructuur en de rechten en verantwoordelijkheden van beide partijen met betrekking tot gebruik, beveiliging, onderhoud en de gegevensbescherming.
Afhankelijk van het contractvoorwerp kan men cloudserviceovereenkomsten kwalificeren als huur, koop, licentie of een gemengd karakter. De specifieke aard bepaalt het toepasselijke juridische kader. Steeds moet men de nodige aandacht besteden aan de regels rond het doorgeven van data aan derde landen en de opslag van gevoelige persoons- en/of overheidsgegevens.
5.2 Soorten cloudservices
Er bestaan in cloudservicediensten drie dienstmodellen en vier gebruiksmodellen
5.2.1
Drie dienstmodellen
In eerste instantie kunnen we drie dienstmodellen onderscheiden, elk met specifieke kenmerken en functionaliteiten.
5.2.1.1 Software as a Service (SaaS)
Bij SaaS biedt men applicaties als dienst aan via het internet. Gebruikers kunnen toegang krijgen tot en gebruikmaken van softwareapplicaties die gehost worden op externe servers. Dit model is geschikt voor gebruikers die geen complexe software willen installeren en onderhouden. Het biedt de klant geen controle maar wel gemak en toegankelijkheid omdat de aanbieder het onderhoud en de updates verzorgt.
VOORBEELD
Populaire SaaS-oplossingen omvatten Microsoft Office 365, Google Workspace (voorheen G Suite), Salesforce en Dropbox.
5.2.1.2 Platform as a Service (PaaS)
PaaS biedt een ontwikkelings- en implementatieplatform via het internet. Gebruikers kunnen applicaties bouwen, testen, uitrollen en beheren zonder zich zorgen te hoeven maken over de onderliggende infrastructuur. Dit model is zeer geschikt voor ontwikkelaars en bedrijven die zich willen richten op de creatie van software of applicaties zonder zich te moeten bekommeren om besturingssystemen, netwerkbeheer of serveronderhoud.
VOORBEELD
Bekende PaaS-oplossingen zijn Google App Engine, Microsoft Azure en AWS Elastic Beanstalk.
5.2.1.3 Infrastructure as a Service (IaaS)
IaaS biedt essentiële computinginfrastructuur zoals virtuele servers, netwerkmogelijkheden en dataopslagruimte via het internet. Dit model is ideaal voor bedrijven die complete controle wensen over hun infrastructuur in de cloud, maar niet de kosten en complexiteit willen van het fysiek beheren van servers en datacenters.
VOORBEELD
Amazon Web Services (AWS), Microsoft Azure en Google Compute Engine zijn voorbeelden van IaaS-providers.
5.2.2 Vier gebruiksmodellen
We onderscheiden vervolgens vier gebruiksmodellen, elk met unieke kenmerken en toepassingsgebieden – elk model biedt verschillende niveaus van controle, flexibiliteit en beheer, waardoor ondernemingen kunnen kiezen wat het best past bij hun specifieke behoeften en vereisten.
5.2.2.1 Private cloud
Een private cloud is een cloudinfrastructuur die exclusief is opgezet voor één organisatie. Ze kan ze zelf intern hosten of een derde partij daartoe de opdracht geven, maar ze is niet toegankelijk voor het publiek. Dit model is geschikt voor organisaties die hoge eisen stellen aan controle, beveiliging en privacy, zoals financiële instellingen of overheidsinstanties. Hoofdstuk 4 Vaak voorkomende
5.2.2.2 Publieke cloud
Bij een publieke cloud bieden externe cloudserviceproviders services zoals servers, opslag en applicaties aan via het internet. Zij delen die infrastructuur met andere organisaties of individuen. Dit model is ideaal voor bedrijven die behoefte hebben aan hoge schaalbaarheid, lagere initiële kosten en beperkte technische vereisten voor het beheer van de infrastructuur.
VOORBEELD
Diensten als Amazon Web Services (AWS), Dropbox, Google Cloud en Microsoft Azure.
5.2.2.3 Communitycloud
Een communitycloud is vergelijkbaar met een private cloud, maar meerdere organisaties met gemeenschappelijke belangen en vereisten, zoals regelgeving, beveiligingsbehoeften of missie, delen deze cloud. Dit model is nuttig voor sectoren waar organisaties soortgelijke behoeften hebben en waar samenwerking wordt bevorderd, zoals bij bepaalde overheidsinstanties of in de gezondheidszorg.
5.2.2.4 Hybride cloud
Een hybride cloud combineert private- en publieke-cloudelementen, waardoor organisaties kunnen profiteren van de voordelen van beide. Deze omgevingen zijn verbonden om data en applicaties te delen, wat meer flexibiliteit en optimalisatiemogelijkheden biedt. Dit model is geschikt voor organisaties die voldoende flexibiliteit wensen om bepaalde workloads in de publieke cloud te plaatsen terwijl ze kritieke data of applicaties in een private omgeving behouden. Het is dus nuttig voor bedrijven die behoefte hebben aan zowel schaalbaarheid als controle over gevoelige data.
5.3 Meest voorkomende bedingen
In cloudserviceovereenkomsten komen verschillende standaardbedingen voor die essentieel zijn voor het beheer en de regulering van de relatie tussen de serviceprovider en de klant. De meest gebruikte bedingen zijn:
1. Servicelevelagreement (SLA): definieert de prestatienormen waaraan de provider moet voldoen, zoals beschikbaarheid, reactietijd en onderhoudsschema’s. Het omvat vaak details over compensaties of boetes bij niet-naleving.
2. Gegevensbescherming en privacy : deze clausule bepaalt hoe men persoonsgegevens verzamelt, gebruikt, opslaat en beveiligt. Dat is vooral belangrijk in het licht van regelgeving zoals de GDPR en uiteraard van belang wanneer er werkelijk sprake is van het verwerken van data door een derde partij (zie daarvoor het hoofdstuk 'Privacy en gegevensbescherming').
3. Beveiliging : beveiligingsmaatregelen en protocollen die de provider gebruikt om de data en applicaties van de klant te beschermen tegen ongeautoriseerde toegang en andere cyberdreigingen.
4. Compliance en standaarden: verwijst naar de naleving van industriestandaarden en wettelijke vereisten, wat cruciaal kan zijn in gereguleerde sectoren.
5. Audit : mogelijkheden voor en beperkingen van het auditen van gegevens en diensten, zeker in publieke clouds.
6. Beëindigingsvoorwaarden en exit strategie: niets blijft eeuwig duren... hoe en wanneer men de overeenkomst kan opschorten of beëindigen, en afspraken over de overdracht van data bij beëindiging mogen niet ontbreken – eventueel gekoppeld aan de auditclausule die periodieke controle toelaat op het gebruik en de lokalisatie van (eventueel gevoelige of persoonsgebonden) data, geen eenvoudige opdracht.
7. Wijzigingen en updates: omvat hoe men updates aan de dienst regelt en hoe men contractwijzigingen afhandelt.
6
IT-consultancy
6.1 Situering en definitie
Een IT-consultancyovereenkomst is een contractuele afspraak tussen een cliënt en een ITconsultant of consultancybedrijf, waarin men de voorwaarden en de reikwijdte van de geleverde IT-consultancydiensten vastlegt.
De diensten kunnen variëren van adviesverlening en strategische planning tot implementatieondersteuning en projectmanagement op het gebied van IT. De overeenkomst specificeert doorgaans de doelstellingen van het project, de te leveren diensten, de tijdslijnen, de verantwoordelijkheden van beide partijen, de vergoedingsstructuur en de regels voor vertrouwelijkheid en gegevensbescherming. Het doel van de overeenkomst is een duidelijk kader te bieden voor de samenwerking, waarbij de consultant zijn expertise en advies inbrengt om de IT-gerelateerde doelstellingen van de cliënt te ondersteunen en te realiseren.
6.2 Belangrijkste clausules
Naast de voor de hand liggende elementen zoals taakomschrijving of vergoeding zijn volgende juridische aandachtspunten van specifiek belang in het kader van consultancydiensten:
– De consultant heeft een uitgebreide verantwoordelijkheid en aansprakelijkheid die vaak beperkt is tot het verzekerde bedrag.
– De duur kan variabel zijn en afhankelijk van de projectresultaten of een vastgesteld aantal mandagen, waarbij men vaak ook rekening moet houden met de driehoeksverhouding tussen consultant, bureau en klant – men moet de termijnen op elkaar afstemmen.
– Intellectuele eigendomsrechten: de klant wordt eigenaar van de resultaten na volledige betaling, maar de consultant behoudt de rechten op gebruikte methodes en technieken.
– Clausules die beide partijen verplichten tot vertrouwelijkheid over bedrijfsinformatie, handelsgeheimen en andere gevoelige gegevens.
– ‘Afwerven’ van personeel: de soms intense contacten en het gebruik van de kennis van de consultant geven wel vaker aanleiding tot (pogingen tot) aanwerving door de klant. Er is dan sprake van een zekere tegenstelling van belangen... regelgeving over het wederzijds ‘afwerven’ van personeel is dan ook vaak opgenomen om oneerlijke praktijken te voorkomen. Dat kan bestaan uit een verbod tot een principiële toelating mits – uiteraard – het betalen van een zekere vergoeding.
7 IT-outsourcing
7.1 Situering en definitie
Een IT-outsourcingcontract is een formele overeenkomst tussen de klant, een onderneming/organisatie/overheid en een externe IT-dienstverlener, waarbij de klant bepaalde IT-functies en -diensten uitbesteedt aan de dienstverlener.
Dat kan inhoudelijk variëren van het beheer van IT-infrastructuur, zoals servers en netwerksystemen, tot specifieke diensten waaronder softwareontwikkeling, data-analyse, cloudservices en helpdeskondersteuning. Het contract bepaalt de reikwijdte van de uit te besteden diensten, de prestatie-eisen, de kwaliteitsnormen, de kostenstructuur, de duur van de overeenkomst en de verantwoordelijkheden van beide partijen. Ook neemt men afspraken over vertrouwelijkheid, gegevensbeveiliging en naleving van regelgeving op.
Het doel van een IT-outsourcingcontract is organisatorische efficiëntie te verhogen, kosten te reduceren, toegang tot gespecialiseerde expertise te verkrijgen en de focus te leggen op de eigen kernactiviteiten, terwijl de externe provider de uitbestede IT-diensten beheert en optimaliseert. De samenwerking heeft in principe betrekking op activiteiten die niet tot de kerntaken van de klant behoren en kan beperkt of net heel uitgebreid en uiteindelijk behoorlijk complex zijn. Er is ipso facto niet alleen behoefte aan vertrouwen maar ook aan performante controle en overgangsafspraken en -mechanismen.
7.2 Belangrijkste criteria
Elk outsourcingcontract bevat bepaalde specifieke en essentiële clausules, waaronder de omschrijving van de diensten, kwaliteitseisen, prijs- en betalingsafspraken, aansprakelijkheid en vrijwaring, intellectuele eigendomsrechten, geheimhouding, beveiliging, duur en beëindiging van het contract, incl. geschillenregeling. Men moet de nodige aandacht besteden aan de transitie- en transformatieperiode, zowel bij aanvang als bij een beëindiging van de overeenkomst op initiatief van een van de partijen. Het is immers niet zo evident om een bedrijfsproces plots weer over te nemen of uit te besteden aan een andere consultant.
7.2.1 Single- versus multisourcing
We maken een onderscheid tussen:
– single sourcing, waarbij één leverancier alle IT-diensten levert; – multisourcing, waarbij verschillende leveranciers voor verschillende diensten zorgen.
Beide benaderingen hebben voor- en nadelen, zoals afhankelijkheid van één leverancier bij single sourcing en een complexere coördinatie bij multisourcing
7.2.2 Onderscheiden fases in een outsourcingproject
Outsourcingprojecten worden vaak in verschillende fases uitgevoerd, waaronder interne voorbereiding, contact met potentiële leveranciers, offerteaanvragen, onderhandelingen en de transitiefase. Elke fase heeft haar eigen kenmerken en vereisten.
Voor het bevestigen van een outsourcingcontract hebben zowel de klant als de dienstverlener bepaalde (precontractuele) informatieverplichtingen. Ze moeten elkaar correcte en substantiële informatie verstrekken over die elementen die essentieel zijn voor de overeenkomst. Men definieert een outsourcingcontract vaak als een aannemingsovereenkomst . Zoals eerder aangestipt heeft dat belangrijke implicaties voor zaken als prijsafspraken en beëindigingsvoorwaarden.
Hoofdstuk 4 Vaak voorkomende IT-contracten
Servicelevelagreements (SLA)
8.1 Situering en definitie
Een servicelevelagreement of -overeenkomst is vaak een onderdeel van een bredere overeenkomst tussen een dienstverlener en een klant, formeel van aard en waarbij de aard, kwaliteit en reikwijdte van de te leveren diensten wordt afgesproken. Het doel is het vestigen van een meetbare prestatienorm en het servicelevelagreementonderdeel bevat specifieke details over de reactietijd, de beschikbaarheid, de kwaliteit van de dienstverlening en de procedures voor het oplossen van problemen.
Servicelevelagreements definiëren vaak ook de verantwoordelijkheden van beide partijen, de omstandigheden voor het uitvoeren van de diensten en de gevolgen bij het niet voldoen aan de overeengekomen normen, inclusief eventuele compensaties of sancties. Het is als instrument cruciaal voor het managen van verwachtingen en het waarborgen van een duidelijke, op aansprakelijkheid gebaseerde transparante dienstverlening. Hoewel steeds vermeld als juridisch IT-contract betreft het vooral een verzameling aan onderlinge praktische afspraken, soms verpakt als een commercieel keuzemodel voor de klant.
8.2 Belangrijkste criteria
Een ‘standaard’ servicelevelagreement bestaat niet; het is behalve in commerciële toepassingen tussen ondernemers eerder gericht op een breed publiek van consumenten, dan een doorgaans op maat gemaakte verzameling van afspraken, met – in grotere projecten – ook een duidelijke regeling van governance- en escalatiemechanismen.
8.2.1 Kwaliteitsniveaus (servicelevels)
Een goede formulering én concretisering is cruciaal – de servicelevels moeten voldoende objectief meetbaar zijn en voldoen aan enkele basiscriteria, onder andere qua meetbaarheid, meldingswijze of rapportering en wijzen van opvolging, tijdsverloop en dergelijke. Daarbij moet men duidelijk aangeven of de overeengekomen prestaties inspannings- of resultaatsverbintenissen betreffen (zie punt 3.1 van het hoofdstuk ‘IT-contracten: gebruikelijke clausules, juridische uitdagingen en aandachtspunten’).
8.2.2 Sancties bij niet nakoming
Men kan diverse soorten sancties overeenkomen, waaronder boetes, prijscorrectiemechanismen en servicecredits. De juridische aard van servicecredits kan variëren, afhankelijk van het feit of ze gezien worden als schadebedingen of als prijsafspraken voor verschillende dienstenniveaus. Belangrijk is de duidelijkheid over het forfaitaire karakter van sancties en of ze de enige compensatie vormen of dat de klant eventuele hogere schade kan claimen.
9 Escrow
De term escrow vindt z’n oorsprong in het Oudengelse recht en is afgeleid van het Middelengelse woord escrowe, wat een soort van schriftelijke verplichting of document betekent. Dat Middelengelse woord is op zijn beurt afgeleid van het Oudfranse woord escroue, dat verwijst naar een stuk perkament of rol papier.
In de Middeleeuwen werd de term gebruikt om een document te beschrijven dat een derde partij bijhield totdat bepaalde voorwaarden waren, voldaan. De derde partij, of escrow-agent, was verantwoordelijk voor het bewaren van het document en zorgde ervoor dat het alleen aan de ontvanger werd overhandigd als aan de vooraf overeengekomen voorwaarden was voldaan. In de loop van de tijd evolueerde het gebruik van de term naar de meer hedendaagse betekenis, waarbij ‘escrow’ verwijst naar een regeling waarbij een neutrale derde partij activa, geld of documenten in bewaring houdt totdat specifieke voorwaarden zijn voldaan, zoals gebruikelijk is bij vastgoedtransacties, online handel en andere juridische overeenkomsten. Een escrowclausule heeft dan specifiek betrekking op een bepaalde ‘trigger’, een specifieke situatie/gebeurtenis die respectievelijk een specifiek feit dat een afgesproken juridisch gevolg doet ontstaan.
In het IT-recht is een escrowovereenkomst (meestal een clausule in een groter geheel) een speciale regeling waarbij een derde partij (de escrow-agent) de broncode van software, samen met bijbehorende documentatie, bewaart. Dat gebeurt om de continuïteit en het onderhoud van de software te waarborgen voor de licentienemer, mocht de softwareleverancier niet meer in staat zijn de software te ondersteunen of te onderhouden, bijvoorbeeld door een faillissement, fusies, bedrijfsopheffing of andere omstandigheden. De essentie van een dergelijke overeenkomst is het beschermen van de belangen van de licentienemer. De broncode is immers meestal eigendom van de softwareontwikkelaar.
Onder bepaalde vooraf overeengekomen omstandigheden (zie hoger) krijgt de licentienemer echter toegang tot de broncode via de escrow-agent. Daardoor kan de licentienemer de software blijven gebruiken en onderhouden. De escrowovereenkomst regelt concreet de voorwaarden waaronder de broncode wordt vrijgegeven, de verplichtingen van de escrow-agent (zoals het veilig bewaren en verifiëren van de broncode), en de rechten en plichten van alle betrokken partijen. Dat zorgt voor een vangnet voor de licentienemer en biedt tegelijkertijd zekerheid en bescherming van intellectuele eigendom voor de softwareontwikkelaar.
De eerste escrowclausules waren vaak duur en weinig performant, in die zin dat een notaris een (één) versie van de broncode fysiek bijhield; die zou de documenten dan bijvoorbeeld vrijgeven bij een faillissement van de IT-onderneming. Onnodig op te merken dat de code doorgaans verouderd was en dat een geschreven code niet bepaald een vlotte overgang naar een nieuwe IT-leverancier kon waarborgen. Nog steeds last men escrow-clausules in voor situaties waarin dat weinig nuttig is. Voor SaaSdiensten bijvoorbeeld zal de broncode geen meerwaarde bieden mocht de dienstverlener failliet gaan.
De huidige clausules zijn op het vlak van omschrijving, actualisering, opslag in een cloudomgeving en de bewaring door een professionele derde partner al heel wat beter georganiseerd maar de escrow garandeert doorgaans nog steeds geen vlekkeloze overdracht na bijvoorbeeld het faillissement van de IT-leverancier.
10
Verwerkersovereenkomsten
Een verwerkersovereenkomst, in de context van artikel 28 van de Algemene Verordening Gegevensbescherming (AVG) of de General Data Protection Regulation (GDPR), is een juridisch bindende overeenkomst tussen een verwerkingsverantwoordelijke en een verwerker van persoonsgegevens. Die overeenkomst is essentieel wanneer een organisatie (de verwerkingsverantwoordelijke) een andere organisatie (de verwerker) inschakelt om namens hen persoonsgegevens te verwerken. De verwerkersovereenkomst moet garanderen dat de verwerkingsverantwoordelijke controle kan uitoefenen op de verwerker, die op die basis zal moeten zorgen voor voldoende technische en organisatorische waarborgen.
We verwijzen naar het hoofdstuk 'Privacy en gegevensbescherming' en bespreken kort de essentiële elementen van zo’n verwerkersovereenkomst.
De kernaspecten van een verwerkersovereenkomst zijn:
1. Men moet de rol, de verantwoordelijkheden en de reikwijdte van de verwerking door de verwerker duidelijk omschrijven: welke persoonsgegevens verwerkt men, de doeleinden van de verwerking en de duur van de verwerking.
2. De verwerker moet passende technische en organisatorische maatregelen nemen om de persoonsgegevens te beschermen en de vertrouwelijkheid, de integriteit en de beschikbaarheid ervan te waarborgen.
3. Klassiek is de opname van het ‘doorwerken’ van de bescherming, onder andere rond het gebruik van zelfstandige dienstverleners en/of subverwerkers door de verwerker. De verwerkersovereenkomst moet bepalen of en onder welke voorwaarden men subverwerkers mag inzetten.
4. Procedures om te zorgen dat men de rechten van de betrokkenen (de personen van wie gegevens worden verwerkt) respecteert, zoals het recht op inzage, correctie en verwijdering van hun gegevens.
5. Richtlijnen voor het omgaan met datalekken, inclusief meldingsplichten.
6. Audit- en controlerechten: afspraken alleen zijn niet voldoende; de verwerkingsverantwoordelijke last bij voorkeur een duidelijk recht in om audits uit te voeren of te laten uitvoeren om te controleren of de verwerker de AVG/GDPR-regels ook werkelijk naleeft.
7. Dataoverdracht : de wetgeving voorziet duidelijke beperkingen en voorwaarden voor de overdracht van persoonsgegevens naar landen buiten de Europese Economische Ruimte (EER).
8. Beëindiging van de overeenkomst : niet steeds op de voorgrond, maar het is essentieel om te voorzien wat men exact moet regelen rond de verwijdering of teruggave van de persoonsgegevens na afloop van de dienstverlening.