Security & compliance
Security & compliance
De databescherming en GDPR-mechanismen die in het platform zijn ingebouwd — hoe persoonsgegevens worden beschermd, hoe verzoeken van betrokkenen worden afgehandeld en hoe elke privileged action wordt vastgelegd.
- Regelgeving
- GDPR · EU 2016/679
- Encryptie
- Per-tenant AES-256-GCM
- Status
- Gebouwd & demonstreerbaar
Fundament
Waar alles op gebouwd is
Zeven uitgangspunten die gelden voor elk scherm dat volgt. De features laten zien hoe ze worden nagekomen.
- P1
PII verlaat het platform nooit in cleartext
Persoonsgegevens worden via tokenization vervangen voordat een extern model ze ziet, en op de terugweg hersteld. Niets gevoeligs passeert de tenant boundary in cleartext.
- P2
Encryptie per tenant
AES-256-GCM met keys die per tenant en per doel worden afgeleid. De key van de ene tenant kan de data van een andere tenant niet lezen — afgedwongen door de cipher, niet door beleid.
- P3
Acties staan in een immutable trail
De audit log is append-only op databaseniveau. Entries kunnen worden toegevoegd, maar nooit worden bewerkt of stilletjes verwijderd.
- P4
Writes over de trust boundary controleren de rol opnieuw
Admin-acties lezen de rol van de actor opnieuw uit de database op het moment van de write, nooit uit een gecachte sessie.
- P5
Verwijderen betekent dat de data weg is
Het recht op verwijdering wist de records en PII-mappings van de betrokkene, verwijdert key material waar dat van toepassing is en laat een gedateerd proof certificate achter.
- P6
Bewaartermijnen worden afgedwongen, niet beloofd
Scheduled jobs passen de termijnen toe en schonen verouderde data automatisch op — en elke automatische verwijdering wordt zelf ook geaudit.
- P7
Data-isolatie is de standaard
De data van elke tenant staat in een eigen directory. Toegang, export en verwijdering zijn vanuit de opzet tot die grens beperkt.
Dataminimalisatie
PII-bescherming & detectie
Voordat een bericht een extern taalmodel bereikt, worden gevoelige entiteiten gedetecteerd en vervangen door stabiele tokens; in het antwoord worden de echte waarden hersteld.
Instance → PII protection · master switch, regex + NLP layers, backend health, confidence threshold, allowlist, per-entity control.
- Art 5(1)(c)
- Art 25
- Art 32
Dataminimalisatie, protection by design en beveiliging bij verstrekking aan derden.
- Reversible tokenization — binnen een gesprek krijgt dezelfde entiteit steeds hetzelfde token, zodat de context behouden blijft zonder de waarde te tonen.
- Twee detectielagen — een ingebouwde regex-pass (e-mails, telefoonnummers, kaarten, IBAN’s) plus een NLP-pass voor namen, plaatsen en organisaties.
- Pluggable backend — Microsoft Presidio is de standaard; een alternatieve detector is in te pluggen zonder de pipeline aan te passen.
- Fail-safe — als NLP onbereikbaar is, valt de detectie terug op alleen regex en wordt dat vastgelegd.
- Gelogd zonder blootstelling — operaties loggen het aantal en het type entiteiten, nooit de waarden.
Verantwoordingsplicht
Audit log
Een volledig, filterbaar en append-only overzicht van elke privileged action — wie wat deed, met welke resource en wanneer. Te exporteren voor rapportage en tamper-evident bij export.
Instance → Audit log · filteren op actor, action, resource en datumbereik; gepagineerd; export naar signed CSV / JSON.
- Art 5(2)
- Art 30
- Art 33(5)
Verantwoordingsplicht, verwerkingsregister en documentatie voor breach-onderzoek.
- Append-only vanuit de opzet — afgedwongen in de database; entries kunnen niet achteraf worden gewijzigd of verwijderd.
- Filteren & pagineren — op actor (naam, e-mail of id), action, resource type en datumbereik.
- Tamper-evident export — CSV / JSON achter een signed, tijdgebonden URL die achteraf te verifiëren is.
- Geen PII in de trail — de log en de export bevatten alleen metadata.
- Inclusief systeemacties — retention purges, key rotations en breach-signalen staan naast menselijke acties.
Toegangsbeheer
Rollen & rechten
Toegang loopt via een matrix van rollen en rechten, verdeeld over instance-brede en workspace-specifieke bevoegdheden, met overrides per gebruiker. De admin-rol kan zichzelf niet buitensluiten.
Instance → RBAC · matrices op instance- en workspaceniveau; de RBAC-config-cel van de admin-rol is vergrendeld; elke wijziging wordt geaudit.
- Art 5(1)(f)
- Art 32(1)(b)
Integriteit en vertrouwelijkheid via toegangsbeheer dat past bij het risico.
- Least privilege per rol — vier rollen boven een vaste catalogus van rechten.
- Scheiding tussen instance en workspace — tenant-brede en workspace-specifieke bevoegdheden zijn aparte partities; een wijziging in de ene kan niet doorlekken naar de andere.
- Per-user overrides — geef of ontneem één recht aan één persoon, bovenop diens rol.
- Lockout protection — RBAC-config kan niet van de admin-rol worden verwijderd; de server weigert de poging.
- Live re-authorisation — elke wijziging leest de rol van de bewerker opnieuw uit en schrijft een before→after audit row.
Rechten van betrokkenen
Inzage, overdraagbaarheid, verwijdering & correctie
Alle rechten van betrokkenen, van begin tot eind — elk verzoek heeft een wettelijke deadline, verwijdering vraagt goedkeuring en is onomkeerbaar, en een afgeronde verwijdering levert een ondertekend proof certificate op.
Compliance → Data subject rights · deadlines volgens artikel 12, approval-gated erasure en het erasure proof certificate.
- Art 12
- Art 15
- Art 16
- Art 17
- Art 20
Transparante, tijdige afhandeling van inzage, correctie, verwijdering en overdraagbaarheid.
- Inzage en overdraagbaarheid, apart gehouden — Art 15 levert alles wat is opgeslagen; Art 20 levert de machineleesbare subset die de betrokkene zelf heeft aangeleverd.
- De termijn van één maand is zichtbaar — elk verzoek toont de deadline volgens Art 12(3); een verlenging bij een complexe zaak wordt vastgelegd en geaudit.
- Veilige levering — exports gaan via een signed URL die verloopt; verzoek, generatie en download worden geaudit.
- Verwijdering met bewijs — verzoek → goedkeuring → uitvoering wist records, mappings en key material, en levert een gedateerd certificaat op.
- Correctie — corrigeer velden van een betrokkene met een volledige before→after trail.
Bewaartermijnen & registers
Bewaartermijnen, toestemming & verwerkingsregister
Bewaartermijnen schonen verouderde data volgens schema op, toestemming wordt vastgelegd met de rechtsgrond en een manier om die in te trekken, en het register van verwerkingsactiviteiten en sub-processors volgens artikel 30 wordt bijgehouden.
Compliance → Retention & records · bewaartermijnen per categorie, toestemming met rechtsgrond, sub-processor register en de ROPA-tabel.
- Art 5(1)(e)
- Art 6
- Art 7
- Art 30
- Art 28
- Art 35
Opslagbeperking, rechtsgrond, verwerkingsregister, governance van verwerkers, DPIA.
- Scheduled auto-purge — termijnen per categorie, afgedwongen door durable jobs; de standaard bewaartermijn voor audits is één jaar.
- Geaudite verwijdering — zelfs beleidsmatige verwijdering uit de append-only log loopt via één beveiligd, geaudit pad; onbeveiligde deletes worden nog steeds geweigerd.
- Toestemming met rechtsgrond — doel, rechtsgrond volgens Art 6 en tijdstempel per activiteit, plus een intrekkingsflow en audit trail.
- Verwerkingsregister — een register volgens Art 30 en een goedgekeurde lijst van sub-processors (LLM, observability, shared services), met een DPIA-hook.
Encryptie & breach
Encryption keys & breach response
De encryption keys per tenant roteren als durable job, de rate-limit posture wordt ter informatie getoond, en een bevestigde breach start de meldtermijn van 72 uur uit artikel 33, met een response-checklist die wordt bijgehouden.
Instance → Security · key rotation per doel met live status, read-only rate-limit posture en de Art 33 breach countdown.
- Art 32
- Art 33
- Art 34
Beveiliging van de verwerking, melding van breaches en communicatie met betrokkenen.
- Key rotation op aanvraag — keys per tenant en per doel; de rotatie is durable, hervatbaar en voorzien van een versie, zodat oud en nieuw tijdens de overgang naast elkaar bestaan.
- Crypto-shredding — door key material te verwijderen kan een artifact onherstelbaar worden; dit is het mechanisme achter het verwijderen van versleutelde data.
- Breach detection — anomaly signals (herhaalde auth-fouten, rate-limit-pieken, ongebruikelijke toegang) maken een candidate aan.
- De klok van 72 uur — een bevestigde breach krijgt een deadline; het scherm toont de resterende tijd, markeert een overschreden deadline en legt een eventuele reden voor late melding vast.
- Response workflow — assess → contain → notify, elke stap gedateerd en geaudit; de admin krijgt een melding in de app en, als dat is ingesteld, per e-mail.
Dekking
GDPR-dekking in één oogopslag
Hoe de gebouwde features de verplichtingen afdekken. “Gebouwd” betekent geleverd en demonstreerbaar; het ene open punt staat er eerlijk bij.
| Verplichting | Artikelen | Hoe we eraan voldoen | Status |
|---|---|---|---|
| Dataminimalisatie & protection by design | 5(1)(c) · 25 | Reversible PII tokenization vóór verstrekking aan externe modellen | Gebouwd |
| Beveiliging van de verwerking | 32 | Per-tenant AES-256-GCM, rotation, RBAC, rate limiting | Gebouwd |
| Verantwoordingsplicht & registers | 5(2) · 30 | Append-only audit log + verwerkingsregister | Gebouwd |
| Recht op inzage & overdraagbaarheid | 15 · 20 | Portable export, scheiding tussen inzage en overdraagbaarheid, signed delivery | Gebouwd |
| Correctie & verwijdering | 16 · 17 | Approval-gated verwijdering met proof certificate + crypto-shred | Gebouwd |
| Tijdige reactie | 12(3) | Deadline van één maand op elk verzoek, geaudite verlenging | Gebouwd |
| Opslagbeperking | 5(1)(e) | Bewaartermijnen per categorie met geaudite auto-purge | Gebouwd |
| Rechtsgrond & toestemming | 6 · 7 | Toestemmingsregistratie met rechtsgrond + intrekkingsflow | Gebouwd |
| Governance van verwerkers & DPIA | 28 · 35 | Sub-processor register met goedkeuring; DPIA-record hook | Gebouwd |
| Melding van breaches | 33 · 34 | Candidate detection, klok van 72 uur, response workflow | Gebouwd |