Software as a Service: grip op data
Software-as-a-service (SaaS) is software die als online dienst wordt aangeboden. Denk hierbij aan een abonnement: een klant hoeft de data niet zelf aan te schaffen, maar krijgt toegang door iedere maand een bepaald bedrag te betalen. Veelal zullen zij toegang krijgen tot de data door middel van het dashboard van de aanbieder van de software. In de praktijk komt het voor dat deze klanten toegang willen tot de data via het dashboard van een derde partij. Het is in deze situatie belangrijk om goede afspraken te maken met deze derde partij: hoe houd je grip op de data?
In deze blog zal er gekeken worden naar de technische en juridische mogelijkheden.
Casus
De verschillende mogelijkheden zullen worden besproken aan de hand van een casus.
Kappa BV en Kolos BV (beiden klant van Beta BV) hebben op basis van een Saas-overeenkomst toegang tot bepaalde data van Beta. Ze krijgen de data in ruwe vorm aangeleverd, maar zijn daar nog niet tevreden mee. Ze willen namelijk graag meer inzicht in de data die ze ontvangen. Een derde partij, Nano NV geeft aan dat ze wel een dashboard kunnen maken die de data van Beta overzichtelijk weergeeft. In de SaaS overeenkomst staat echter dat een klant zijn toegangsgegevens niet aan derden mag verstrekken, ook niet voor de uitvoer van verdere diensten. Beta en Nano zijn dus genoodzaakt samen te werken en hieromtrent afspraken te maken. Hierbij is het volgende van belang:
- Beta wil de controle over haar data behouden
- Beta heeft geen problemen met de ontwikkeling van software die haar data kan verrijken
- Nano wil wel samenwerken, maar ook geld kunnen verdienen
Met deze aspecten in het achterhoofd zijn er meerdere oplossingen mogelijk. In de illustratie zijn er twee voor de hand liggende oplossingen al aangegeven. Deze oplossingen verschillen van elkaar doordat in optie 1 het dashboard wel wordt gemaakt door Nano, maar daarna niet door hen wordt beheerd. Hierdoor krijgt Nano geen toegang tot de data die door Kappa opgevraagd wordt. Bij optie 2 wordt het beheer ook door Nano gedaan. Hierdoor zal Nano de data van Beta in ieder geval tijdelijk op moeten slaan om het dashboard te laten werken.
Optie 1: Data naar Kappa en Kolos
Optie 1 houdt in dat de data uitsluitend wordt gedeeld met de klant. Op deze manier behoudt Beta grip op haar data, ook al staat deze data in het dashboard van Nano. In dit kader is het wel van belang dat Nano het dashboard zo inricht dat deze ofwel op servers van de klant draait, of op de computers van de gebruikers. Hierdoor verandert de stroom van de data dus niet. Nano zal genoegen moeten nemen met een abonnementsmodel voor het dashboard of een eenmalige betaling voor de ontwikkeling en eventueel onderhoud.
Optie 2: Data tijdelijk naar Nano
In het geval van optie 2 wordt het dashboard door Nano ontwikkeld én beheerd. Hierdoor verwerkt Nano de data van Beta, anders kan het dashboard niet functioneren. Dit kan intern op twee manieren geregeld worden. Nano kan iedere keer de data opvragen die de klant wil gebruiken en vervolgens niet opslaan. Nano kan er ook voor kiezen om de data die door een klant wordt opgevraagd, (tijdelijk) op te slaan zodat er daarna sneller gereageerd kan worden op een nieuwe aanvraag voor dezelfde data. Dit verminderd de communicatie tussen Nano en Beta, hetgeen efficiënter is voor beide bedrijven. De keerzijde is dat Beta de controle over haar data voor een deel verliest. Om dit te voorkomen kan Beta eisen dat Nano de data alleen tijdelijk, bijvoorbeeld voor de duur van de gebruikssessie, op mag slaan en daarna moet verwijderen. Beta zou ook kunnen eisen dat ze inzage krijgt in de code van Nano om te controleren of alle afspraken worden nageleefd.
Optie 3: Data permanent naar Nano
Een derde optie ligt in deze casus minder voor de hand. Deze optie houdt in dat Beta alle data waar de gebruikers van het dashboard toegang toe hebben, deelt met Nano. Hierdoor worden de servers van Beta niet meer belast door het gebruik van het dashboard van Nano, wat bij optie 2 nog wel het geval is. Hiervoor zou Beta een manier moeten creëren om haar datasets naar Nano te kopiëren. Nano krijgt echter wel uitgebreide toegang, waardoor Beta een deel van haar controle kwijt raakt. Om grip te houden op haar data kan Beta afdwingen dat ze inzage krijgt in de code van Nano of dat ze de systemen van Nano laat controleren door een externe partij. Ook kan ze aan de data die ze met Nano deelt bepaalde kenmerken toevoegen waaraan ze de data kan herkennen als die door Nano met externe partijen wordt gedeeld.
Conclusie
Voor Kappa en Kolos zijn optie 2 en 3 het meest gebruiksvriendelijk en goedkoop op de korte termijn. Om optie 2 te laten slagen, dienen Beta en Nano afspraken te maken over de interne behandeling van de data. Zo zou Beta kunnen eisen dat ze inzage krijgt in de code van Nano of dat de data maar voor een korte tijd opgeslagen mag worden bij Nano. In het geval van optie 3 zijn er voor Beta alleen maar nadelen, waardoor de kans minimaal is dat Beta hier aan zal meewerken.
Heeft u vragen? Neem vrijblijvend contact op.
