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 en is op elk moment in te trekken; een uitnodiging of een formulierlink vervalt bovendien na een beperkte tijd, een agendafeed werkt tot je hem intrekt. Het ouderformulier toont bovendien niets van wat al bekend is: de ouder ziet de voornaam van het kind en verder alleen lege velden.
- Het ouderportaal. Ouders melden zich aan in een eigen aanmelddienst, volledig los van die van de praktijk: een aanmelding van een ouder werkt nooit in de praktijkapp, en omgekeerd. Een ouderaccount opent op zich niets. Toegang tot een kind ontstaat alleen uit een uitnodiging of een koppelcode van de praktijk; een uitnodiging per mail opent meteen alleen voor wie zich met dat adres aanmeldt, en een uitnodiging per WhatsApp pas na een code naar dat nummer. De praktijk kan elke toegang op elk moment intrekken.
- Binnen de applicatie gelden drie rollen: eigenaar, therapeut en assistent. Een assistent doet de administratie en heeft geen toegang tot klinische inhoud: hij ziet van een dossier de identificatie, de afspraken, de voorschriften en de facturatie, maar geen notities, behandeldoelen, bilans, anamneses, metingen, verslagjes, gesprekken met de ouders of andere dan administratieve documenten.
- Toegang tot productiesystemen is beperkt tot wie ze nodig heeft voor onderhoud, verloopt over versleutelde verbindingen met een persoonlijke identiteit en tweestapsverificatie, en elke beheersessie wordt met inhoud gelogd. De server heeft geen open beheerpoort.
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. Voor ouders in het ouderportaal geldt een eigen regel, eveneens op één plaats: een ouder ziet alleen het kind waaraan de praktijk hem koppelde, nooit de notities van de logopedist, en van de berichten alleen zijn eigen uitwisseling, ook wanneer beide ouders gekoppeld zijn.
4. Logging en controleerbaarheid
- Toegangslog op cliëntdata. Het openen van een dossier, een lijst of een document en elke wijziging wordt vastgelegd met gebruiker, tijdstip en handeling; het lezen van een afzonderlijk bilan, een anamnese of een notitie binnen een al geopend dossier nog niet. De applicatie schrijft het log, en de database bewaakt dat een regel daarna niet meer gewijzigd of verwijderd kan worden.
- 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 gaat per functie een vaste, beperkte set gegevens. Voor een verslagje aan de ouders: de voornaam, de leeftijd, de behandeldoelen, de notitie van de therapeut, het therapieplan van die zitting en de titels van het huiswerk. Voor een anamnese: het leerjaar, de taal- en onderwijsgegevens en de ingevulde intakeblokken. Voor een bilan: de testscores, de foutenanalyse, de interpretatie, de vorige afname en de anamnese. Voor een brief aan de school: het geslacht en de laatste verslagjes. 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 overdag om de twee uur en 's nachts om de drie uur geback-upt via een geautomatiseerde taak. De back-ups worden vóór het verzenden versleuteld, 35 dagen onwisbaar bewaard bij Amazon Web Services in Ierland, en een uitgebleven back-up geeft een alarm. Daarnaast wordt dagelijks een versleutelde momentopname van de server gemaakt.
- Het schema wordt beheerd met migraties die versiebeheer volgen; er wordt nooit handmatig aan een productieschema gewerkt.
- De herstelprocedure wordt maandelijks getest door de jongste back-up in een wegwerpdatabase terug te zetten, met een logboek van elke test.
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.
- Elke wijziging aan de software doorloopt vóór de uitrol een geautomatiseerde controle: de volledige testsuite, een typecontrole en een statische analyse; mislukt een van die stappen, dan gaat de wijziging niet live. Een wekelijkse geautomatiseerde beveiligingsaudit leest de code en houdt een register van bevindingen bij.
- 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.