Advocaten en notariaat in Leiden en Den Haag
Menu

Uitbesteden is nog steeds hot . Uit een recent onderzoek blijkt dat de Nederlandse IT-outsourcingmarkt zal blijven groeien. Toch zijn er ook bedrijven die aarzelen of juist gas willen terugnemen. Die aarzeling is niet onbegrijpelijk. IT-outsourcing blijft complex. Ook vanuit juridisch oogpunt.

Nog steeds groei

Bijna de helft van de respondenten geeft aan dat ze de komende twee jaar in een hoger tempo te zullen uitbesteden. Dit is momenteel het hoogste niveau in Europa. De plannen om te insourcen zijn gehalveerd, van 16% naar 8%. De financiële dienstverleningssector voorspelt de meeste outsourcinggroei: 64% van de organisaties is van plan meer uit te besteden. De hoofdredenen om te gaan outsourcen zijn: focus op kernactiviteiten, terugdringen van IT-kosten en verbetering van de IT-ondersteuning. Door outsourcing kun je focussen op waar je sterk in bent en ondersteunende taken, zoals IT, overdragen aan partijen die dáár sterk in zijn en ook schaal in hebben. Door die schaal kunnen deze partijen meer kwaliteit leveren tegen lagere kosten.

(Juridische) pitfalls

Onvoldoende oog voor eventuele beperkingen in licentievoorwaarden is een bekende juridische pitfall. In licentievoorwaarden van softwareleveranciers zijn immers vaak beperkingen opgenomen die outsourcing niet toestaan. Handelen in strijd met deze voorwaarden kan bedrijven duur komen te staan. Andere pitfalls zijn: geen heldere en meetbare service levels voor het gewenste niveau van dienstverlening, onvoldoende aandacht voor het borgen van de continuïteit van de dienstverlening, onvoldoende oog voor compliance met voorschriften en regelgeving en het ontbreken van een exitprocedure die de continuïteit van de dienstverlening waarborgt in de situatie dat partijen uit elkaar gaan.

Tips

Een outsourcing vergt een goede voorbereiding en een goede samenwerking, óók met juristen. Vanuit onze jarenlange ervaring met outsourcingstrajecten, geven wij u alvast de volgende tips mee:

Contracting with U.S. cloud service providers is a hot topic. This has everything to do with, on the one hand, the dominant position of American players in the global IT services market and, on the other hand, the strict European legislation on the transfer of personal data. Under what conditions can U.S. cloud service providers still be used? An overview and update.

The Internet is American

In many ways, the Internet is an American invention. In the 1960s, the U.S. Department of Defense was looking for a way for its globally-based personnel to exchange information regardless of where those personnel were located and regardless of the type of device they were working on. That system became ARPANET and ARPANET eventually became the Internet.

Much of today’s Internet infrastructure is still designed and built by American companies. This applies to the hardware (HP, Apple, Dell), the chips (Intel, Qualcomm) and to routers and modems (Cisco, Juniper). The market for web services and platforms for e-mail and cloud storage is also mainly in the hands of a few large U.S.-based players (Google, Oracle, Amazon, Microsoft). As a result, European organizations and companies are in many cases dependent on American parties for their IT needs.

European restrictions

Since 1981, a special legal regime has existed in Europe for the processing and transfer of personal data. This legal regime, which has meanwhile been laid down in Chapter V of the General Data Protection Regulation (GDPR), imposes restrictions on the free transfer of personal data. Under the GDPR, personal data can circulate freely within the European Economic Area (EEA), but the transfer of personal data to a country or territory outside the jurisdiction of one of the EEA member states is only permitted if strict requirements are met. The European legislator thus wanted to prevent the level of legal protection that the GDPR aims to guarantee from being easily circumvented by transferring data processing activities abroad.

Since a lot of computing power and data processing has been moved from local PCs to central servers of cloud service providers since the 10s, the legal regime on international data transfers has grown significantly in importance.

Three-pronged analysis

In the event of an international data transfer, it must be assessed on the basis of a three-pronged analysis whether the transfer is permitted. If the European Commission has declared that a country outside the EEA offers an adequate level of protection, then personal data may be transferred to that country on the basis of the relevant adequacy decision. In the absence of an adequacy decision, appropriate safeguards are required. The most important appropriate safeguards in practice are the Standard Contractual Clauses (SCCs) and Binding Corporate Rules (BCRs). If there are no appropriate safeguards either, a transfer may still be permitted in a few specific situations under strict conditions.

Schrems I and II

For the U.S., an adequacy decision has been issued twice by the European Commission. The first decision was better known as Safe Harbor and the second decision as the Privacy Shield. Both decisions were declared invalid by the Court of Justice of the European Union in 2015 (Schrems I) and 2020 (Schrems II), respectively. According to the CJEU, the agreements made in both instruments do not result in a level of protection for personal data that broadly corresponds to the level of protection in the Union. The European Commission should therefore not have issued the adequacy decisions.

According to the CJEU, the ‘shortage’ of protection in the U.S. lies in the fact that the powers of American intelligence agencies are formulated too broadly. Firstly, this concerns legislation that gives intelligence agencies the power to demand information concerning non-Americans from internet service providers and telecommunications companies (FISA 702). Second, it concerns the power to tap on submarine cables on the Atlantic seabed, and to collect and store this data before it arrives on U.S. territory (E.O. 12333). By European standards, this legislation contains insufficient guarantees to ensure that such far-reaching powers are only used when strictly necessary, according to the CJEU.

The Privacy Shield is dead, long live the SCCs?

The Privacy Shield can therefore no longer be used as a transfer mechanism. The question then arises as to whether it is possible to switch to the ‘second’ instrument, the appropriate safeguards. Unfortunately, this is difficult. In Schrems II, the CJEU also ruled that the SCCs and other appropriate safeguards do not operate in a vacuum. Companies wishing to transfer personal data on the basis of these tools must assess on a case-by-case basis whether the safeguards are actually effective. Sometimes additional safeguards will be required.

This reasoning is understandable. After all, SCCs do not alter or limit the powers of U.S. intelligence agencies. Nothing in the SCCs prevents the NSA from requisitioning data under FISA 702 or the CIA tapping submarine cables under E.O. 12333. It would be strange if, because of those broad powers, a transfer could not be based on an adequacy decision, but could still be based on the SCCs that do not contain any guarantees against these broad authorities.

CLOUD Act

In 2013, Microsoft was ordered by a U.S. judge to surrender emails sent through its email platform (hotmail.com, msn.com, outlook.com) in connection with an investigation into illegal drug trafficking. The emails in question were stored on servers in Dublin, Ireland. Microsoft believed that the U.S. court had no jurisdiction to issue an injunction over data stored outside the U.S. and refused to comply with the injunction.

Microsoft was unsuccessful in first and second instance, but was successful on appeal to the Second Circuit Court in July 2016. According to the Second Circuit Court, there were insufficient leads to believe that the law on which the order was based had “extraterritorial” effect. While the case then went to the Supreme Court, Congress passed a new law called the Clarifying Lawful Overseas Use of Data Act (CLOUD Act). As the title implies, this law clarified that a court order can also apply to data stored on servers outside the United States.

Under the CLOUD Act, U.S. law enforcement agencies can thus recover data held by U.S. cloud service providers, regardless of where that data resides. This risk can be mitigated by making proper arrangements about inter alia encryption and about the IT supplier’s obligation to examine and challenge information requests.

Key attention points

Effectively, the foregoing means that the following attention points should at minimum be considered when contracting with U.S. cloud service providers.

  1. The transfer of personal data to a cloud service provider in the U.S. who must be able to access the data in the clear is effectively no longer possible since Schrems II. Not even when using SCCs.
  2. There is still scope to transfer personal data to the U.S. when the data (i) are pseudonymised; or (ii) encrypted with the cryptographic keys remaining under the control of the data exporter within the EEA.
  3. Today, almost all major cloud service providers offer the option of contractually agreeing that customer data will only be stored on servers within the EEA. Note that such an option generally only applies to data storage at rest and not to (i) customer data in transit; (ii) meta-data; and (iii) data processed in the context of support. Increasingly, cloud service providers are making efforts to keep such data also within EEA borders.
  4. Even if customer data is stored at rest in the EEA, U.S. cloud service providers may still be required under the CLOUD Act to transfer this data to U.S. government agencies. This risk can be mitigated by making proper arrangements about encryption and about examining and challenging information requests.
  5. Customers should carry out a thorough data transfer impact assessment (DTIA) to ensure that the above points are reviewed and that a documented risk assessment has been made.

Would you like to learn more about contracting with U.S. cloud service providers or need help conducting a DTIA? Feel free to contact our team.

Jeroen van Helden, attorney at law

Inschrijvingen voor it-aanbestedingen zijn aan zeer strikte regels gebonden. Een kleine fout of omissie bij de inschrijving is genoeg om uit de procedure te worden verwijderd. Aan dit formalisme wordt echter met steeds meer succes gemorreld. Herstel van sommige fouten is toegestaan. Rechters kiezen steeds meer voor de menselijke maat, constateren Menno de Wijs en Jeroen van Helden in hun artikel in AG Connect (mei 2022).

De wet van Moore heeft bewezen dat ontwikkelingen in de chipindustrie zeker niet stilstaan. In de juridische wereld is die vooruitgang minder eenvoudig te meten. Het IT-aanbestedingsrecht was echter ook in 2021 weer volop in beweging. Waar de chipindustrie mikt op meer transistors op een chip, roept men binnen de wereld van het aanbestedingsrecht juist om minder: minder regels en een minder formalistische opstelling van aanbestedende diensten.

Nieuwe wet- en regelgeving aanbestedingen

De wens brengt ons allereerst bij een in 2021 gepresenteerde wetswijziging van de Aanbestedingsweg. Aanbestedende diensten worden verplicht een onafhankelijk klachtenloket in te stellen. Dat zou moeten leiden tot minder procedures bij de rechtbanken en tot een snellere oplossing van klachten. De wetswijziging moet leiden tot een betere (rechts)bescherming van inschrijvers. Er komen dan ook meer eisen aan de motiveringsplicht bij selectie- en gunningsbeslissingen en het wordt makkelijker om een overeenkomst van de concurrent te vernietigen. Zo komt er een gloednieuwe vernietigingsgrond voor het geval sprake is van een grove schending van het aanbestedingsrecht. Bedoeling is dat het wetsvoorstel wordt aangenomen en in werking zal treden. Ultiem voorbeeld van formalisme zijn waarschijnlijk de zogenaamde rechtsverwerkingsclausules. Denk aan de bepaling dat het stellen van vragen altijd leidt tot verval van het recht om te mogen klagen. Dat is niet (meer) toegestaan, zo bepaalt de herziene Gids Proportionaliteit, die per 1 januari 2022 in werking is getreden. Nieuw is ook dat een aanbesteding dienst niet meer op voorhand mag bepalen dat het indienen van een klacht niet zal leiden tot opschorting van de lopende termijnen.

Verder lezen, download het volledige artikel (PDF) van Menno de Wijs, advocaat aanbestedingsrecht, en Jeroen van Helden, advocaat IT,  zoals dat is verschenen in AG Connect Mei 2022.

De waarde van informatie is sterk gestegen sinds de overgang van industriële ontwikkeling naar een kenniseconomie. Door de snelle groei van de afgelopen jaren zijn systemen erg complex geworden. Dit brengt uitdagingen met zich mee voor de veiligheid van informatie.

Design-thinking

Innovatie brengt veel voordelen met zich mee, maar het is belangrijk om onze persoonlijke data te beschermen. Volgens Ann Cavoukian moet privacy benaderd worden vanuit een ‘design-thinking’ perspectief. Dit houdt in dat privacy als standaard wordt opgenomen in datasystemen en nieuwe technologieën. Privacy moet volledig geïntegreerd zijn in elk protocol en proces. Cavoukian introduceerde dit principe in de jaren ‘90 als ‘Privacy by Design’.

Privacy by Design

Privacy by Design (PbD) gaat uit van het principe dat bij het ontwerpen van een informatiesysteem, rekening wordt gehouden met privacy vanaf de start. Tijdens de gehele levensduur van het systeem wordt privacy toegepast. Het doel van PbD is om de beveiliging van persoonsgegevens te verbeteren. Cavoukian heeft zeven principes uitgewerkt die de basis vormen van Privacy by Design.

In deze blogpost werken we de principes verder uit.

Proactief in plaats van reactief; preventief in plaats van herstellen

Iets voorkomen werkt vaak beter dan het achteraf proberen op te lossen. Dit geldt ook voor privacy bij informatiesystemen. Het is beter om privacy vooraf mee te nemen in het ontwerp van het systeem zodat alle gaten gedicht kunnen worden. Als je achteraf de lekken wil dichten, loop je tegen meer problemen aan.

Privacy als standaard

Het principe van PbD streeft naar maximale veiligheid door te zorgen dat data automatisch beschermd is in IT systemen en de bedrijfsvoering. Personen hoeven zelf geen actie te ondernemen om hun privacy te beschermen, dit gebeurt automatisch.

Privacy geïntegreerd in het ontwerp

Vaak wordt privacy gezien als een functie van, of toevoeging op, een systeem. Hierdoor is de beveiliging niet geoptimaliseerd. Door privacy te integreren in het ontwerp, zorg je ervoor dat de privacy gegarandeerd goed zit in het systeem.

Volledige functionaliteit; ‘positive sum’ in plaats van ‘zero sum’

Privacy by Design streeft naar een win-win situatie. Functionaliteit en veiligheid gaan hand in hand, het één hoeft niet te wijken voor het ander.

Veiligheid van begin tot eind; bescherming tijdens de volledig levenscyclus

Doordat privacy in het systeem is opgenomen voordat de eerste data werd verzameld, kan veiligheid de gehele levenscyclus van het systeem gewaarborgd worden. Goede veiligheidssystemen zijn essentieel voor privacy, van begin tot eind. Dit zorgt ervoor dat data veilig wordt opgeslagen en aan het einde wordt vernietigd.

Zichtbaarheid en transparantie; houd het open

Privacy by Design informeert alle stakeholders over de gemaakte afspraken om verantwoordelijkheid af te dragen. Zichtbaarheid en openheid zijn belangrijk voor het opbouwen van vertrouwen en verantwoordelijkheid.

Respect voor de privacy; laat de gebruiker centraal staan

Privacy by Design vraagt de developers van een systeem om het belang van de gebruiker als hoogste prioriteit mee te nemen. Dit wordt gedaan door sterke privacy basisprincipes en gebruiksvriendelijke opties te bieden. De gebruiker wordt als centraal punt meegenomen in de opbouw van de systemen.

Neem contact op met onze IT en Privacy expert

Wil je meer weten over de implicaties van Privacy by Design? Neem dan contact op met onze expert op het gebied van IT en Privacy; Natascha van Duuren.

Voortschrijdende digitalisering, globalisering en een haast onbegrensde connected wereld stellen bestaande maatschappelijke verhoudingen op de proef. Daarbij komen dan nog de impact van de Covid-19 pandemie en wereldwijde handelsconflicten. Het belang van data en van toegang tot die data is meer dan ooit tevoren kraakhelder.

Hoe komt het nu dat sommige bedrijven er wél in slagen een succesvolle digitale transformatie door te maken en andere niet? Daarover schreef Natascha van Duuren samen met Ernst-Jan Louwers een hoofdstuk voor het boek Data Waarde Creatie – Zo verdien je geld in het digitale tijdperk (onder redactie van Ken van Ierlant en Fiona van Maanen).

Het hoofdstuk Digitale transformatie en het recht kunt u hier downloaden.

 

 

Beveiligingsincidenten en datalekken, ze lijken bijna net zo normaal te zijn geworden als de wekelijkse boodschappen. Recentelijk nog is de Gemeente Buren slachtoffer geworden van een hack met als resultaat dat 130 gigabyte aan (o.a. privacygevoelige) gegevens is gepubliceerd op het Dark Web. Wat kunt u als organisatie nu tegen beveiligingsincidenten en datalekken doen? En, biedt responsible disclosure wellicht een maatregel die vaak nog te onderbelicht is gebleven?

Beveiligingsincidenten en datalekken

Wanneer een inbreuk plaatsvindt op de beveiliging van een organisatie kan dit resulteren in een beveiligingsincident en in een datalek. Een beveiligingsincident is een inbreuk op de beveiliging waardoor (tijdelijk) de beschikbaarheid, integriteit of vertrouwelijkheid van data of systemen niet langer is geborgd. Van een datalek is, simpel gezegd, sprake als een inbreuk op de beveiliging tot resultaat heeft dat persoonsgegevens onrechtmatig kunnen worden verwerkt. Denk hierbij aan onrechtmatige toegang, inzage, verwijdering, etc.

Wat te doen tegen beveiligingsincidenten en datalekken?

Over wat organisaties tegen beveiligingsincidenten en datalekken kunnen doen, is reeds ontzettend veel geschreven. Denk hierbij aan tips als:

Een thema dat over het algemeen nog wat minder belicht is, maar dat volgens o.a. NCSC UK van groot belang is ter voorkoming van beveiligingsincidenten en datalekken, is het hanteren van responsible disclosure-beleid. Met responsible disclosure-beleid nodigt een organisatie de vinder van een kwetsbaarheid (zoals een toevalliger bezoeker, ethische hacker of beveiligingsonderzoeker) in bijvoorbeeld netwerk- en informatiesystemen uit om hiervan een melding te maken bij de organisatie (al dan niet tegen vergoeding). Door deze melding kan de organisatie de ontdekte kwetsbaarheid verhelpen voordat er misbruik van wordt gemaakt.

Recentelijk is (na vijf jaar overleg!) een nieuw protocol gepubliceerd als potentiële standaard voor het melden van kwetsbaarheden, namelijk: “Security.txt”. Dit protocol is ontwikkeld door de Internet Engineering Task Force (IETF).[1] Het idee achter Security.txt is eenvoudig: de organisatie plaatst een bestand met de naam security.txt op een voorspelbare plaats met hierin een link naar informatie over het beveiligingsbeleid van de organisatie en een e-mailadres voor contact.

Het doel van Security.txt is om het proces rondom het melden van kwetsbaarheden zo duidelijk, discreet en efficiënt mogelijk te maken. Het voordeel van het protocol is volgens het Digital Trust Center (DTC) dat het 1) relatief simpel te implementeren is, 2) eraan kan bijdragen dat kwetsbaarheden gemakkelijker en vaker worden gemeld, 3) het melden minder tijd kost en 4) organisaties sneller en efficiënter schadebeperkende maatregelen kunnen nemen. Een nadeel is volgens het DTC een mogelijke toename aan spam- en nepmeldingen op het voor de meldingen beschikbaar gestelde contactadres.

Kortom, gezien de voordelen van responsible disclosure – al dan niet in combinatie met Security.txt – is het overwegen hiervan in de strijd tegen beveiligingsincidenten en datalekken een absolute aanbeveling.

Overweegt u om gebruik te maken van responsible disclosure en/of heeft u ondersteuning nodig bij het voorkomen van beveiligingsincidenten en datalekken? Neem dan gerust contact op.

 

Michelle Wijnant, Advocaat IT, IE & Privacy

Deze blog is geschreven in samenwerking met Sander van Oostrom (student-stagiaire).

 

[1] IETF is een standaardenorganisatie die zich via discussies binnen de internetcommunity bezighoudt met het ontwikkelen van vrijwillige internetstandaarden.

Digitale veiligheid staat hoog op de agenda. Volgens het Cybersecuritybeeld Nederland 2021 is de technische laag waarop het Internet draait kwetsbaarder dan vaak gedacht, neemt misbruik van (zero day) kwetsbaarheden toe, worden DDoS aanvallen steeds krachtiger en is het infecteren van systemen met gijzelsoftware inmiddels uitgegroeid tot een solide verdienmodel voor criminelen met risico’s voor de nationale veiligheid.

De schade als gevolg van digitale beveiligingsincidenten – in de vorm van betaalde ransom, herstelkosten, bedrijfsstagnatie, reputatieschade, claims van derden en eventuele boetes van toezichthouders – kan enorm zijn. Steeds vaker dringen geschillen over de vraag wie opdraait voor de schade door tot de rechter.

Voor het boek ‘Multidisciplinaire aspecten van digital security’ schreef ik een hoofdstuk over aansprakelijkheid voor digitale beveiligingsgebreken. In het hoofdstuk komen diverse grondslagen aan de orde op basis waarvan naar Nederlands recht schadevergoeding gevorderd kan worden voor een digitaal beveiligingsgebrek, inclusief voorbeelden uit de rechtspraktijk. U kunt het hoofdstuk hier lezen.

Jeroen van Helden, advocaat IT, IE & Privacy

Een aantal gemeenten besluit gezamenlijk de aanschaf van een softwarepakket (een SaaS-oplossing) meervoudig onderhands aan te besteden. De waarde van de software ligt boven de € 50.000,- (maar onder het Europese drempelbedrag), zodat de meervoudig onderhandse procedure volgens de Gids Proportionaliteit de aangewezen route is. Meerdere partijen worden uitgenodigd en doen een inschrijving.

Tijdens het traject komen de gemeenten tot een andere visie op de eisen. Zij besluiten de aanbesteding in te trekken. Logischerwijs starten de inschrijvers geen kort geding, want vaste jurisprudentie is dat een aanbestedingsprocedure mag worden ingetrokken zonder dat daarvoor bijzondere omstandigheden zijn vereist (zie HvJEU 11 december 2014, C-440/13, ECLI:EU:C:2014:2435 (Croce Amica)).

Echter, vervolgens geven de gemeenten aan zij de opdracht ‘wezenlijk gewijzigd’ aan één van de inschrijvers hebben gegund. Enkelvoudig onderhands (lees: 1-op-1) en dus zonder procedure. Reden, de waarde zou toch onder € 50.000,- liggen, zodat 1-op-1 gunning toch was toegestaan. De gemeenten hebben aangegeven dat zij de uitvraag “wezenlijk gewijzigd” hebben en dat “helemaal is afgeweken van de oorspronkelijk opdracht”. Een nadere toelichting ontbreekt.

Logischerwijs kan één van de partijen die had ingeschreven (en nu dus volledig gepasseerd is) zich niet vinden in deze handelwijze. Zij start een kort geding, terwijl de overeenkomst inmiddels al is gegund.

De voorzieningenrechter (klik) acht deze handelwijze niet transparant. Geoordeeld wordt dat geen heldere en dat niet een voldoende objectieve rechtvaardiging is gegeven. Achteraf de redenen voor intrekking aanvullen is bovendien niet toegestaan, aldus de voorzieningenrechter. Er is een ontoelaatbaar risico van ongeoorloofde manipulatie, favoritisme en een kunstmatige beperking van de mededinging. De voorzieningenrechter verbiedt de gemeenten om nog langer uitvoering te geven aan de al gegunde overeenkomst. Kortom, het bezwaar is terecht en het traject moet opnieuw.

Menno de Wijs, advocaat aanbestedingsrecht

Recent onderzoek van de Universiteit Twente wijst uit dat in 2020 20% van de Nederlanders te maken heeft gehad met phishing. Uit cijfers van de Autoriteit Persoonsgegevens (AP) blijkt daarbij dat hacking, malware en phishing een toename van 30% aan incidenten hebben veroorzaakt in 2020 (vergeleken met 2019). Uit ander onderzoek blijkt daarnaast dat de financiële schade van phishing in 2020 ruim 12,8 miljoen euro bedroeg. Reden genoeg dus om het phishingbewustzijn binnen uw organisatie te vergroten.

Wat is phishing?

Phishing is een vorm van digitale oplichting waarbij cybercriminelen persoonsgegevens (zoals bank- of inloggegevens) proberen te verkrijgen. Phishing gebeurt via verschillende kanalen zoals e-mail, post, social media berichten, telefoontjes, WhatsApp en sms. Phishing kan zijn gericht op het verkrijgen van geld maar ook op het toebrengen van schade aan een organisatie. Door bijvoorbeeld via phishing inloggegevens te verkrijgen of malware te plaatsen, kan toegang worden verkregen tot de kantooromgeving. Eenmaal binnen, kunnen cybercriminelen verschillende activiteiten ontplooien. Zo kan gevoelige bedrijfsdata worden buitgemaakt en verkocht worden op het Dark Web, kan data worden versleuteld en worden teruggeven in ruil voor losgeld of kunnen urgente bedrijfsprocessen worden lamgelegd waardoor alles vastloopt. Het versturen van een goed phishingbericht is relatief simpel, de gevolgen kunnen daarentegen immens zijn.

Hoe herkent u phishing?

Goede phishingberichten zijn vaak moeilijk te herkennen. Desondanks zijn er een aantal elementen waarop u kunt letten om phishing te herkennen:

Wat kunt u doen tegen phishing?

Tegen phishing kunt u zowel technische als organisatorische maatregelen nemen. Phishing vindt echter op zoveel manieren massaal plaats dat het voor een organisatie simpelweg niet mogelijk is om alle phishingberichten met behulp van technische maatregelen tegen te houden. In de praktijk blijkt dat voor veel organisaties winst valt te behalen door het verhogen van de awareness van medewerkers. Zorg er daarom voor dat u binnen uw organisatie:

Mocht u ondersteuning behoeven bij aansprakelijkheidsstellingen als gevolg van een geslaagde phishingaanval of het treffen van organisatorische maatregelen hiertegen, neem dan gerust contact op.

Michelle Wijnant, Advocaat IT, IE & Privacy

In 2001, the authors of the Agile Manifesto probably could not foresee what flight the concept of ‘agile’ would take. Most software developers nowadays work on the basis of some form of lightweight development method and there are organisations that set up their entire (non-IT) organisation ‘agile’. Much has been written in the legal literature about the nature of software development agreements based on agile principles.

This literature usually amounts to a warning for the client who does business with an agile developer: if you do not make agreements about the end result to be achieved, you cannot hold a supplier liable for poor quality software.

We are now seeing the first case law on agile IT projects in the Netherlands. Do these rulings confirm the warnings in the literature?

Agile vs Waterfall

When applying the traditional waterfall method, the emphasis is on the design phase. In the design phase, all the technical and functional requirements for the software are drawn up. After this phase has been completed, the software is realized in its entirety, possibly divided into a handful of large components. This sounds logical, and makes contracting relatively easy, but in practice it  poses a number of problems. During the building process, new wishes and insights often arise. The waterfall method can then be experienced as a straitjacket, in which there is insufficient space for flexibility and manoeuvrability. In an extreme case, the software is delivered at the end of the project in accordance with design and planning, but the software does not meet the (actual) wishes of the customer. The agile approach offers a solution here.

In an agile working method, the emphasis is not on the design phase and formulating an end-result upfront, but on the process. Above all, there is an iterative, flexible process of software development. This usually means working with a central list of desired functionalities that have yet to be developed. These tasks are estimated by hours and prioritized. Within a fixed period of one or more weeks, the tasks with the highest priority are then taken up, with the intention that working software is delivered at the end of each sprint. By indicating the prioritization, the customer has a grip on what will be carried out and can easily adjust during the process. What the customer gains in flexibility, however, the customer may lose in terms of certainty about the end-result to be achieved.

Auction platform

Developer DPDK spends almost three years building an online auction platform for client Dream Bid on the basis of the agile method. The launch of the platform is delayed several times due to issues with the system’s performance. After go-live, these problems persist and it turns out that a definitive fix would require a complete “rebuild” of the platform’s architecture. Dream Bid wants to wait nor pay for this rebuild and sues DPDK for damages.

In court, DPDK defends itself stating that the parties agreed on an agile approach. The functionality to be delivered was not predetermined and therefore whatever issues existed they do not amount to breach of contract. Moreover, according to DPDK, the fact that the architecture is not suitable for the desired number of users is the result of Dream Bid’s changes during the course of the project, which incidentally fits with the agile approach, but again cannot result in breach of contract.

The court finds the defense unconvincing and rules in favor of Dream Bid. The court bases this conclusion on DPDK’s duty of care. A software development agreement qualifies as a contract for services (Article 7:400 Civil Code). The developer must therefore observe the care of a good contractor (Article 7:401 Civil Code). In other words, DPDK must behave as a reasonably competent and reasonably skilled IT service provider. According to the court, a reasonably competent IT service provider can be expected to have provided a platform with an acceptable performance. If that were no longer possible due to changing requirements, DPDK should have explicitly warned about this. The fact that work is done on an agile basis does not in any way affect this warning obligation, according to the court.

Investment platform

A somewhat similar project ended up before the district court in The Hague (the judgment has not been published, but I represented the supplier). For several years, a software developer works on an investment platform. At the start of the project, only the basic outline of the platform is clear and development takes place on the basis of agile principles, with many changes along the way. When go-live comes into view the performance does not meet the expectations of the customer. Go-live is delayed several times, the customer loses faith in the project and eventually terminates the agreement for cause.

The customer argues, among other things, that it was not sufficiently informed about the agile method and what that would mean for the project. It is also argued that the supplier has not warned sufficiently about the consequences of the customer’s changes during the project, resulting in long project duration and potentially inappropriate underlying architecture.

In this case, the court dismisses the customer’s claims. The assertion that the system was not working properly and that on that basis there would be a shortcoming is dismissed on formal grounds without touching on the substantive issues. With regard to the duty of care, the supplier is able to demonstrate, in the form of emails and other documents, that they have indeed informed the customer about the nature of agile projects and have warned the customer about the potential impact of certain changes in the project. The multi-million euro claim is therefore dismissed.

Provisional conclusion

The above judgments only come from lower courts and, moreover, strongly depend on the specific facts of those projects. One should caution to draw general conclusions too quickly on this basis. Nevertheless, a provisional conclusion may be appropriate.

The cases seem to underline that while it is relatively difficult to successfully hold a supplier liable in an agile project, this is by no means impossible. The most promising base will generally be the duty of care of the IT service provider. In particular, a supplier must clearly warn the customer when the customer (in its role of product owner) changes the course of the project in ways that affect the progress of the project or the suitability of the underlying architecture. As is evident from other IT cases, under certain circumstances, this could mean that a supplier must warn insistently, suggest alternatives or even refuse to proceed on a certain course.

In my opinion, both cases also illustrate a specific vulnerability of agile projects, in which, as mentioned, the emphasis is not on the design phase. There is therefore a chance that the actual wishes of the customer in terms of functionality and performance, which become clear during the project, ultimately do not match the underlying architecture of the solution. This is an important point to consider when starting an agile project.

Would you like to know more about the legal aspects of (agile) software development or IT projects? Feel free to contact our team.

Jeroen van Helden, attorney at law