Wat het auditlogboek wel en niet is
In Microsoft 365 schrijft het unified auditlogboek gebeurtenissen weg die u later kunt doorzoeken: wie meldde zich aan, wie wijzigde een rol, wie gaf een app toestemming, wie gevonden of gedeeld in SharePoint of OneDrive. Het is geen realtime alarmcentrale en geen vervanging van meervoudige authenticatie. Het is het bewijs achteraf — of juist het ontbreken daarvan als logging uit stond of te kort bewaard bleef.
Afhankelijk van uw abonnement en instellingen verschillen bewaartermijnen en beschikbare werkbelasting. Voor het MKB telt vooral: staat logging überhaupt aan, hoe lang houdt u records vast, en wie mag zoeken. Zonder die drie antwoorden heeft u bij een verdachte aanmelding of een verdwenen bestand weinig om op terug te vallen.
Zie beheerdersaccounts voor wie die zoekrechten überhaupt mag hebben, en meervoudige authenticatie voor de laag die voorkomt dat een gestolen wachtwoord überhaupt binnenkomt — dezelfde tenant-hygiëne, andere knop.
Wat het MKB doorgaans fout doet
Vier patronen komen terug. Logging nooit aangezet — dan is er na een incident niets om te doorzoeken. Logging wel aan, maar geen bewaartermijn of doel — dan verdwijnen records vóór u ze nodig heeft, of houdt u alles bij zonder te weten waarom. Niemand reviewt — dan liggen de logs er, maar kijkt er niemand bij verdachte admin-acties of massaal delen. Of juist: alles loggen “voor de zekerheid” zonder wie-mag-zoeken en zonder schriftelijk doel — dan heeft u data zonder stuur.
De praktische lijn: bevestig dat auditlogging aan staat; kies een bewaartermijn die bij uw MKB past (vaak maanden tot een jaar, langer alleen met reden); wijs één of twee personen of Floor ICT aan die mogen zoeken; en koppel reviews aan signalen — niet aan “elke week alles lezen”.
Wanneer aanzetten — en wat aanhouden
Aanzetten past bij bijna elk MKB met Microsoft 365: u heeft medewerkers, gasten, apps en beheerders. Zonder log mist u reconstructie bij phishing, bij een vertrokken medewerker met nog rechten, of bij een app die te veel toegang kreeg. Uitzondering is zeldzaam; “we hebben niets te verbergen” is geen reden om logging uit te laten.
Wat u aanhoudt hangt af van wat u wilt kunnen beantwoorden: wie meldde zich aan vanaf een onbekende locatie; wie wijzigde beheerdersrollen; wie deelde een map extern; wie gaf een app toestemming. Spreek een termijn af die die vragen nog haalbaar maakt. Langer is niet altijd beter: meer bewaren zonder doel of zonder wie mag zoeken, geeft schijnveiligheid.
Echte dreiging: een account dat plotseling veel postvakken doorzoekt, een admin die rechten uitdeelt buiten het normale pad, of een gastaccount dat bestanden massaal downloadt. Het auditlogboek is dan uw reconstructie — naast gastaccounts en inactieve accounts.
Wie mag zoeken — en wanneer
Zoeken in het auditlogboek is een gevoelige bevoegdheid: u ziet gedrag van medewerkers en gasten. Beperk die rechten tot beheerders die u vertrouwt (of tot Floor ICT onder uw opdracht). Spreek af wanneer er gezocht wordt: bij een incident, bij een vermoeden, of bij een gerichte review — niet “even snuffelen”.
Leg vast wie een zoekopdracht mag starten, hoe u het resultaat bewaart, en dat u niet structureel mailboxinhoud of chat leest via auditlogs alsof het monitoring van mensen is. Het doel is reconstructie en beveiliging, niet surveillance zonder afspraak.
Wat u schriftelijk vastlegt
Houd het kort genoeg om dit kwartaal echt te besluiten:
- of auditlogging (unified audit log) in uw tenant aan staat;
- welke bewaartermijn u aanhoudt, met een korte reden (bijvoorbeeld reconstructie bij incidenten);
- wie mag zoeken in de logs (rollen of namen, of Floor ICT onder opdracht);
- wanneer er gezocht wordt (incident, vermoeden, periodieke steekproef — niet “altijd alles”);
- koppeling met beheerdersaccounts, inactieve accounts, gastaccounts, app-toestemming en meervoudige authenticatie — één identity-hygiëne;
- wat u verwacht na een treffer: escaleer naar Floor ICT of de processeigenaar, niet stilzwijgend negeren.
Schrijf die punten op één pagina. Dat is uw auditlog-afspraak; de tenant volgt die tekst.
Wat Floor ICT configureert — en wat u beslist
In de Microsoft 365-tenant zetten wij doorgaans: auditlogging aan of bevestigen dat die aan staat; een bewaartermijn die bij uw afspraak past; beperkte zoekrechten voor de juiste beheerdersrollen; en uitleg hoe wij bij een ticket of incident logs raadplegen. We helpen bij gerichte zoekopdrachten (verdachte aanmelding, rare admin-actie, massaal delen) zonder uw tenant “vol te monitoren” zonder opdracht.
U beslist nog steeds: hoe lang u aanhoudt; wie namens u mag zoeken; en hoe streng u reageert als een zoekopdracht iets zorgelijks toont. Technische knoppen zonder die afspraak geven schijnveiligheid; beleid zonder werkende logging ook niet.
Meer diepte
Checklist voor directeuren in het MKB
1) Vraag of het unified auditlogboek in uw tenant aan staat. 2) Ken de bewaartermijn — past die bij “we willen een half jaar terug kunnen kijken”? 3) Weet wie mag zoeken (niet iedereen met een admin-rol “voor het gemak”). 4) Koppel dit aan reviews van beheerders-, gast- en inactieve accounts. 5) Spreek af: verdachte treffer = melden, niet stilzwijgend wegklikken. 6) Laat Floor ICT dit meenemen in dezelfde Microsoft 365-hygiëne als meervoudige authenticatie en app-toestemming.
Auditlog versus aanmeldingslogs alleen
Aanmeldingslogs tonen vooral wie binnenkwam. Het unified auditlogboek dekt ook beheerdersacties, delen, zoeken en app-toestemming. Voor het MKB wilt u die bredere laag — niet alleen “wie logde in”. Floor ICT wijst aan welke console of zoekopdracht bij uw vraag past.
Relatie met app-toestemming en beheerders
Als iemand een app te brede rechten geeft, of een beheerdersrol wijzigt, wilt u dat terug kunnen vinden. Zonder auditlog mist u die reconstructie. Zie app-toestemming en beheerdersaccounts — logging maakt die afspraken controleerbaar.