Tweeluik NTA 7516, deel 2 van 2. Dit is Het advies. 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 two parts on NTA 7516, the Dutch standard for secure email in healthcare. Part one read the norm clause by clause. This part turns that diagnosis into advice: two theses, a practical middle path you can build today, and concrete proposals for a better NEN 7516.

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. Dit is een persoonlijke bijdrage aan het normdebat, geen compliance-advies en geen standpunt van Microsoft. NTA 7516-conformiteit stel je zelf vast.

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 twee stellingen in, allebei 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 uitkomst en architectuur in plaats van servergeografie, om een certificeringsroute die daadwerkelijk bestaat, en om aantoonbaarheid als expliciete eis. Daarna beschrijf ik een middenpad dat je vandaag al zelf kunt bouwen, met zijn eerlijke grenzen, en sluit ik af met wat ik zelf nog niet weet.

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.

Maar ik moet meteen eerlijk zijn over wat die richting niet oplost, want anders is ze niet geloofwaardig. Een EPD-patiëntenportaal sluit § 6.5 niet. Zo’n portaal bedient in de praktijk alleen geregistreerde patiënten, terwijl de norm juist vraagt dat het inkomende kanaal bruikbaar is voor “iedereen met voor particulieren gebruikelijke internetvoorzieningen”. Iemand die nog geen patiënt is, een mantelzorger of wettelijk vertegenwoordiger zonder eigen dossier, een familielid dat een tweede opinie zoekt: het gesloten portaal bereikt hen niet. En § 6.1.15 voorziet expliciet in het geval dat een persoon een ontvangen bericht doorstuurt, bijvoorbeeld naar zijn mantelzorger. Dat valt buiten de muren van een gesloten portaal.

Er is nog een grens, en die weegt zwaar. 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. 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. Dat hardop zeggen is wat de stelling geloofwaardig maakt.

Stelling B: architectuur 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. Dat onderscheid is geen slag om de arm. Het is het verschil tussen een scherpe observatie en een aanvechtbare bewering, en die grens zou ik in het openbaar niet willen overschrijden.

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, back-upt of naartoe doorstuurt, valt erbuiten, terwijl de AVG over de héle verwerking gaat. Verifieerbare transportcontroles dienen dat doel beter. DNSSEC (Domain Name System Security Extensions), DANE (DNS-based Authentication of Named Entities) en MTA-STS (Mail Transfer Agent Strict Transport Security) zijn voor iedere partij machinaal na te meten. Gecombineerd met contractuele, auditeerbare toezeggingen over dataresidentie, zoals de EU Data Boundary die Microsoft documenteert, is dat een beter antwoord op de feitelijke AVG-eis dan een IP-gok op de rand van het netwerk.

Het middenpad: wat je vandaag zelf kunt bouwen

Tussen “koop een kant-en-klare oplossing” en “bouw alles zelf” ligt een derde weg, en dit is een gedachte die ik zelf heb uitgewerkt. Een zorgorganisatie wisselt beveiligde ad-hoc-mail uit met een begrensde set ketenpartners, niet met het hele internet. Die set is met de hand op te sommen. Een periodieke evaluatie-job controleert per partnerdomein het NTA-record en de transporthygiëne (DNSSEC, DANE, geldige TLS, een streng SPF- en DMARC-beleid) en levert een allowlist van veilig rechtstreeks te bedienen domeinen. Die lijst voedt uitgaande connectors met afgedwongen, gevalideerde TLS: mail naar die partners gaat alleen over gecontroleerde versleuteling, anders wordt ze niet afgeleverd. Purview Data Loss Prevention (DLP), oftewel gegevensverliespreventie, classificeert vervolgens mail met medische gegevens en stuurt de routering.

Eerlijk is eerlijk, er zitten grenzen aan. De toets is periodiek, niet per bericht: een partner die zijn beveiliging na de laatste run verzwakt, wordt tot de volgende run nog bediend. De afgedwongen TLS in de connector dekt een deel van dat gat wél per bericht af, maar de bredere NTA-toets blijft een momentopname. Een uitgaande connector accepteert daarnaast maximaal 1266 ontvangende domeinen, wat voor een zorg-allowlist ruim is, maar wel een grens. En licenties tellen mee: DLP op e-mail zit in E3, terwijl het automatisch toekennen van een gevoeligheidslabel aan een bestand op SharePoint of Teams een E5-licentie vereist. Reken dus met wat je al bezit qua licenties of wat je in de toekomst wil gaan afnemen.

En het middenpad lost een aantal dingen simpelweg niet op, precies de dingen waar deel 1 op wees. Het bekendgemaakte inkomende burgerkanaal uit § 6.5 rolt hier niet uit; de allowlist regelt uitgaand verkeer. De ad-hoc-ontvanger die niet op de lijst staat, een patiënt, een advocaat, een huisarts op gewone mail, valt terug op het OME-portaal (Purview Message Encryption) met een eenmalige code, en daar is de authenticatie-eis het lastigst hard te maken. Beantwoorden en doorsturen (§ 6.1.14 en § 6.1.15) blijven lastig aantoonbaar zodra een bericht een tweede hop maakt. En je wordt er niet herkenbaar of bereikbaar mee in het onderlinge ntamx-afsprakennetwerk van de keten.

Dan de kosten. De verleiding om te zeggen dat dit “bakken met geld” scheelt is er niet voor niets. Een aparte licentie voor veilig mailen kost per gebruiker per maand een aanzienlijk deel van wat een volledige productiviteits- en securitysuite kost, en dat voor één functie binnen die suite. Bij duizenden gebruikers loopt dat verschil op tot een post die je op de begroting terugziet. Reken het voor je eigen aantallen na, met de tarieven die jij betaalt, want dat is de enige berekening die ertoe doet. Maar de besparing blijft een saldo, geen brutobedrag. Tegenover de vervallen leverancierslicentie staan engineering en onderhoud van de allowlist. Welke oplossing je ook kiest, de aantoonbaarheidslast blijft in alle gevallen die volledig bij de organisatie liggen. De nuchtere boodschap is dus niet “vervang de leverancier”, maar “verklein de leverancierscope tot het verkeer waar hij echt waarde levert”.

Concrete voorstellen aan de normcommissie

“Betere architectuureisen” is voor een normcommissie niet bruikbaar. Daarom maak ik het concreet. Vijf voorstellen, elk met de reden erbij, constructief bedoeld en aan de commissie gericht.

  1. E-mail expliciet als uitzonderingskanaal. Laat de norm vragen dat de aanbieder eerst een gestructureerd, dossier-gebonden kanaal aanbiedt en ad-hoc beveiligde e-mail reserveert voor gevallen waarin dat aantoonbaar niet kan, met een lichte documentatieplicht voor het waarom. Dit lost op dat e-mail vandaag het pad van de minste weerstand is voor gegevens die in het dossier thuishoren.

  2. Verifieerbare transportcontroles als uitkomst-eis. Eis DNSSEC, DANE en MTA-STS als toetsbare, machinaal na te meten controls in plaats van een geolocatie-gok op de eerste hop. Dit lost op dat een geografie-proxy zwak en zelf-gedeclareerd is, terwijl het eigenlijke doel, vertrouwelijke en authentieke aflevering, wél objectief meetbaar is.

  3. Jurisdictie als AVG-uitkomst over de hele keten. Houd de AVG-conditionele lijn van § 6.1.13 aan, verwerking AVG-conform, opslag en back-up inbegrepen, in plaats van een enkelvoudige geografische maatstaf. Dit lost op dat een locatiecheck op de eerste hop hooguit dekt waar de mail binnenkomt, terwijl de AVG over de hele verwerking gaat.

  4. Herstel een toetsingsroute die daadwerkelijk bestaat. Sinds NEN het schema inactiveerde en er geen aantoonbaar vervangend schema is, verschuift de volledige bewijslast naar de klant. Voorstel: een uitvoerbaar toetsingsschema via een geaccrediteerde instelling, of een erkende zelfassessment-route met externe steekproef. Dat het oude schema omstreden was, een leverancier sprak destijds zelf van certificaten op “onjuiste en onvolledige toetsing”, is een reden om het beter te doen, niet om het weg te laten.

  5. Formuleer § 6.5 uitkomstgericht. Beschrijf het door-personen-geïnitieerde kanaal in de uitkomsten die het moet leveren: bereikbaar voor iedereen met gangbare internetvoorzieningen, toegankelijk conform EN 301 549, versleuteld zowel onderweg als in opslag, en met aantoonbare afzender-assurance die past bij de gevoeligheid van de gegevens. Laat in het midden met welke techniek een aanbieder dat invult. Dit lost op dat de huidige lezing impliciet een aparte secure-mailsuite verplicht stelt, en zo de complexiteit vergroot die deel 1 aankaartte, zonder de lat voor beveiliging te verlagen.

Dit blijft een persoonlijke bijdrage aan het normdebat, geformuleerd als “de norm zou X kunnen eisen omdat Y”, niet als aanklacht en niet als standpunt van Microsoft.

Wat ik zelf nog niet weet

Ik sluit liever af met wat ik niet weet dan met een triomfantelijke samenvatting. Drie dingen houden me bezig. Of de herziening naar NEN 7516 een toetsingsroute herstelt, weet ik niet; ik ken de inhoud van het ontwerp niet en noem daarom geen datum of richting. Of ntamx-interoperabiliteit vanzelf werkt of pas na bilaterale activering tussen partijen, is me niet duidelijk; aflevering lijkt in de praktijk mede af te hangen van afspraken tussen partijen, maar dat is een observatie, geen normuitspraak. En hoe de EER-locatiecheck door leveranciers feitelijk wordt uitgevoerd, kon ik nergens publiek onderbouwd vinden. Geen enkele leverancier documenteert die methode openbaar.

Er is een vierde onbekende die het hele kostenverhaal bepaalt: welk deel van het beveiligde verkeer van een organisatie naar vaste ketenpartners gaat, en welk deel naar losse ad-hoc-ontvangers. Zit het leeuwendeel bij de keten, dan is het middenpad reëel en de besparing echt. Zit het bij de ad-hoc-ontvangers, dan houdt een gespecialiseerde leverancier juist zijn waarde. Dat verschilt per organisatie, en het is precies de vraag die je eerst zou moeten meten. Wie eerlijk diagnosticeert, verdient het recht om te adviseren. Wie de open vragen verzwijgt, niet.

Tweeluik NTA 7516, deel 2 van 2. Je las Het advies. In deel 1, De diagnose, staat de close reading van de norm waarop dit voortbouwt.

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; 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.