Serie NTA 7516, deel 3 van 3. Dit is Het advies. Deel 1, De diagnose, las de norm clausule voor clausule. Deel 2, De analyse, zette de opbrengst naast de kosten en keek naar het netwerkeffect dat overstappen duur maakt.

In short, this article is in Dutch. It is the final of three parts on NTA 7516, the Dutch standard for secure email in healthcare. Parts one and two read the norm and weighed what it costs. This part looks at how Denmark and Norway solve the same problem, decomposes the requirement into the functions it actually consists of, and puts nine concrete proposals to the committee revising the standard.

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.

  • Buurlanden regelen dit collectief. Denemarken en Noorwegen hebben een landelijke voorziening met publieke governance, in plaats van honderden organisaties die apart inkopen.
  • De eis is geen product, maar een set functies. Weten met wie je veilig kunt mailen, dat afdwingen, en weten wanneer de regel geldt. KPMG toetste Microsoft 365 tegen 84 controls: 67 volledig gehaald, 6 gedeeltelijk, geen enkele niet. Wel met kanttekeningen die in dit deel benoemd staan, waaronder dat alleen de opzet is getoetst en niet de werking over tijd.
  • Negen voorstellen aan de normcommissie. De kern: toets transportbeveiliging machinaal, beleg jurisdictie contractueel en auditeerbaar, herstel een toetsingsroute die daadwerkelijk bestaat, en sluit aan bij internationale standaarden in plaats van een eigen Nederlandse invulling.
  • Zet het portaal voorop in plaats van e-mail. Inloggen met DigiD haalt het authenticatieniveau dat de norm vraagt makkelijker dan een los mailbericht, en de gegevens blijven in het systeem waar autorisatie en logging al geregeld zijn.

Het advies om mee te nemen: leg deze vraag voor aan uw eigen auditor voordat u een contract verlengt of een nieuwe oplossing aanschaft. Niet aan uw leverancier.

Van diagnose naar voorstel

Deel 2 eindigde op een ongemakkelijke constatering. De overstapkosten in deze markt hebben weinig met beveiliging te maken, en het is de vraag of een gepubliceerd record op zichzelf genoeg is om bereikbaar te zijn. Een aanwijzing dat het dat niet altijd is, staat in het onderzoek van Adapta zelf, dat als symptoom “een wildgroei aan ‘veilig mailen’-software/appjes/extensies. Soms meerdere per zorginstelling” noemt. Wie meerdere oplossingen naast elkaar draait om iedereen te kunnen bereiken, laat zien dat bereikbaarheid niet vanzelf spreekt. Kritiek leveren is daarmee het makkelijke deel. Dit slotdeel probeert het moeilijke deel: wat zou er dan anders moeten, en wat kun je zelf doen zonder op een herziene norm te wachten?

Ik begin bij de buurlanden, want die worstelen met vergelijkbare privacyeisen en kwamen tot een ander antwoord. Daarna ontleed ik de eis tot de functies waar ze uit bestaat, met de eerlijke grenzen erbij. Dan volgen negen voorstellen aan de normcommissie, elk met de reden erbij. En het slot gaat over de dingen die ik zelf niet weet.

Hoe doen andere landen dit?

Als de Nederlandse invulling scheef staat, is de voor de hand liggende tegenvraag hoe het elders gaat. Ik heb geen volledig vergelijkend onderzoek gedaan, dus lees dit als een oriëntatie en niet als een uitputtend overzicht, maar het patroon is opvallend genoeg om te noemen.

In Denemarken loopt de veilige uitwisseling in de zorg via MedCom, dat standaarden beheert en systemen certificeert, met een landelijke berichteninfrastructuur waarop de sector is aangesloten. Noorwegen heeft Norsk Helsenett, een staatsdeelneming die een landelijk zorgnetwerk exploiteert waarop zorgaanbieders zijn aangesloten en waarbinnen uitwisseling plaatsvindt. Zweden organiseert het grotendeels via Inera en de landelijke platformen daaromheen.

Wat die drie gemeen hebben, is dat het probleem één keer centraal is opgelost, als infrastructuur, in plaats van dat elke zorgaanbieder afzonderlijk een product inkoopt om aan dezelfde eis te voldoen. Er zijn daar ook commerciële producten, en die moeten aan de nationale eisen voldoen, maar ze zitten bovenop een gedeelde basis in plaats van dat ze die basis vervangen.

En dan het eerlijke tegenvoorbeeld, want dat is er ook. Zwitserland, dat op privacy zeker niet minder streng is, kent met HIN een breed gebruikte aanbieder van beveiligde zorgmail. Dat lijkt in opzet meer op de Nederlandse situatie dan op de Scandinavische. Wie dus wil betogen dat het buitenland unaniem de andere kant op gaat, heeft het mis.

De les die ik eruit trek is daarom bescheiden, maar ze raakt wel voorstel 5. Een landelijke, gedeelde voorziening is geen theoretische optie: buurlanden met vergelijkbare privacyeisen doen het zo, met publieke governance en verplichte certificering erbij. Het is dus de moeite waard om die vraag expliciet te stellen bij de herziening naar NEN 7516, in plaats van hem impliciet te beantwoorden door de invulling aan de markt te laten.

Het middenpad: dezelfde eisen, andere architectuur

Tussen “koop een kant-en-klare oplossing” en “doe het zelf” ligt een derde weg. Dit is geen bouwadvies, want vrijwel geen enkele zorgorganisatie bouwt dit soort systemen zelf en de sector gaat juist verder richting SaaS. Het is een technische beschrijving: uit welke functies bestaat de eis eigenlijk, en welke daarvan zitten al als ingebouwde mogelijkheid in het platform waar je vandaag voor betaalt? Die vraag is al een keer systematisch beantwoord. In de whitepaper De (waan)zin van veilig mailen uit februari 2025 legde KPMG, in opdracht van Adapta en met negen zorgorganisaties, Microsoft 365 langs een raamwerk van 84 controls afkomstig uit wet- en regelgeving, industriestandaarden en marktpraktijk. Daarvan werden er 67 volledig gehaald en 6 gedeeltelijk, en geen enkele niet. De conclusie luidt dat er geen fundamentele technische belemmeringen zijn, mits het correct is ingeregeld en de licenties toereikend zijn. Dat het hier niet om een platformvoorkeur gaat, blijkt uit het feit dat dezelfde exercitie ook voor Google Workspace is gedaan, met een eigen whitepaper. Bij beide hoort bovendien een technische implementatiegids met de configuratiestappen erin uitgeschreven. Die whitepapers en gidsen staan vrij te downloaden, zonder aanmelding of e-mailadres.

Drie dingen horen daar meteen bij, anders is het geen eerlijke weergave. Microsoft en Google werkten aan dat onderzoek mee, en voor de Microsoft-toets betekent dat concreet dat Microsoft technologiepartner was en de bevindingen heeft geverifieerd. Volledig onafhankelijk is die toets dus niet, en ik werk er zelf. Ten tweede is het raamwerk zelf niet openbaar. De whitepaper beschrijft hoe het OCF is opgebouwd en noemt de uitkomst, maar de 84 controls en de beoordeling per control staan er niet in, en het is een raamwerk dat KPMG ook voor andere onderzoeken inzet. Die score is dus niet na te tellen; je neemt hem aan van de partijen die het onderzoek lieten doen. En het derde weegt het zwaarst: KPMG beoordeelde uitsluitend de opzet, dus of een control aanwezig is of ingericht kan worden. Het bestaan, de werking en de effectiviteit over langere tijd zijn expliciet niet getoetst. Dat is precies het onderscheid waar dit stuk telkens op terugkomt, want die tweede vraag is nu juist wat § 6.6 bij de organisatie zelf neerlegt.

Het is ook dezelfde vraag die voorstel 5 hierna aan de normcommissie stelt, en het antwoord bepaalt waar je een leverancier écht voor nodig hebt.

Ontleed je de eis, dan vallen er drie functies uiteen die vaak als één product worden ingekocht. De eerste is weten met wie je veilig kunt mailen. Een zorgorganisatie wisselt beveiligde ad-hoc-mail uit met een begrensde set ketenpartners, niet met het hele internet, en die set is eindig en overzichtelijk: tientallen domeinen, geen duizenden. Een periodieke evaluatie 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. De tweede is afdwingen dat het ook zo gaat: die lijst voedt uitgaande connectors met afgedwongen, gevalideerde TLS, zodat mail naar die partners alleen over gecontroleerde versleuteling gaat en anders niet wordt afgeleverd. De derde is weten wanneer de regel moet gelden: Data Loss Prevention (DLP), oftewel gegevensverliespreventie, classificeert mail met medische gegevens en stuurt de routering. Geen van die drie is een mailproduct. Het zijn ingebouwde mogelijkheden van het platform die je configureert, aangevuld met open standaarden die per definitie leveranciersonafhankelijk zijn en waarvoor je geen licentie nodig hebt.

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; loop je er toch tegenaan, dan is de route een tweede connector met dezelfde configuratie. En licenties tellen mee, en dat is bij Microsoft ingewikkelder dan het hoort te zijn. Het KPMG-onderzoek merkt op dat de module Purview Message Encryption (Basic), die je nodig hebt om een extra verificatiestap aan een bericht toe te voegen, in alle Microsoft 365-bundels zit behalve Business Basic, Business Standard en Office 365 Enterprise E1, en dat het herkennen van medische informatie in een bericht of bestand niet in F3 zit. Reken dus met wat je al bezit qua licenties of wat je in de toekomst wil gaan afnemen.

En deze architectuur 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. De 40 miljoen per jaar uit stelling C in deel 2 is een geschat bedrag, maar het is niet uit de lucht gegrepen, en een deel daarvan is voor een individuele instelling reëel te maken. Reken het na voor je eigen aantallen en je eigen tarieven, want dat is de enige berekening die ertoe doet. Maar de besparing blijft een saldo, geen brutobedrag. Tegenover de vervallen leverancierslicentie staan inrichting 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”.

Tot slot wat je overhoudt aan eigen verantwoordelijkheid, want ook een inrichting van ingebouwde mogelijkheden vraagt onderhoud. Vijf dingen wegen daarbij het zwaarst. Ten eerste stille degradatie: een evaluatie die niet meer draait, een DNS-controle die stilletjes faalt, een connector die iemand voor een ander doel aanpast. De mail blijft gewoon verzonden worden, alleen de waarborg eronder is weg, en niets waarschuwt je. Bewaak daarom de controle zelf, niet alleen de uitkomst. Ten tweede kennisborging: leg vast waarom iets zo staat ingericht, niet alleen dat het zo staat, want anders vertrekt de onderbouwing met de mensen die haar bedachten. Ten derde configuratiedrift, want connectors en DLP-beleid worden ook door anderen aangeraakt, om redenen die niets met de norm te maken hebben. Ten vierde, en dat is de zwaarste: aantoonbaarheid over tijd. Je moet niet kunnen laten zien dat het vandaag goed staat, maar dat het al die maanden goed heeft gestaan. Dat vraagt bewaarde logging en periodieke vastlegging, en dat is precies de last die § 6.6 bij de organisatie zelf legt. En ten vijfde, want dezelfde kritiek geldt hier onverkort: deze inrichting routeert op wat de classificatie herkent. Herkent die een bericht niet als medisch, dan gaat het langs de veilige route heen, precies zoals in deel 2 bij de aparte dienst. Meet dus hoe vaak de classificatie raak zit voordat je erop vertrouwt, en behandel dat cijfer als onderdeel van je aantoonbaarheid.

Geen van deze vijf is op zichzelf een reden om het niet te doen. Ze zijn wel de reden om het niet stilzwijgend te doen. Wie functies uit het eigen platform haalt, kiest bewust voor meer eigen regie en meer eigen verantwoordelijkheid, en dat is een bestuurlijk besluit, geen technische voorkeur.

Concrete voorstellen aan de normcommissie

“Betere architectuureisen” is voor een normcommissie niet bruikbaar. Daarom maak ik het concreet. Negen 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 voor de vertrouwelijkheid en authenticiteit van de aflevering. Niet als vervanging van de jurisdictie-eis, die staat los daarvan en komt in het volgende punt aan bod, maar wel in plaats van een geolocatie-gok op de eerste hop als maat voor transportbeveiliging. Dit lost op dat een geografie-proxy zwak en zelf-gedeclareerd is, terwijl dit doel 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. Geef § 6.5 een referentie-implementatie, en stel de vraag of dit collectief hoort. De clausule zelf is niet het probleem: ze is al uitkomstgericht en schrijft geen techniek voor. Het probleem is dat er geen uitgewerkt voorbeeld naast ligt, waardoor de markt de invulling bepaalt en het antwoord in de praktijk een aparte secure-mailsuite wordt. Voorstel, in twee delen. Publiceer bij de norm een conformiteitsprofiel dat laat zien hoe een aanbieder § 6.5 haalt met generieke componenten, inclusief wat er minimaal gelogd en bewaard moet worden om het achteraf aan te tonen. En leg de commissie de voorafgaande vraag voor: dit is voor elke zorgaanbieder in Nederland dezelfde eis, met dezelfde doelgroep en dezelfde toegankelijkheidseisen, dus hoort een bekendgemaakt burgerkanaal een collectieve voorziening te zijn in plaats van iets dat honderden organisaties los van elkaar inkopen? Dit lost op dat een uitkomst-eis zonder referentie stilzwijgend een productcategorie voorschrijft, en dat dezelfde voorziening nu honderden keren apart wordt betaald.

  6. Maak de authenticatie-eis proportioneel en haalbaar. Deel 1 liet zien waar § 5.6 en § 6.1.10 in de praktijk vastlopen: het niveau vraagt twee factoren uit verschillende categorieën, en in de praktijk is een tweede kanaal naar de ontvanger daarvoor de enige werkbare invulling, terwijl dat kanaal er bij ad-hoc-verkeer vaak simpelweg niet is, ongeacht welk product je koopt. Voorstel: koppel het vereiste assurance-niveau expliciet aan de gevoeligheid van de inhoud, en vraag van de aanbieder vast te leggen welk niveau er wordt gehanteerd, wanneer er wordt teruggevallen en waarom. Dit lost op dat de norm nu een niveau noemt dat in een deel van de gevallen niet te halen is, waardoor organisaties formeel iets claimen dat de praktijk niet waarmaakt.

  7. Regel interoperabiliteit en overstapbaarheid expliciet. De norm legt de controleplicht bij de afzender, maar zegt niets over de vraag of een conforme ontvanger ook bereikbaar is zonder lid te zijn van het netwerk van een specifieke leverancier. Voorstel: leg vast dat conformiteit aantoonbaar moet zijn en bereikbaarheid bereikt moet kunnen worden op basis van openbaar publiceerbare gegevens, zonder bilaterale activering of leveranciersspecifieke koppeling, en dat een organisatie van aanbieder moet kunnen wisselen zonder onbereikbaar te worden. Dit lost op dat een zorgorganisatie vandaag niet kan nagaan of een correct gepubliceerd record genoeg is om voor iedereen bereikbaar te zijn. De norm belooft dat niet, dus dat antwoord ligt bij de leveranciers en niet bij de standaard. Wie overweegt over te stappen, kan daardoor vooraf niet vaststellen of dat de bereikbaarheid raakt.

  8. Zoek eerst de internationale standaard, en breng wat overblijft als één vraag bij de platformen. Voorstel 2 vraagt transportcontroles die pas iets waard zijn als de platforms waar de zorg feitelijk op draait ze ook ondersteunen. Dat is geen vrome wens, want deze route heeft zich bewezen. Forum Standaardisatie zette DANE in 2016 op de ‘pas toe of leg uit’-lijst, en vanaf 2019 voerden SLM Rijk, het ministerie van BZK en Forum Standaardisatie een briefwisseling met Microsoft, in Europees verband samen met onder meer de Deense, Duitse, Letse, Tsjechische en Portugese overheden. Ondersteuning voor uitgaande DANE volgde begin 2022, voor inkomende DANE eind 2024, en het aanvankelijke voornemen om die functie alleen aan premium-klanten te geven ging van tafel. Let wel op wát daar werkte: een internationale open standaard met gedeeld draagvlak, niet een Nederlandse eis, en zelfs dan kostte het jaren. Dat is geen toeval maar een prioriteringsvraagstuk. Een platformleverancier bouwt functies in volgorde van hoeveel klanten, markten en toezichthouders erom vragen. Een eis van één sector in één land belandt ergens onderaan een backlog, terwijl dezelfde eis vanuit meerdere landen en meerdere sectoren vanzelf naar boven schuift. Draagvlak is dus niet alleen politiek nuttig, het is de meest directe manier om de kans te vergroten dat de functie er überhaupt komt. Dat is precies het verschil met de huidige invulling van NTA 7516, die met een eigen recordtype en een eigen toetsingsschema een nationale constructie is. Een eis die alleen hier geldt, levert ook alleen een Nederlandse markt op, terwijl de open standaarden waar voorstel 2 om vraagt vrij te gebruiken zijn en geen licentie of leveranciersrelatie vereisen. Voorstel, in twee stappen. Toets bij de herziening voor elke eis eerst of een internationale standaard het doel al dient, en geef die voorrang boven een eigen invulling. Laat de commissie voor wat dan nog overblijft expliciet opschrijven welke platformfuncties nodig zijn om de norm te halen, breng die lijst via diezelfde route bij de leveranciers onder de aandacht in plaats van hem bij elke zorgorganisatie apart neer te leggen, en zoek daarvoor draagvlak op Europees niveau. Dit lost op dat een norm die functies veronderstelt die het platform niet biedt, de rekening bij de individuele zorgaanbieder legt, terwijl dezelfde vraag één keer op leveranciersniveau te stellen is, en dat een eis die alleen in Nederland bestaat duurder uitvalt en minder interoperabiliteit oplevert dan een standaard die toch al breed wordt geïmplementeerd.

  9. Maak het portaal het eerste kanaal, en regel de uitwisseling tussen dossiers met een open standaard. Stelling A in deel 2 kwam uit op de vraag waarom iemand die met DigiD inlogt niet gewoon een bericht in het portaal achterlaat, met een notificatie per e-mail die alleen meldt dát er post is. De inhoud blijft dan in het systeem waar autorisatie, logging en intrekbaarheid al geregeld zijn. De Belastingdienst en MijnOverheid werken zo, de zorg heeft de bouwstenen al, en DigiD Substantieel haalt het authenticatieniveau dat § 5.6 vraagt makkelijker dan een los mailbericht dat ooit zal kunnen. Voor het verkeer tussen zorgverleners onderling geldt hetzelfde principe een niveau hoger: dat hoort niet via de mail te lopen maar tussen de dossiers zelf. Ook daarvoor bestaat de richting al, want de Wegiz verplicht sinds 1 juli 2023 stapsgewijs elektronische, gestandaardiseerde uitwisseling en positioneert Zorginstituut Nederland die wet expliciet als bouwsteen richting de European Health Data Space, met MedMij en HL7 FHIR als bestaande afspraken- en standaardenlaag. Voorstel: laat de herziening het bekendgemaakte kanaal uit § 6.5 primair invullen als geauthenticeerd berichtenkanaal met notificatie, met e-mail als terugvaloptie voor wie daar niet in kan, en sluit voor het professionele verkeer expliciet aan op de Wegiz- en EHDS-route in plaats van daar een eigen mailnorm naast te zetten. Dit lost op dat de norm nu het zwakste kanaal tot uitgangspunt neemt en er beveiliging omheen bouwt, terwijl het sterkste kanaal er al ligt en wettelijk toch al wordt uitgerold.

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.

En dan het advies waarmee ik deze serie het liefst afsluit: leg dit vraagstuk voor aan je eigen auditor, voordat je een contract verlengt of een nieuwe oplossing aanschaft. Niet aan je leverancier, en niet aan mij. Vraag hem of haar welk bewijs er bij een controle daadwerkelijk op tafel moet komen nu het toetsingsschema is vervallen, of een gepubliceerd DNS-record daarbij als bewijs geldt of als een claim, en wat er in jouw dossier moet zitten om aan te tonen dat de maatregelen niet alleen vandaag maar het hele jaar hebben gewerkt. De antwoorden bepalen wat je nodig hebt, en dat kan zowel meer als minder zijn dan wat er nu op de begroting staat.

Serie NTA 7516, deel 3 van 3. Je las Het advies. Terug naar deel 1, De diagnose of deel 2, De analyse.

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.