Een SaaS-contract dat vandaag wordt getekend, kan in 2029 nog steeds de administratie, klantdata, betalingsstromen of productiedata van een onderneming dragen. Juist daarom hoort post-quantum security niet alleen op de agenda van banken en ministeries. Voor Nederlandse ondernemers wordt het een gewone contractvraag: wat belooft de leverancier over cryptografie, bewijs, migratie en aansprakelijkheid wanneer bestaande versleuteling haar houdbaarheid verliest?
De aanleiding is concreet. NIST heeft de eerste post-quantum cryptografiestandaarden FIPS 203, 204 en 205 vastgesteld; zie de publieke NIST-uitleg over de goedkeuring van de post-quantum cryptography FIPS. De Europese Commissie publiceerde eerder al een gecoördineerde Europese roadmap voor de overgang naar post-quantum cryptografie. Wie cloudsoftware inkoopt, hoeft geen cryptograaf te worden. Hij moet wel voorkomen dat het contract alleen zegt dat de leverancier “passende beveiliging” toepast.
Waarom dit inkooprecht is, niet alleen cybersecurity
Post-quantum risico klinkt technisch, maar de juridische kern is vertrouwd. Een ondernemer koopt een dienst, vertrouwt data toe aan een leverancier en moet later kunnen aantonen dat hij redelijke vendor-risk vragen heeft gesteld. Dat speelt bij verwerkersovereenkomsten onder de AVG, bij algemene zorgplichten, bij B2B-aansprakelijkheid en bij financierings- of auditvragen. De vraag is niet of elke mkb-leverancier morgen quantumveilige encryptie moet hebben. De vraag is of uw contract voldoende ruimte geeft om tijdig bewijs, planning en herstel te eisen.
Het lastige punt is de levensduur van data. Sommige gegevens zijn na zes maanden waardeloos; andere dossiers blijven jaren gevoelig. Een aanvaller kan versleutelde communicatie of back-ups nu verzamelen en later ontsleutelen zodra technologie of kwetsbaarheden dat mogelijk maken. Dat scenario wordt vaak “harvest now, decrypt later” genoemd. Voor een webshop met gewone orderdata is het risico anders dan voor een SaaS-bedrijf met medische, financiële of technische klantgegevens. Contracten moeten dat verschil kunnen dragen.
Daarom verdient de quantumclausule een plaats naast bekende onderwerpen zoals uptime, datalekmelding, subverwerkers, escrow, exit, intellectuele eigendom en aansprakelijkheidslimieten. JAVB bouwde eerder de bredere praktijk rond contracten, AI-recht, IE en ondernemingsrecht voor ondernemers uit; de ondernemerspagina over AI en quantumrecht laat dezelfde ontwikkeling zien vanuit technologie- en bedrijfsregulering. Deze clausule maakt een abstracte standaard concreet in de stukken die oprichters en directeuren daadwerkelijk ondertekenen.
De fout: een garantie vragen die niemand serieus kan geven
Een absolute garantie dat een SaaS-dienst “quantum safe” is, klinkt aantrekkelijk en is juridisch vaak onhandig. De stand van de techniek beweegt. Leveranciers hebben afhankelijkheden in cloudhosting, TLS-configuraties, certificaten, libraries, identity-providers, API-gateways en back-upsoftware. Een brede garantie zonder bewijsmechanisme leidt later tot discussie: wat viel er precies onder, welke standaard gold op welk moment, en welke kosten of downtime waren redelijk?
Beter is een bewijsclausule. Die vraagt niet om geruststelling, maar om een inventaris, een routekaart en een wijzigingsplicht wanneer relevante standaarden of risico’s veranderen. De juridische winst zit in administratieve leesbaarheid. Een directeur, auditor, investeerder of wederpartij kan achteraf zien wat gevraagd is, welk antwoord is gegeven en wanneer een update nodig werd. Dat is contractrecht als logboek, niet als decoratie.
De nuttige vergelijking komt uit software supply chain governance. Een SBOM of CBOM geeft geen magische veiligheid, maar maakt afhankelijkheden zichtbaar. CycloneDX beschrijft bijvoorbeeld Cryptography Bill of Materials als een manier om cryptografische componenten, algoritmen en certificaten in kaart te brengen. Voor veel ondernemers is dat nog te technisch om letterlijk in elke overeenkomst te eisen. Als contractmodel is het wel bruikbaar: vraag naar een begrijpelijke lijst van cryptografische afhankelijkheden die voor uw data en dienstniveau relevant zijn.
Wat hoort in een quantumclausule?
Een werkbare clausule begint met scope. Welke data, koppelingen, omgevingen en subleveranciers vallen onder de verplichting? Een leverancier die alleen een planningstool levert voor interne afspraken hoeft anders te rapporteren dan een leverancier die klantdossiers, broncode of betalingsgegevens verwerkt. Scope voorkomt dat de clausule een theoretisch monster wordt.
Vervolgens komt bewijs. De leverancier kan periodiek verklaren welke cryptografische standaarden hij gebruikt voor transport, opslag, signing, key management en identity. Hij hoeft niet altijd broncode of gevoelige beveiligingsdetails te delen. Een samenvattende verklaring, aangevuld met SOC 2-, ISO-, penetratietest- of architectuurbewijs waar beschikbaar, kan al veel doen. Belangrijk is dat de verklaring gedateerd is en bij materiële wijzigingen wordt bijgewerkt.
Daarna volgt migratie. De clausule moet regelen dat de leverancier een redelijke post-quantum migratieplanning onderhoudt wanneer standaarden, wetgeving of algemeen aanvaarde beveiligingspraktijk dat verlangen. NIST’s PQC-pagina’s over post-quantum cryptography en de FIPS-publicaties zijn hierbij bruikbare publieke ijkpunten. Een contract hoeft die standaarden niet blind te incorporeren, maar kan wel verwijzen naar “relevante, publiek erkende standaarden” en een overlegplicht opnemen zodra die voor de dienst materieel worden.
Tot slot moet de clausule kosten, verstoring en aansprakelijkheid adresseren. Wie betaalt voor een noodzakelijke migratie? Wanneer mag de leverancier onderhoud inplannen? Geldt een beveiligingsgebrek als wanprestatie, of alleen wanneer de leverancier nalaat om afgesproken bewijs, updates of herstelmaatregelen te leveren? Zonder die verdeling verandert post-quantum taal in een ruzie bij verlenging of incident.
Een korte beslisroute voor ondernemers
Gebruik geen lange vragenlijst als de transactie klein is. Kies een risicogestuurde route. Eén: bevat de dienst persoonsgegevens, bedrijfsgeheimen, IP, broncode, financiële data of lang houdbare klantinformatie? Twee: is de leverancier technisch kernleverancier of slechts ondersteunend? Drie: loopt het contract langer dan twaalf maanden, of verlengt het automatisch? Vier: zijn subverwerkers en cloudproviders belangrijk voor de beveiliging? Vijf: kan de leverancier ten minste een gedateerde security- en cryptografieverklaring geven?
Bij laag risico is een lichte informatieplicht voldoende: de leverancier bevestigt dat hij algemeen aanvaarde beveiligingsmaatregelen volgt en materiële wijzigingen meldt. Bij middelhoog risico vraagt u om jaarlijkse evidence, een updateplicht en overleg bij relevante standaardwijzigingen. Bij hoog risico hoort een zwaardere clausule met migratieplanning, auditrecht op samenvattend niveau, exit-assistentie en een expliciete regeling voor herstelkosten.
Let ook op inkooppsychologie. Grote leveranciers sturen vaak standaardantwoorden. Kleine leveranciers beloven soms te veel. In beide gevallen helpt een compacte clausule beter dan dreigende taal. Vraag om bewijs dat past bij de leverancier. Een start-up kan misschien geen volledige CBOM leveren, maar wel uitleggen welke cloudprovider, certificaatstrategie en updateprocedure zij gebruikt. Een enterprise leverancier kan niet volstaan met “we monitor developments”.
De verbinding met AVG, AI en gewone aansprakelijkheid
Voor AVG-contracten raakt de quantumclausule aan passende technische en organisatorische maatregelen. Dat betekent niet dat de AVG nu een specifieke post-quantum standaard voorschrijft. Het betekent wel dat gevoelige en lang houdbare persoonsgegevens anders gewogen kunnen worden dan vluchtige operationele data. Een verwerkersovereenkomst die alleen statisch naar beveiliging verwijst, mist de dynamiek van cryptografische veroudering.
Voor AI- en datasamenwerkingen is de inzet nog scherper. Trainingsdata, prompts, embeddings, modeloutput, klantdocumenten en API-logs kunnen contractueel door meerdere lagen gaan. Als een AI-leverancier of analytics-platform informatie lang bewaart, kan cryptografische migratie deel worden van de vraag wie feitelijke controle houdt over bedrijfsinformatie. Dat sluit aan bij de bredere JAVB-lijn rond vendor risk en documentcontrole: het contract moet de technische keten leesbaar maken voor ondernemers die niet zelf de infrastructuur beheren.
Voor aansprakelijkheid is nuance nodig. Een leverancier moet niet onbeperkt aansprakelijk worden voor alle toekomstige cryptografische doorbraken. Een afnemer moet ook niet alle schade dragen wanneer de leverancier elementaire informatie weigert of een afgesproken migratieplicht negeert. De beste clausule koppelt aansprakelijkheid aan concrete contractplichten: juiste verklaring, tijdige update, redelijke migratie, melding van materiële wijziging en medewerking bij exit.
Van geruststelling naar dossier
De commerciële les is eenvoudig: vraag uw SaaS-leverancier niet om een belofte die marketing goed klinkt maar juridisch mistig blijft. Vraag om een dossier. Een dossier bevat de datum, de scope, de gebruikte standaarden, bekende afhankelijkheden, migratieroute, updateplicht en een contactpunt voor securityvragen. Als later een investeerder, auditor, klant of toezichthouder vraagt wat u aan vendor risk heeft gedaan, is dat dossier veel waardevoller dan een algemene zin in de offerte.
JAVB kan helpen met een gerichte contract-readiness scan voor SaaS-, vendor- en verwerkersovereenkomsten: rode vlaggen in beveiligingsclausules, aansprakelijkheidslimieten, subverwerkers, exit en post-quantum bewijsverplichtingen. Voor ondernemers die veel leverancierscontracten tekenen, is een vaste clausulebibliotheek vaak genoeg om de onderhandeling scherper te starten zonder elk dossier onnodig zwaar te maken.
Snapshotdatum bronnen: 29 juni 2026. Gebruikte publieke bronnen zijn onder meer NIST post-quantum cryptography/FIPS-informatie, de Europese PQC-roadmap en CycloneDX CBOM-documentatie.