IT-dienstverleningsovereenkomst: waar let u op?

Gepubliceerd op 30 augustus 2025 · Laatst bijgewerkt op 7 oktober 2026

Een IT-dienstverleningsovereenkomst legt vast welke IT-diensten een leverancier levert, op welk niveau, tegen welke vergoeding en wat er gebeurt als het misgaat. De wet vult veel open punten zelf in, meestal met de regels voor de overeenkomst van opdracht, maar die wettelijke regels passen zelden goed bij IT-dienstverlening. Wat u niet vastlegt over scope, service levels, intellectueel eigendom, aansprakelijkheid en exit, kan u later veel geld kosten.

Hieronder leest u welke onderdelen in een goede IT-dienstverleningsovereenkomst horen, hoe u een service level agreement meetbaar maakt, wat de wet zegt als het contract zwijgt, en waar u bij onderhandelen, beheren en beëindigen op let.

Waarom is een goed IT-contract onmisbaar?

Zonder schriftelijk contract vallen partijen terug op aannames en mondelinge toezeggingen, en dat leidt snel tot conflicten. Een IT-dienstverleningsovereenkomst legt de rechten en plichten van beide partijen vast en gaat daarmee verder dan een offerte.

Een IT-contract voorkomt misverstanden over wat er wordt geleverd en geeft u een houvast als de dienstverlening tekortschiet. Het is zowel een juridisch vangnet als een praktisch stuurinstrument voor de dagelijkse samenwerking.

IT-dienstverlening loopt uiteen van cloudopslag en softwareontwikkeling tot beveiliging, netwerkbeheer en werkplekbeheer. Steeds vaker gaat het om doorlopende diensten waarvan de bedrijfsvoering van de klant direct afhankelijk is. Valt het systeem van een webwinkel een dag uit, dan loopt de omzet direct weg. Een vage afspraak over ondersteuning is dan niet genoeg.

Een moderne overeenkomst legt in elk geval vast:

• welke diensten precies worden geleverd, zoals onderhoud, ontwikkeling, hosting of een combinatie;
• welke service levels gelden, zoals reactietijden bij storingen en de gegarandeerde beschikbaarheid;
• wie eigenaar wordt van de ontwikkelde software, documentatie en ontwerpen;
• welke aansprakelijkheid geldt als een van de partijen tekortschiet;
• hoe de samenwerking eindigt en hoe gegevens en kennis worden overgedragen.

Een goed contract werkt vooraf, niet achteraf. Het schept duidelijkheid voordat er een probleem ontstaat, in plaats van dat partijen na een storing moeten uitzoeken wat zij eigenlijk hadden afgesproken.

Welke onderdelen horen in een IT-dienstverleningsovereenkomst?

De kern bestaat uit een heldere omschrijving van de diensten, afspraken over intellectueel eigendom, aansprakelijkheid, geheimhouding en de verwerking van persoonsgegevens. Ontbreekt een van die onderdelen of is het vaag, dan loopt de samenwerking bij de eerste tegenvaller vast.

Hoe bakent u de scope van de diensten af?

De scopeomschrijving beschrijft precies welke taken en verantwoordelijkheden de leverancier op zich neemt. Het is het belangrijkste onderdeel van het contract, omdat de meeste geschillen over de vraag gaan of iets wel of niet was afgesproken.

Vergelijk het met een boodschappenlijst. Staat er alleen eten op, dan komt u met de verkeerde spullen thuis. Staat er twee liter halfvolle melk, een volkorenbrood en een kilo appels, dan is de kans op succes veel groter.

Een omschrijving als het leveren van IT-support nodigt uit tot scope creep: de klant vraagt gaandeweg steeds meer, zonder dat daar budget of tijd tegenover staat. Omgekeerd kan de leverancier werk als meerwerk factureren dat de klant als inbegrepen beschouwde. Een goede scopeomschrijving bevat daarom:

• specifieke taken, bijvoorbeeld maandelijks serveronderhoud met installatie van beveiligingsupdates en het maken van back-ups;
• duidelijke uitsluitingen, bijvoorbeeld dat hardwarereparaties en ondersteuning van privésoftware buiten de dienst vallen;
• concrete opleveringen, bijvoorbeeld een maandelijks rapport over prestaties en beschikbaarheid;
• de verplichtingen van de klant zelf, zoals het tijdig aanleveren van informatie en toegang tot systemen.

Dat laatste punt wordt vaak vergeten. Loopt een project vertraging op omdat de klant niet tijdig meewerkt, dan kan de leverancier zich daarop beroepen. Leg daarom ook vast wat de leverancier van de klant nodig heeft.

Wie wordt eigenaar van de ontwikkelde software?

Zonder afspraak blijft de leverancier, als maker, in de regel rechthebbende op de software die hij ontwikkelt. De klant krijgt dan alleen een gebruiksrecht, en de omvang daarvan is vaak onduidelijk.

Wil de klant eigenaar worden, dan moet het auteursrecht worden overgedragen. Volgens artikel 2 van de Auteurswet kan dat alleen bij een akte, een ondertekend document waarin de overdracht staat. Een mondelinge toezegging of een verwijzing in een offerte is niet genoeg.

Vaak draagt de leverancier het maatwerk na volledige betaling over, maar behoudt hij de rechten op generieke componenten, bibliotheken en eigen hulpmiddelen die hij ook voor andere klanten gebruikt. De klant krijgt daarop een licentie. Leg vast welke onderdelen maatwerk zijn, welke standaard, en wat de klant met beide mag doen. Let ook op opensourcecomponenten: de licentievoorwaarden daarvan gaan mee in het product.

Intellectueel eigendom omvat meer dan code. Het gaat ook om documentatie, ontwerpen, databases en andere resultaten die tijdens het project ontstaan. Voor de klant is ook de broncode van belang: zonder toegang tot de broncode kan hij de software niet door een andere partij laten onderhouden. Een escrowregeling, waarbij de broncode bij een onafhankelijke partij wordt gedeponeerd, kan dat risico ondervangen.

Hoe regelt u aansprakelijkheid en verzekering?

De aansprakelijkheidsclausule bepaalt wie welk financieel risico draagt als het misgaat. Leveranciers beperken hun aansprakelijkheid bijna altijd, bijvoorbeeld tot het bedrag dat de klant in de laatste zes of twaalf maanden heeft betaald.

Een datalek, een langdurige storing of een fout in de software kan veel schade veroorzaken. Zonder beperking is de leverancier volgens de wet aansprakelijk voor alle schade die het gevolg is van zijn tekortkoming (artikel 6:74 BW). Een beperking is tussen bedrijven in beginsel toegestaan. Volgens vaste rechtspraak kan een leverancier zich er echter niet op beroepen bij opzet of bewuste roekeloosheid van hemzelf of zijn leidinggevenden.

Zorg dat de grenzen in verhouding staan tot de schade die kan ontstaan. Let op uitsluitingen van gevolgschade, gederfde winst en verlies van gegevens: juist dat is bij IT-storingen vaak de grootste post. Vraag daarnaast of de leverancier een beroeps- of bedrijfsaansprakelijkheidsverzekering heeft, voor welk bedrag, en vraag om een bewijs daarvan.

Wat regelt een geheimhoudingsclausule?

Tijdens een IT-project deelt u vaak gevoelige informatie met de leverancier, zoals klantgegevens, financiële cijfers en strategische plannen. Een geheimhoudingsclausule verplicht beide partijen die informatie vertrouwelijk te houden, tijdens en na de samenwerking.

Een goede clausule omschrijft wat onder vertrouwelijke informatie valt, voor wie binnen de organisatie de informatie toegankelijk mag zijn en hoe lang de plicht geldt. Een boete bij schending maakt de clausule beter afdwingbaar, omdat u dan niet de precieze schade hoeft te bewijzen.

Wanneer heeft u een verwerkersovereenkomst nodig?

Verwerkt de leverancier persoonsgegevens voor u, bijvoorbeeld bij hosting of beheer van een klantensysteem, dan is hij verwerker in de zin van de Algemene verordening gegevensbescherming (AVG). U bent dan verplicht met hem een verwerkersovereenkomst te sluiten (artikel 28 AVG).

Daarin staan onder meer de beveiligingsmaatregelen, de inschakeling van subverwerkers, de meldplicht bij een datalek en wat er na afloop met de gegevens gebeurt. De verwerkersovereenkomst kan een bijlage bij de IT-dienstverleningsovereenkomst zijn. Let erop dat de aansprakelijkheidsregeling in beide documenten op elkaar aansluit.

Mag de leverancier derden inschakelen?

Veel IT-leveranciers besteden delen van hun dienst uit, bijvoorbeeld hosting aan een datacenter of ontwikkeling aan freelancers. Leg vast of dat mag, onder welke voorwaarden en wie daarvoor aansprakelijk blijft.

Volgens de wet blijft de leverancier tegenover u aansprakelijk voor de hulppersonen die hij inschakelt (artikel 6:76 BW). In de praktijk proberen leveranciers die aansprakelijkheid te beperken, bijvoorbeeld door te bepalen dat zij niet instaan voor storingen bij het datacenter of bij een cloudplatform. Weet daarom welke partijen in de keten zitten en waar uw gegevens worden opgeslagen. Voor persoonsgegevens geldt bovendien dat subverwerkers alleen met uw toestemming mogen worden ingeschakeld en dat voor opslag buiten de Europese Economische Ruimte extra waarborgen nodig zijn. Een eenvoudige lijst van onderaannemers als bijlage bij het contract, met een meldplicht bij wijzigingen, voorkomt verrassingen.

Welke clausules controleert u in elk geval?

Gebruik het overzicht hieronder om te controleren of uw overeenkomst de belangrijkste onderdelen bevat.

Hoe maakt u een service level agreement meetbaar?

Een service level agreement (SLA) vertaalt de beloften van de leverancier in meetbare prestaties. Zonder concrete cijfers en gevolgen bij het niet halen ervan is een SLA juridisch weinig waard.

Veel bedrijven brengen de SLA terug tot één getal, zoals 99,9 procent beschikbaarheid. Dat getal zegt weinig als niet vaststaat over welke periode wordt gemeten, of gepland onderhoud meetelt en wat als storing geldt. Een beschikbaarheid van 99,9 procent per maand laat ruim veertig minuten uitval toe; per jaar gemeten is dat bijna negen uur, die ook in één keer kan vallen.

Zonder gedetailleerde SLA werkt u op basis van aannames. U denkt misschien dat een kritieke storing binnen een uur wordt opgepakt, terwijl de leverancier uitgaat van een reactie binnen een werkdag.

Welke prestatie-indicatoren horen in een SLA?

Een goede SLA bevat prestatie-indicatoren voor alle belangrijke onderdelen van de dienst. De snelheid en kwaliteit van de ondersteuning bepalen vaak meer dan de beschikbaarheid alleen.

• Reactietijd: de maximale tijd tot de leverancier reageert op een melding, meestal verdeeld naar prioriteit, zoals kritiek, hoog en normaal.
• Oplostijd: de maximale tijd om een gemeld probleem op te lossen of een tijdelijke oplossing te bieden. Een printer die niet werkt is hinderlijk, een server die plat ligt is een ramp.
• Hersteltijd: de gemiddelde tijd om na een storing de dienst te herstellen.
• Oplossing bij eerste contact: het percentage meldingen dat de helpdesk direct afhandelt.

Leg ook vast wie meet, hoe wordt gemeten en hoe vaak de leverancier rapporteert. Zonder betrouwbare meting is er bij een geschil geen bewijs. Spreek daarom ook af dat u de meetgegevens zelf kunt inzien en dat u bij twijfel een onafhankelijke controle mag laten uitvoeren.

Wat als de leverancier de afspraken niet nakomt?

Een SLA heeft pas tanden als er gevolgen aan verbonden zijn. De meest gebruikte instrumenten zijn servicekortingen, boetes en een recht op beëindiging.

• Servicekortingen: een korting op de volgende factuur als een norm niet wordt gehaald. Dit is de meest gangbare vorm.
• Boetebeding: een vooraf vastgesteld bedrag bij het niet halen van een kritieke norm.
• Recht op beëindiging: bij herhaald of ernstig tekortschieten mag de klant de overeenkomst voortijdig beëindigen.

Let op de verhouding tussen deze regelingen en schadevergoeding. Volgens artikel 6:92 lid 2 BW treedt een boete in beginsel in de plaats van schadevergoeding. Is de werkelijke schade hoger dan de boete, dan kunt u die meerdere schade alleen vorderen als het contract dat uitdrukkelijk toestaat. Omgekeerd kan de rechter een buitensporig hoge boete matigen (artikel 6:94 BW). Leveranciers bepalen vaak dat servicekortingen de enige remedie zijn bij het niet halen van een SLA; lees zo’n clausule dus goed.

Het doel van deze gevolgen is niet in de eerste plaats straffen, maar de leverancier prikkelen om de afgesproken kwaliteit te leveren. Zo worden uw prioriteiten ook de prioriteiten van uw IT-partner.

Waarom is een vage SLA juridisch zwak?

Een SLA vol termen als zo snel mogelijk of een passende oplossing is juridisch nauwelijks afdwingbaar. U kunt dan niet objectief aantonen dat de leverancier tekortschiet.

Maak de afspraken daarom specifiek, meetbaar, haalbaar en tijdgebonden. Gebruik vaste definities voor begrippen als storing, beschikbaarheid en werkdag. Leg ook vast of een norm een inspanningsverplichting of een resultaatsverplichting is. Bij een inspanningsverplichting moet u bewijzen dat de leverancier niet genoeg zijn best heeft gedaan; bij een resultaatsverplichting is het niet halen van de norm op zichzelf al een tekortkoming.

Wat zegt de Nederlandse wet over IT-contracten?

Een IT-dienstverleningsovereenkomst is naar Nederlands recht meestal een overeenkomst van opdracht, of een mengvorm waarin opdracht de belangrijkste rol speelt. De regels voor opdracht gelden dan automatisch, tenzij u in het contract iets anders afspreekt.

Volgens artikel 7:400 BW is opdracht de overeenkomst waarbij de opdrachtnemer zich verbindt werkzaamheden te verrichten voor de opdrachtgever, anders dan op grond van een arbeidsovereenkomst. Denk aan beheer, advies, ondersteuning en ontwikkeling in regie.

Welke wettelijke regels gelden bij opdracht?

Spreekt u niets anders af, dan gelden onder meer de zorgplicht, de plicht tot verantwoording en de vrije opzegging door de opdrachtgever. Voor IT-dienstverlening zijn vooral deze regels van belang:

• Zorgplicht: de leverancier moet bij zijn werk de zorg van een goed opdrachtnemer in acht nemen (artikel 7:401 BW). Dat is een open norm: hij moet zorgvuldig en deskundig werken, maar garandeert in beginsel geen resultaat.
• Verantwoording: de leverancier moet de klant op de hoogte houden en verantwoording afleggen over de uitvoering (artikel 7:403 BW).
• Opzegging: de opdrachtgever kan de opdracht in beginsel altijd opzeggen (artikel 7:408 BW). Tussen bedrijven kan dat contractueel worden beperkt (artikel 7:413 BW).

Die standaardregels zijn niet altijd gunstig. Voor een leverancier die investeert in een langlopend contract is de ruime opzegmogelijkheid van de klant een risico. Voor de klant is de open zorgnorm vaak te vaag om op te bouwen. Daarom is het verstandig bewust van de wet af te wijken.

Wanneer gelden de regels voor aanneming, koop of huur?

Niet elk IT-contract is een opdracht. Wordt een vast omschreven systeem voor een vaste prijs gebouwd, dan kan het contract trekken hebben van aanneming van werk. Wordt standaardsoftware geleverd, dan komen de regels voor koop in beeld.

Bij software op een fysieke drager of met een eeuwigdurende licentie kunnen de regels over koop en non-conformiteit van toepassing zijn. Bij software als dienst (SaaS) lijkt de relatie soms op huur, maar is ze juridisch vaak een mengvorm. Het juiste regime bepaalt welke garanties en klachttermijnen gelden. Dat maakt het des te belangrijker om in het contract zelf te regelen wat de leverancier moet leveren en wanneer er sprake is van een gebrek.

Welke rol spelen algemene voorwaarden in de IT?

Veel IT-leveranciers werken met algemene voorwaarden, zoals de voorwaarden van de brancheorganisatie NLdigital. Die bevatten vaak ruime aansprakelijkheidsbeperkingen en eigen regels over intellectueel eigendom.

Algemene voorwaarden gelden alleen als ze zijn overeengekomen en tijdig ter hand gesteld. Stuurt de klant zijn eigen inkoopvoorwaarden mee, dan kan een zogenoemde battle of forms ontstaan: welke voorwaarden gelden dan? Volgens artikel 6:225 lid 3 BW gelden in beginsel de voorwaarden waarnaar het eerst is verwezen, tenzij de andere partij die uitdrukkelijk van de hand wijst. Regel dit in het contract zelf, zodat daar later geen discussie over ontstaat.

Hoe onderhandelt u over een IT-contract?

Bepaal vóór de onderhandeling wat voor u onmisbaar is en waar u ruimte hebt. Focus niet alleen op de prijs: de bepalingen over aansprakelijkheid, intellectueel eigendom en exit bepalen op lange termijn vaak meer dan een korting op de maandfactuur.

Stel uzelf vooraf deze vragen:

• Welke minimale service levels hebt u nodig om uw bedrijf draaiende te houden, zoals beschikbaarheid, reactietijd en oplostijd?
• Hoe belangrijk is het intellectueel eigendom: moet alle maatwerk uw eigendom worden, of volstaat een ruime licentie?
• Hoeveel risico kunt en wilt u dragen, en welke aansprakelijkheidsgrens is voor u aanvaardbaar?
• Hoe afhankelijk wordt u van deze leverancier, en hoe eenvoudig kunt u later overstappen?

Met die antwoorden onderhandelt u vanuit een helder kader en laat u zich minder snel meenemen door een overtuigend verkoopverhaal.

Welke valkuilen komen vaak voor?

Wees alert op vage taal en beloften die te mooi klinken. Een leverancier die belooft alles zo snel mogelijk op te lossen of optimale prestaties te leveren, geeft in feite geen concrete toezegging.

1. Vage formuleringen: vraag om concrete, meetbare afspraken. Vervang regelmatig onderhoud door maandelijks onderhoud in een vast onderhoudsvenster.
2. Verborgen kosten: vraag naar tarieven voor meerwerk, licentiewijzigingen, extra opslag en ondersteuning buiten kantoortijden.
3. Eenzijdige wijzigingen: veel standaardvoorwaarden geven de leverancier het recht prijzen of diensten tussentijds te wijzigen. Beperk dat recht of koppel er een opzegmogelijkheid aan.
4. Onrealistische normen: een belofte van 100 procent beschikbaarheid is technisch vrijwel onhaalbaar. Het kan een signaal zijn dat de leverancier de complexiteit onderschat.

Vraag door tot elke clausule helder is. Een goede partner neemt de tijd om zijn voorstel uit te leggen.

Hoe beheert u het contract na de ondertekening?

Na de ondertekening begint het beheer. Een IT-contract werkt alleen als u de prestaties volgt, wijzigingen vastlegt en problemen tijdig escaleert.

Plan vaste evaluatiemomenten, bijvoorbeeld ieder kwartaal, waarin u met de SLA-rapportages in de hand de prestaties bespreekt. Een goed beheerproces bevat:

• periodieke evaluaties van samenwerking en prestaties;
• kritische controle van de SLA-rapportages van de leverancier;
• een wijzigingsprocedure voor het aanvragen en goedkeuren van aanpassingen in scope of diensten;
• een escalatieprocedure die vastlegt wie aan beide kanten wordt ingeschakeld als problemen op operationeel niveau niet worden opgelost.

Leg afspraken die tijdens de looptijd worden gemaakt schriftelijk vast. Een mondeling akkoord over extra werk of een lagere norm leidt later gemakkelijk tot discussie over wat er geldt.

Wat doet u als de leverancier tekortschiet?

Schiet de leverancier structureel tekort, stel hem dan schriftelijk in gebreke en geef hem een redelijke termijn om alsnog na te komen. Pas daarna is hij in de regel in verzuim en kunt u schadevergoeding vorderen of de overeenkomst ontbinden (artikelen 6:74 en 6:265 BW).

Een ingebrekestelling is niet nodig als nakoming blijvend onmogelijk is of als uit de houding van de leverancier blijkt dat hij niet zal nakomen. Bij IT-projecten is dat moment vaak niet scherp. Een klant die maandenlang klaagt maar de leverancier nooit formeel een termijn stelt, kan later moeite hebben om te ontbinden. Documenteer daarom de tekortkomingen en de correspondentie.

Waar let u op bij het beëindigen van de overeenkomst?

Regel vooraf de opzegtermijn, de gronden voor tussentijdse beëindiging en vooral de exit: hoe gegevens, documentatie en kennis worden overgedragen aan een nieuwe leverancier of aan uw eigen organisatie.

Zonder goede exitregeling kan een klant feitelijk gegijzeld worden, omdat een overstap te ingewikkeld of te duur is. Een sterke exitregeling bevat afspraken over:

• de overdracht van alle gegevens in een bruikbaar, gangbaar formaat;
• de verplichting van de vertrekkende leverancier om mee te werken aan de overgang, en tegen welk tarief;
• termijnen waarbinnen de overdracht is afgerond, en het doorlopen van de dienst tot dat moment;
• het documenteren en overdragen van kennis over de systemen en processen;
• het verwijderen van gegevens bij de leverancier na de overdracht.

Voor clouddiensten gelden sinds 12 september 2025 ook de overstapregels van de Europese Dataverordening. Aanbieders van clouddiensten moeten klanten onder meer in staat stellen over te stappen naar een andere aanbieder en daarbij hun gegevens mee te nemen; de kosten die zij daarvoor mogen rekenen worden stapsgewijs afgebouwd. Controleer of uw contract met deze regels in overeenstemming is.

Wat als de leverancier failliet gaat?

Gaat de leverancier failliet, dan beslist de curator of de dienstverlening wordt voortgezet. Voor een klant die volledig afhankelijk is van één leverancier, kan dat binnen enkele dagen tot een acuut probleem leiden.

De curator is niet verplicht de overeenkomst na te komen. Een klant kan de curator vragen binnen een redelijke termijn te laten weten of hij de overeenkomst gestand doet (artikel 37 Faillissementswet). Intussen kunnen servers worden uitgezet omdat de hostingpartij van de leverancier niet meer wordt betaald. Beperk dat risico vooraf met een escrowregeling voor broncode, met afspraken over directe toegang tot uw gegevens en met regelmatige back-ups die u zelf beheert of bij een andere partij onderbrengt. Controleer ook bij welke partijen de leverancier zelf de infrastructuur afneemt.

Waar let u als klant op?

• Controleer of het auteursrecht op maatwerk bij akte aan u wordt overgedragen (artikel 2 Auteurswet), of welke licentie u anders krijgt.
• Controleer of de aansprakelijkheidsgrens in verhouding staat tot de schade van een storing of datalek.
• Leg een exitregeling vast met overdracht van uw gegevens in een gangbaar formaat.
• Sluit een verwerkersovereenkomst als de leverancier persoonsgegevens voor u verwerkt (artikel 28 AVG).

Waar let u als IT-leverancier op?

• Beschrijf scope en uitsluitingen zo concreet dat meerwerk herkenbaar is.
• Leg vast welke medewerking u van de klant nodig hebt en wanneer.
• Beperk de vrije opzegging door de klant in het contract (artikel 7:413 BW).
• Stel uw algemene voorwaarden vóór of bij het sluiten van het contract ter hand.
• Leg per SLA-norm vast of het om een inspannings- of een resultaatsverplichting gaat.

Wat kunnen wij voor u doen bij een IT-dienstverleningsovereenkomst?

Wij staan klanten en leveranciers bij; meer leest u op de pagina over ICT-recht.

• Wij stellen de IT-dienstverleningsovereenkomst, de SLA en de verwerkersovereenkomst op, of beoordelen het concept van de wederpartij.
• Wij toetsen de aansprakelijkheidsbeperking en de algemene voorwaarden van de leverancier op de risico’s voor uw organisatie.
• Wij regelen de overdracht van intellectueel eigendom bij akte en waar nodig een escrowregeling voor de broncode.
• Wij stellen bij tekortschieten een ingebrekestelling met een redelijke termijn op, zodat daarna schadevergoeding of ontbinding mogelijk is (artikelen 6:74 en 6:265 BW).
• Wij begeleiden de exit en de overstap naar een nieuwe leverancier, ook als de leverancier failliet gaat (artikel 37 Faillissementswet).

Samengevat

• Een IT-dienstverleningsovereenkomst is meestal een overeenkomst van opdracht (artikel 7:400 BW); de wettelijke standaardregels passen zelden goed bij IT.
• Een heldere scopeomschrijving met uitsluitingen en verplichtingen van de klant voorkomt de meeste geschillen.
• Het auteursrecht op maatwerk blijft zonder akte van overdracht bij de leverancier.
• Een SLA werkt alleen met meetbare normen, betrouwbare meting en duidelijke gevolgen, zoals servicekortingen of een beëindigingsrecht.
• Een goede exitregeling en, bij persoonsgegevens, een verwerkersovereenkomst horen in elk IT-contract.

Veelgestelde vragen over IT-contracten

Law & More stelt IT-contracten, SLA’s en verwerkersovereenkomsten op, beoordeelt voorwaarden van leveranciers en staat partijen bij in geschillen over IT-projecten. Meer over onze werkzaamheden leest u op de pagina ICT-recht; voor algemene contractvragen kunt u ook ons artikel over de advocaat contractenrecht raadplegen.