Vertrouwelijke documenten mailen is in de meeste organisaties nog altijd de standaard, terwijl e-mail daar nooit voor is gebouwd. Het protocol ontstond begin jaren tachtig voor tekstberichten. Bijlagen en versleuteling zijn er later aan vastgemaakt. Dat organisaties toch niet direct aan een speciaal platform voor veilig documenten delen denken, is zelden onwetendheid.
E-mail is de vanzelfsprekende standaard, de kosten van het risico blijven onzichtbaar en niemand is eigenaar van het proces. Dit artikel legt uit waar die drempels vandaan komen en hoe je ze intern doorbreekt.
Kort antwoord: organisaties blijven vertrouwelijke documenten mailen omdat e-mail er al is, gratis voelt en geen eigenaar heeft die het kanaal ter discussie stelt. De beperkingen van een bijlage zijn bekend, maar worden pas zichtbaar bij een incident of audit. Wie wil overstappen, heeft daarom minder aan nóg een risicolijst en meer aan drie dingen: een eigenaar, één concrete documentstroom en een alternatief dat net zo makkelijk werkt als een bijlage.
Dit artikel is bedoeld voor IT-managers, CISO’s en privacy officers die de overstap intern moeten organiseren. Welke bijlagen wel en niet per e-mail kunnen, welke risico’s een gewone bijlage heeft en welke functies gecontroleerd delen moet bieden, lees je in Waarom e-mailbijlagen niet altijd geschikt zijn voor gevoelige bestanden. Hier gaat het om een andere vraag: waarom verandert die kennis zo weinig in de praktijk?
E-mail is gebouwd voor berichten, niet voor documenten
Toen de standaard voor internetberichten in 1982 werd vastgelegd, ging het om tekst. De latere MIME-specificatie zegt dat letterlijk: RFC 822 was bedoeld als formaat voor tekstberichten. Het transport via SMTP was beperkt tot 7-bits tekst in regels van maximaal 1.000 tekens. Een PDF of een scan van een paspoort paste niet in dat ontwerp.
Bijlagen kwamen er pas echt bij met MIME, vastgelegd in RFC 2045 uit 1996. Een bestand wordt met base64 omgezet in gewone tekens, zodat bestaande mailservers het kunnen doorgeven. De opstellers schreven er eerlijk bij dat compatibiliteit voorrang kreeg boven elegantie. Versleuteling volgde nog later: met STARTTLS (RFC 3207, 2002) kunnen mailservers het transport versleutelen, als beide kanten dat ondersteunen. De IETF beschrijft zelf dat een aanvaller die delen van de SMTP-sessie weghaalt, die versleuteling kan omzeilen. Daarvoor verscheen in 2018 MTA-STS.
Elke stap loste een echt probleem op, zonder het fundament te veranderen. Het resultaat is dat een bijlage technisch een kopie in een bericht is, geen gedeeld document met eigen voorwaarden. Dat verklaart de beperkingen van e-mail. Het verklaart nog niet waarom organisaties er massaal aan vasthouden.
Waarom vertrouwelijke documenten mailen toch de standaard blijft
Het probleem is niet onbekend. In de eerste helft van 2024 ging 18 procent van de ruim 9.800 datalekmeldingen bij de Autoriteit Persoonsgegevens over persoonsgegevens in een e-mail, bijvoorbeeld verstuurd aan een verkeerde ontvanger, volgens voorlopige cijfers van CBS en AP. Bij 88 procent van alle meldingen waren vooraf geen maatregelen genomen om de gegevens te versleutelen of anders ontoegankelijk te maken. Toch leidt zo’n cijfer zelden tot een ander kanaal. Vijf mechanismen verklaren waarom.
1. E-mail is de status quo
Bijna elke beslissing kent een optie om niets te veranderen. De economen Samuelson en Zeckhauser lieten in 1988 met experimenten en praktijkdata zien dat mensen onevenredig vaak bij die status quo blijven. Hun onderzoek ging over keuzes als zorg- en pensioenregelingen, niet over IT. Het mechanisme is wel herkenbaar: voor e-mail heeft niemand ooit gekozen, het was er al.
2. E-mail voelt gratis
De mailbox zit in de bestaande licentie. Een apart platform is een zichtbare kostenpost met een inkooptraject. De kosten van het huidige kanaal blijven verspreid en onzichtbaar: uren voor een datalekonderzoek, een melding, herstel en vertrouwensverlies komen pas op de rekening als het misgaat.
3. Niemand is eigenaar van documentuitwisseling
IT beheert de mailserver, de privacy officer schrijft het beleid, de CISO bewaakt de risico’s en de afdelingen doen het werk. Het proces “een vertrouwelijk document naar een externe partij sturen” valt daartussen. Zonder eigenaar stelt niemand de vraag of het kanaal nog past.
4. “Dat hebben we toch al geregeld”
Veel organisaties hebben versleutelde e-mail, gevoeligheidslabels of SharePoint. Dat zijn waardevolle maatregelen, maar ze beantwoorden deels andere vragen. Berichtbeveiliging beschermt de mail, samenwerkingsomgevingen ondersteunen gezamenlijk werken. Gecontroleerde overdracht aan een externe ontvanger, met verificatie en bewijs, is een derde vraagstuk. Het verschil met SharePoint werken we uit in SharePoint vs. Secure File Transfer.
5. Het risico wordt pas zichtbaar bij een incident of audit
Een verkeerd verstuurde bijlage voelt als een individuele vergissing, niet als een patroon. Pas wanneer een toezichthouder of auditor vraagt aan te tonen wie een document heeft ontvangen en geopend, blijkt dat de mailbox dat antwoord niet geeft. De AVG verplicht organisaties om naleving te kunnen aantonen (artikel 5, lid 2). Onder de Cyberbeveiligingswet moet het bestuur bovendien de beveiligingsmaatregelen goedkeuren en erop toezien, zoals toegelicht op onze pagina over NIS2, de Cyberbeveiligingswet en veilig bestanden delen.
Daar komt een terechte zorg bij: dat een nieuw kanaal het werk ingewikkelder maakt. Complexiteit ondermijnt compliance, dus een alternatief werkt alleen als het minstens zo makkelijk is als een bijlage toevoegen.
Van bezwaar naar gesprek
Wie de overstap op de agenda zet, hoort vrijwel altijd dezelfde bezwaren. Ze zijn zelden onredelijk, maar ze gaan meestal over iets anders dan de vraag of e-mail geschikt is. De tabel koppelt elk bezwaar aan wat erachter zit en aan een vraag die het gesprek concreet maakt.
| Bezwaar | Wat er meestal achter zit | Vraag die het gesprek verandert |
|---|---|---|
| “E-mail werkt toch prima?” | Gewoonte. Er is nooit bewust voor e-mail gekozen. | “Voor welke documentstroom hebben we ooit expliciet besloten dat e-mail volstaat?” |
| “We hebben al versleutelde mail en Microsoft 365.” | Berichtbeveiliging en documentcontrole worden door elkaar gehaald. | “Kunnen we voor het laatste contract dat we extern deelden aantonen wie het heeft gedownload?” |
| “Een apart platform kost geld.” | De kosten van het huidige kanaal zijn onzichtbaar. | “Hoeveel uren kostte ons laatste onderzoek naar een verkeerd verstuurde e-mail?” |
| “Medewerkers gaan het niet gebruiken.” | Een terechte zorg over frictie en schaduw-IT. | “Werkt het alternatief vanuit de omgeving waar medewerkers nu al mailen?” |
| “Dat is een IT-onderwerp.” Of: “Dat ligt bij privacy.” | Er is geen eigenaar van het proces. | “Wie is verantwoordelijk als morgen een dossier bij de verkeerde externe partij belandt?” |
| “Het is nog nooit misgegaan.” | Incidenten worden gezien als losse fouten, niet als patroon. | “Hoeveel verkeerd verstuurde e-mails zijn er het afgelopen jaar intern gemeld?” |
Wie is eigenaar van veilig documenten delen?
Eigenaarschap is de drempel die het vaakst blijft liggen, omdat elke betrokkene een deel van het vraagstuk bezit. Een werkbare verdeling ziet er zo uit:
| Rol | Waar deze rol over gaat | Rol in de overstap |
|---|---|---|
| Afdelingsmanager (HR, financiën, zorg, projecten) | Het werkproces en de externe relaties | Eigenaar van de documentstroom |
| CISO of security officer | Informatiebeveiligingsbeleid en risico’s | Stelt eisen aan verificatie, toegang en logging |
| Privacy officer of FG | AVG, datalekken, verantwoording | Toetst en adviseert, is niet de proceseigenaar |
| IT-manager | Werkplek, integratie en beheer | Kiest en implementeert het kanaal |
| Directie of bestuur | Eindverantwoordelijkheid en budget | Neemt het besluit en borgt de uitvoering |
De kern: leg het eigenaarschap per documentstroom bij de afdeling die het werk doet, met security en privacy als toetsers. Dan heeft de vraag of het kanaal nog past eindelijk een adres.
Zo krijg je de overstap intern op de agenda
Een organisatiebrede verandering in één keer lukt zelden. Een overtuigend eerste besluit wel. Deze vijf stappen richten zich op dat besluit, niet op de technische inrichting.
- Kies één documentstroom. Neem de stroom waar de gevolgen van een fout het grootst zijn. Denk bijvoorbeeld aan loonstroken naar een extern salarisbureau, medische informatie naar een verzekeraar of contracten naar een ketenpartner. Zet twee of drie kandidaten naast elkaar en tel per stroom hoe vaak het antwoord op de zes vragen hieronder ja is. De stroom met de meeste keren ja pak je als eerste aan. Een stroom met nul keer ja kan gewoon per e-mail.
- Stel de bewijsvraag. Vraag, zoals een auditor zou doen: kunnen we voor deze stroom aantonen wie welk document ontving, wanneer het is gedownload en hoe lang het beschikbaar was? Het antwoord is vaak het sterkste argument.
- Maak het risico concreet in de taal van de beslisser. Beschrijf wat er gebeurt als het morgen misgaat: de beoordeling, een mogelijke melding binnen 72 uur, het herstel en het gesprek met de betrokken klant of partner. Gebruik geschatte uren uit eigen incidenten in plaats van generieke bedragen.
- Test in de bestaande werkplek. Laat echte gebruikers de stroom een paar weken via het gecontroleerde kanaal afhandelen, met echte externe ontvangers. Meet of mensen de veilige route kiezen en waar ze vastlopen.
- Leg het besluit vast. Benoem de eigenaar, de stromen die volgen en een evaluatiemoment. Voor het bredere kanaalbeleid per type informatie is het stappenplan in ons artikel over e-mailbijlagen een goed vervolg.
- Bevat de stroom persoonsgegevens, zoals een BSN, medische of financiële gegevens?
- Gaat het naar een externe partij buiten je eigen domein?
- Moet je later kunnen aantonen wie het ontving en downloadde?
- Is het een probleem als een document wordt doorgestuurd of bij een verkeerde ontvanger belandt?
- Mogen de documenten maar een beperkte periode beschikbaar zijn?
- Valt de stroom onder de AVG, DORA, de Cyberbeveiligingswet of contractuele geheimhouding?
Welke eisen de AVG stelt aan het uitwisselen van bestanden met persoonsgegevens, lees je op onze pagina AVG en veilig bestanden delen.
Hoe Msafe de overstap makkelijker maakt
De meeste drempels in dit artikel gaan over gewoonte en gemak, niet over techniek. Daar is Msafe Secure File Transfer op ingericht. In de Enterprise- en Unlimited-abonnementen delen medewerkers vanuit Outlook, zodat de veilige route in hetzelfde scherm zit als de bijlage. Externe ontvangers hebben geen account nodig. Zij krijgen toegang na verificatie, bijvoorbeeld met een sms-code, authenticator of pincode. De afzender stelt een vervaldatum in en kan toegang intrekken.
Voor de bewijsvraag uit stap 2 legt Msafe uploads, downloads en shares vast in een exporteerbare audit trail. Sinds Msafe 2.5 kunnen beheerders centraal beleid instellen, bijvoorbeeld welke bestandstypen niet gedeeld mogen worden, en gebruikers via SCIM automatisch aan het juiste beleid koppelen. Zo helpt Msafe aantoonbaar te maken wat er met een document is gebeurd. Functies en abonnementen staan op de productpagina van Msafe Secure File Transfer.
Ook met Msafe blijft een gedownload bestand een kopie bij de ontvanger. Het verschil zit in de voorwaarden vooraf en het bewijs achteraf.
Veelgestelde vragen
Waarom gebruiken organisaties nog e-mail voor vertrouwelijke documenten?
Omdat e-mail al aanwezig is, gratis voelt en geen eigenaar heeft die het kanaal ter discussie stelt. De beperkingen van een bijlage worden meestal pas zichtbaar bij een incident of een auditvraag. Tot dat moment voelt de status quo als de veilige keuze.
Wie beslist over een platform voor veilig documenten delen?
Formeel meestal de directie of het bestuur, op voorstel van IT en security. In de praktijk werkt het beter als de afdeling die de documentstroom beheert eigenaar wordt, met de CISO en privacy officer als toetsers. Onder de Cyberbeveiligingswet moet het bestuur de beveiligingsmaatregelen bovendien zelf goedkeuren.
Hoe maak je een business case voor veilig bestanden delen?
Begin niet met de hele organisatie, maar met één documentstroom met hoog risico. Stel de bewijsvraag, beschrijf wat een incident in uren en gevolgen kost en test een alternatief met echte gebruikers. Een meetbaar resultaat uit een kleine test overtuigt sneller dan een algemene risicoanalyse.
Wil je de overstap onderbouwen met één echte documentstroom uit je eigen organisatie? Vraag een Proof of Concept van Msafe Secure File Transfer aan.
