Beveiliging is een kernonderdeel van hoe wij bouwen. Deze pagina beschrijft wat er vandaag daadwerkelijk waar is over onze architectuur en werkwijze — geen marketingchecklist. Waar wij iets nog niet hebben afgerond (een formele audit, een certificering), zeggen wij dat gewoon ronduit in plaats van iets anders te suggereren.
Gezondheidszorg en HIPAA
Op dit moment zijn de producten van Divinci niet goedgekeurd voor beschermde gezondheidsinformatie (PHI). Geen enkele Business Associate Agreement dekt het Divinci-platform, en u moet er geen PHI in invoeren.
Wij bereiden één afzonderlijk aanbod voor de gezondheidszorg voor: een speciale chat-runtime, gehost in een eigen Google Cloud-project en gescheiden van de rest van het Divinci-platform. Deze is zo ontworpen dat hij geen gespreksverslagen opslaat. Wij tekenen nog geen Business Associate Agreements.
Wat dit niet is: een HIPAA-nalevingscertificering. Er bestaat geen door de overheid afgegeven HIPAA-certificaat, en wij beweren niet HIPAA-compliant te zijn. Naleving is een combinatie van technische maatregelen, schriftelijke beleidsregels en ondertekende Business Associate Agreements met elke leverancier in het gegevenspad, beoordeeld per klantrelatie. Wij hebben schriftelijk beleid vastgesteld dat nog juridisch wordt getoetst, en wij melden het hier zodra dat verandert.
Gegevensbescherming
Versleuteling
- Tijdens transport: overal TLS tussen clients, onze edge en onze origin-infrastructuur.
- In rust: versleuteling op aanbiedersniveau voor onze primaire gegevensopslag en objectopslag, plus een aparte versleutelingslaag op veldniveau voor aangewezen gevoelige velden.
- Beheer van geheimen: inloggegevens en API-sleutels worden beheerd via een centrale secrets manager, niet hard gecodeerd of in platte tekst in configuratie opgeslagen. De productieomgeving is zo geconfigureerd dat zij gesloten faalt in plaats van stilzwijgend terug te vallen op verouderde inloggegevens wanneer de secrets-dienst onbereikbaar is.
Gegevensminimalisatie
- Optionele PII-redactie (Microsoft Presidio) kan worden toegepast op chatinhoud voordat deze wordt opgeslagen of naar een AI-aanbieder wordt gestuurd. Het is entiteitsdetectie, geen HIPAA-vaststelling van de-identificatie, en het maakt een product niet geschikt voor PHI.
- Logs bevatten volgens beleid uitsluitend metadata: wij schrijven geen berichtinhoud, e-mailadressen of andere persoonsgegevens naar applicatielogs of foutmeldingen.
Toegangsbeheer
- Authenticatie via Auth0.
- Rolgebaseerd toegangsbeheer (op platformniveau) plus rechten per resource (op document-/workspaceniveau) — standaard volgens het principe van minimale rechten.
- Manipulatiebestendige auditlogging: toegang tot gevoelige gegevens wordt vastgelegd in een via hashes geketend logboek, ontworpen zodat vermeldingen achteraf niet ongemerkt kunnen worden gewijzigd.
- Elk kwartaal beoordelingen van toegang en configuratie van productiediensten.
Applicatiebeveiliging
- XSS-verdediging op de rendergrens: door gebruikers en door AI gegenereerde inhoud wordt opgeschoond (DOMPurify) overal waar die als HTML wordt weergegeven; rauwe HTML-injectie vanuit niet-vertrouwde bronnen is niet toegestaan.
- Autorisatietests: wij voeren onze eigen AI-ondersteunde en handmatige beveiligingstests uit tegen staging en productie, inclusief geauthenticeerde autorisatie-/IDOR-tests — dit is (nog) géén terugkerend programma voor penetratietests door een externe partij, en wij gaan er ook geen claimen zolang het niet bestaat.
- Afhankelijkheden en code review: standaard code review op alle wijzigingen; updates van afhankelijkheden worden bijgehouden via onze normale buildtooling.
Beschikbaarheid en monitoring
- Synthetische monitoring op endpoints die klanten gebruiken, waarbij de wachtdienst via PagerDuty binnen enkele minuten na een echte storing wordt gealarmeerd, niet alleen bij serverfouten — controles die de inhoud verifiëren, niet alleen “gaf het een 200 terug”.
- Infrastructuur in meerdere regio’s (Cloudflare edge + Google Cloud origin) met geautomatiseerde back-ups van onze primaire gegevensopslag.
- Wij publiceren op dit moment geen contractuele uptime-SLA. Heeft uw use case er wel een nodig, vraag het ons dan — dan bespreken wij wat realistisch is voor uw implementatie.
Incidentrespons
Wij hanteren een gedocumenteerd incidentresponsproces: detectie en classificatie, indamming, een eerlijke beoordeling of een incident neerkomt op een meldingsplichtig datalek, herstel, en een blameless post-mortem die terugvloeit in waar wij vervolgens op monitoren. Bent u klant met een Business Associate Agreement bij ons, dan legt die overeenkomst onze meldingsverplichtingen aan u vast — die voorwaarden zijn bepalend, niet deze pagina.
Om een beveiligingszorg of een vermoedelijke kwetsbaarheid te melden, mailt u security@divinci.ai. Wij hebben op dit moment geen formeel bug-bountyprogramma; wij nemen meldingen wel serieus en werken te goeder trouw met u samen.
Waar wij staan met formele certificeringen
Hierover zijn wij direct, omdat veel beveiligingspagina’s dat niet zijn:
- HIPAA: wij hebben geen HIPAA-certificering en beweren geen naleving. Zie „Gezondheidszorg en HIPAA” hierboven.
- SOC 2: nog niet gestart. Het staat op onze roadmap; wij werken deze pagina bij zodra er iets echts te melden valt — niet eerder.
- ISO 27001, FedRAMP, PCI DSS: deze certificeringen bezitten wij niet. Kaartbetalingen worden verwerkt via Stripe; Divinci slaat zelf geen kaarthoudergegevens op.
Wij claimen liever te weinig en worden vertrouwd, dan te veel te claimen en er later op terug te moeten komen.
Contact
Beveiligingsvragen, kwetsbaarheidsmeldingen of nalevingsvragen voor een specifieke deal: security@divinci.ai