DLP-beleid instellen in Microsoft Purview: een praktische basis voor het MKB

Een offerte met bankgegevens naar de verkeerde ontvanger, een Excel-bestand met personeelsgegevens in een openbare Teams-chat of een klantlijst die via een persoonlijke cloudopslag wordt gedeeld: een klein foutje kan grote gevolgen hebben. Data Loss Prevention, meestal afgekort tot DLP, helpt zulke fouten te herkennen en waar nodig te blokkeren.

Microsoft Purview DLP controleert niet alleen bestanden op één centrale plek. Afhankelijk van je licentie en configuratie kan beleid worden toegepast op Exchange Online, SharePoint, OneDrive, Teams en ondersteunde apparaten. Daardoor kun je gevoelige informatie beschermen op de plekken waar medewerkers dagelijks werken.

DLP is geen automatische garantie dat gegevens nooit uitlekken. Het is een combinatie van herkenning, waarschuwing, blokkering, rapportage en goed ingerichte werkprocessen. Deze handleiding legt uit hoe je voor een MKB-organisatie een beheersbare basis opzet zonder medewerkers direct met te veel blokkades te hinderen.

Wat is DLP in Microsoft Purview?

Een DLP-beleid bestaat grofweg uit drie onderdelen:

1. Locaties: waar Microsoft controleert, bijvoorbeeld Exchange, SharePoint, OneDrive of Teams.
2. Voorwaarden: welke informatie of welk gedrag je wilt herkennen, bijvoorbeeld persoonsgegevens, financiële gegevens of veel records tegelijk.
3. Acties: wat er gebeurt bij een match, zoals een waarschuwing tonen, een incident registreren of delen blokkeren.

Microsoft gebruikt daarvoor gevoelige informatietypen. Zo'n type bevat herkenningsregels voor gegevens als creditcardnummers, paspoortnummers, bankrekeningnummers en andere persoons- of financiële gegevens. De herkenning kijkt doorgaans niet alleen naar een cijferreeks, maar ook naar controlesommen, woorden in de buurt en de betrouwbaarheid van de match.

Je kunt ook eigen gevoelige informatietypen maken. Denk aan een intern klantnummer, dossiernummer of projectcode. Begin daar niet mee voordat je de ingebouwde typen hebt getest. Een te brede eigen regel kan duizenden onschuldige documenten markeren en daarmee het vertrouwen in meldingen beschadigen.

Wanneer is DLP nuttig voor een MKB-organisatie?

DLP levert vooral waarde wanneer je eerst duidelijk maakt welke informatie extra bescherming nodig heeft. Voor de meeste MKB-organisaties zijn dit praktische startcategorieën:

• personeelsgegevens, zoals burgerservicenummers, salarisinformatie en identiteitsdocumenten;
• klantgegevens, vooral wanneer meerdere persoonsgegevens samen worden gedeeld;
• financiële informatie, zoals bankrekeningnummers en betaalkaartgegevens;
• medische of andere bijzondere persoonsgegevens;
• vertrouwelijke offertes, contracten en overnamedocumenten;
• grote exports uit CRM-, boekhoud- of HR-systemen.

Bescherm niet automatisch ieder document met het woord “vertrouwelijk”. DLP werkt het beste met controleerbare kenmerken en een concrete risicosituatie. Een regel “waarschuw wanneer één IBAN intern wordt gemaild” kan bijvoorbeeld veel ruis geven, omdat een rekeningnummer ook legitiem op een factuur staat. Een regel voor meerdere gevoelige records die extern worden gedeeld, is vaak een beter eerste signaal.

Eerst inventariseren, dan pas blokkeren

Schrijf vóór de technische inrichting een eenvoudige beslismatrix. Leg per informatiesoort vast wie eigenaar is, waar de informatie normaal staat, met wie deze mag worden gedeeld en wat bij een overtreding moet gebeuren.

Informatiesoort	Normale locatie	Extern delen	Eerste DLP-reactie
Personeelsdossier	Beperkte SharePoint-site	Alleen met aangewezen partijen	Waarschuwen en incident registreren
Klantenexport	CRM of beveiligde bibliotheek	Alleen na controle	Delen blokkeren met gemotiveerde uitzondering
Factuur met één IBAN	Exchange en boekhouding	Normaal toegestaan	Alleen monitoren bij aanvullende risicosignalen
Kopie identiteitsbewijs	Beperkte dossieromgeving	Zeer uitzonderlijk	Blokkeren en securityteam informeren

Koppel deze keuzes aan je bestaande deelrechten. DLP repareert geen onbeheerde SharePoint-sites of te brede gasttoegang. Controleer daarom ook SharePoint-machtigingen op site-, bibliotheek- en mapniveau en leg voor externe samenwerking vast wie gasten beoordeelt en verwijdert. De handleiding externe gasten uitnodigen in Microsoft Teams geeft daarvoor een praktische basis.

Een veilig invoermodel: simuleren, bijstellen en afdwingen

Een goede DLP-invoering verloopt in fasen. Begin niet met een brede blokkade op alle Microsoft 365-locaties. Je weet dan nog niet hoeveel legitieme processen de regel raakt.

Wat je hier moet zien: Een beheersbare invoering begint met dataclassificatie, meet daarna echte beleidsmatches en activeert blokkades pas na beoordeling van impact en uitzonderingen.

Fase 1: inventariseren. Kies één duidelijk risico, bijvoorbeeld het extern delen van meerdere identiteits- of financiële gegevens. Bepaal de eigenaar en de normale uitzonderingen.

Fase 2: simuleren. Maak het beleid in Microsoft Purview en gebruik de beschikbare simulatie- of testmodus. Laat het beleid matches verzamelen zonder gebruikers direct te blokkeren. De precieze testopties kunnen per Microsoft-licentie en beleidsvariant verschillen.

Fase 3: analyseren. Bekijk welke locaties, afdelingen en bestandstypen de meeste matches veroorzaken. Controleer steekproefsgewijs of echte gevoelige gegevens zijn gevonden. Noteer false positives en legitieme bedrijfsprocessen.

Fase 4: bijstellen. Pas aantallen, betrouwbaarheidsniveau, uitzonderingen en locaties aan. Sluit niet zomaar hele afdelingen uit; maak een uitzondering zo smal mogelijk en geef deze een eigenaar en einddatum.

Fase 5: gecontroleerd afdwingen. Activeer eerst beleidsmeldingen en waarschuwingen. Blokkeer alleen situaties waarvan de impact bekend is. Controleer incidenten na ingebruikname dagelijks en evalueer na twee tot vier weken opnieuw.

Het beleid praktisch configureren

Open het Microsoft Purview-portaal met een account dat de vereiste rechten heeft en ga naar het onderdeel voor Data Loss Prevention. Kies om een nieuw beleid te maken. Microsoft biedt sjablonen voor onder meer privacy- en financiële regelgeving. Een sjabloon is een startpunt, geen kant-en-klare juridische beoordeling.

Geef het beleid een naam die doel en bereik uitlegt, bijvoorbeeld MKB – persoonsgegevens – extern delen – simulatie. Vermijd namen als “DLP 1” of “Nieuw beleid”; die zijn later niet te beheren.

Selecteer vervolgens de gewenste locaties. Begin bijvoorbeeld met Exchange, SharePoint en OneDrive als daar het grootste risico zit. Voeg Teams of apparaten toe wanneer je de bijbehorende licenties, beheerprocessen en impact hebt gecontroleerd. Beperk de eerste uitrol eventueel tot een representatieve groep, maar zorg dat die groep echte werkprocessen bevat.

Stel daarna de regel in:

• kies de relevante gevoelige informatietypen;
• bepaal hoeveel instanties nodig zijn voordat de regel actief wordt;
• kies of alleen extern delen of ook intern gebruik relevant is;
• stel het betrouwbaarheidsniveau passend in;
• voeg gebruikersmeldingen toe met duidelijke uitleg;
• bepaal wie incidentmeldingen ontvangt;
• gebruik een uitzondering alleen wanneer er een aantoonbaar bedrijfsproces achter zit.

Een bruikbare melding zegt niet alleen dat iets niet mag. Leg uit welke gegevens zijn gevonden, waarom delen risico oplevert en welk veilig alternatief beschikbaar is. Vermeld een intern contactpunt voor twijfelgevallen. Zo wordt de melding een leermoment in plaats van een onbegrijpelijke blokkade.

Wel of geen overschrijving toestaan?

Sommige regels kunnen een medewerker toestaan de waarschuwing te overschrijven, meestal met een reden. Dat is nuttig wanneer uitzonderingen legitiem maar niet volledig voorspelbaar zijn. Het geeft medewerkers handelingsruimte en levert informatie op over processen die nog niet goed in het beleid passen.

Sta overschrijven niet toe bij situaties die volgens je eigen risicoanalyse nooit via het gekozen kanaal mogen gebeuren. Denk aan een grote export met identiteitsgegevens naar een persoonlijk e-mailadres. Zorg dan wel voor een werkbaar alternatief, zoals een goedgekeurde beveiligde overdracht.

Analyseer opgegeven redenen periodiek. Veel dezelfde overschrijvingen kunnen betekenen dat de regel te breed is, maar ook dat een afdeling een onveilig proces structureel gebruikt. Los de oorzaak op in plaats van alleen een uitzondering toe te voegen.

Meldingen en incidenten opvolgen

Een DLP-beleid zonder opvolging is vooral een verzameling waarschuwingen. Wijs daarom vooraf rollen toe:

• een proceseigenaar die bepaalt wat zakelijk nodig is;
• een privacy- of securityverantwoordelijke die risico's beoordeelt;
• IT-beheer dat de technische regel onderhoudt;
• een vervanger voor afwezigheid;
• een escalatiepad voor mogelijke datalekken.

Leg minimaal vast: datum, getroffen locatie, informatietype, aantal records, interne of externe ontvanger, actie van het beleid en beoordeling door een medewerker. Bewaar niet onnodig de volledige gevoelige inhoud in losse tickets of e-mails.

Een DLP-match is niet automatisch een meldplichtig datalek. De context bepaalt of persoonsgegevens daadwerkelijk ongeoorloofd zijn ingezien, gewijzigd, verloren of verstrekt. Laat die beoordeling uitvoeren volgens het privacy- en incidentproces van je organisatie.

Veelgemaakte fouten

Meteen alles blokkeren

Een brede blokkade zonder simulatie raakt onverwachte facturen, sollicitaties, klantmails en bestaande integraties. Begin met meten en verhoog de handhaving gecontroleerd.

Alleen standaardinstellingen accepteren

Een sjabloon kent jouw processen, klanten en uitzonderingen niet. Controleer aantallen, locaties, meldingen en ontvangers altijd zelf.

Uitzonderingen zonder eigenaar maken

Een permanente uitzondering voor een afdeling of domein kan een groot gat creëren. Geef iedere uitzondering een reden, eigenaar, scope en beoordelingsdatum.

Geen rekening houden met licenties

Beschikbare locaties, endpointmogelijkheden, analyses en geavanceerde classificatie hangen af van je Microsoft-licenties. Controleer vóór de uitrol welke functies daadwerkelijk in jouw tenant beschikbaar zijn.

DLP verwarren met back-up of toegangsbeheer

DLP voorkomt niet dat een bestand wordt verwijderd en vervangt geen back-up. Het vervangt evenmin MFA, Conditional Access of correcte SharePoint-rechten. Zie het als één beveiligingslaag in een breder pakket van maatregelen.

Controlelijst voor ingebruikname

Controleer voor activering van blokkades:

• De informatiesoort en het risicoscenario zijn beschreven.
• Een proceseigenaar heeft de gewenste deelroute bevestigd.
• Het beleid heeft voldoende lang in simulatie gedraaid.
• False positives en legitieme uitzonderingen zijn beoordeeld.
• De gebruikersmelding legt reden en veilig alternatief uit.
• Incidentmeldingen gaan naar een actief bewaakte groep.
• Overschrijvingen worden gelogd en periodiek beoordeeld.
• De servicedesk kent de meldtekst en de escalatieroute.
• De gekozen locaties en functies passen bij de licenties.
• Er staat een evaluatiemoment in de agenda.

Wil je eerst weten waar gevoelige informatie, brede deelrechten en ontbrekende beveiligingsinstellingen in jouw Microsoft 365-omgeving samenkomen? Vraag de gratis IT-scan aan voor een concrete prioriteitenlijst.

Veelgestelde vragen

Kan DLP voorkomen dat medewerkers een screenshot maken?

Niet in alle situaties. DLP controleert ondersteunde gegevensstromen en locaties. Schermafbeeldingen, foto's en niet-ondersteunde apps vragen aanvullende endpoint-, app- en gebruikersmaatregelen. Behandel DLP daarom niet als volledige kopieerbeveiliging.

Werkt DLP ook in Microsoft Teams?

Microsoft Purview kan DLP-beleid toepassen op Teams-berichten, afhankelijk van de beschikbare licenties en configuratie. Bestanden die via Teams-kanalen worden gebruikt, staan in SharePoint en vallen onder beleid voor die locatie. Controleer beide gegevensstromen afzonderlijk.

Wat is het verschil tussen een gevoelig informatietype en een gevoeligheidslabel?

Een gevoelig informatietype herkent kenmerken in inhoud, zoals een paspoort- of bankrekeningnummer. Een gevoeligheidslabel classificeert en kan bescherming toepassen op documenten, e-mail of containers. DLP-regels kunnen classificatie en herkende inhoud gebruiken om gedrag te sturen.

Hoe lang moet een beleid in simulatie draaien?

Er is geen universele termijn. Kies een periode die normale werkcycli bevat, bijvoorbeeld salarisverwerking, facturatie en maandrapportage. Voor veel organisaties is twee tot vier weken een bruikbaar startpunt, waarna je met de proceseigenaren beslist of de resultaten representatief zijn.

Kunnen medewerkers zien waarom een actie wordt geblokkeerd?

Ja, wanneer je beleidsmeldingen goed configureert. Schrijf de melding in gewone taal en geef een veilige vervolgactie. Test de tekst met medewerkers voordat je brede blokkades activeert.

Hebben we DLP nodig als alleen intern wordt gedeeld?

Ook intern kunnen te brede rechten of verkeerde ontvangers risico opleveren. Begin echter bij de situaties met de grootste impact. Extern delen van grote hoeveelheden gevoelige informatie heeft vaak meer prioriteit dan één intern document binnen een beperkt team.

Gebruikte Microsoft-bronnen

De productwerking en termen zijn op 31 juli 2026 gecontroleerd tegen:

• Learn about data loss prevention
• Create and deploy data loss prevention policies
• Sensitive information type entity definitions