Tweeluik NTA 7516, deel 1 van 2. Dit is De diagnose. Het vervolg staat in deel 2, Het advies.

In short, this article is in Dutch. It examines NTA 7516, the Dutch standard for secure email in healthcare. In 2022 the standard lost its certification scheme, while the norm itself remained valid. This first part reads the norm clause by clause and asks what that gap means for compliance and for demonstrating it.

Rond het certificeren van ‘veilig mailen’ is het al een tijdje stil, maar rond de norm zelf juist niet. NEN heeft het toetsingsschema NCS 7516 per 15 mei 2022 ingetrokken; in NEN’s eigen woorden op de productpagina van dat schema zijn daarmee “alle bestaande NTA 7516-certificeringen van alle leveranciers ingetrokken”, terwijl “de NTA 7516 zelf … wel geldig [blijft]”. Let op het onderscheid. NCS 7516 is het toetsingsschema, NTA 7516 de norm: het schema verviel, de norm niet. Er worden dus geen nieuwe certificeringen meer afgegeven, en de norm zelf wordt intussen herzien tot NEN 7516.

Wat wegviel is de route om een claim te staven via een gecertificeerde leverancier; wat blíjft, is de conformiteitsplicht van de professional zelf (§ 6.6), de kern van dit stuk.

Sinds die certificering wegviel, hoor ik van zorgorganisaties steeds vaker dat de huidige ‘veilig mailen’-oplossingen een doorn in het oog zijn: extra complexiteit zonder dat de veiligheidswinst daar vanzelf tegen opweegt. Geen onderbuikgevoel. Toen Adapta en KPMG met een aantal zorgorganisaties concludeerden dat bespoke veilige-mailapplicaties “duur, gebruiksonvriendelijk en onnodig” zijn, was dat groot nieuws in de sector.

Openheid vooraf. Ik werk als Solution Engineer bij Microsoft. Dit stuk gaat over een markt waarin Microsoft met eigen producten aanwezig is. Ik heb de analyse zo geschreven dat je de feiten zelf kunt narekenen. Alle normverwijzingen en bronnen staan erbij, en de norm zelf is gratis op te vragen bij NEN, dus je kunt de clausules naast mijn lezing leggen. Ik beoordeel hier 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. Oordeel op de argumenten, niet op mijn werkgever.

Dit is een persoonlijke analyse en een persoonlijke bijdrage aan het normdebat, geen compliance-advies en geen standpunt van Microsoft. NTA 7516-conformiteit stel je zelf vast.

Waarom is NTA 7516 eigenlijk verplicht?

Het mooiste antwoord komt van de normeigenaar zelf. In NEN’s eigen FAQ, onder de kop “Moet een zorgaanbieder aan NTA 7516 voldoen?”, staat:

“De invoering van of het voldoen aan NTA 7516 is (nog) niet verplicht; je kan er immers ook voor kiezen om medische gegevens niet op die manier uit te wisselen. Wil je niet voldoen? Dat mag, maar dan ook niet mailen of chatten. De NTA is gebaseerd op de AVG en eIDAS. Wetgeving waar iedereen al aan moet voldoen. In de AVG of aanvullende toelichtingen van de AP [Autoriteit Persoonsgegevens] staat dat mailen mag, maar dat dat veilig moet.”

Dat is geen woordenspel maar een keuze. Je hoeft niet aan NTA 7516 te voldoen, maar dan mag je gezondheidsgegevens ook niet mailen of chatten. Dat is de trade-off die zorgorganisaties dagelijks maken zonder hem hardop te benoemen. Let op het woordje “(nog)”: NEN houdt zelf de deur open dat dit verandert. Met de herziening naar NEN 7516 in aantocht is het antwoord van vandaag niet per se dat van volgend jaar, relevant voor wie nu een meerjarig contract tekent.

Onder die keuze zit een tweede laag, niet juridisch maar veiligheidstechnisch. Vanuit beveiligingsoogpunt wil je bijzondere patiëntinformatie zo min mogelijk in de e-mail hebben. E-mail is een kanaal waar fouten goedkoop en makkelijk zijn — één verkeerd aangevulde adresregel, één doorgestuurde thread — en waar een lek zich niet meer laat terugtrekken. Een elektronisch patiëntendossier (EPD) is het tegenovergestelde: gebouwd om toegang juist gecontroleerd te ontsluiten, met autorisatie, logging en intrekbaarheid. Tekenend dat NEN’s eigen FAQ die uitweg al impliciet aanbiedt. Niet-mailen is geen ontwijking maar een door de norm erkende route: kiezen voor het dossier boven de mail is compliance halen langs de weg die de norm zelf prefereert, niet compliance omzeilen. Waar de grens ligt tussen wat in het dossier hoort en wat legitiem per e-mail gaat, is de spanning die deel 2 oppakt; deel 1 stelt haar alleen scherp.

De tweede helft van het citaat doet nog iets. “De NTA is gebaseerd op de AVG en eIDAS” bevestigt onafhankelijk waar de plicht vandaan komt: de AVG-zorgplicht om passende technische en organisatorische maatregelen te nemen bij het uitwisselen van gezondheidsgegevens (art. 32 AVG, voor de bijzondere persoonsgegevens uit art. 9). En het verklaart meteen waar de eIDAS-betrouwbaarheidsniveaus uit § 5.6 en § 6.1.10 vandaan komen. Daarover straks meer.

Naast NTA 7516 staat NEN 7510, samen met NEN 7512 en 7513, wél wettelijk verankerd, via het Besluit elektronische gegevensverwerking door zorgaanbieders (Begz), een algemene maatregel van bestuur (AMvB) uit 2017, met toezicht van de Inspectie Gezondheidszorg en Jeugd (IGJ). Die directe buur, een harde norm met een toezichthouder erachter, is vermoedelijk waarom zoveel zorgorganisaties aannemen dat NTA 7516 óók verplicht is.

Blijft één ding overeind, en het is de scharnier naar deel 2: "(nog) niet verplicht" is geen vrijbrief. NTA 7516 is een breed geaccepteerde invulling van die AVG-zorgplicht — je kunt er op andere manieren aan voldoen, en partijen als de Rechtspraak en de Raad van State eisen hem contractueel — maar een gepubliceerd record maakt je niet vanzelf compliant. En de éne route die conformiteit hard kon máken, certificering onder § 6.6, trok NEN in 2022 in. De plicht bleef; het bewijsmechanisme niet. Daarmee verschuift de vraag van “heb je een certificaat” naar aantoonbaarheid, en daar bouwt deel 2 op voort.

Wat het NTA-record wél en niet is

Als een organisatie naar buiten toe wil laten zien dat ze veilig mailen ondersteunt, publiceert ze een NTA 7516-record: een zelf-gepubliceerde DNS TXT-declaratie op haar maildomein. Vereenvoudigd, met een verzonnen voorbeeld, ziet zo’n record er zo uit:

v=NTA7516-1;startdate=2025-01;enddate=2025-12;provider=voorbeeldveiligmailen;ntamx=10 relay.voorbeeldveiligmailen.example

De velden zijn generiek: een versie, een geldigheidsvenster, de provider die de veilige-maillaag levert, en een of meer ntamx-verwijzingen. Meer is het niet: een aankondiging, geen bewijs.

Dat laatste veld verdient toelichting, want het is het enige dat de mailstroom daadwerkelijk stuurt. Een ntamx is opgebouwd als een MX-record: een prioriteit, gevolgd door een hostnaam, en er mogen er meerdere naast elkaar staan zodat een afzender bij uitval kan uitwijken naar de volgende. Het verschil met het gewone MX-record zit in de reikwijdte. Waar MX zegt waar álle post voor het domein terechtkomt, wijst ntamx specifiek de host aan die het NTA-conforme verkeer aankan. Een verzendende partij die de norm volgt, levert daar af, in volgorde van prioriteit; ontbreekt het veld, dan valt ze terug op de reguliere MX-hosts. Zo kan een organisatie gevoelige post over een apart, strenger ingericht gateway leiden zonder haar gewone mailstroom te verleggen. Ter illustratie met een echte leverancier: ZorgMail toont in zijn handleiding voor NTA 7516 het record v=NTA7516-1;startdate=2023-03;enddate=2026-03;provider=zorgmail;ntamx=10 relay.zorgmail.nl, waarin diezelfde opbouw terugkomt.

Twee dingen volgen daaruit, en ze zijn allebei makkelijk verkeerd te lezen.

Aanwezigheid is een claim, geen keurmerk. Een record zegt “wij richten ons hierop in”. Het is geen uitkomst van een audit, het ís, in de woorden van de Raad van State, “in feite een zelfverklaring”. En sinds NEN het toetsingsschema NCS 7516 introk, is er geen geaccrediteerde route meer die zo’n claim staaft. Dat is geen theorie: Zivver stelde zelf in 2022 dat veel certificaten waren afgegeven op “onjuiste en onvolledige toetsing”.

Afwezigheid is geen bewijs van onveiligheid. Geen record betekent niet “deze organisatie mailt onveilig”. Het kan betekenen dat ze het record op een ander maildomein publiceert, dat ze veilige uitwisseling via een portaal of via het EPD regelt, of simpelweg dat ze de moeite van het declareren niet heeft genomen. Het record is een signaal aan de buitenkant, niet een röntgenfoto van de binnenkant.

Er zit nog een kant aan dat record die makkelijk over het hoofd wordt gezien: het is niet alleen een signaal áán de buitenkant, maar ook een instrument vóór de afzender. § 6.2.2.1 legt de verantwoordelijkheid voor veilige aflevering bij de verzendende partij, die de ontvangende kant moet controleren vóórdat ze verstuurt. De DNS-declaratie is precies hoe die afzender dat technisch kan doen, een vooraf op te vragen aanwijzing of de ontvanger NTA-conform verkeer aankan. Dat draait het record om: geen keurmerk dat de ontvanger draagt, maar een controlepunt van de afzender, om zijn eigen afleverplicht na te komen.

Naar mijn eigen lezing van de norm, en waarom alleen Microsoft 365

Wat volgt is geen meting en geen marktonderzoek, maar een lezing: ik houd de tekst van de norm naast wat een standaardomgeving vandaag doet.

Twee grenzen vooraf. Auteursrecht: mijn exemplaar draagt een persoonlijke stempel, dus het bestand zelf verspreid ik niet, maar de norm is gratis op te vragen bij NEN, dus lees vooral mee. Ik citeer alleen clausulenummers en korte, functionele zinsdelen; hele paragrafen of tabellen niet. En scope: ik beoordeel bewust één platform, Microsoft 365, omdat ik dat ken en dagelijks gebruik. De clausules zijn platformonafhankelijk, dus de analyse is voor elk ander platform te herhalen.

De norm naast de praktijk, clausule voor clausule

Nu het diagnostische hart. Ik leg de eisen van de norm naast wat een standaard Microsoft 365-omgeving vandaag levert. Eén ding vooraf, want het bepaalt de hele lezing: de norm is uitkomstgericht, niet flow-voorschrijvend, ze stelt eisen aan het resultaat, niet aan een specifieke techniek. Je hebt dus vaak méér dan één weg naar conformiteit, en “leverancier X doet het zó” is niet hetzelfde als “de norm eist het zó”.

Transport. Vertrouwelijke, authentieke aflevering (§ 6.1.11). Hier staat het platform het sterkst. Microsoft 365 doet outbound SMTP DANE met DNSSEC standaard, en inbound DANE/DNSSEC is per geverifieerd domein in te schakelen (Enable-DnssecForVerifiedDomain, Enable-SmtpDaneInbound), gedocumenteerd op Microsoft Learn. De versleutelde, geauthenticeerde transportlaag die de norm vraagt, heb je grotendeels al.

Toegang en betrouwbaarheidsniveau (§ 5.6 / § 6.1.10). De norm koppelt toegang aan een eIDAS-betrouwbaarheidsniveau (substantieel of hoog): een authenticatielat, geen transportvraag. De meest voorkomende ontgrendelmethode is een eenmalige code (Microsofts one-time pass code) via Purview Message Encryption (OME). Die code gaat naar dezelfde mailbox als de notificatie, een tweede stap op hetzelfde kanaal, geen tweede factor uit een andere categorie. eIDAS-niveau substantieel vraagt juist twee factoren uit verschillende categorieën plús dynamische authenticatie (Uitvoeringsverordening (EU) 2015/1502, bijlage, onder 2.3). De federatieve route, inloggen met een bestaand Microsoft-, Google- of Yahoo-account, leunt op de multifactorauthenticatie (MFA) van de ontvanger zélf, die de afzender niet kan afdwingen of aantonen. Tóch is OME niet gediskwalificeerd: § 6.1.10 noemt een eenmalig wachtwoord in een informatieve noot wél als mogelijk middel, een assurance-vraag die de organisatie zélf moet aantonen, geen beslechte diskwalificatie.

Functionaliteit is niet hetzelfde als praktijk. Als functionaliteit levert een gespecialiseerd product hier reële meerwaarde: het kan de code via sms sturen, dus over een kanaal dat losstaat van de mailbox, waar een standaard Microsoft 365-omgeving diezelfde mailbox gebruikt. Maar die functie valt of staat met de gegevens die je van die ontvanger hebt. In de praktijk zie ik dat ook bestaande, gespecialiseerde oplossingen die tweede factor lang niet altijd afdwingen: de MFA-tooling is ingericht, maar er staat geen mobiel nummer van de patiënt in het systeem, waardoor de verificatiecode gewoon naar hetzelfde e-mailadres gaat als het bericht. Zelfde kanaal, zelfde beperking als bij OME. Functionaliteit verschilt dus wél, praktijk niet, geen platformkwestie maar een implementatie- en datakwaliteitsvraag. Welk product je ook koopt, zonder een tweede kanaal naar de ontvanger heb je geen tweede factor, en daarmee ligt de last bij de organisatie, waar deel 2 op voortbouwt.

De verzendende server verifieert de ontvangende (§ 6.2.2.1). De norm vraagt dat de verzendende kant de ontvangende controleert vóór aflevering. Belangrijk en vaak verkeerd geciteerd: het beveiligde portaal komt in deze clausule alleen voor als een informatieve opmerking. Een portaaloplossing, zoals die van Purview Message Encryption, is dus niet categorisch uitgesloten; ze is één van de manieren, niet de voorgeschreven en niet de verboden.

Het bekendgemaakte inkomende burgerkanaal (§ 6.5). Hier vraagt de norm iets dat geen mailplatform van huis uit levert. De norm vraagt een gepubliceerd kanaal waarlangs een burger de organisatie beveiligd kan bereiken, toegankelijk conform EN 301 549 en met afzenderidentificatie. Dat rolt niet vanzelf uit een mailplatform. Of specifieke portalen aan EN 301 549 voldoen, vergt toetsing per portaal, maar het is een uitkomst-eis die een bewuste architectuurkeuze vraagt, en waar een leverancier reëel werk uit handen neemt. Het patiëntportaal bij het EPD ligt hier het meest voor de hand, en dekt de eis maar tot op zekere hoogte: het bedient wie al als patiënt bekend is, terwijl § 6.5 over een burger spreekt, dus ook over wie nog geen dossier heeft, over een familielid en over een verwijzer.

Beantwoorden en doorsturen (§ 6.1.14 / § 6.1.15). Twee clausules die onderbelicht blijven en juist daarom bijten: de beveiliging mag niet stilletjes wegvallen zodra een bericht een tweede hop maakt. Een reply of forward verlaat vaak het pad waarlangs het origineel binnenkwam. Bij een portaaloplossing loopt het antwoord doorgaans netjes terug door het portaal; bij transport-gebaseerde aflevering moet je aantoonbaar maken dat reply en forward hun beschermingsniveau behouden. Het patiëntportaal is hier het sterkst van allemaal: een gesprek dat het dossier nooit verlaat, maakt geen tweede hop, dus kan er ook geen bescherming wegvallen. Dat is dezelfde route die de norm volgens NEN’s eigen FAQ prefereert, nu terug te zien in een concrete clausule. Precies daar zit menselijk gedrag, en precies daar is aantoonbaarheid het moeilijkst.

Beleid en toezicht (§ 6.1.12). Veel van wat de norm vraagt is niet technisch maar organisatorisch: gedocumenteerd beleid plus toezicht dat het beleid ook echt geldt. Geen product levert dit uit de doos; het is dezelfde § 6.6-plicht van hierboven, nu in de dagelijkse praktijk, papier plus toezicht, niet een knop.

Europese Economische Ruimte (EER). Jurisdictie (§ 6.1.13). De meest voorkomende misvatting. De clausule is AVG-conditioneel: ad-hocverkeer mag de buitengrenzen van de EER slechts in overeenstemming met de AVG overschrijden. Dat is géén absolute eis dat elke server op EU/EER-grondgebied staat; die harde bodemeis komt uit leverancier-implementaties en inkoopeisen, niet uit de normtekst. Voor het platform betekent dit dat je jurisdictie contractueel en auditeerbaar kunt beleggen; Microsoft documenteert dat via de EU Data Boundary. Let op de valkuil van een simpele geografie-check: die dekt hooguit de eerste mailhop, terwijl de AVG over de héle verwerking gaat, opslag, back-up, doorrouteren inbegrepen.

Samengevat: de transportlaag heb je grotendeels al; het inkomende burgerkanaal, de sterke ad-hoc-identificatie, de beveiligde reply/forward en de keten-interoperabiliteit zijn waar gespecialiseerde leveranciers waarde toevoegen; en de aantoonbaarheid — beleid, classificatie, logging, toezicht — blijft hoe dan ook het werk van de zorgorganisatie.

Wat dit wél en niet betekent

Voordat iemand hier meer in leest dan er staat, twee valkuilen tot slot. Een leverancier in het SPF-record is een verzendautorisatie, geen keurmerk, en sinds mei 2022 kan niemand het onderliggende certificaat nog vernieuwen, dus een bekende ‘veilig mailen’-naam in dat record zegt niets over de conformiteit van vandaag. En een teruggeschaalde aflevering (beveiligde e-mail lukt niet, het bericht komt via een portaal met sms-code binnen) is volgens de Raad van State geen weigering maar een alternatief, één voorbeeld van degradatie, niet iets wat ik naar alle leveranciers generaliseer.

En de eerlijkheid naar de andere kant: leveranciers leveren reële waarde, dingen die je niet triviaal zelf bouwt, plus risico-overdracht en een kant-en-klaar aantoonbaarheidsverhaal. De vraag is niet “vendor of niet”, maar: welk deel van een NTA-oplossing is de leverancier, en welk deel is functionaliteit die je al hebt?

De open vraag, bruggetje naar deel 2

En dan de vraag die onder dit alles ligt, en die me het meest bezighoudt. Als niemand je meer kan certificeren, en een groot deel van wat de norm vraagt organisatorisch is in plaats van technisch, wat betekent naleving dan eigenlijk nog? En, een stap terug: als bijzondere patiëntinformatie vaak beter in het dossier past dan in de e-mail, zou e-mail dan de uitzondering moeten worden in plaats van het standaardkanaal, en hoe kan een betere NEN 7516 dat vragen zónder de gevallen te breken waarin e-mail écht nodig is? Dat is precies waar deel twee over gaat.

Tweeluik NTA 7516, deel 1 van 2. Je las De diagnose. Deel 2, Het advies bouwt hierop voort.

*Normverwijzingen betreffen NTA 7516:2019; de norm is auteursrechtelijk beschermd en gratis op te vragen bij NEN. De intrekking van het toetsingsschema is gedocumenteerd op de bron zelf: NEN, NCS 7516-1:2020, productpagina van het ingetrokken schema, aanvullend bevestigd door Raad van State, technische vereisten veilig mailen en Advocatenblad (2022). Verder: NEN, NTA 7516, Zorgvisie. De wettelijke verankering van NEN 7510/7512/7513 loopt via het Besluit elektronische gegevensverwerking door zorgaanbieders (Begz, Stb. 2017, 446); zie ook de VWS (Ministerie van Volksgezondheid, Welzijn en Sport), Kamerbrief over veilige gegevensuitwisseling.