Is een SaaS dienstverlener vanwege de AVG verplicht escrow op te zetten?

Een lezer vroeg me:

Strekt de AVG zover dat softwarepartijen verplicht zijn – in het kader van beveiligen van de continuiteit – een escrowachtige regeling aan te bieden waarbij software en hosting geborgd zijn na een faillissement of overname?
De AVG verplicht tot adequate maatregelen tot beschikbaar houden van persoonsgegevens zo lang als dat nodig is voor de toegezegde dienstverlening en de rechten van betrokkenen. Er is dus nergens een algemeen lijstje met wat je moet doen of hoe lang, je moet zelf beredeneren (al dan niet in een DPIA) wat er nodig is om aan deze eis te voldoen.

Een partij die een softwaredienst met persoonsgegevens aanbiedt, moet er dus voor zorgen dat die dienst blijft draaien zo lang als nodig. Escrow of een continuïteitsregeling is daarvoor een mogelijk middel. Maar als er andere manieren zijn om de klanten te blijven bedienen, dan is dat ook prima. Een offline backup die in noodgevallen naar de klanten gestuurd kan worden, zou ook kunnen werken.

Bij faillissement zal de dienstverlening gewoonlijk eindigen, hoewel dat niet wil zeggen dat de betrokkenen dan geen rechten meer hebben. Dus formeel zou ik zeggen dat er dan iets van continuïteit moet zijn, hoewel dat praktisch gezien lastig af te dwingen is want de organisatie is dan nou eenmaal failliet en dan houdt het gewoon op.

Het grote probleem met escrow is dat het daadwerkelijk uitvoeren pittig kan zijn: ga er maar aan staan om vanuit een broncodedepot een online dienst weer neer te zetten. Zat de database met gegevens bijvoorbeeld ook in het depot? Hoe oud was die databasedump dan eigenlijk?

Een overname is geen excuus voor welke wijziging in de dienstverlening dan ook. Daar moet de dienst dus gewoon doorlopen en moeten de gegevens gewoon beschikbaar zijn.

Het maakt natuurlijk ook nog uit of het softwarebedrijf een verwerkingsverantwoordelijke is of een verwerker. Als dat laatste het geval is, dan zal de afnemer van de dienst meer stappen moeten nemen om zich tegen uitval van die verwerker te wapenen. Escrow of continuïteit ligt dan meer voor de hand.

Arnoud

7 reacties

  1. Bij faillissement speelt natuurlijk mee dat de AVG verplichtingen per direct overgaan op de curator, en, in tegenstelling tot contractuele verplichtingen, moet hij zich ook op eigen titel blijven houden aan de AVG. Zolang deze denkt een doorstart te kunnen maken, is er een gerechtvaardigd belang de gegevens te behouden (maar moet hij aan wel de verplichtingen uit de AVG voldoen: dus voldoen aan informatie- en verwijderverzoeken); gaat hij over tot het opbreken van de boedel en alles los veilen, dan mag hij de gegevens niet verwerken. Omdat verwijderen ook een vorm van verwerken is, moet hij dat kunnen rechtvaardigen. Ik denk dat het kunnen verkopen (of afvoeren) van de hardware waar de gegevens op staan voldoende “eigen belang” opleveren, maar krijg de indruk dat dit makkelijk fout kan gaan.

  2. Een specifiek voorbeeld van een soort van continuiteitseis is wettelijk opgelegd aan de banken. Als een bank failliet gaat, moet deze een bestand van alle klanten met hun actuele tegoeden kunnen opleveren aan de DNB, zodat deze het Deposito Garantiestelsel in werking kan zetten. Dit is een uitdraai van de stand van zaken op het moment van failliesement, in een gestandariseerd formaat. Banken moeten jaarlijks aantonen dat zij deze uitdraai met niet veel meer werk dan een druk op de knop kunnen leveren. Je zou aan iets dergelijks kunnen denken voor data-dienstverleners, maar zelfs dan heb je een stuk wettelijke grondslag nodig om de curator daar toe te dwingen.

  3. ga er maar aan staan om vanuit een broncodedepot een online dienst weer neer te zetten

    Een code escrow is volslagen onzinnig. Dat gaat een gemiddelde SaaS-gebruiker niets helpen. Zelfs niet als de code & documentatie volledig en uptodate zijn en ze toevallig zelf een heel recente backup hebben van de data (in een voor terugzetten geschikt formaat). De tijd die het zou kosten om weer up en running te komen voor de korte tijd dat je het zou willen, is vast groter dan de tijd die het kost om met alleen de data naar een andere SaaS-dienst te stappen.

    Ik mag hopen dat er eerder een SaaS-escrow waar “de servers as-is doorgaan” (zeg ik erg kort door de bocht) wordt overwogen door de verantwoordelijke. En dan alsnog zsm migreren.

    1. Dat is dus wat wij vanuit ICTRecht ook altijd pushen. Een simpele constructie is een stichting met een potje geld die de hoster van de SaaS-dienstverlener dan nog drie maanden doorbetaalt. Als het even kan inclusief wat geld voor het periodiek resetten van de server.

      Ik ken ook oplossingen waarbij men de SaaS oplossing geheel in een VM realiseert en daar een image van dumpt. Die image zet je dan terug op een nieuwe server en je gaat gewoon verder. Dat hadden ze twintig jaar geleden moeten zeggen, mag ik even uw softwaredienst in een zipfile stoppen voor het geval dat?

  4. Ik zal niet betwisten dat een dergelijke continuiteitsregeling wenselijk is, om vele redenen.

    Maar hebben we nu echt de AVG nodig om dat af te dwingen? Ik krijg echt het gevoel dat, hoe wenselijk de uitkomst ook is, dit een gebruik is van de AVG dat nooit gewenst, noch voorzien, is door de wetgever.

    In bijna alle databases zit wel ergens een persoonsgegeven. Om nu op basis van de AVG maar allerlei technisch/organisatorische noodvoorzieningen, in de hele keten, te gaan eisen, gaat wel wat ver, of niet.

    Jouw spreuk ‘data is niets’, met alle (eigenlijk maatschappelijk onwesenlijke) gevolgen van dien, zal dan worden ‘de meeste data is AVG-data’, ook met alle maatschappelijke gevolgen van dien.

    Meer bescherming voor data is prima, maar we moeten niet alles willen ophangen aan de AVG.

    1. Dat klopt. Deel van onze continuïteitsconstructie is dus ook een zzp contract met die mensen te sluiten (onder opschortende voorwaarde van faillissement werkgever en met waiver van hun geheimhouding & concurrentiebeding) waarin ze tegen een leuk uurtarief medewerking toezeggen. Dat dit niet eenvoudig is, lijkt me duidelijk.

Geef een reactie

Handige HTML: <a href=""> voor hyperlinks, <blockquote> om te citeren, <UL>/<OL> voor lijsten, en <em> en <strong> voor italics en vet.