[{"content":" 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.\nIn 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.\nOpenheid 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.\nTerugblik 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 \u0026ldquo;heb ik een record?\u0026rdquo; naar \u0026ldquo;kan ik naleving aantonen?\u0026rdquo;. Dat is het scharnier van dit tweede deel.\nIk 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.\nStelling 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: \u0026ldquo;Wil je niet voldoen? Dat mag, maar dan ook niet mailen of chatten.\u0026rdquo; 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.\nMaar 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\u0026rsquo;n portaal bedient in de praktijk alleen geregistreerde patiënten, terwijl de norm juist vraagt dat het inkomende kanaal bruikbaar is voor \u0026ldquo;iedereen met voor particulieren gebruikelijke internetvoorzieningen\u0026rdquo;. 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.\nEr 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.\nStelling 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) \u0026ldquo;slechts in overeenstemming met de AVG\u0026rdquo; 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.\nEn 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.\nWant 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.\nHet middenpad: wat je vandaag zelf kunt bouwen Tussen \u0026ldquo;koop een kant-en-klare oplossing\u0026rdquo; en \u0026ldquo;bouw alles zelf\u0026rdquo; 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.\nEerlijk 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.\nEn 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.\nDan de kosten. De verleiding om te zeggen dat dit \u0026ldquo;bakken met geld\u0026rdquo; 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 \u0026ldquo;vervang de leverancier\u0026rdquo;, maar \u0026ldquo;verklein de leverancierscope tot het verkeer waar hij echt waarde levert\u0026rdquo;.\nConcrete voorstellen aan de normcommissie \u0026ldquo;Betere architectuureisen\u0026rdquo; 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.\nE-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.\nVerifieerbare 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.\nJurisdictie 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.\nHerstel 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 \u0026ldquo;onjuiste en onvolledige toetsing\u0026rdquo;, is een reden om het beter te doen, niet om het weg te laten.\nFormuleer § 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.\nDit blijft een persoonlijke bijdrage aan het normdebat, geformuleerd als \u0026ldquo;de norm zou X kunnen eisen omdat Y\u0026rdquo;, niet als aanklacht en niet als standpunt van Microsoft.\nWat 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.\nEr 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.\nTweeluik 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.\nNormverwijzingen 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.\n","permalink":"https://scratchpad.ravensberg.org/nl/berichten/nta-7516-deel-2-advies/","summary":"De vraag verschuift van \u0026lsquo;heb ik een record?\u0026rsquo; naar \u0026lsquo;kan ik naleving aantonen?\u0026rsquo;. Ik werk twee stellingen uit, bijzondere patiëntdata hoort in het dossier en architectuur gaat boven geografie, schets een middenpad met zijn eerlijke grenzen, en doe voorstellen aan de normcommissie.","title":"Hoe NEN 7516 beter kan: architectuur boven geografie"},{"content":" Tweeluik NTA 7516, deel 1 van 2. Dit is De diagnose. Het vervolg staat in deel 2, Het advies.\nIn 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.\nRond het certificeren van \u0026lsquo;veilig mailen\u0026rsquo; 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\u0026rsquo;s eigen woorden op de productpagina van dat schema zijn daarmee \u0026ldquo;alle bestaande NTA 7516-certificeringen van alle leveranciers ingetrokken\u0026rdquo;, terwijl \u0026ldquo;de NTA 7516 zelf … wel geldig [blijft]\u0026rdquo;. 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.\nWat 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.\nSinds die certificering wegviel, hoor ik van zorgorganisaties steeds vaker dat de huidige \u0026lsquo;veilig mailen\u0026rsquo;-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 \u0026ldquo;duur, gebruiksonvriendelijk en onnodig\u0026rdquo; zijn, was dat groot nieuws in de sector.\nOpenheid 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.\nDit 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.\nWaarom is NTA 7516 eigenlijk verplicht? Het mooiste antwoord komt van de normeigenaar zelf. In NEN\u0026rsquo;s eigen FAQ, onder de kop \u0026ldquo;Moet een zorgaanbieder aan NTA 7516 voldoen?\u0026rdquo;, staat:\n\u0026ldquo;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.\u0026rdquo;\nDat 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 \u0026ldquo;(nog)\u0026rdquo;: 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.\nOnder 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\u0026rsquo;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.\nDe tweede helft van het citaat doet nog iets. \u0026ldquo;De NTA is gebaseerd op de AVG en eIDAS\u0026rdquo; 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.\nNaast 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.\nBlijft één ding overeind, en het is de scharnier naar deel 2: \u0026quot;(nog) niet verplicht\u0026quot; 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 \u0026ldquo;heb je een certificaat\u0026rdquo; naar aantoonbaarheid, en daar bouwt deel 2 op voort.\nWat 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\u0026rsquo;n record er zo uit:\nv=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.\nDat 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.\nTwee dingen volgen daaruit, en ze zijn allebei makkelijk verkeerd te lezen.\nAanwezigheid is een claim, geen keurmerk. Een record zegt \u0026ldquo;wij richten ons hierop in\u0026rdquo;. Het is geen uitkomst van een audit, het ís, in de woorden van de Raad van State, \u0026ldquo;in feite een zelfverklaring\u0026rdquo;. En sinds NEN het toetsingsschema NCS 7516 introk, is er geen geaccrediteerde route meer die zo\u0026rsquo;n claim staaft. Dat is geen theorie: Zivver stelde zelf in 2022 dat veel certificaten waren afgegeven op \u0026ldquo;onjuiste en onvolledige toetsing\u0026rdquo;.\nAfwezigheid is geen bewijs van onveiligheid. Geen record betekent niet \u0026ldquo;deze organisatie mailt onveilig\u0026rdquo;. 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.\nEr 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.\nNaar 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.\nTwee 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.\nDe 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 \u0026ldquo;leverancier X doet het zó\u0026rdquo; is niet hetzelfde als \u0026ldquo;de norm eist het zó\u0026rdquo;.\nTransport. 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.\nToegang 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.\nFunctionaliteit 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.\nDe 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.\nHet 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.\nBeantwoorden 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\u0026rsquo;s eigen FAQ prefereert, nu terug te zien in een concrete clausule. Precies daar zit menselijk gedrag, en precies daar is aantoonbaarheid het moeilijkst.\nBeleid 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.\nEuropese 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.\nSamengevat: 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.\nWat 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 \u0026lsquo;veilig mailen\u0026rsquo;-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.\nEn 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 \u0026ldquo;vendor of niet\u0026rdquo;, maar: welk deel van een NTA-oplossing is de leverancier, en welk deel is functionaliteit die je al hebt?\nDe 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.\nTweeluik NTA 7516, deel 1 van 2. Je las De diagnose. Deel 2, Het advies bouwt hierop voort.\n*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.\n","permalink":"https://scratchpad.ravensberg.org/nl/berichten/nta-7516-deel-1-diagnose/","summary":"Rond het certificeren van \u0026lsquo;veilig mailen\u0026rsquo; is het stil, rond de norm zelf niet. Ik lees NTA 7516 clausule voor clausule — met de norm erbij, die gratis bij NEN op te vragen is — en laat zien waaraan je nu eigenlijk gehouden bent, door wie, en wat daarvan techniek is en wat organisatie.","title":"Veilig mailen in de zorg: waar de schoen wringt bij de huidige NTA 7516"},{"content":"Om de paar maanden los ik iets op, voel me even slim, en ben vervolgens alle details weer vergeten. Dit is de oplossing: een kladblok.\nWaarom een kladblok, en geen blog Het etiket doet meer dan het zou moeten. Zodra iets Een Blogpost is, wil ik dat het af is: een nette inleiding, een afgeronde conclusie, een diagram, nog één keer nalezen voordat het online gaat. Voor een uitgebreid artikel is dat een prima maatstaf. Voor \u0026ldquo;dit is de vlag die het oploste\u0026rdquo; niet.\nDit een kladblok noemen legt de lat bewust anders, voor wie het leest, en vooral voor mezelf. Een stuk hier mag drie alinea\u0026rsquo;s zijn met een commando dat toevallig werkte. Het mag informeel zijn, het mag een mening zijn, en het mag volgende maand achterhaald blijken. Niets hoeft het laatste woord over iets te zijn; het moet vooral opgeschreven zijn.\nDe vorm is dus met opzet vrij. Als een stuk af en toe leest als een aantekening aan mezelf, dan is dat precies de bedoeling.\nDe techniek, en waarom die saai is Het idee is dat deze site over vijf jaar nog steeds bouwt zonder dat ik er veel naar hoef om te kijken. Daarmee vielen de meeste leuke opties af.\nHugo, één statische binary. Het rendert Markdown naar HTML en verder niets. Het komt binnen via het npm-pakket hugo-extended, dus er is geen aparte toolchain nodig. PaperMod, toegevoegd als Hugo Module in plaats van een gekopieerd thema of een git submodule. Het thema staat vastgezet in go.mod, zodat Renovate het bijwerkt als elke andere dependency. Geen eigen JavaScript. Niets om te bundelen, niets om te patchen. Dat laatste punt is waar het mij om gaat. Ik heb eerder een Hugo-thema gehad dat niet meer onderhouden werd, en zo\u0026rsquo;n gekopieerd thema jaren later uit een repository peuteren is geen pretje. Door het thema als dependency te behandelen merk ik het wanneer het stil komt te liggen, in plaats van pas wanneer Hugo een API verandert.\nDeployen Een push naar main start een GitHub Actions-workflow die de site bouwt en wrangler pages deploy uitvoert richting Cloudflare Pages. Pull requests krijgen hun eigen preview-URL, die als reactie op de PR wordt geplaatst.\nWat hier komt te staan Korte aantekeningen over infrastructuur, security en automatisering, vooral het soort dingen dat ik anders uit een verlopen browsertab moet terugzoeken.\n","permalink":"https://scratchpad.ravensberg.org/nl/berichten/hallo-kladblok/","summary":"Waarom dit een kladblok is en geen blog, en de bewust saaie techniek erachter.","title":"Hallo, kladblok"},{"content":"Ik ben Jean-Paul van Ravensberg. Dit is mijn kladblok: korte stukken over dingen die ik tegenkwam tijdens het werken aan infrastructuur, security en automatisering.\nDe site is gebouwd met Hugo en het PaperMod-thema, en wordt rechtstreeks vanaf GitHub naar Cloudflare Pages gedeployed.\n","permalink":"https://scratchpad.ravensberg.org/nl/over/","summary":"\u003cp\u003eIk ben Jean-Paul van Ravensberg. Dit is mijn kladblok: korte stukken over\ndingen die ik tegenkwam tijdens het werken aan infrastructuur, security en\nautomatisering.\u003c/p\u003e\n\u003cp\u003eDe site is gebouwd met \u003ca href=\"https://gohugo.io/\"\u003eHugo\u003c/a\u003e en het\n\u003ca href=\"https://github.com/adityatelange/hugo-PaperMod\"\u003ePaperMod\u003c/a\u003e-thema, en wordt\nrechtstreeks vanaf \u003ca href=\"https://github.com/DevSecNinja/scratchpad\"\u003eGitHub\u003c/a\u003e naar\nCloudflare Pages gedeployed.\u003c/p\u003e","title":"Over"}]