Verwerkersovereenkomst
Dit is de verwerkersovereenkomst die iedere school bij Schoolbibliotheek krijgt. Eén tekst voor alle scholen, te lezen voordat je klant wordt.
Versie 1.0, geldig vanaf 1 september 2026
Verwerkersovereenkomst Schoolbibliotheek
Dit is de verwerkersovereenkomst tussen de school en Schoolbibliotheek. Hij legt vast welke persoonsgegevens wij namens de school verwerken, waarvoor, hoe wij ze beveiligen en hoe lang wij ze bewaren. De bijlagen horen erbij en hebben dezelfde status als de artikelen.
Partijen
Deze overeenkomst geldt tussen:
De school. Het bevoegd gezag van de onderwijsinstelling die een account heeft bij Schoolbibliotheek. In deze tekst noemen we die partij "de school". De school is verwerkingsverantwoordelijke.
Schoolbibliotheek. Weektaak.com, dat de dienst levert onder de handelsnaam Schoolbibliotheek.nl, gevestigd aan Smidshof 31, 3862 CZ Nijkerk, ingeschreven bij de Kamer van Koophandel onder nummer 65352025, vertegenwoordigd door Joke Meijer, directeur. In deze tekst noemen we die partij "wij" of "ons". Wij zijn verwerker.
De school gaat deze overeenkomst aan door hem te accepteren. Dat doet iemand die daarvoor namens het bevoegd gezag gemachtigd is: een beheerder van de school in de applicatie, of iemand aan wie de school een beoordelingslink heeft doorgestuurd, bijvoorbeeld de privacyfunctionaris van het bestuur. Van die beoordelaar leggen wij naam, e-mailadres en functie vast. Dat is een geldige manier om een verwerkersovereenkomst te sluiten: artikel 28 lid 9 AVG schrijft voor dat de overeenkomst schriftelijk moet zijn, "waaronder elektronische vorm". Een handtekening is niet vereist. Degene die accepteert bevestigt daarbij dat hij daartoe namens het bevoegd gezag gemachtigd is. Na acceptatie kan de school de overeenkomst als pdf downloaden, met daarin de naam van degene die accepteerde, het tijdstip, het versienummer en een kenmerk van de tekst die op dat moment gold.
Waar dit over gaat
De school gebruikt Schoolbibliotheek om haar schoolbibliotheek te beheren. In die applicatie staan gegevens van leerlingen: hun naam, hun groep, en wat zij lenen en lezen. Dat zijn persoonsgegevens, en de school blijft daar verantwoordelijk voor. Wij bewaren en verwerken die gegevens namens de school.
Onderwerp: de verwerking van persoonsgegevens die nodig is om de applicatie Schoolbibliotheek te leveren en te laten werken, in het kader van de overeenkomst die de school met ons heeft over het gebruik van die applicatie. Die overeenkomst noemen wij hier de hoofdovereenkomst.
Aard en doel: het uitlenen en innemen van boeken, het beheren van de collectie en van de leerlingenlijst, het leerlingportaal, de kiosk en de scanner, plus ondersteuning, foutherstel en beveiliging. Artikel 3 werkt de doelen uit.
Soort persoonsgegevens en categorieën betrokkenen: bijlage A benoemt per groep betrokkenen precies welke gegevens er in de applicatie terechtkomen. Het gaat om leerlingen, om medewerkers van de school, en verder om niemand.
Duur: deze overeenkomst loopt zolang de hoofdovereenkomst loopt. Artikel 14 regelt begin en einde.
De AVG verplicht ons om hier samen afspraken over te maken. Dit document bevat die afspraken. We hebben geprobeerd het leesbaar te houden, maar het is wel bindend.
De indeling, de begrippen en de inhoud volgen de Model Verwerkersovereenkomst 4.0 van het Privacyconvenant Onderwijs. Wij zijn geen deelnemer aan dat convenant en zijn dus niet verplicht dat model letterlijk te gebruiken, maar de onderwerpen die scholen daaruit kennen komen hier allemaal terug, in dezelfde volgorde. Waar wij afwijken, is dat in het voordeel van de school of omdat het model iets regelt dat op onze dienst niet van toepassing is.
1. Begrippen
We gebruiken de begrippen uit de AVG. Deze komen vaak terug:
- Persoonsgegevens: alle gegevens over een herkenbaar persoon. Een naam en een groep zijn persoonsgegevens, maar bijvoorbeeld ook een leengeschiedenis die aan een leerling hangt.
- Verwerken: alles wat je met gegevens kunt doen. Opslaan, tonen, wijzigen, doorzoeken, verwijderen.
- Betrokkene: de persoon over wie de gegevens gaan. Meestal een leerling, soms een medewerker van de school.
- Verwerkingsverantwoordelijke: degene die bepaalt waarvoor en hoe persoonsgegevens worden verwerkt. Dat is de school.
- Verwerker: degene die dat in opdracht doet. Dat zijn wij.
- Subverwerker: een partij die wij inschakelen en die daarbij persoonsgegevens van de school verwerkt. Bijlage C is de lijst.
- Instructie: een schriftelijke of elektronische opdracht van de school aan ons over de verwerking. Deze overeenkomst en de bijlagen zijn de instructie; artikel 2 regelt hoe de school er een toevoegt.
- Datalek: een inbreuk in verband met persoonsgegevens zoals bedoeld in artikel 4 onder 12 AVG, waarbij persoonsgegevens verloren gaan, gewijzigd worden of in verkeerde handen komen.
- Toezichthoudende autoriteit: in Nederland de Autoriteit Persoonsgegevens.
- De dienst: de applicatie Schoolbibliotheek met alles wat erbij hoort: de beheeromgeving voor de school, het leerlingportaal, de kiosk en de scanner.
2. Wie waarvoor verantwoordelijk is
De school bepaalt welke gegevens er in Schoolbibliotheek komen en waarvoor ze gebruikt worden. De school zorgt ervoor dat zij die gegevens mag verwerken en dat leerlingen en ouders daarover geïnformeerd zijn. De school zorgt er ook voor dat zij niet méér persoonsgegevens aan ons doorgeeft dan in bijlage A staat.
Wij verwerken die gegevens uitsluitend in opdracht van de school en volgens haar instructies. Deze overeenkomst en de bijlagen zijn die instructie. Wil de school een aanvullende instructie geven, dan doet zij dat schriftelijk of per e-mail, via het adres in het contacthoofdstuk. Een instructie die redelijkerwijs niet uitvoerbaar is binnen de dienst zoals die werkt, bespreken we samen.
Op die opdracht bestaat één uitzondering: als een wettelijke bepaling ons tot een verwerking verplicht, dan mogen wij die verwerking uitvoeren zonder instructie van de school. Wij laten de school dat vooraf weten en vertellen om welke bepaling het gaat, tenzij die wet dat verbiedt om gewichtige redenen van algemeen belang. Artikel 5 beschrijft wat wij doen als politie, justitie of een andere overheidsinstantie gegevens bij ons vordert.
Als een instructie van de school naar ons oordeel in strijd is met de AVG, dan melden wij dat zo snel mogelijk bij de school. Zolang wij samen beoordelen of dat klopt, voeren wij die instructie niet uit.
Wij gebruiken de gegevens niet voor onze eigen doelen. We verkopen ze niet, we verhuren ze niet, en we gebruiken ze niet voor reclame, voor ongevraagde aanbiedingen of om profielen op te bouwen buiten de dienst om. Zouden wij toch zelf doel en middelen van een verwerking bepalen, dan zijn wij voor die verwerking verwerkingsverantwoordelijke en niet langer verwerker.
Wij houden een register bij van de verwerkingen die wij voor scholen uitvoeren, zoals artikel 30 lid 2 AVG voorschrijft, en geven de school op verzoek inzage in het deel dat op haar betrekking heeft.
3. Wat wij met de gegevens doen
Wij verwerken persoonsgegevens voor deze doelen:
- Het leveren en laten werken van de applicatie: uitlenen, innemen, zoeken, het beheren van de leerlingenlijst en de collectie, het leerlingportaal, de kiosk en de scanner.
- Ondersteuning geven als de school een vraag of een probleem heeft.
- Fouten opsporen en oplossen.
- De applicatie beveiligen en misbruik voorkomen.
- De school inzicht geven in het gebruik van haar eigen bibliotheek.
- De applicatie verbeteren, op basis van gebruiksgegevens die niet tot een individuele leerling herleidbaar zijn.
Voor doel 2 en 3 kan het nodig zijn dat wij meekijken in de gegevens van de school. Dat doen we alleen als het nodig is. Het gebruik van onze beheeromgeving en het starten van een bekijk-als-sessie in de omgeving van een school leggen wij vast in een logboek, met wie het deed, om welke school het ging, wanneer, en welk scherm werd opgevraagd.
Voor foutanalyse kunnen wij een kopie van de database van de school op een beveiligde ontwikkelmachine zetten. In zo'n kopie zitten alleen de gegevens van de betreffende school. Wachtwoorden en toegangscodes worden vervangen en lopende sessies worden gewist, maar de namen van leerlingen staan er echt in. Zo'n kopie verwijderen wij zodra het onderzoek klaar is, en in ieder geval binnen dertig dagen. Wij houden bij wanneer een kopie is gemaakt en bewaken die termijn.
Wij verwerken geen bijzondere persoonsgegevens zoals bedoeld in artikel 9 AVG, en we vragen ze ook niet uit. Er zijn geen velden voor. De school zet ze niet in vrije tekstvelden.
4. Beveiliging
Wij nemen passende technische en organisatorische maatregelen om de gegevens te beschermen, zoals artikel 32 AVG voorschrijft. Welke maatregelen dat zijn, staat in bijlage B. Die bijlage beschrijft wat wij daadwerkelijk doen, niet wat wij van plan zijn.
Wij evalueren die maatregelen regelmatig en scherpen ze aan als de techniek of het dreigingsbeeld daar aanleiding toe geeft. We kunnen maatregelen vervangen, maar het beschermingsniveau gaat daarbij niet omlaag.
Ook de school heeft hier een taak: zij zorgt voor zorgvuldig omgaan met accounts, voor het tijdig loskoppelen van medewerkers die vertrekken, en voor een veilige plek voor de kiosk en de scanner.
Een absolute garantie op veiligheid bestaat niet, en die geven wij dus ook niet. Wat we wel toezeggen: een niveau dat past bij de gevoeligheid van leerlinggegevens en bij wat in onze branche gebruikelijk is.
5. Geheimhouding
Iedereen die bij ons toegang heeft tot de gegevens van de school is tot geheimhouding verplicht. Dat geldt voor medewerkers en voor ingeschakelde derden. Toegang krijgt alleen wie het voor zijn werk nodig heeft, en niet tot meer gegevens dan daarvoor nodig is.
Die geheimhouding geldt niet als de school ons uitdrukkelijk toestemming geeft om gegevens aan een derde te verstrekken, als het verstrekken nodig is om de dienst te kunnen leveren, of als een wettelijke bepaling ons tot verstrekking verplicht.
Vordert politie, justitie, een toezichthouder of een andere overheidsinstantie gegevens bij ons, dan doen wij dit:
- Wij controleren eerst op welke wettelijke bepaling de vordering berust en wie hem doet.
- Wij verstrekken niet meer dan de vordering vraagt.
- Wij informeren de school onmiddellijk en vóór de verstrekking, zodat zij zich er zo nodig tegen kan verzetten. Verbiedt de wet ons die kennisgeving om gewichtige redenen van algemeen belang, dan doen wij dat zodra het weer mag.
- Wij leggen elke vordering en wat wij daarop hebben verstrekt vast.
6. Subverwerkers
Wij schakelen andere partijen in om de dienst te kunnen leveren, bijvoorbeeld voor het versturen van e-mail en voor de opslag van bestanden. Die partijen heten subverwerkers. Wie dat zijn en wat zij zien, staat in bijlage C.
De school geeft ons hierbij algemene toestemming om de subverwerkers uit bijlage C in te schakelen. Wij leggen aan elke subverwerker langs een overeenkomst dezelfde verplichtingen op als in deze overeenkomst staan, en wij blijven tegenover de school aansprakelijk voor wat zij doen. Op verzoek van de school laten wij zien welke afspraken dat zijn.
Als wij een subverwerker willen toevoegen of vervangen, melden wij dat minstens zes weken van tevoren per e-mail aan de beheerders van de school en op de pagina met de overeenkomst. Binnen die zes weken kan de school bezwaar maken. Heeft de school een gegrond bezwaar, dan zoeken we samen naar een oplossing. Komen we daar niet uit, dan mag de school de overeenkomst opzeggen tegen de datum waarop de wijziging ingaat, zonder kosten. De school krijgt dan het niet gebruikte deel van de licentie terug.
7. Waar de gegevens staan
Alle persoonsgegevens van de school staan binnen de Europese Economische Ruimte:
- De applicatie en de database draaien op onze eigen server, die is ondergebracht in een datacentrum in Groningen.
- De nachtelijke backup gaat versleuteld naar een tweede locatie in Nederland.
- Boekafbeeldingen en exportbestanden staan bij Amazon Web Services in Frankfurt.
- E-mail gaat via Mailgun in de EU-regio.
Wij geven geen persoonsgegevens van leerlingen of medewerkers door aan landen buiten de EER. Mocht dat ooit nodig worden, dan melden wij dat vooraf, nemen wij het op in bijlage C en zorgen wij voor een geldige grondslag volgens hoofdstuk V van de AVG.
Er is wel een gegevensstroom die de EER verlaat. Wij benoemen hem hier, ook al zit er geen leerlinggegeven in.
Boekgegevens naar OpenAI. Wij laten boeken automatisch indelen en van een leesprofiel voorzien. Daarvoor sturen wij boekgegevens naar OpenAI: titel, auteur, ISBN, samenvatting, thema's, aantal bladzijden en AVI-niveau, plus de labelnamen en labelomschrijvingen die de school zelf heeft ingevoerd. Er gaat geen naam, geen groep, geen leengeschiedenis en geen boekbespreking van een leerling mee, en ook de naam van de school niet. Onze contractspartij is OpenAI Ireland Limited, maar de aanroep gaat naar het wereldwijde adres van OpenAI, en de verwerking kan dus buiten de EER plaatsvinden. Daarvoor gelden de standaardcontractbepalingen van de Europese Commissie uit de verwerkersovereenkomst van OpenAI. Omdat er geen persoonsgegevens in zitten, is dit geen doorgifte van persoonsgegevens. Wél vragen wij de school om geen namen van leerlingen in labelteksten of in eigen boektitels te zetten: die tekst gaat letterlijk mee.
Zie bijlage C voor de plek van elke partij die wij inschakelen.
8. Datalekken
Ontdekken wij een datalek dat de gegevens van de school raakt, dan melden wij dat zonder onnodige vertraging en in ieder geval binnen 24 uur nadat wij het ontdekt hebben. Die melding gaat naar de beheerders van de school.
We melden wat er is gebeurd, wanneer, welke gegevens en hoeveel personen het betreft, wat de vermoedelijke gevolgen zijn, en wat wij eraan doen om het te beperken en herhaling te voorkomen. Weten we nog niet alles, dan melden we alvast wat we wel weten en vullen we later aan.
De school beslist zelf of zij het lek meldt bij de Autoriteit Persoonsgegevens of bij de betrokkenen. Dat is haar taak, niet de onze. Wij helpen met alle informatie die zij daarvoor nodig heeft, en wij melden een datalek nooit zelf namens de school.
Ontdekt de school een datalek dat met de dienst te maken heeft, dan laat zij ons dat weten, zodat wij kunnen helpen het te beperken.
Wij houden een register bij van datalekken en van beveiligingsincidenten, met de feiten, de gevolgen en de maatregelen die wij hebben genomen.
9. Verzoeken van leerlingen en ouders
Leerlingen en ouders hebben rechten: inzage, correctie, verwijdering, beperking, overdraagbaarheid en bezwaar. Die verzoeken horen bij de school terecht te komen, want de school is verantwoordelijk voor de afhandeling.
Veel daarvan kan de school zelf in de applicatie regelen: gegevens inzien, aanpassen, een leerling verwijderen, en een export maken van de gegevens van haar leerlingen.
Lukt het niet zelfstandig, dan helpen wij. Wij reageren binnen vijf werkdagen op zo'n verzoek om hulp. Voor hulp die in redelijkheid van ons gevraagd kan worden, rekenen wij geen kosten. Is een verzoek uitzonderlijk bewerkelijk, dan overleggen we vooraf over de kosten voordat wij beginnen.
Komt er bij ons rechtstreeks een verzoek binnen van een leerling of een ouder, dan sturen wij dat door naar de school en laten wij de aanvrager weten dat de school het afhandelt. Wij handelen zo'n verzoek niet zelf af, tenzij de wet ons daartoe verplicht. In dat geval laten wij de school weten wat wij hebben gedaan, tenzij de wet ons verbiedt dat te melden.
10. Hulp bij beoordelingen en bij de toezichthouder
Wij helpen de school bij een gegevensbeschermingseffectbeoordeling (DPIA) en bij een verplichte voorafgaande raadpleging van de Autoriteit Persoonsgegevens, voor zover dat onze dienst betreft. Ook hier rekenen wij geen kosten voor hulp die in redelijkheid van ons gevraagd kan worden.
Wij helpen de school ook bij het voldoen aan een verzoek van de Autoriteit Persoonsgegevens of van een andere overheidsinstantie.
Neemt de Autoriteit Persoonsgegevens contact met ons op over de gegevens van de school, dan laten wij de school dat weten, tenzij de wet ons verbiedt dat te doen.
11. Controle
De school mag controleren of wij ons aan deze overeenkomst houden.
In de eerste plaats doen we dat zonder gedoe: wij geven op verzoek alle informatie die de school nodig heeft om aan te tonen dat wij de afspraken nakomen. Denk aan de beveiligingsbijlage, de subverwerkerslijst en antwoorden op een vragenlijst van de school of van SIVON.
Is dat niet genoeg, dan mag de school eens per jaar een audit laten uitvoeren door een onafhankelijke deskundige die zelf tot geheimhouding verplicht is. De school kondigt zo'n audit minstens dertig dagen van tevoren aan en houdt rekening met onze bedrijfsvoering. Het rapport gaat alleen naar de school en naar ons. De kosten van de audit zijn voor de school.
Blijkt uit de audit dat wij tekortschieten, dan lossen wij dat op eigen kosten op, binnen een redelijke termijn die we samen afspreken. De kosten van die audit dragen wij dan ook.
Bij een ernstig datalek of een aanwijzing van de toezichthouder vervalt de beperking van eens per jaar.
12. Bewaren, teruggeven en verwijderen
Zolang de school de applicatie gebruikt, bewaren wij de gegevens. De bewaartermijnen per soort gegeven staan in bijlage A. Wij bewaren persoonsgegevens niet langer dan die termijnen, en niet langer dan de school ons opdraagt.
De school kan op elk moment zelf een export maken van haar gegevens, in een gangbaar bestandsformaat. Daarbij maken wij één onderscheid:
- De export van leerlinggegevens (de leerlingen, hun leengeschiedenis, hun boekbesprekingen en hun leeswensen) is altijd beschikbaar voor een beheerder van de school. Ook als er een betalingsachterstand is, ook als de omgeving daardoor beperkt is, en ook na een opzegging. Het gaat om persoonsgegevens van leerlingen, en het recht om die terug te krijgen hangt niet aan een factuur.
- De export van de collectie, de boekenlijst zelf, hoort bij de betaalde dienst en is beschikbaar zolang het abonnement loopt.
Eindigt de overeenkomst, dan kiest de school wat er met de gegevens gebeurt:
- teruggeven: de school maakt zelf de export, of wij leveren die aan;
- wissen: wij verwijderen alles definitief;
- allebei: eerst teruggeven, dan wissen.
De school laat ons haar keuze weten. Horen wij niets, dan geldt dit:
- De school houdt na het einde van de overeenkomst nog dertig dagen toegang om een export te maken.
- Daarna markeren wij haar omgeving als verwijderd. Vanaf dat moment is er geen toegang meer, maar kunnen wij de omgeving nog terugzetten als de school daarom vraagt.
- Binnen negentig dagen daarna wordt alles definitief en onherstelbaar verwijderd.
- Wil de school dat het eerder definitief weg is, dan doen wij dat op verzoek.
- Backups die op dat moment nog bestaan, verlopen binnen dertig dagen en worden dan overschreven.
Deze termijnen beginnen te lopen op het moment dat de overeenkomst eindigt: als de school opzegt, of als wij samen vaststellen dat zij stopt. Stopt een school alleen met betalen zonder op te zeggen, dan wordt haar omgeving beperkt, maar verdwijnen de gegevens niet uit zichzelf. Wij nemen dan contact op, want zolang er geen einde is afgesproken weten wij niet of de school terugkomt. Wil een school dat haar gegevens weg zijn, dan is één bericht genoeg.
Als het wissen is uitgevoerd, bevestigen wij dat schriftelijk aan de school. De school mag op eigen kosten laten controleren dat het is gebeurd. Wij zorgen ervoor dat ook onze subverwerkers de gegevens verwijderen.
Verwijdert de school zelf haar bibliotheek in de applicatie, dan geldt dezelfde route: er volgt een periode waarin wij haar nog kunnen terugzetten, en binnen negentig dagen daarna is alles definitief weg.
Accounts van medewerkers. Een persoonlijk account staat los van de school en kan aan meer dan één school gekoppeld zijn. Bij het wissen verdwijnt de koppeling met de school die stopt. Is een account daarna aan geen enkele school meer gekoppeld, dan verwijderen wij dat account met alles wat eraan hangt: het e-mailadres, de naam, het wachtwoord, de gegevens voor tweefactorauthenticatie, de herstelcodes en de passkeys.
Wij bewaren na afloop geen persoonsgegevens van de school meer, behalve wat wij wettelijk moeten bewaren. Dat gaat om onze factuuradministratie, niet om leerlinggegevens en niet om accounts.
13. Aansprakelijkheid
Als de school schade lijdt doordat wij ons niet aan deze overeenkomst houden, dan zijn wij daarvoor aansprakelijk.
Onze aansprakelijkheid is beperkt tot het hoogste van deze twee bedragen: het bedrag dat de school in de twaalf maanden vóór de gebeurtenis aan ons heeft betaald, of 2.500 euro. Die beperking geldt per gebeurtenis en voor alle gebeurtenissen in één kalenderjaar samen. Samenhangende gebeurtenissen tellen als één gebeurtenis.
Op die beperking bestaan drie uitzonderingen. Zij geldt niet:
- bij opzet of bewuste roekeloosheid van onze kant;
- bij een verhaalsactie op grond van artikel 82 AVG, waarbij de ene partij verhaalt wat zij aan een betrokkene heeft moeten vergoeden;
- bij het verhalen van een boete die een partij aan de Autoriteit Persoonsgegevens heeft betaald, voor zover die boete geheel of gedeeltelijk aan de andere partij is toe te rekenen.
Krijgt de school dus een boete van de Autoriteit Persoonsgegevens die aantoonbaar het gevolg is van een tekortkoming van ons, dan kan zij die onbeperkt op ons verhalen. Andersom geldt hetzelfde.
Wordt een van ons aansprakelijk gesteld of dreigt er een boete die met deze overeenkomst te maken heeft, dan laten we dat de ander zonder onnodige vertraging weten. We houden bij het voeren van verweer rekening met elkaars belangen, geven elkaar de gelegenheid een zienswijze te geven, en accepteren geen schikking en doen geen afstand van een rechtsmiddel zonder de ander eerst te raadplegen. Voor informatie en ondersteuning die we elkaar daarbij geven, mogen we redelijke kosten in rekening brengen; dat melden we dan vooraf.
14. Ingang, wijziging en einde
Deze overeenkomst gaat in op het moment dat iemand die daarvoor namens het bevoegd gezag gemachtigd is hem accepteert: een beheerder van de school in de applicatie, of iemand aan wie de school een beoordelingslink heeft doorgestuurd. Van die beoordelaar leggen wij naam, e-mailadres en functie vast. Daarna loopt de overeenkomst zolang de hoofdovereenkomst loopt.
De artikelen van deze overeenkomst kunnen wij niet eenzijdig wijzigen. Wil een van ons iets veranderen, dan gaat dat zo:
- Wij maken een nieuwe versie met een nieuw versienummer.
- Beheerders krijgen daarover een e-mail, met in gewone taal wat er verandert, en zien de nieuwe versie na het inloggen in de applicatie.
- De nieuwe versie geldt pas als de school hem accepteert. Tot dat moment blijft de oude versie gewoon gelden, dus er is nooit een moment zonder geldige overeenkomst.
- Is de school het niet eens met de nieuwe versie, dan mag zij de overeenkomst opzeggen tegen de ingangsdatum van die versie, zonder kosten en met teruggave van het niet gebruikte deel van de licentie.
- Alle versies blijven terug te lezen op de pagina met de overeenkomst.
De bijlagen A, B en C beschrijven hoe de dienst op dit moment werkt. Verandert de dienst, dan werken wij die bijlagen bij en melden wij dat aan de beheerders van de school en op de pagina met de overeenkomst. Daarbij geldt:
- Voor het toevoegen of vervangen van een subverwerker geldt altijd de procedure van artikel 6: zes weken vooraf melden, met bezwaarrecht.
- Leidt een wijziging ertoe dat wij meer of andere persoonsgegevens gaan verwerken, of dat wij ze voor een ander doel gaan verwerken, dan leggen wij dat vooraf in begrijpelijke taal uit en is die wijziging een nieuwe versie van de overeenkomst, die de school dus eerst accepteert.
- Wijzigingen die het beschermingsniveau verhogen of die alleen een feitelijke beschrijving actualiseren, voeren wij door met een melding en zonder nieuwe acceptatie.
Eindigt de hoofdovereenkomst over het gebruik van Schoolbibliotheek, dan eindigt deze verwerkersovereenkomst van rechtswege tegelijk. De afspraken over geheimhouding en over teruggeven en verwijderen blijven daarna gelden totdat ze zijn uitgevoerd.
15. Recht en geschillen
Op deze overeenkomst is Nederlands recht van toepassing. Komen we er samen niet uit, dan leggen we het geschil voor aan de bevoegde rechter in het arrondissement waar de school gevestigd is, tenzij de hoofdovereenkomst een andere bevoegde rechter aanwijst.
Wijkt deze overeenkomst af van de hoofdovereenkomst of van onze algemene voorwaarden, dan gaat deze overeenkomst voor waar het de verwerking van persoonsgegevens betreft.
Is een bepaling uit deze overeenkomst nietig of niet afdwingbaar, dan blijft de rest gewoon gelden en vervangen we die bepaling samen door een geldige die er zo dicht mogelijk bij komt.
Contact
Vragen over privacy, verzoeken van betrokkenen en meldingen van datalekken: info@schoolbibliotheek.nl
Meldingen van datalekken en verzoeken van betrokkenen gaan bij ons met voorrang door dat adres heen. Dringend en buiten kantooruren mag de school ook bellen; het telefoonnummer staat in de applicatie bij de contactgegevens.
Wij vragen de school om in de applicatie bij te houden wie namens haar de contactpersoon is voor privacyzaken en wie instructies mag geven. Wij richten onze meldingen aan de beheerders van de bibliotheek.
Wij hebben geen functionaris gegevensbescherming aangesteld. Dat hoeft ook niet: die verplichting geldt voor overheidsinstanties en voor organisaties die op grote schaal mensen volgen of bijzondere persoonsgegevens verwerken. Wij vallen daar niet onder. Bovenstaand adres komt terecht bij de persoon die binnen ons bedrijf verantwoordelijk is voor privacy.
Bijlagen
Bijlage A. Welke gegevens wij verwerken
Deze bijlage beschrijft welke persoonsgegevens in Schoolbibliotheek terechtkomen, van wie, waarvoor, en hoe lang wij ze bewaren. Het is de privacybijsluiter bij deze overeenkomst.
Het zijn er weinig, en ze mogen onvolledig zijn
Schoolbibliotheek is een uitleensysteem, geen leerlingadministratie. Om een boek uit te lenen hebben wij van een leerling in de basis maar twee dingen nodig: een naam en een groep. Verder niets. Er is geen veld voor een geboortedatum, geen veld voor een adres, geen veld voor een burgerservicenummer.
De naam is één vrij tekstveld. Daar hoeft geen volledige naam in te staan.
Aanbeveling. Zet er een voornaam en de eerste letter van de achternaam in: "Sanne B." Dat is genoeg om in de klas de juiste leerling aan te wijzen, en het is echte dataminimalisatie: het scheelt dat een volledige naam op een kioskscherm of in een backup staat. Zit een school met twee keer "Sanne B." in dezelfde groep, dan volstaat een tweede letter. Wij raden dit aan, maar de school beslist.
Zodra een leerling de applicatie zelf gebruikt, komt er wel meer bij: wat hij leent, wat hij ervan vond, wat hij nog wil lezen en welke badges hij haalt. Dat hoort bij de dienst, en de lijst hieronder is volledig.
Leerlingen
Wat de school invoert of importeert
- naam, als één tekstveld
- groep of klas, als vrije tekst
- of de leerling actief is
- AVI-leesniveau, als de school dat bijhoudt
- leesgroep, met de herkomst ervan (afgeleid uit de groepsnaam, ingesteld bij de groep, of door de leerling zelf opgegeven) en het schooljaar waarin dat is vastgelegd
- een sleutel uit het leerlingadministratiesysteem, zodat een volgende import dezelfde leerling herkent
- een inlognaam die de applicatie zelf afleidt uit de naam, bijvoorbeeld "sanne-b"
- instellingen over wat de leerling zelf mag: zelf uitlenen of alleen inleveren, en welke kasten toegankelijk zijn
Wat ontstaat door gebruik van de applicatie
- het nummer van de bibliotheekpas, met de datum van uitgifte en de status van die pas
- de leengeschiedenis: welk exemplaar, wanneer geleend, wanneer het terug moet, wanneer het terug was, en of dat via een medewerker of via een kiosk ging
- boekbesprekingen: een cijfer, eventueel een geschreven tekst, voor wie de leerling het boek aanraadt, en of de bespreking zichtbaar is voor klasgenoten
- het verlanglijstje
- thuis gelezen boeken die de leerling zelf toevoegt, met de datum waarop hij ze uit had en een eventuele eigen bespreking daarvan
- behaalde badges, met het moment waarop ze behaald zijn
- de boekenmatch, als de school die aanzet: de antwoorden op de vragen, het leesprofiel dat daaruit volgt (voorkeuren over stemming, onderwerp, lengte, plaatjes en spanning), en welke boeken zijn getoond, gekozen of weggeschoven
- van de sessie in het leerlingportaal: het IP-adres, de browsergegevens en het moment van laatste activiteit
- vermeldingen in het logboek van wijzigingen, bijvoorbeeld toen de leerling werd aangemaakt, verplaatst naar een andere groep of verwijderd
Wij slaan geen pincode van een leerling op. Inloggen in het leerlingportaal gaat uitsluitend met de bibliotheekpas.
Wat wij niet verwerken
Wij slaan van een leerling geen geboortedatum, geslacht, adres, postcode, woonplaats, telefoonnummer, e-mailadres, burgerservicenummer, onderwijsnummer, ECK-iD, nationaliteit of foto op. Wij vragen er ook niet om. Er zijn geen velden voor. Wij verwerken geen toetsresultaten, rapportcijfers, absentiegegevens, handelingsplannen of zorggegevens.
Een leerlingbestand uit het leerlingadministratiesysteem (EDEX) bevat vaak wel meer: geboortedatum, geslacht, de laatste vier cijfers van het burgerservicenummer en soms een postcode. Wij lezen daar alleen de roepnaam, het tussenvoegsel, de achternaam, de groep, de herkenningssleutel en, om vertrokken leerlingen te herkennen, de uitstroomdatum uit. Die uitstroomdatum bewaren wij niet; die gebruiken wij alleen tijdens het inlezen zelf. Uit de kop van het bestand lezen wij het schooljaar, de peildatum, de brincode en de naam van het administratiepakket, om in de voorbeeldweergave te kunnen tonen wat er wordt ingelezen. Ook die bewaren wij niet.
Het terugbrengen tot die velden gebeurt in de browser van de school, vóór het bestand wordt verstuurd. In de meeste gevallen verlaten geboortedatum, geslacht en de burgerservicenummercijfers de computer van de school dus niet eens. Lukt dat niet, bijvoorbeeld in een oude browser, dan doet de server precies hetzelfde direct na ontvangst, vóór er iets wordt getoond of opgeslagen. Het geüploade bestand zelf bewaren wij niet.
Bijzondere persoonsgegevens
Wij verwerken geen bijzondere persoonsgegevens zoals bedoeld in artikel 9 AVG. Er is geen veld voor gezondheid, geloof, afkomst of iets vergelijkbaars.
Wel goed om te weten: een leengeschiedenis zegt iets over wat een kind leest, en dat is gevoeliger dan het lijkt. Wij behandelen die gegevens daarom met dezelfde zorg als gegevens waar de wet een extra label op plakt.
Waarvoor
Om boeken te kunnen uitlenen en innemen, om de leerling in het portaal te laten zien wat hij heeft geleend en gelezen, om passende boeken voor te stellen, om te kunnen vaststellen wie wat heeft gedaan, en om de school inzicht te geven in het gebruik van haar bibliotheek.
Wie kan erbij
- Medewerkers van de school die een account hebben bij die school. Zij zien alleen de scholen waaraan zij gekoppeld zijn.
- De leerling zelf, in het leerlingportaal, en dan alleen zijn eigen gegevens.
- Klasgenoten zien de leengeschiedenis, het verlanglijstje en de badges van een leerling niet. Eén ding is wel zichtbaar: een boekbespreking. Bij het schrijven kiest de leerling of die zichtbaar is voor andere leerlingen of alleen voor hemzelf; kiest hij niets, dan is hij zichtbaar. Een zichtbare bespreking staat met de naam van de leerling bij dat boek in het portaal van dezelfde school. Een bespreking van een thuis gelezen boek is altijd privé.
- Op een kiosk kan de school kiezen tussen inloggen met de pas en zichzelf aanwijzen in een lijst. Kiest de school voor die tweede vorm, dan kiest de leerling eerst zijn groep en daarna zijn naam, en staan de namen van de actieve leerlingen van de school op dat apparaat. Dat is een bewuste keuze van de school, bedoeld voor klassen zonder pasjes. In het leerlingportaal bestaat zo'n namenlijst niet: daar kan alleen met de pas worden ingelogd.
- Onze eigen medewerkers, alleen voor ondersteuning en foutanalyse, en alleen als het nodig is. Het gebruik van onze beheeromgeving en het starten van een bekijk-als-sessie worden vastgelegd, met wie, welke school, wanneer en welk scherm.
Hoe lang
| Gegeven | Bewaartermijn |
|---|---|
| Leerlinggegevens en alles wat daaraan hangt | Zolang de school ze in de applicatie laat staan. De school beslist dat zelf en kan een leerling verwijderen |
| Verwijderde leerling | Direct weg, samen met leningen, boekbesprekingen, wensen, thuisboeken, badges, boekenmatch en portaalsessies |
| Naam en groep van een verwijderde leerling in het logboek | Maximaal 24 maanden, daarna automatisch weg |
| Sessie in het leerlingportaal | 14 dagen na het laatste gebruik, daarna automatisch weg |
| Logboek van wijzigingen | 24 maanden |
| Export met leerlinggegevens | 30 dagen, daarna automatisch weg |
| Alles, na het einde van de overeenkomst of bij verwijdering van de bibliotheek | 30 dagen exporttoegang, daarna een periode waarin herstel nog kan, en binnen 90 dagen daarna definitief weg |
| Backup | 30 nachtelijke kopieën, daarna overschreven |
Bij het verwijderen van een leerling blijft de bijbehorende bibliotheekpas bestaan, maar zonder koppeling aan een persoon. De pas is daarna een leeg kaartje dat de school opnieuw kan uitgeven.
Medewerkers van de school
Welke gegevens
- e-mailadres
- naam, als die is ingevuld
- het wachtwoord, opgeslagen als bcrypt-hash en bij ons dus niet leesbaar
- of tweefactorauthenticatie aanstaat, en de gegevens die nodig zijn om de codes uit de authenticator-app te controleren
- herstelcodes voor tweefactorauthenticatie, opgeslagen als hash
- passkeys, als de medewerker die gebruikt: de publieke sleutel, een label en het moment van laatste gebruik
- de rol binnen elke school waaraan de medewerker gekoppeld is
- persoonlijke voorkeuren in de applicatie, en of het e-mailadres bevestigd is
- van de sessie: het IP-adres, de browsergegevens en het moment van laatste activiteit
- welke handelingen de medewerker in de applicatie heeft verricht
Waarvoor
Om te kunnen inloggen, om de juiste rechten te geven, om het account te beveiligen, en om achteraf te kunnen vaststellen wie wat heeft gedaan.
Hoe lang
| Gegeven | Bewaartermijn |
|---|---|
| Account | Zolang het aan minstens één school gekoppeld is. Een beheerder van de school kan een collega loskoppelen. Is het account aan geen enkele school meer gekoppeld, dan verwijderen wij het met alles wat eraan hangt |
| Sessie | 30 dagen na het laatste gebruik, daarna automatisch weg |
| Logboek van handelingen | 24 maanden |
De school zelf
Wij bewaren de naam van de school, een kenmerk waarmee haar omgeving in de applicatie wordt aangeduid, de instellingen van de bibliotheek (uitleenduur, maximaal aantal boeken per leerling, wat leerlingen zelf mogen, of de boekenmatch aanstaat), de indeling in kasten en groepen, de aangemelde kiosken en scanners, en de gegevens over het abonnement: het plan, de startdatum, de einddatum, de status en een logboek van wijzigingen daarin.
Wij bewaren geen adres, telefoonnummer of bankgegevens van de school in de applicatie. Facturatie loopt buiten Schoolbibliotheek om.
Wat er met de gegevens gebeurt buiten de applicatie
- Backups. Elke nacht wordt een versleutelde kopie van de hele database gemaakt en naar een tweede locatie in Nederland gestuurd. De dertig nieuwste kopieën blijven bewaard, oudere worden verwijderd. Een verwijderde leerling kan dus nog maximaal dertig dagen in een backup voorkomen.
- Exports. Een export van leerlinggegevens bestaat uit drie bestanden: een overzicht van de leerlingen, de uitleengeschiedenis, en de boekbesprekingen en leeswensen inclusief de tekst die kinderen zelf hebben geschreven. Die bestanden worden opgeslagen bij Amazon Web Services in Frankfurt, zijn alleen te downloaden via de applicatie door een beheerder van die school, en worden na dertig dagen automatisch verwijderd. De collectie-export bevat geen leerlinggegevens.
- Ondersteuning. Voor het oplossen van een gemeld probleem kunnen wij een kopie van de gegevens van de school op een beveiligde ontwikkelmachine zetten. Zo'n kopie verwijderen wij zodra het onderzoek klaar is en in ieder geval binnen dertig dagen. Wij houden bij wanneer een kopie is gemaakt en bewaken die termijn.
- E-mail. Berichten over accounts, uitnodigingen en het abonnement gaan via Mailgun in de EU-regio, naar medewerkers van de school. Er gaat nooit e-mail naar leerlingen of ouders, en er staan nooit leerlinggegevens in.
- Boekgegevens. Om omslagen en beschrijvingen op te halen bevragen wij externe boekendatabases, altijd op ISBN. Zoekt een medewerker in de aanschaflijst naar een titel, dan gaat die zoekterm naar Google Books en naar de Koninklijke Bibliotheek. Daar gaat nooit een naam van een leerling, een medewerker of een school heen. Wat leerlingen in het portaal of op de kiosk zoeken, blijft in onze eigen database.
- Camerabeelden. Het scannen van barcodes en pasjes gebeurt in de browser op het apparaat zelf. Er wordt geen camerabeeld naar ons of naar een derde gestuurd.
Bijlage B. Beveiliging
Deze bijlage beschrijft de maatregelen die wij daadwerkelijk hebben getroffen. Alles wat hier staat, zit in de software of in de manier waarop wij hem uitrollen. Wat wij nog van plan zijn, staat er niet in.
Toegang tot de applicatie
- Medewerkers van de school loggen in met een e-mailadres en een wachtwoord. Een wachtwoord is minimaal acht tekens lang en wordt onleesbaar opgeslagen als bcrypt-hash. Wij kunnen het wachtwoord van een medewerker niet zien.
- Een link om een wachtwoord opnieuw in te stellen is vijftien minuten geldig. Zodra het wachtwoord verandert, worden alle lopende sessies van die medewerker beëindigd.
- Tweefactorauthenticatie met een authenticator-app is beschikbaar voor alle medewerkers, met tien eenmalige herstelcodes voor als de telefoon kwijtraakt. Die herstelcodes worden als hash opgeslagen en zijn na gebruik ongeldig.
- Inloggen met een passkey is beschikbaar als alternatief voor een wachtwoord.
- Voor toegang tot onze eigen beheeromgeving is tweefactorauthenticatie verplicht.
- Inloggen, de tweefactorstap, inloggen met een passkey, het aanvragen van een wachtwoordreset, het accepteren van een uitnodiging, registreren en het wijzigen van een wachtwoord of van de tweefactorinstellingen zijn allemaal begrensd op tien pogingen per drie minuten per IP-adres. Een bevestigingsmail opnieuw sturen kan drie keer per uur per e-mailadres.
- Sessies van medewerkers vervallen na dertig dagen zonder activiteit, sessies van leerlingen na veertien dagen omdat die vaker op een gedeelde tablet zitten. Dat wordt bij elk verzoek op de server gecontroleerd; een verlopen sessie wordt meteen vernietigd. Sessiecookies zijn ondertekend, niet uitleesbaar door scripts, en gaan alleen over een beveiligde verbinding mee. Bij het inloggen wordt de sessie ververst, zodat een oude sessie geen rechten kan erven.
Toegang van leerlingen
- In het leerlingportaal loggen leerlingen uitsluitend in met hun eigen bibliotheekpas. Er is daar geen namenlijst waarin een leerling zichzelf aanwijst, want dan zouden de namen van een hele klas op het scherm staan.
- Op een kiosk kan de school wel kiezen voor "zonder pas", waarbij de leerling zichzelf uit een lijst per groep aantikt. Dat is bedoeld voor klassen zonder pasjes en is een bewuste keuze van de school. Een kiosk is aan één apparaat gebonden en staat in de school.
- Het nummer op een pas is willekeurig en lang genoeg om niet te raden te zijn.
- Mislukte paslogins zijn begrensd op tien pogingen per tien minuten per IP-adres, met daarna een wachttijd.
- Een leerling ziet alleen de gegevens van zijn eigen school. Komt een sessie op de omgeving van een andere school terecht, dan wordt die sessie direct beëindigd. Wordt een leerling gedeactiveerd, dan verliest hij bij het eerstvolgende verzoek zijn toegang en wordt zijn pas gearchiveerd.
Scheiding tussen scholen
- Elke opvraging in de applicatie is beperkt tot de scholen waar de ingelogde medewerker aan gekoppeld is. Een school die niet bij die medewerker hoort, is niet op te vragen, ook niet door in de adresbalk te knoeien: de applicatie doet dan alsof die school niet bestaat. Onze eigen beheerders vormen hierop de uitzondering; zij hebben toegang tot alle scholen, en dat wordt gelogd.
- Schoolomgevingen hebben een niet te raden kenmerk in de URL, geen oplopend nummer. Dat is een extra drempel bovenop de afscherming hierboven, niet de afscherming zelf.
- Kiosk en scanner leiden hun school af uit een geheim dat in het apparaat zelf zit, niet uit de URL. Dat geheim wordt eenmalig gekoppeld met een code die daarna direct vervalt.
Transport en opslag
- Al het verkeer loopt over HTTPS. Onversleutelde verbindingen worden doorgestuurd naar de beveiligde variant, en de browser krijgt de opdracht om twee jaar lang alleen nog beveiligd te verbinden, ook op subdomeinen.
- Certificaten worden automatisch vernieuwd.
- De database staat op onze eigen server in Groningen, binnen de EER.
- Boekafbeeldingen en exportbestanden staan bij Amazon Web Services in Frankfurt, binnen de EER. De opslag zelf is niet publiek toegankelijk. Afbeeldingen worden via de applicatie geleverd met een ondertekende verwijzing. Een export met leerlinggegevens staat daar maximaal dertig dagen en komt er alleen uit via de applicatie, na inloggen, en alleen voor een beheerder van die school. Daarna wordt het bestand automatisch verwijderd, ook bij de opslagpartij.
- De nachtelijke databasebackup wordt versleuteld terwijl hij gemaakt wordt, en staat dus nooit onversleuteld op schijf. De backup weigert te draaien als de versleutelingssleutel ontbreekt. De sleutel om hem te openen ligt niet op de plek waar de backup bewaard wordt.
- De backup gaat over een versleutelde verbinding naar een tweede locatie. Wij controleren daarbij dat die locatie het certificaat toont dat wij vooraf hebben vastgelegd, en dat het op de juiste naam staat. Klopt dat niet, dan wordt er niets verstuurd.
Logging en controle
- Wijzigingen aan leerlingen, leningen, passen, exemplaren, boeken, locaties, groepen, gebruikers, kiosken, scanners en instellingen worden vastgelegd in een logboek, met wie het deed en wanneer. Dat logboek wordt 24 maanden bewaard en daarna automatisch opgeruimd.
- Passen, pincodes en apparaatgeheimen worden uit dat logboek gefilterd.
- Het gebruik van onze beheeromgeving en het starten van een bekijk-als-sessie worden vastgelegd met gebruiker, school, tijdstip en opgevraagd pad, en zijn terug te zien in een overzicht met filters.
- Wachtwoorden, tokens, pincodes, e-mailadressen, claimcodes en het geüploade leerlingbestand worden uit alle logbestanden gefilterd.
- Onze foutmeldingendienst is zo ingesteld dat hij geen gebruikersgegevens meestuurt.
Ontwikkeling en onderhoud
- Bij elke wijziging aan de software draait automatisch een reeks controles: een beveiligingsscanner voor de code, een controle op bekende kwetsbaarheden in de gebruikte onderdelen, een controle op de gebruikte JavaScript, een stijlcontrole, de volledige testsuite en de browsertests. Is er iets rood, dan gaat de wijziging niet naar productie.
- Er draait wekelijks een automatische controle op nieuwe versies van de gebruikte onderdelen.
- Toegangsgegevens voor de productieomgeving staan in een wachtwoordkluis en worden pas bij het uitrollen opgehaald. Ze staan niet in de broncode. Ontbreekt er een, dan start de applicatie niet in plaats van stilletjes verkeerd te werken.
- De applicatie draait in een container zonder beheerdersrechten. Gereedschap dat alleen nodig is om de software te bouwen, zit niet in de container die draait.
- De applicatie stuurt de browser instructies mee die bepalen wat er geladen mag worden. Scripts mogen alleen van onze eigen server komen en moeten een kenmerk dragen dat per verzoek verschilt, zodat een ingevoegd script van buitenaf niet wordt uitgevoerd. Voor opmaak binnen de pagina zelf is een uitzondering gemaakt, en afbeeldingen mogen van elke beveiligde bron komen.
Beschikbaarheid
- Er wordt elke nacht een volledige backup van de database gemaakt.
- De dertig nieuwste backups blijven bewaard, oudere worden verwijderd.
- Een backup die verdacht klein is, wordt niet verstuurd. Na het versturen wordt gecontroleerd of het bestand aan de andere kant even groot is. Klopt dat niet, dan mislukt de backup zichtbaar.
- Na een geslaagde backup gaat er een signaal naar een bewakingsdienst. Blijft dat signaal uit, dan volgt er een melding. Het backupscript weigert te draaien als die bewaking niet is ingesteld.
Bijlage C. Subverwerkers
Dit zijn de partijen die wij inschakelen en die daarbij persoonsgegevens van de school kunnen zien. De actuele lijst staat altijd op de pagina met de overeenkomst in de applicatie.
| Partij | Waarvoor | Land | Welke gegevens |
|---|---|---|---|
| QTS Groningen | Datacentrum waar onze eigen server staat: ruimte, stroom, netwerk en fysieke beveiliging | Nederland (Groningen) | Geen logische toegang tot de gegevens. Wel fysieke toegang tot de apparatuur |
| Backupopslag op een tweede locatie in Nederland | Bewaren van de nachtelijke databasebackup | Nederland | Alle gegevens uit de applicatie, maar uitsluitend versleuteld. De sleutel ligt niet op die locatie |
| Amazon Web Services EMEA SARL | Opslag van boekafbeeldingen en van exportbestanden | Duitsland (Frankfurt) | Boekafbeeldingen bevatten geen persoonsgegevens. Een export met leerlinggegevens bevat namen, groep, leengeschiedenis en de tekst van boekbesprekingen, en staat er maximaal dertig dagen |
| Mailgun (EU-regio) | Verzenden van e-mail over accounts, uitnodigingen en het abonnement | Europese Unie | E-mailadressen en namen van medewerkers van de school, en de naam van de school. Geen leerlinggegevens |
| OpenAI Ireland Limited | Automatisch indelen van boeken en het maken van leesprofielen per boek | Ierland, met verwerking op het wereldwijde adres van OpenAI | Alleen boekgegevens en de labelteksten die de school zelf heeft ingevoerd. Geen leerlinggegevens en geen schoolnaam |
Wat er niet in deze lijst staat, en waarom
- Onze foutmeldingendienst draait op onze eigen server en is dus geen derde partij.
- Boekendatabases zoals ISBNdb, Google Books, de Koninklijke Bibliotheek, Open Library en de Nederlandse en Belgische boekhandels bevragen wij op ISBN. Zoekt een medewerker in de aanschaflijst op titel, dan gaat die zoekterm naar Google Books en naar de Koninklijke Bibliotheek. Daar gaat nooit een naam van een leerling, een medewerker of een school heen, dus deze partijen verwerken geen persoonsgegevens voor ons.
- Contentnetwerken en beschermingsdiensten zoals Cloudflare en een CDN gebruiken wij niet voor de productieomgeving. Zetten wij er ooit een voor, dan komt die eerst in deze lijst en geldt de procedure van artikel 6.
- De partijen die onze broncode en onze uitrol beheren krijgen geen persoonsgegevens van scholen of leerlingen te zien.
Versiegeschiedenis
-
Versie 1.0, geldig vanaf 1 september 2026
Eerste versie.