← Back to all articles

Digitale soevereiniteit in documentinfrastructuur: wat het betekent en waarom het ertoe doet

SealDoc Team · · 5 min read

“In de EU gehost” is niet hetzelfde als “EU-soeverein.” Dit onderscheid is de bron van de meeste complianceproblemen die organisaties ontdekken als het te laat is: na een gegevensdoorvoer-impactbeoordeling, na een regelgevingsonderzoek of na een leverancier die zijn voorwaarden wijzigt.

Voor documenten die juridisch gewicht dragen, is de soevereiniteitsvraag niet academisch. Ze bepaalt of je organisatie de controle over haar eigen bewijs heeft, of dat die controle is gedelegeerd aan een leverancier onder voorwaarden die kunnen veranderen.

Wat soevereiniteit betekent voor documentinfrastructuur

Soevereiniteit over documentinfrastructuur betekent:

Gegevenswoonplaats: documenten zijn opgeslagen op infrastructuur die zich fysiek bevindt in een jurisdictie waar de toepasselijke gegevensbeschermingswet van toepassing is, en er wordt geen kopie buiten die jurisdictie bewaard of verwerkt zonder uitdrukkelijke toestemming.

Toegangsbeheer zonder leveranciersuitzonderingen: de leverancier heeft geen toegang tot je documenten tenzij onder de voorwaarden die je uitdrukkelijk hebt afgesproken. Dit sluit leveranciersonderhoudstoegang, verzoeken van wetshandhaving onder buitenlands recht en toegang door moederbedrijven in andere jurisdicties uit.

Overdraagbaarheid van bewijs: je kunt al je documenten, auditsporen, tijdstempels en evidence packs exporteren in een formaat dat verifieerbaar is zonder deelname van de leverancier. Als de leverancier morgen sluit, blijft je bewijs geldig.

Geen blootstelling aan buitenlandse jurisdictie: de leverancier is niet onderworpen aan wetten die openbaarmaking aan buitenlandse overheden of agentschappen verplichten, zoals de Amerikaanse CLOUD Act of vergelijkbare wetgeving in andere jurisdicties.

Waarom “in de EU gehost” niet voldoende is

Een cloudservice kan gegevens hosten in EU-datacenters terwijl hij nog steeds onderworpen is aan een niet-EU-jurisdictie. Als de exploiterende onderneming is gevestigd in de Verenigde Staten, haar moederbedrijf Amerikaans is of anderszins onderworpen is aan Amerikaans recht, kan ze onder de CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 2018) verplicht worden in EU-faciliteiten opgeslagen gegevens te verstrekken aan de Amerikaanse wetshandhaving, zonder medeweten of toestemming van de betrokkene.

Het Hof van Justitie van de EU (HvJEU) heeft het EU-VS Privacy Shield in 2020 (Schrems II) nietig verklaard, juist omdat de Amerikaanse surveillancewet adequate bescherming onmogelijk maakt voor persoonsgegevens die worden overgedragen aan of toegankelijk zijn voor door de VS gecontroleerde entiteiten. Het daaropvolgende EU-VS Data Privacy Framework kent juridische onzekerheid sinds zijn aanneming.

Voor documenten die persoonsgegevens bevatten (waaronder facturen, HR-dossiers, contracten en medische documenten) is een leverancier die onderworpen is aan de Amerikaanse jurisdictie maar gegevens opslaat in EU-datacenters geen soevereine oplossing. De gegevenswoonplaats is EU; de juridische blootstelling niet.

Het leveranciersafhankelijkheidsprobleem specifiek voor documentbewijs

De meeste documentplatforms creëren afhankelijkheid die onzichtbaar is totdat je wilt vertrekken. Voor documenten zonder juridisch gewicht is dit een ongemak. Voor documenten die als juridisch bewijs dienen, is het een structureel risico.

De specifieke afhankelijkheidsmechanismen om op te letten:

Eigen auditspoorformaten: als het auditspoor van de leverancier niet exporteerbaar is in een verifieerbaar formaat, hangt je chain of custody af van het operationeel blijven van het systeem van de leverancier en hun API toegankelijk blijft. Als de leverancier wordt overgenomen, sluit of hun API wijzigt, kan je chain of custody onverifieerbaar worden.

Tijdstempels van door leveranciers gecontroleerde autoriteiten: als de RFC 3161-tijdstempels op je documenten worden uitgegeven door een TSA die door de leverancier wordt beheerd, vereist het verifiëren van die tijdstempels nadat de leveranciersrelatie is beeindigd de voortdurende medewerking van de leverancier. Dit is een tegenstrijdigheid: de tijdstempel is juist bedoeld om onafhankelijk verifieerbaar te zijn.

Ondoorzichtige validatierecords: als de validatierapporten in je evidence pack leesbaar HTML zijn in plaats van machine-parseerbare gestructureerde gegevens, kan een toekomstige auditor de validatie misschien niet reproduceren zonder hem opnieuw uit te voeren, wat hem niets vertelt over of het document geldig was op het moment van archivering.

De test voor echte soevereiniteit: kun je je documenten en evidence packs meenemen naar een technisch competente derde partij die nooit interactie heeft gehad met je leverancier, en laten ze de integriteit en herkomst van elk document verifiëren, uitsluitend met open standaarden en publieke-sleutelinfrastructuur?

Als het antwoord nee is, is je bewijsinfrastructuur niet soeverein.

AVG en verplichtingen voor documentbewaring

De AVG creëert specifieke spanningen met langetermijndocumentbewaring. Artikel 5 lid 1 sub e vereist dataminimalisatie: persoonsgegevens mogen niet langer worden bewaard dan noodzakelijk. Artikel 17 stelt het recht op wissing in. Maar nationale belastingwetten verplichten het bewaren van facturen (die persoonsgegevens bevatten) gedurende zeven tot tien jaar.

De oplossing is de bewaringsuitzondering in AVG artikel 17 lid 3 sub b: wissingsverplichting geldt niet waar verwerking noodzakelijk is voor naleving van een wettelijke verplichting. Factuurbewarig onder de GoBD, de Franse fiscale wet of Belgisch btw-recht kwalificeert.

De praktische implicatie voor soevereiniteit: je moet voor elk bewaard document kunnen aantonen dat de bewaring wordt gedekt door een specifieke wettelijke verplichting, en dat de bewaartermijn en reikwijdte niet ruimer zijn dan die verplichting vereist. Dit is een documentatie- en auditspoorvereiste, niet alleen een opslagvereiste.

Hoe soevereine documentinfrastructuur eruitziet

Een soevereine documentinfrastructuur voldoet aan deze criteria:

  1. Geexploiteerd door een entiteit die uitsluitend is opgericht en actief is in een jurisdictie met adequate gegevensbescherming (EU-lidstaten voldoen hieraan voor EU-gegevens)
  2. Geen moederbedrijf, investeringsstructuur of contractuele regeling die blootstelling aan niet-EU-jurisdictie creëert
  3. Evidence packs exporteerbaar in open, verifieerbare formaten (PDF/A-3, CMS-tijdstempeltokens, JSON-auditsporen)
  4. RFC 3161-tijdstempels van TSA’s vermeld op de EU-vertrouwenslijst, geen door leveranciers beheerde TSA’s
  5. Hashketens verifieerbaar met open-sourcehulpmiddelen zonder leveranciersdeelname
  6. Zelfhostbare optie voor organisaties die complete infrastructuurcontrole vereisen

Punt 6 is bijzonder relevant voor overheidsinstellingen, gereguleerde financiele instellingen en exploitanten van kritieke infrastructuur, die mogelijk vereisten hebben die het gebruik van elke door derden gehoste dienst uitsluiten, ongeacht jurisdictie.

SealDoc en EU-soevereiniteit

SealDoc opereert uitsluitend op EU-gebaseerde infrastructuur onder EU-jurisdictie. Er is geen moederbedrijfsrelatie die buitenlandse jurisdictieblootstelling creëert.

Evidence packs geproduceerd door SealDoc zijn onafhankelijk verifieerbaar: RFC 3161-tijdstempels van TSA’s op de EU-vertrouwenslijst, hashketens verifieerbaar met SHA-256 en auditsporen geexporteerd als gestructureerde JSON. Verificatie vereist geen API-aanroep naar SealDoc en geen voortdurende relatie met SealDoc.

Voor organisaties die on-premises of private-cloudimplementatie vereisen, ondersteunt SealDoc zelf-gehoste implementatie op je eigen infrastructuur. Het evidence-formaat is identiek aan de gehoste versie, zodat migreren van gehost naar zelfgehost of terug de verificeerbaarheid van eerder uitgegeven evidence packs niet beinvloedt.

Het onderliggende principe is dat het bewijs elke specifieke leveranciersrelatie moet overleven. Als SealDoc in 2038 niet meer bestaat, moet elk vandaag uitgegeven evidence pack nog steeds verifieerbaar zijn door een auditor met een SHA-256-implementatie en het publieke certificaat van de TSA.


← Back to all articles