Meteen naar de inhoud

Technische en organisatorische maatregelen

Laatst bijgewerkt op

Dit document beschrijft de technische en organisatorische maatregelen zoals bedoeld in artikel 32 AVG. Het vormt een bijlage bij de verwerkersovereenkomst. Zoek je hetzelfde verhaal zonder juridische termen, lees dan de pagina over veiligheid.

1. Versleuteling

  • Onderweg: al het verkeer tussen browser en server verloopt over TLS. Er is geen onversleutelde toegang mogelijk.
  • In rust: de opslag waarop de database en de documenten staan is versleuteld. Documenten worden alleen uitgeleverd via kortlopende, ondertekende links.
  • Op veldniveau: het rijksregisternummer wordt apart versleuteld opgeslagen, met een sleutel die buiten de database bewaard wordt in een beheerde sleutelkluis. Zoeken op dat veld gebeurt via een afgeleide blinde index, zodat de zoekfunctie werkt zonder de waarde leesbaar te maken.

2. Toegangsbeheer

  • Authenticatie verloopt via een beheerde aanmelddienst. Wachtwoorden worden gehasht bewaard en zijn voor ons niet leesbaar.
  • Elk verzoek aan de backend wordt geverifieerd tegen de ondertekening van de aanmelddienst, op de hieronder beschreven links met een ingebouwd geheim na. Een andere omweg voor die controle bestaat niet in productie.
  • Links met een ingebouwd geheim.Een paar functies richten zich tot iemand die zich niet kan aanmelden: de agendafeed naar je eigen telefoon, de uitnodiging aan een collega, en het formulier waarmee ouders ontbrekende gegevens aanvullen. Zo'n link draagt een willekeurige sleutel van 256 bit waarvan wij alleen een hash bewaren, vervalt na een beperkte tijd en is op elk moment in te trekken. Het ouderformulier toont bovendien niets van wat al bekend is: de ouder ziet de voornaam van het kind en verder alleen lege velden.
  • Binnen de applicatie gelden drie rollen: eigenaar, therapeut en assistent. Een assistent heeft geen toegang tot klinische inhoud.
  • Toegang tot productiesystemen is beperkt tot wie ze nodig heeft voor onderhoud, en verloopt over versleutelde verbindingen met sleutelgebaseerde authenticatie.

3. Scheiding tussen praktijken

Elke praktijk is een afgescheiden ruimte. Elke opvraging van domeingegevens filtert verplicht op de praktijk van de aangemelde gebruiker, en binnen een praktijk geldt bovendien de ingestelde zichtbaarheid van dossiers: privé, alleen voor de eigenaar, of gedeeld. Die regel staat op één plaats in de code en wordt toegepast op de cliëntenlijst, het dossier, de zoekfunctie, de sessies, de prestaties en de facturen.

4. Logging en controleerbaarheid

  • Toegangslog op cliëntdata. Elke raadpleging van een dossier wordt vastgelegd met gebruiker, tijdstip en handeling. Het log wordt door de database zelf geschreven en is append-only: rijen kunnen niet gewijzigd of verwijderd worden, ook niet door de applicatie.
  • Technische logbestanden bevatten een verzoek-identificatie zodat een incident te reconstrueren valt, maar geen inhoud van dossiers.

5. Dataminimalisatie bij de schrijfhulp

Naar het taalmodel gaan uitsluitend de voornaam, de leeftijd, de behandeldoelen en de notitie van de therapeut. Bij een intake komen daar het leerjaar en de taal- en onderwijsgegevens van het kind bij, omdat een anamnese die context nodig heeft. Nooit een achternaam, een schoolnaam, een rijksregisternummer, een adres of het volledige dossier. Het gegenereerde voorstel wordt niet bewaard en niet verzonden; het bestaat pas als gegeven zodra de therapeut het bewaart.

Gedicteerde audio wordt onmiddellijk omgezet naar tekst en daarna verwijderd. Er blijft geen opname bestaan. De verwerking gebeurt binnen ons eigen account bij de in de subverwerkers genoemde clouddienst, met een Europees inferentieprofiel.

Bij een opgenomen intakegesprek geldt hetzelfde voor de opname: die wordt binnen ons eigen account omgezet naar tekst en daarna verwijderd, inclusief oudere kopieën. De uitgeschreven tekst van het gesprek blijft wel in het dossier staan, als bron voor het anamneseverslag. De therapeut ziet in het dossier dat dit transcript er is en kan het op elk moment definitief verwijderen. Ook dit transcript gaat alleen naar het taalmodel op het moment dat de therapeut daar zelf om vraagt.

6. Beschikbaarheid en herstel

  • De database wordt dagelijks geback-upt via een geautomatiseerde taak, en de back-ups worden versleuteld bewaard.
  • Het schema wordt beheerd met migraties die versiebeheer volgen; er wordt nooit handmatig aan een productieschema gewerkt.
  • Herstelprocedures worden getest, zodat een back-up niet pas bij een incident zijn eerste proef aflegt.

7. Beveiliging van de applicatie

  • Strikte instellingen voor herkomstcontrole, zodat de API alleen vanaf de eigen applicatie aanspreekbaar is.
  • Beveiligingsheaders op elk antwoord.
  • Snelheidsbegrenzing op gevoelige eindpunten, om geautomatiseerd raden en misbruik af te remmen.
  • De backend is niet rechtstreeks bereikbaar vanaf het internet: de browser praat uitsluitend met de webserver, die het verzoek intern doorstuurt.

8. Organisatorische maatregelen

  • Toegang tot persoonsgegevens is beperkt tot wie ze nodig heeft voor onderhoud of ondersteuning, en gebeurt in principe niet zonder aanleiding.
  • Iedereen die toegang heeft, is tot geheimhouding gehouden.
  • Wijzigingen aan de software worden nagekeken voor ze in productie komen.
  • Bij een incident geldt een vaste procedure: vaststellen, indammen, betrokken praktijken informeren, en herstellen.

9. Een kwetsbaarheid melden

Ben je op een beveiligingsprobleem gestoten, meld het dan op beveiliging@logobuddy.be voor je het elders deelt. We bevestigen de ontvangst, houden je op de hoogte van de oplossing, en ondernemen geen juridische stappen tegen wie in goed vertrouwen meldt. De contactgegevens staan ook in security.txt.

Vragen over dit document stel je via privacy@logobuddy.be.