Serie NTA 7516, deel 2 van 3. Dit is De analyse. In deel 1, De diagnose, las je de close reading van de norm waarop dit voortbouwt.

In short, this article is in Dutch. It is the second of three parts on NTA 7516, the Dutch standard for secure email in healthcare. Part one read the norm clause by clause. This part weighs what the current implementation delivers against what it costs, and why switching providers is so hard. Part three turns that into proposals.

Openheid vooraf. Ik werk als Solution Engineer bij Microsoft, en dit stuk gaat over een markt waarin Microsoft met eigen producten aanwezig is. Ik beoordeel het platform dat ik ken en dagelijks gebruik, Microsoft 365, en ik benoem expliciet waar een gespecialiseerde leverancier vandaag méér levert dan Microsoft 365. Alle normverwijzingen staan erbij, en de norm zelf is gratis op te vragen bij NEN, dus je kunt de clausules naast mijn lezing leggen. En één ding hoort daar expliciet bij: het middenpad dat ik verderop schets leunt op betaalde Microsoft-functionaliteit, en consolidatie op dat platform is in het voordeel van mijn werkgever. Dat maakt het argument niet onjuist, maar je mag het meewegen. Dit is een persoonlijke bijdrage aan het normdebat, geen compliance-advies en geen standpunt van Microsoft. NTA 7516-conformiteit stel je zelf vast.

In het kort

Voor wie weinig tijd heeft, en zeker voor wie over contracten en budgetten gaat.

  • De zorg lekt vooral door verkeerde adressering, niet door onderschepte mail. Van ruim 9.800 datalekmeldingen over de eerste helft van 2024 kwam 41 procent door verkeerd geadresseerde post en 18 procent door fouten bij het mailen. Malware, hacking en phishing samen waren goed voor 8 procent. Bij Z-CERT zegt slechts 6 procent van de respondenten dat verkeerd bezorgde mail nooit voorkomt.
  • Het geld gaat naar de categorie waar het minst misgaat. Versleuteling helpt per definitie niet tegen een correct versleuteld bericht dat bij de verkeerde persoon aankomt.
  • De kosten zijn substantieel. Vijftien zorgorganisaties becijferden een geschatte besparing van 40 miljoen euro per jaar in alleen al de ouderenzorg.
  • Jurisdictie is iets anders dan geografie. Toen Zivver werd overgenomen door het Amerikaanse Kiteworks, veranderde de juridische situatie zonder dat er één server verhuisde. Een controle op serverlocatie ziet dat verschil nooit. Dat geldt overigens net zo goed voor Amerikaanse platformleveranciers, mijn eigen werkgever inbegrepen.
  • Overstappen is duur om redenen die weinig met beveiliging te maken hebben.

De vraag om mee te nemen: weet u welk deel van uw beveiligde mailverkeer naar vaste ketenpartners gaat en welk deel naar losse ontvangers? Dat bepaalt of een aparte dienst zijn geld waard is.

Terugblik en stellingname

Deel 1 eindigde op een vraag die ik hier niet laat liggen. Als niemand je nog kan certificeren, en een groot deel van wat de norm vraagt organisatorisch is in plaats van technisch, wat betekent naleving dan eigenlijk nog? Het toetsingsschema NCS 7516 verviel per 15 mei 2022, maar de onderliggende plicht bleef. De AVG blijft passende technische en organisatorische maatregelen eisen bij het uitwisselen van gezondheidsgegevens (artikel 32, voor de bijzondere gegevens uit artikel 9). Daarmee verschuift de vraag van “heb ik een record?” naar “kan ik naleving aantonen?”. Dat is het scharnier van dit tweede deel.

Ik breng drie stellingen in, alle drie bedoeld als bijdrage aan het normdebat, niet als eindoordeel. De eerste: bijzondere patiëntgegevens horen in het dossier, met e-mail als uitzondering in plaats van standaardkanaal. De tweede: een betere norm vraagt om jurisdictie in plaats van servergeografie, om een certificeringsroute die daadwerkelijk bestaat, en om aantoonbaarheid als expliciete eis. De derde, en de scherpste: wat de huidige invulling netto oplevert, staat niet in verhouding tot wat de zorg ervoor betaalt. Daarna laat ik zien hoe de overstapkosten in deze markt tot stand komen, en waarom die weinig met beveiliging te maken hebben. Wat er dan zou moeten gebeuren, komt in deel 3 aan bod.

Waarom dit er überhaupt toe doet

Voordat ik de norm bekritiseer, hoort het probleem erkend te worden dat ze probeert op te lossen, en dat probleem is groot. De zorg is al jaren de sector met de meeste datalekmeldingen bij de Autoriteit Persoonsgegevens: in 2024 ging het om enkele duizenden meldingen uit gezondheid en welzijn alleen. De AVG-zorgplicht is dus geen papieren exercitie, en wie hier bezuinigt op beveiliging heeft het verkeerd begrepen.

Maar kijk naar de oorzaken, want daar wordt het interessant. Uit de CBS-analyse van ruim 9.800 datalekmeldingen over de eerste helft van 2024 blijkt dat 41 procent van de meldingen kwam door verkeerd geadresseerde post en 18 procent door fouten bij het versturen van e-mail, vaak simpelweg een verkeerde ontvanger. Malware, hacking en phishing samen waren goed voor 8 procent.

Die cijfers gaan over meldingen bij de toezichthouder. Z-CERT, het expertisecentrum voor cybersecurity in de Nederlandse zorg, vroeg het de sector zelf, en dat beeld wijst dezelfde kant op. In het Cybersecuritybeeld Zorg 2025 staat een tabel met datalekken door onopzettelijk en nalatig handelen. Bovenaan staat “verkeerd bezorgd (mail)”. Zes procent van de respondenten zegt dat dit nooit gebeurt. Tweeënveertig procent ziet het maandelijks, dertien procent wekelijks. Geen andere oorzaak in die tabel wordt zo breed herkend.

Zet daar de aanvalskant naast, uit datzelfde rapport. Z-CERT kreeg in 2025 drie ransomware-incidenten bij Nederlandse zorginstellingen gemeld, een tiental geslaagde aanvallen op leveranciers van zorginstellingen, en telde 29 gevallen waarin phishing werd verstuurd vanuit een gekraakte mailbox in de zorgketen.

Dat is geen argument om transportbeveiliging te laten zitten, want die is goedkoop en ze hoort er gewoon te zijn. Het is een argument over waar de volgende euro het meeste oplevert. Die bronnen meten verschillende dingen, een aandeel in meldingen, een waargenomen frequentie en een aantal incidenten, maar ze wijzen wel dezelfde kant op: de gegevens die weglekken, lekken vooral weg door een verkeerde ontvanger, en de aanvallen die de zorg plat leggen, komen vooral binnen via gijzelsoftware, phishing en de keten.

Zet dat naast waar een aparte veilig-mailen-dienst op stuurt. Die versleutelt het transport, authenticeert de ontvanger en controleert of de ontvangende server de norm aankan. Allemaal nuttig, en allemaal gericht op de kleinste van de drie categorieën hierboven. Tegen de grootste oorzaak, een correct versleuteld bericht dat keurig bij de verkeerde persoon aankomt, helpt versleuteling per definitie niet. Sommige leveranciers hebben daar een ontvangercontrole voor, en dat is precies de functie die ertoe doet, maar dat is een andere functie dan waar de norm om vraagt. § 6.2.2.1 gaat over het verifiëren van de ontvangende partij als systeem, niet over de vraag of het de bedoelde persoon is.

Daar zit wat mij betreft de scheefheid, en het is een scherpere formulering van stelling C. Het geld gaat naar de categorie waar het minst misgaat. En dat is geen toeval, want een systeemfout wordt nu eenmaal minder vaak gemaakt dan een menselijke. Versleuteling doet elke keer precies hetzelfde, een medewerker die onder tijdsdruk een adresregel laat aanvullen niet. Daaruit volgt de conclusie die stelling A hierna uitwerkt: elke keer dat gevoelige patiëntinformatie in een e-mail belandt, leun je voor de bescherming ervan op de minst betrouwbare schakel in de keten. Je kunt die schakel beter maken met training en met techniek, en dat moet ook, maar je kunt hem vooral minder vaak belasten. De categorie waar het meest misgaat, menselijke fouten bij het adresseren, vraagt daarnaast om andere maatregelen: adresboekhygiëne, een waarschuwing bij externe ontvangers, een korte terugroepmogelijkheid, en werkprocessen waarin gevoelige informatie niet standaard per mail vertrekt. Dat is deels techniek en deels gedrag, en het is precies waar stelling A op uitkomt.

Stelling A: hoort bijzondere patiëntdata wel in de e-mail?

NEN biedt de uitweg zelf al aan. In de eigen FAQ, op de vraag of een zorgaanbieder aan de norm moet voldoen, staat: “Wil je niet voldoen? Dat mag, maar dan ook niet mailen of chatten.” Niet-mailen is dus geen ontwijking, maar een door de normeigenaar erkende route. Daarop bouw ik voort. Vanuit beveiligingsoogpunt is e-mail een kanaal waar fouten goedkoop en onomkeerbaar zijn. Eén verkeerd aangevulde adresregel, één doorgestuurde thread, en een lek laat zich niet meer terugtrekken. Een elektronisch patiëntendossier (EPD) is het tegenovergestelde: gebouwd om toegang juist gecontroleerd te ontsluiten, met autorisatie, logging en intrekbaarheid. De richting van mijn eerste stelling is daarmee simpel. Laat bijzondere patiëntgegevens zoveel mogelijk in het dossier, en behandel e-mail als uitzondering.

Die richting is bovendien concreter dan ze klinkt, want het model bestaat al. Wie met DigiD inlogt op een portaal kan daar gewoon een bericht achterlaten voor de organisatie, met een notificatie per e-mail die alleen meldt dát er een bericht klaarstaat. De inhoud blijft in het systeem. Dat is precies hoe de Belastingdienst en MijnOverheid het doen, en in de zorg draait het ook al: ziekenhuizen bieden e-consult via hun patiëntenportaal, en Nedap levert bij Ons Dossier het cliëntportaal Caren, “een digitale zorgmap en communicatieplatform ineen” dat naast de cliënt ook diens verwanten bedient.

Belangrijker nog is wat DigiD met de authenticatie-eis doet. DigiD Substantieel komt overeen met eIDAS Substantieel, precies het niveau waar § 5.6 en § 6.1.10 om vragen. Bij losse e-mail is dat niveau lastig te halen, omdat je een tweede kanaal naar de ontvanger nodig hebt dat er vaak niet is. Voor een Nederlandse burger bestaat dat kanaal wel, landelijk, en het is gratis. Ook de mantelzorger en de wettelijk vertegenwoordiger zijn belegd: het Stelsel Toegang kent voorzieningen voor vrijwillig machtigen en wettelijk vertegenwoordigen op substantieel en hoog. Het portaal haalt de authenticatie-eis dus juist makkelijker dan het mailkanaal, en niet moeilijker.

Toch sluit een portaal § 6.5 niet helemaal. De norm vraagt dat het inkomende kanaal bruikbaar is voor “iedereen met voor particulieren gebruikelijke internetvoorzieningen”, en DigiD veronderstelt een BSN. Wie dat niet heeft, een familielid in het buitenland bijvoorbeeld, komt er niet in. En § 6.1.15 voorziet expliciet in het geval dat iemand een ontvangen bericht doorstuurt, bijvoorbeeld naar een mantelzorger, wat binnen de muren van een portaal nu juist niet kan. Dat laatste is overigens net zo goed een kenmerk als een gebrek, want die onomkeerbaarheid is precies wat je bij e-mail mist.

Er is nog een grens, en die weegt zwaarder. Een groot deel van het reële ad-hoc-verkeer loopt niet van of naar een patiënt, maar van professional naar ketenpartner: een huisarts, een gemeente, een zorgverzekeraar, een advocaat, een andere zorgaanbieder. Voor dat verkeer doet een patiëntenportaal helemaal niets, en dat is dan ook precies waar de open standaard uit voorstel 9 in deel 3 over gaat. Mijn eerste stelling is dus richtinggevend, geen volledig antwoord. E-mail hoort de uitzondering te worden, en veel verkeer kan naar het dossier verhuizen, maar er blijft een categorie ad-hoc-verkeer over die een veilig e-mail- of webkanaal nodig houdt.

Stelling B: jurisdictie boven geografie

De hardnekkigste misvatting over de norm is dat elke server op EU-grondgebied zou moeten staan. Dat staat er niet. § 6.1.13 is AVG-conditioneel: ad-hocverkeer mag de buitengrenzen van de Europese Economische Ruimte (EER) “slechts in overeenstemming met de AVG” overschrijden. Dat is geen absolute bodemeis dat elke server op EU- of EER-grond staat. Die harde eis komt uit leverancier-implementaties en inkoopeisen, niet uit de normtekst. Ik richt mijn kritiek daarom bewust op de implementatie en de inkoop, niet op de norm zelf.

En eerlijk naar de andere kant: voor wie met de Rechtspraak of de Raad van State mailt, is de EER-locatie in de praktijk wél een harde eis. Die partijen leggen hem contractueel op. Wie hun mailstroom moet bedienen, ontkomt er niet aan, hoe de normtekst ook luidt. Ik pleit er dus niet voor die eis te negeren. Ik pleit ervoor de eis te formuleren op de manier die het onderliggende doel echt dient.

Want dat doel is jurisdictie, niet geografie op zichzelf. Een geolocatie-check op de eerste SMTP-hop is een best-effort waarborg op zelf-gedeclareerde registratiedata, en hij dekt hooguit die eerste hop. Waar de ontvanger de data daarna opslaat of back-upt, en vanuit welk land beheerders erbij kunnen, valt erbuiten, terwijl de AVG over de héle verwerking gaat.

Hier moet ik preciezer zijn dan ik in eerste instantie was, want het gaat om twee verschillende vragen die makkelijk door elkaar lopen. De eerste is of de aflevering vertrouwelijk en authentiek is. Daarvoor bestaan controles die iedere partij machinaal kan nameten: DNSSEC (Domain Name System Security Extensions), DANE (DNS-based Authentication of Named Entities) en MTA-STS (Mail Transfer Agent Strict Transport Security). Die zijn objectief toetsbaar, en daarin zijn ze een stuk sterker dan een IP-gok op de rand van het netwerk. Maar ze zeggen niets over jurisdictie. Een perfect geauthenticeerde TLS-verbinding vertelt je niet waar de ontvanger het bericht daarna bewaart of vanuit welk land zijn beheerders erbij kunnen.

De tweede vraag, waar de verwerking plaatsvindt en onder welk recht, is een contractuele en auditeerbare vraag, geen technische. Daarvoor kijk je naar verwerkersovereenkomsten, productvoorwaarden en onafhankelijke auditrapportages. Microsoft documenteert dat via de EU Data Boundary, en het loont om die documentatie preciezer te lezen dan de discussie meestal doet. Voor de diensten die eronder vallen worden klantgegevens opgeslagen en verwerkt in datacenters binnen de EU en de EVA. Voor een Nederlandse tenant blijft de mail dus gewoon hier staan.

Dat is precies waarom ik deze vraag contractueel wil beleggen in plaats van met een geolocatie-check. Met documentatie, verwerkersovereenkomsten en auditrapporten kun je dit soort onderscheid daadwerkelijk nagaan en aantonen. Een IP-controle op de eerste hop geeft je die precisie nooit.

Er is een recent voorbeeld dat dat verschil pijnlijk scherp maakt, en Z-CERT noemt het zelf. In het hoofdstuk over digitale autonomie wijst het rapport op de Amerikaanse CLOUD Act, die ertoe kan leiden dat niet-Europese overheden toegang krijgen tot patiëntgegevens “zelfs als die data in Europa is opgeslagen”, en noemt als illustratie de discussie die ontstond toen Zivver in de zomer van 2025 werd overgenomen door het Amerikaanse Kiteworks. Let op wat daar gebeurde. De jurisdictievraag rond die dienst veranderde niet doordat er servers verhuisden, maar door een overname. De eerste hop stond ervoor en erna op precies dezelfde plek. Geen enkele geolocatie-controle had dit ooit gezien, terwijl dit nu juist de verandering is waar § 6.1.13 zich zorgen over hoort te maken.

Daar hoort meteen bij dat dit geen argument vóór mijn eigen werkgever is. Microsoft is een Amerikaans bedrijf en valt net zo goed onder de CLOUD Act, en dat geldt onverkort voor de EU Data Boundary die ik hierboven juist als sterk punt aanhaalde. Die regelt waar gegevens worden opgeslagen en verwerkt, en dat is een reële waarborg, maar ze verandert niets aan de nationaliteit van het moederbedrijf. Dat is precies waarom ik het over het ontwerp van de controle heb en niet over de vraag bij wie je koopt. Een toets die naar een IP-adres kijkt, mist de vraag die er werkelijk toe doet, ongeacht welke leverancier eronder zit.

Mijn voorstel is daarom niet om het een voor het ander in te ruilen, maar om ze uit elkaar te trekken: toets transport machinaal, en beleg jurisdictie contractueel en auditeerbaar over de hele verwerking.

Stelling C: wat levert het netto op?

Hier word ik het scherpst, en ik zeg er meteen bij dat dit een mening is en geen normuitspraak. Zet naast elkaar wat een aparte veilig-mailen-dienst een zorgorganisatie oplevert, gemeten langs de clausules uit deel 1, en wat ze ervoor betaalt.

De opbrengst eerst, en dan volledig. Sterkere authenticatie richting de ontvanger, al staat of valt die met een tweede kanaal naar die ontvanger. Een verzendende partij die de ontvangende kant controleert vóór aflevering (§ 6.2.2.1), een goed principe dat de norm terecht vastlegt. Een bekendgemaakt inkomend burgerkanaal (§ 6.5), een reële plus die een mailplatform niet van huis uit levert. Beveiligd beantwoorden en doorsturen (§ 6.1.14 en § 6.1.15), waar een portaaloplossing structureel sterker staat dan transportbeveiliging. Herkenbaarheid en bereikbaarheid in het onderlinge afsprakennetwerk van de keten. En, minstens zo belangrijk in de praktijk: risico-overdracht, ondersteuning, en een kant-en-klaar aantoonbaarheidsverhaal waar je zelf niets voor hoeft te schrijven.

Dat is niet niks. Maar zet er de kosten naast. Een aparte licentie per gebruiker per maand, plus wat niet op de factuur staat: implementatie, koppelingen met het EPD en de mailomgeving, beheer, opleiding, en de kennis die je permanent in huis moet houden. En een extra systeem in de keten is ook een extra systeem dat gekoppeld, geautoriseerd en bijgehouden moet worden. Inloggen gaat tegenwoordig via SSO, dus losse wachtwoorden zijn het probleem niet meer, maar daarvoor in de plaats staat er wel een federatievertrouwen naar een externe partij, plus een eigen beheerinterface en eigen opslag van gevoelige berichten bij die partij. Dat vergroot het aanvalsoppervlak, precies bij de gegevens die je wilde beschermen. En het vergroot je blootstelling aan een supply chain-aanval: je haalt een extra leverancier binnen die per definitie in het pad van je gevoeligste verkeer zit, met code die in je mailstroom draait en een vertrouwensrelatie met je identiteitsprovider. Een inbraak bij die leverancier is daarmee onmiddellijk een inbraak bij jou, en juist bij het verkeer waarvoor je de dienst had aangeschaft.

Dat is geen theoretisch bezwaar meer. Z-CERT schat het dreigingsniveau voor afpersing van leveranciers van zorginstellingen in als “hoog”, en legt uit waarom die concentratie zo aantrekkelijk is: doordat medische data steeds vaker bij toeleveranciers via SaaS wordt ontsloten, krijgt een aanvaller “door slechts één doelwit aan te vallen” potentieel toegang tot de gegevens van tientallen tot honderden klanten. Het jaar 2025 leverde de voorbeelden erbij. Bij de ransomware-aanval op laboratorium Clinical Diagnostics noemt Z-CERT 850.000 patiënten van wie medische gegevens zijn buitgemaakt, en dat cijfer is tijdens het onderzoek meermaals naar boven bijgesteld: van ruim 485.000 deelnemers naar minimaal 715.000, waarbij uiteindelijk niet uit te sluiten viel dat alle 941.000 mensen van wie gegevens in de systemen stonden geraakt waren. Wie een aparte mailleverancier in het pad van zijn gevoeligste verkeer zet, voegt aan die concentratie een schakel toe, en doet dat bij uitstek bij de gegevens die het meeste waard zijn.

Daar hoort meteen een eerlijke kanttekening bij, want dit argument snijdt aan twee kanten. De grootste concentratie in dit verhaal is niet de gespecialiseerde leverancier, maar het samenwerkingsplatform zelf. Als Microsoft 365 of Google Workspace uitvalt of gecompromitteerd raakt, gebeurt dat bij duizenden organisaties tegelijk, en dat is een ordegrootte erger dan welk incident bij een mailleverancier ook. Wie consolidatie op zo’n platform bepleit, kan zich dus niet achter het concentratieargument verschuilen.

Al is dat maar de helft van de som. Concentratie zegt iets over de impact als het misgaat, niet over de kans dát het misgaat, en risico is het product van die twee. Op dat tweede punt werkt schaal juist de andere kant op: partijen als Microsoft en Google investeren miljarden in de beveiliging van hun platform, met permanente detectie, gescheiden beheerprocessen en externe auditrapportages. Dat niveau haalt een kleinere leverancier niet zomaar. Waterdicht is niemand, want dat bestaat niet. Beveiliging is ook geen toestand die je bereikt, maar een kansverdeling die je verschuift. Daar hoort dan wel bij dat schaal ook de best toegeruste aanvallers aantrekt, dus die redenering gaat niet oneindig door.

Wat overblijft is een smaller, marginaal punt, en zo bedoel ik het ook: dat platform zit hoe dan ook al in het pad van je mail. Een aparte dienst voegt daar een tweede vertrouwensgrens, een tweede codebase in je mailstroom en een tweede federatierelatie aan toe. De vraag is niet óf je concentratie accepteert, want dat doe je sowieso, maar of die extra schakel genoeg oplevert om de extra blootstelling te rechtvaardigen.

En dan de kern van de zaak, die in de discussie vaak impliciet blijft. Vrijwel elke zorgorganisatie heeft al een volwaardig samenwerkingsplatform, Microsoft 365 of Google Workspace, inclusief de mailomgeving die daarbij hoort. Daar is voor betaald, dat is uitgerold, daarin zijn medewerkers opgeleid. Bovenop dat platform komt vervolgens een tweede mailkanaal, met een eigen adresboek, een eigen interface, een eigen beheerlast en een eigen leveranciersrelatie, en dat puur om aan één clausulereeks te voldoen. Twee mailomgevingen naast elkaar is geen architectuurkeuze die iemand zou maken als hij of zij vandaag opnieuw mocht beginnen. Het is een consequentie van hoe de eis in de markt is ingevuld.

Er is nog iets dat de rekensom pijnlijk maakt. De aparte dienst vervangt het gewone mailkanaal zelden volledig. Er gaat nog steeds medische informatie over de reguliere mailomgeving, omdat iemand de knop vergeet, omdat de detectielogica de gevoelige informatie niet als zodanig heeft herkend, omdat de ontvanger niet meewerkt, of omdat het simpelweg sneller is. Dan betaalt een organisatie voor een tweede, veilig kanaal en houdt ze het risico op het eerste. Dat is de slechtste van beide werelden.

Dat is geen eigen schatting. Zes zorgorganisaties, waaronder Laurens, Amstelring en Buurtzorg, lieten samen met Adapta en KPMG onderzoeken wat die aparte applicaties opleveren en concludeerden dat ze “duur, gebruiksonvriendelijk en onnodig” zijn. De beweging is inmiddels gegroeid naar vijftien organisaties, en de bijbehorende whitepapers komen op een geschatte besparing van “40 miljoen euro per jaar” in alléén de ouderenzorg. Hun conclusie: bij zorgvuldig gebruik en de juiste instellingen volstaan de mailplatformen van Google en Microsoft. Dat is de conclusie van afnemers met KPMG ernaast, niet van een leverancier.

En de andere kant, want die hoort erbij. Op die conclusie is stevige kritiek gekomen, onder meer in een weerwoord op Zorgvisie, waarin de stap naar een standaardplatform gewaagd wordt genoemd en gewezen wordt op verplichtingen uit de norm die een generiek platform niet vanzelf invult. Die kritiek is terecht in dit opzicht: “volstaat” hangt volledig aan “bij de juiste instellingen”, en dat is precies de configuratie- en aantoonbaarheidslast waar deel 1 op uitkwam. Wie de aparte dienst opzegt en de instellingen niet op orde brengt, koopt geen besparing maar een risico.

Mijn stelling is dus niet dat de norm waardeloos is. De opbrengst hierboven is echt, en § 6.2.2.1 en § 6.5 vragen dingen die er zonder de norm niet zouden zijn. Mijn stelling is dat de verhouding scheef staat: er gaat serieus zorggeld naar een toevoeging boven wat een goed ingerichte standaardomgeving al kan, en 40 miljoen per jaar in één deelsector is genoeg om die vraag hardop te stellen. Dat is geen technisch argument maar een bestedingsargument, en juist daarom hoort het in het normdebat thuis. Waar de markt een uitkomst-eis invult met een aparte productcategorie, mag de vraag op tafel wat die uitgave oplevert.

Het netwerkeffect, en waar de macht ligt

Er is een reden waarom een organisatie die de rekensom uit stelling C maakt, alsnog blijft betalen. Die reden staat niet op de factuur en heeft weinig met beveiliging te maken.

§ 6.2.2.1 legt de verantwoordelijkheid voor veilige aflevering bij de verzendende partij, die de ontvangende kant moet controleren voordat ze verstuurt. Op zichzelf is dat een verstandige eis, en in deel 1 noem ik hem ook zo. Maar draai hem om en kijk wat hij betekent voor de ontvanger. Of jij bereikbaar bent, wordt niet door jou bepaald maar door wat de systemen van anderen over jouw domein concluderen. Zeg je je aparte dienst op, dan verandert er technisch misschien weinig aan je beveiliging, maar verandert er wel iets aan hoe je gezien wordt door de partijen die jou moeten kunnen mailen.

Daar zit de kern. De overstapkosten bestaan niet alleen uit een project en een migratie, maar uit het risico dat een huisarts, een gemeente of een ketenpartner je straks niet meer kan of wil bereiken via het kanaal waar zij aan gewend zijn. Dat risico raakt de zorgverlening zelf, en dat is een heel andere afweging dan een licentiebedrag. Het is volstrekt rationeel om te veel te betalen voor een dienst als het alternatief is dat je moeilijker bereikbaar wordt voor de mensen met wie je patiënten deelt.

Het gevolg is een netwerkeffect dat de bestaande aanbieders in de kaart speelt. Hoe meer organisaties op zo’n netwerk zitten, hoe duurder het voor de volgende is om eruit te stappen, en hoe kleiner de kans dat iemand het als eerste doet. Ik schrijf dat nadrukkelijk niet als verwijt aan die aanbieders: dit is geen gedrag maar een structuur, en ze hebben die structuur niet bedacht. Ze is ontstaan doordat de norm wél een controleplicht bij de afzender legt, maar niets regelt over interoperabiliteit of overstapbaarheid. Wie de eis invult met een gesloten netwerk, krijgt dat effect er gratis bij.

Hoe hard dit in de praktijk bijt, weet ik niet precies, en dat hoort er eerlijk bij. Het hangt af van de vraag of aflevering generiek werkt op basis van een gepubliceerd record, of dat er in de praktijk een bilaterale activering tussen partijen aan te pas komt. Die vraag staat in deel 3 niet voor niets bij wat ik nog niet weet. Maar de richting is duidelijk genoeg om te benoemen, en het is precies het soort marktordeningsvraag dat bij een normherziening op tafel hoort, niet in een commerciële onderhandeling.

Serie NTA 7516, deel 2 van 3. Je las De analyse. In deel 3, Het advies, staan een ontleding van de eis in losse functies en negen voorstellen aan de normcommissie.

Normverwijzingen betreffen NTA 7516:2019; de norm is auteursrechtelijk beschermd en gratis op te vragen bij NEN. Clausules worden binnen auteursrechtgrenzen geciteerd (nummers en korte zinsdelen). Verder aangehaald: NEN, FAQ NTA 7516 (de norm wordt herzien tot NEN 7516, met een deel voor e-mail en een deel voor chat, en interoperabiliteit en gebruiksvriendelijkheid als expliciete aandachtspunten); NEN, NCS 7516-1:2020, productpagina van het ingetrokken toetsingsschema; Raad van State, technische vereisten veilig mailen; Advocatenblad (2022), juridische status veilig mailen onzeker; Adapta en KPMG, De (waan)zin van veilig mailen, whitepaper van februari 2025 (de beoordeling van Microsoft 365 tegen 84 controls, waarbij Microsoft technologiepartner was, alleen de opzet is getoetst en het raamwerk zelf niet is gepubliceerd; op dezelfde pagina staan de Google-variant en de technische implementatiegidsen, alle vrij te downloaden); Z-CERT, Cybersecuritybeeld Zorg 2025 (gepubliceerd maart 2026, met een toelichting van Z-CERT zelf; de cijfers over verkeerd bezorgde mail komen uit tabel 3, en de passage over de CLOUD Act en de overname van Zivver uit het hoofdstuk over digitale autonomie); Forum Standaardisatie, over de DANE-implementatie van Microsoft na verzoek van de Nederlandse overheid en het standaardprofiel STARTTLS en DANE; en, voor de transport- en dataresidentie-onderbouwing, Microsoft Learn over SMTP DANE met DNSSEC en de EU Data Boundary. De eIDAS-betrouwbaarheidsniveaus waarnaar deel 1 verwijst, staan in Uitvoeringsverordening (EU) 2015/1502, die de minimale technische specificaties per niveau vastlegt.