Waarom ISO 27001 A.8.15 meer eist dan 'adequate' MSP-logging

Waarom MSP-logging adequaat lijkt - tot een ISO 27001-audit

MSP-logging lijkt vaak adequaat totdat u een incident opnieuw moet bekijken en ontdekt dat de logs geen eenduidig verhaal kunnen vertellen. Deze handleiding is algemene informatie, geen juridisch advies, maar weerspiegelt hoe auditors, onderzoekers en verzekeraars logs gebruiken om uw diensten en uw ISO 27001 A.8.15-implementatie te testen. Sterke logging verandert een verwarrende dag in een bewijsspoor dat u onder druk kunt verdedigen.

Slechts ongeveer één op de vijf organisaties in de ISMS.online-enquête van 2025 gaf aan dat zij in het voorgaande jaar enige vorm van gegevensverlies hadden weten te voorkomen.

Met goede logging worden chaotische gebeurtenissen omgezet in verhalen die je daadwerkelijk opnieuw kunt afspelen.

De kloof tussen ‘we hebben logs’ en ‘we hebben bewijs’

De kloof tussen logs en bewijs ontstaat wanneer u ruwe gebeurtenissen niet kunt omzetten in een duidelijke, verdedigbare incidenttijdlijn voor auditors. Het gaat hen minder om het feit dat tools logs kunnen genereren, en meer om de vraag of u kunt aantonen wie wat, wanneer, waar en met welk resultaat heeft gedaan in uw MSP-tooling en klantomgevingen.

Bij veel MSP's leiden deze vragen tot een chaos tussen RMM-dashboards, firewallconsoles, e-mailbeveiligingsportals, cloudbeheercentra en ticketsystemen. Tijdstempels kloppen niet omdat apparaten zich in verschillende tijdzones bevinden of een afwijkende klok hebben. Beheerdersacties zijn verborgen in obscure audit trails. Sommige kritieke wijzigingen zijn alleen zichtbaar in e-mail- of chatgesprekken. Afzonderlijk lijken alle tools "prima"; samen leveren ze niet het coherente verhaal op dat ISO 27001 verwacht onder A.8.15.

Een ander veelvoorkomend patroon is dat logs slechts toegankelijk zijn voor een klein aantal senior engineers. Deze mensen kunnen vaak vragen uit hun hoofd beantwoorden, maar dat is geen vervanging voor objectief, fraudebestendig bewijs. Als een van hen morgen zou vertrekken, zou het moeilijk zijn om hetzelfde verhaal opnieuw te spelen op basis van alleen data. Vanuit het oogpunt van een auditor suggereert dit dat uw organisatie vertrouwt op individuen in plaats van op een ontworpen controle.

Hoe auditors daadwerkelijk naar uw loggingcontrole kijken

Auditors gaan uit van de controleverklaring, niet van de lijst met functies van uw SIEM-leveranciers. Ze zijn geïnteresseerd in hoe logging detectie, onderzoek en assurance ondersteunt. Ze willen zien dat logs van activiteiten, uitzonderingen, fouten en andere relevante gebeurtenissen op een geplande manier worden gegenereerd, opgeslagen, beschermd en geanalyseerd, in lijn met uw beoogde doel.

In de praktijk zoeken ze eerst naar de schriftelijke intentie: beleid, loggingstandaarden en verantwoordelijkheidsmatrices die aangeven wat er moet worden gelogd, waar, door wie en hoe lang. Vervolgens vergelijken ze die intentie met hoe uw omgeving zich nu gedraagt. Als in uw documentatie staat dat alle geprivilegieerde acties op klantsystemen minstens een jaar lang centraal worden gelogd, testen ze die bewering op één of twee klanten en één of twee systemen.

Waar uw documenten en de werkelijkheid uiteenlopen, ontstaan er non-conformiteiten. Als standaardtools retentie voorschrijven, maar uw contracten jarenlange traceerbaarheid beloven, zullen auditors de kloof opmerken. Als u vertrouwt op screenshots of spreadsheets omdat logs moeilijk te raadplegen zijn of verwijderd zijn, zullen ze de effectiviteit van A.8.15 in twijfel trekken. Dit is vaak het moment waarop MSP's zich realiseren dat ze geen logarchitectuur hebben; ze hebben een berg tools. De rest van deze handleiding richt zich op het dichten van die kloof met een ontwerp dat u kunt uitleggen en bewijs dat u kunt verdedigen.

Demo boeken

Wat ISO 27001:2022 A.8.15 Logging eigenlijk vereist

ISO 27001 A.8.15 verwacht dat u logging ontwerpt zodat u incidenten kunt detecteren, onderzoeken en aantonen wat er is gebeurd op een manier die aansluit bij uw risico's en diensten. Onafhankelijke uitleg over de herziening van 2022, zoals praktische commentaren op A.8.15 van ISO 27001-specialisten, herformuleert de beheersmaatregel in zeer vergelijkbare bewoordingen, met de nadruk op logging die tijdige detectie, onderzoek en bewijsreconstructie ondersteunt, afgestemd op het risicoprofiel en de scope van de dienstverlening van de organisatie. Dit is met name belangrijk wanneer u als MSP opereert met gedeelde tools en multi-tenant verantwoordelijkheden.

Voor een MSP moet dat ontwerp zowel uw interne systemen als de gedeelde of beheerde componenten van klantomgevingen omvatten, niet alleen uw eigen kantoornetwerk. Het gaat om het bouwen van een functionaliteit die u kunt beschrijven en herhalen, niet alleen om het inschakelen van standaardinstellingen.

De controle in duidelijke taal

Simpel gezegd vereist A.8.15 dat u kiest wat u wilt loggen, dit op een betrouwbare manier registreert, het beschermt en het daadwerkelijk controleert. Al het andere in de controle vloeit voort uit deze vier ideeën. Als u zich op die beslissingen concentreert, worden de technische details gemakkelijker te beheren. Voor MSP's betekent dit dat dezelfde discipline moet worden toegepast op gedeelde tools, interne systemen en klantomgevingen.

Ten eerste moet u bepalen welke activiteiten, uitzonderingen, fouten en gebeurtenissen van belang zijn voor de beveiliging en de bedrijfsvoering. Ten tweede moeten deze gebeurtenissen daadwerkelijk worden vastgelegd in de relevante systemen en services. Ten derde moeten logs worden opgeslagen en beschermd, zodat ze niet onopgemerkt kunnen worden gewijzigd of verloren gaan. Ten vierde moeten deze logs worden geanalyseerd en beoordeeld, zodat ze bijdragen aan monitoring en onderzoek.

Voor een MSP omvatten "relevante gebeurtenissen" duidelijk meer dan alleen traditionele serverlogs. Externe scripts die via uw RMM worden uitgevoerd, beleidswijzigingen op gedeelde firewalls, aanmeldingen bij cloudbeheerportals, wijzigingen in privileged groups in uw identiteitsplatform en acties in uw ticketsysteem kunnen allemaal een wezenlijke impact hebben op de beveiliging van klanten. Een risicobeoordeling moet bepalen welke hiervan binnen de scope vallen, maar zodra ze binnen de scope vallen, moeten ze op een consistente, vindbare en bruikbare manier worden geregistreerd.

De controle gaat er ook van uit dat logging doelgericht is, niet opportunistisch. Het is niet voldoende om te zeggen "de tool kan dat loggen als we hem aanzetten". Er wordt van u verwacht dat u laat zien dat u hebt gekozen wat u wilt loggen, hoe u het configureert en hoe u het afstemt op veranderingen in uw diensten, klanten en technologiestack. Daarom maakt A.8.15 deel uit van het bredere managementsysteem: het moet terugverwijzen naar risico's, doelstellingen, beleid en continue verbetering.

Hoe A.8.15 verbinding maakt met de rest van uw ISMS

Logging staat niet op zichzelf. A.8.16, dat betrekking heeft op monitoringactiviteiten, beschrijft hoe u logs beoordeelt en ernaar handelt. In algemene beschrijvingen van ISO/IEC 27001 wordt A.8.16 consequent gepresenteerd als de controle die zich richt op het bewaken en beoordelen van beveiligingsgebeurtenissen en logs. Daarom wordt het in de meeste implementaties vanzelfsprekend gecombineerd met A.8.15.

Uit het rapport 'State of Information Security 2025' blijkt dat klanten steeds vaker verwachten dat leveranciers zich houden aan formele kaders zoals ISO 27001, ISO 27701, AVG of SOC 2, in plaats van dat ze vertrouwen op algemene claims over goede praktijken.

Controlemechanismen voor toegangsbeheer, incidentafhandeling, bedrijfscontinuïteit en privacy stellen specifieke eisen aan uw loggingontwerp. Auditors letten op deze verbanden wanneer ze bepalen of uw A.8.15-implementatie effectief is.

Het kan helpen om in termen van gekoppelde controlefamilies te denken:

Toegangsbeheerfuncties vereisen logboeken die laten zien wie toegang heeft gehad tot wat en met welke rechten.
Incidentmanagementmaatregelen zijn afhankelijk van logboeken om gebeurtenissen te reconstrueren en geleerde lessen te ondersteunen.
Voor bedrijfscontinuïteitsmaatregelen zijn logboeken nodig die inzicht geven in de faalmodi en het herstel.
Privacycontroles vereisen dat logs met persoonsgegevens worden geminimaliseerd, beschermd en alleen zo lang als nodig worden bewaard. Dit komt overeen met kernbeginselen voor gegevensbescherming, zoals dataminimalisatie en opslagbeperking in regelgeving zoals de AVG. Deze regelgeving vereist dat organisaties het verzamelen van onnodige persoonsgegevens in logs vermijden en deze verwijderen zodra ze niet langer nodig zijn voor de genoemde doeleinden.

Samen betekenen deze verwachtingen dat uw loggingarchitectuur meerdere doelen tegelijk moet dienen, niet alleen beveiligingsactiviteiten. Hier is een gestructureerd systeem voor informatiebeveiligingsbeheer cruciaal. Een platform zoals ISMS.online kan u helpen om op één plek te laten zien hoe A.8.15 aansluit bij uw risicobeheer, uw verklaring van toepasselijkheid en uw andere controlemaatregelen. U kunt definiëren welke gebeurtenistypen beveiligingsrelevant zijn, deze koppelen aan systemen en services, en vastleggen wie verantwoordelijk is voor de beoordeling ervan en met welke frequentie. Veel MSP's documenteren A.8.15-beslissingen nu samen met risico's en de verklaring van toepasselijkheid in dit soort gestructureerde ISMS, omdat het auditors een duidelijk en consistent beeld geeft.

Door logbeslissingen te koppelen aan risicoverklaringen en doelstellingen, kunt u auditors uitleggen waarom bepaalde logbronnen of bewaartermijnen zijn gekozen, in plaats van dat het lijkt alsof u simpelweg de standaardinstellingen van leveranciers hebt overgenomen. Wanneer uw services evolueren, kunt u het ontwerp centraal bijwerken en wijzigingen doorvoeren in procedures en servicebeschrijvingen. Dat is het verschil tussen A.8.15 als een clausule op papier behandelen en het behandelen als een ontwerpdiscipline die uw omgeving beter verdedigbaar maakt.

ISMS.online geeft u een voorsprong van 81% vanaf het moment dat u inlogt

ISO 27001 eenvoudig gemaakt

Wij hebben het harde werk voor u gedaan, waardoor u vanaf het moment dat u inlogt een voorsprong van 81% heeft. U hoeft alleen nog maar de lege plekken in te vullen.

Start

De MSP-loggingkloof: single-tenant-theorie versus multi-tenant-realiteit

De meeste algemene adviezen voor logging gaan ervan uit dat één organisatie al haar systemen beheert, met één beveiligingsteam en één groep stakeholders. MSP's werken anders: u beheert gedeelde platforms zoals RMM, SOC-tools en cloudbeheerconsoles voor meerdere klanten, en u levert diensten waarbij het eigendom van logs wordt gedeeld tussen u en die klanten. Dat verschil heeft grote gevolgen voor de implementatie en uitleg van A.8.15.

Gedeelde tools en cross-tenant risico

Gedeelde MSP-tools vormen de kern van uw service en uw risico. Centrale firewalls, VPN-concentrators, identiteitsproviders en beheerplatforms waarmee engineers toegang krijgen tot meerdere klantomgevingen genereren vaak uitgebreide logs, maar ze brengen ook een risico met zich mee: als gegevens van de ene klant zichtbaar zijn terwijl de case van een andere klant op het scherm staat, is er sprake van cross-tenant exposure.

Een multi-tenant SIEM of logmanagementplatform dat gebruikmaakt van gedeelde indices of wachtrijen kan dit verergeren. Als gebeurtenissen alleen worden getagd met een losjes afgedwongen klant-ID, kan een verkeerde configuratie of een fout in de invoer ervoor zorgen dat gebeurtenissen in de verkeerde weergave worden weergegeven. Discussies over multi-tenant loggingarchitecturen en gedeelde SIEM-implementaties benadrukken dit risico vaak: zwakke of inconsistent toegepaste tenant-ID's kunnen ertoe leiden dat verkeerd getagde gebeurtenissen telemetrie tussen tenants lekken op manieren die moeilijk snel te ontdekken zijn.

De meeste organisaties die deelnamen aan het ISMS.online-onderzoek van 2025 gaven aan dat ze in het afgelopen jaar te maken hadden gehad met minimaal één beveiligingsincident gerelateerd aan een derde partij of leverancier.

Vanuit ISO 27001-perspectief ondermijnt dat de vertrouwelijkheid. Contractueel gezien kan het verplichtingen schenden. Vanuit logging-perspectief betekent dit dat uw architectuur geen rekening heeft gehouden met tenancy als ontwerpdimensie. Richtlijnen voor logging en monitoring in gedeelde cloudomgevingen, waaronder werk van communities zoals de Cloud Security Alliance, beschouwen blootstelling van logs tussen tenants als een inbreuk op de vertrouwelijkheid en een mogelijke schending van contractuele of wettelijke verplichtingen.

Tegelijkertijd kunnen klanten ervan uitgaan dat u een volledige kopie van al hun logs bewaart, simpelweg omdat u een beheerde service levert. In werkelijkheid bewaart u mogelijk alleen samenvattingen of waarschuwingen van hun systemen, terwijl de onbewerkte logs in hun eigen cloudabonnementen of datacenters blijven. Als die eigendomsverdeling niet duidelijk is, raken de verwachtingen en verantwoordelijkheden rond A.8.15 in de war en wordt uw positie in een geschil of onderzoek moeilijker te verdedigen.

Om te voldoen aan A.8.15 in een MSP-context, moet u heel duidelijk zijn wie welke logs bezit, wie er toegang toe heeft en met welk doel. Voor elk serviceaanbod moet u kunnen beantwoorden: welke systemen logs genereren, waar die logs worden opgeslagen, wie beheerders- en leesrechten heeft, hoe ze worden geback-upt en bewaard, en hoe ze worden gebruikt voor monitoring en incidentafhandeling.

Ongeveer 41% van de respondenten gaf aan dat het beheren van risico's van derden en het bijhouden van de naleving door leveranciers de grootste uitdagingen op het gebied van informatiebeveiliging vormen.

Deze duidelijkheid moet tot uiting komen in uw contracten en servicebeschrijvingen. Als u bijvoorbeeld een beheerde firewallservice aanbiedt, houdt u dan gedetailleerde verkeerslogs bij, alleen beveiligingsgebeurtenissen of alleen maandelijkse overzichten? Als een klant onbewerkte logs voor zijn eigen SIEM wil, valt dat dan expliciet binnen de scope? Wanneer ze zes maanden na de incidentmelding om een incidentrapport vragen, welke logbronnen gebruikt u dan betrouwbaar?

Toezichthouders en zakelijke klanten verwachten steeds vaker dat u architectuurdiagrammen of schriftelijke beschrijvingen van uw logging- en monitoringontwerp toont, vooral als u kritieke sectoren of grensoverschrijdende gegevensstromen bedient. Beleidsdocumenten over cyberbeveiliging voor kritieke infrastructuur en clouddiensten, met name in de Europese context, benadrukken de noodzaak van gedocumenteerde architecturen en duidelijke verantwoordelijkheden voor logging en monitoring als onderdeel van het aantonen van operationele veerkracht en transparantie. Als u deze niet tijdig kunt produceren, suggereert dit dat logging voortkomt uit toolconfiguraties in plaats van uit een doelbewuste, multi-tenant architectuur. In het volgende gedeelte wordt een eenvoudig stackmodel geïntroduceerd dat u helpt bij de overstap van ad-hocpraktijken naar een gestructureerd ontwerp dat standhoudt in audits en onderzoeken.

De A.8.15 MSP Logging Stack: een 4-laags architectuur

Een praktische manier om logging voor een MSP te ontwerpen, is door in vier lagen te denken: verzameling, verwerking en normalisatie, opslag en beveiliging, en toegang en gebruik. Elke laag heeft zijn eigen risico's, controles en bewijs, en elke laag moet in een multi-tenant context werken. Wanneer u deze lagen duidelijk kunt uitleggen, hebben auditors en klanten meer vertrouwen in uw ontwerp.

Collectie: – hoe gebeurtenissen systemen verlaten en uw loggingplatform bereiken.
Verwerking en normalisatie: – hoe u loggegevens parseert, verrijkt en routeert.
Opslag en bescherming: – hoe u logs veilig en met integriteit en back-ups bewaart.
Toegang en gebruik: – hoe mensen logs raadplegen, beoordelen en ernaar handelen.

De vier lagen in de praktijk

De verzamellaag beschrijft hoe gebeurtenissen systemen verlaten en uw loggingplatform bereiken. Voor MSP's kunnen dit agents op servers en eindpunten, connectoren op cloudservices, syslogstreams van netwerkapparaten en API-integraties voor RMM- en PSA-tools zijn. De belangrijkste vragen zijn of alle systemen in de scope geconfigureerd zijn om de juiste gebeurtenissen te verzenden en of die verbindingen veilig en betrouwbaar zijn.

Verwerking en normalisatie omvatten het parsen, verrijken en routeren van logs zodra ze binnenkomen. U kunt bijvoorbeeld tenant-ID's toevoegen, gebruikersnamen over systemen heen normaliseren, leverancierspecifieke velden in een gemeenschappelijk schema in kaart brengen en ruis filteren. Deze beslissingen bepalen hoe gemakkelijk het is om te zoeken naar "wat heeft deze engineer gisteren voor alle clients gedaan" of "toon me alle mislukte admin-aanmeldingen op risicovolle systemen in de afgelopen week".

Opslag en beveiliging gaan over waar logs worden bewaard, hoe ze worden beschermd tegen manipulatie en verlies, en hoe de retentie wordt afgedwongen. U moet datastores, back-upstrategieën, integriteitscontroles zoals alleen-toevoegen-opslag of hashing, en tieringschema's voor actuele en actuele data kiezen. Tot slot omvatten toegang en gebruik rollen, machtigingen, dashboards, waarschuwingen, onderzoeken en rapportage. Dit is waar A.8.15 en A.8.16 samenkomen: het genereren van logs is niet voldoende als niemand ze efficiënt kan bekijken en ernaar kan handelen.

De stack omzetten in MSP-serviceblauwdrukken

Zodra de vier lagen voor uw omgeving zijn gedefinieerd, kunt u ze service voor service toepassen om herhaalbare logging-blueprints te creëren. Voor een beheerde service bepaalt u zelf hoe gebeurtenissen worden verzameld, verrijkt, opgeslagen en benaderd voordat u zich druk maakt over de instellingen van individuele leveranciers. Deze volgorde maakt het gemakkelijker om uw aanpak consistent uit te leggen aan klanten.

Neem bijvoorbeeld een beheerde firewall. Bij het verzamelen activeert u gedetailleerde beveiligings- en beheerlogboeken en stuurt u deze veilig door naar uw centrale platform. Bij het verwerken tagt u gebeurtenissen met klant-ID's en normaliseert u regel- en interfacenamen. Bij het opslaan bewaart u beveiligingsgebeurtenissen gedurende een overeengekomen periode in doorzoekbare opslag en archiveert u onbewerkte logs indien nodig langer. Bij toegang en gebruik ziet uw SOC multi-tenant dashboards, terwijl klanten hun eigen subset bekijken via rapporten of portals.

Hetzelfde patroon kan worden toegepast op beheerd Microsoft 365, endpoint security, identiteitsservices en andere diensten. Voor elk legt u in uw ISMS vast welke lagen er van toepassing zijn, welke controles er worden toegepast en hoe bewijs wordt verzameld. Dit maakt het veel gemakkelijker om nieuwe klanten te onboarden, uw ontwerp toe te lichten in aanbestedingen en conformiteit met A.8.15 aan te tonen tijdens audits.

Stap 1 – Beschrijf de service scope

Definieer welke systemen, gedeelde platforms en klantcomponenten de service bestrijkt, inclusief eventuele regio's, tenants of beperkingen met betrekking tot gegevensresidentie.

Stap 2 – Leg elke loglaag vast

Voor deze service legt u vast hoe u gebeurtenissen verzamelt, verwerkt en normaliseert, opslaat en beveiligt en mensen toegang verleent voor monitoring en onderzoek.

Stap 3 – Koppel lagen aan controles en bewijsmateriaal

Koppel elke laag aan specifieke ISO 27001-controles, -verantwoordelijkheden, -procedures en -registraties, zodat u auditors precies kunt laten zien hoe de stack in de praktijk werkt.

Deze gestructureerde aanpak maakt vragen over veerkracht ook concreter. Als incassobureaus falen, hoe worden logs dan gebufferd? Hoe voorkom je stille hiaten als de logopslag van een regio niet beschikbaar is? Hoe handhaaf je de minimale logging- en bewaarplicht als je SIEM down is? Door je logging als een stack te behandelen, kun je expliciet op deze scenario's anticiperen in plaats van zwakke plekken pas te ontdekken wanneer er iets misgaat.

Integreer, breid uit en schaal uw compliance, zonder rommel. IO geeft u de veerkracht en het vertrouwen om veilig te groeien.

Boek uw demo

Ontwerpen van multi-tenant verzameling, aggregatie, opslag en toegang

Met de stack in gedachten kunt u nu de unieke multi-tenant aspecten van MSP-logging aanpakken: het gescheiden houden van klantgegevens, het respecteren van regionale grenzen en het afstemmen van het technologieontwerp op contracten en privacyverplichtingen. Deze beslissingen hebben een directe impact op de geloofwaardigheid van uw A.8.15-implementatie voor auditors, klanten en toezichthouders.

Verzamelen en aggregeren in een multi-tenantwereld

In een omgeving met één organisatie kunt u alle systemen eenvoudigweg naar één centrale logcollector verwijzen. In een MSP moet u ook rekening houden met welke klanten collectors delen, via welke regio's gegevens stromen en hoe u tenant-ID's tagt en verifieert bij inkomende events. Een verstandig uitgangspunt is het definiëren van standaard verzamelpatronen per service en per regio.

U kunt bijvoorbeeld regiospecifieke ingestie-eindpunten gebruiken, zodat de logs van Europese klanten de regio niet verlaten, tenzij expliciet overeengekomen. U kunt vereisen dat elk logbericht een tenant-ID bevat, die aan de edge wordt gevalideerd voordat deze wordt geaccepteerd. U kunt bijzonder gevoelige klanten isoleren in hun eigen pipelines. Deze beslissingen helpen onbedoelde vermenging van gegevens te voorkomen en ondersteunen dataresidentieverplichtingen.

Aggregatie en normalisatie moeten vervolgens diezelfde grenzen respecteren. Wanneer u logs samenvoegt voor correlatie, aggregeert u dan over alle klanten of alleen binnen gedefinieerde groepen? Kan een query ooit klanten omvatten zonder expliciete toestemming? Als uw SOC wereldwijde detectiecontent gebruikt, hoe zorgt u er dan voor dat de resultaten die analisten zien, binnen de scope van hun goedkeuring vallen?

Een paar vragen kunnen uw ontwerp verankeren:

Welke diensten maken gebruik van gedeelde verzamelaars en waar bevinden deze verzamelaars zich?
Hoe valideer je tenant-ID's bij opname?
Onder welke voorwaarden kunnen vragen of waarschuwingen betrekking hebben op meerdere klanten?

Duidelijke, gedocumenteerde antwoorden op deze vragen zijn essentieel om te voldoen aan zowel A.8.15 als uw vertrouwelijkheidsverplichtingen. Bovendien bieden ze u een verdedigbaar verhaal als een toezichthouder of klant onderzoek doet naar de werking van uw multi-tenant logging.

Opslag, toegangscontrole en privacy

Aan de opslagkant omvatten multi-tenant ontwerpbeslissingen de keuze tussen gedeelde indexen met sterke logische scheiding of aparte datastores per klant. Gedeelde opslag kan efficiënter zijn, maar vereist strenge richtlijnen voor indexering, query's en export. Aparte opslag kan eenvoudiger te overdenken zijn, maar dit brengt extra infrastructuur met zich mee. Hoe dan ook, u moet kunnen aantonen hoe u voorkomt dat de gegevens van de ene klant worden opgehaald in de context van een andere klant.

Toegangscontrole moet uw servicemodel weerspiegelen. SOC-analisten hebben mogelijk leestoegang nodig voor meerdere tenants, maar slechts een zeer kleine groep zou beheerdersrechten moeten hebben om loggingconfiguraties of retentie te wijzigen. Klantmedewerkers zouden alleen hun eigen logs moeten zien, waarbij rollen verder worden beperkt door principes van minimale privileges. Alle toegang tot het loggingplatform zelf zou moeten worden geregistreerd en beoordeeld, met name voor gevoelige acties zoals het wijzigen van retentie-instellingen of het verwijderen van gegevens.

Privacy voegt een extra dimensie toe. Logs bevatten vaak persoonsgegevens zoals gebruikersnamen, IP-adressen, apparaat-ID's en, in sommige gevallen, interactie-inhoud. U moet bepalen welke velden noodzakelijk zijn voor beveiligings- en operationele doeleinden, en waar anonimisering, pseudonimisering of aggregatie gepast zijn. U moet er ook voor zorgen dat de bewaartermijnen en de locatie van de gegevens in overeenstemming zijn met de privacywetgeving en -overeenkomsten. Deze keuzes moeten worden vastgelegd, zodat uw A.8.15-ontwerp compatibel blijft met uw privacymaatregelen en u uw aanpak kunt verdedigen als deze wordt aangevochten.

Wat u moet loggen: onmisbare versus handige MSP-logbronnen

Geen enkele MSP kan of mag alles loggen. De kunst is om een verdedigbare minimale set logbronnen te selecteren waarmee u zinvolle incidenten kunt detecteren en onderzoeken, en vervolgens verdere bronnen toe te voegen waar risico en budget dit rechtvaardigen. ISO 27001 verwacht dat dit risicogebaseerd en gedocumenteerd is, en auditors vragen zich vaak af waarom bepaalde bronnen voorrang hebben gekregen boven andere.

Onmisbare logbronnen voor MSP's

Sommige logbronnen zijn extreem moeilijk te rechtvaardigen om weg te laten uit uw A.8.15-implementatie. Een simpele mentale test is om u een ernstig incident voor te stellen en u af te vragen of u geloofwaardig zou kunnen reconstrueren wat er is gebeurd zonder die logs. Zo nee, dan hoort die bron waarschijnlijk thuis in uw basisontwerp. Praktische A.8.15-implementatiehandleidingen van ISO 27001-adviesbureaus benadrukken vaak dat identiteitssystemen, boundary controls, essentiële beveiligingstools en beheerdersjumphosts tot deze basisset behoren voor een geloofwaardige certificeringsinspanning.

Tot de belangrijkste categorieën behoren doorgaans:

Identiteits- en toegangssystemen: – directory's, single sign-on en multi-factor providers.
Netwerk- en grenscontroles: – firewalls, VPN-gateways en inbraakbeveiligingstools.
Beveiligingstools: – eindpunt-, e-mail- en webbeveiligingsplatformen.
Beheerdershulpmiddelen en jumphosts: – RMM, privileged access tools, bastions en cloudconsoles.
Kern serviceplatforms: – beheerde cloudsuites, belangrijke applicaties en ticketing- of PSA-systemen.

Identiteits- en toegangssystemen staan bovenaan die lijst. Zonder logging van directory services, single sign-on providers en multifactorauthenticatieplatforms kunt u niet betrouwbaar zien wie zich heeft aangemeld, vanaf waar en met welk privilegeniveau.

Netwerk- en grenscontroles zijn een andere onmisbare categorie: firewalls, VPN-gateways, beveiligde webgateways en systemen voor inbraakdetectie of -preventie. Deze logs laten zien welk verkeer is toegestaan of geblokkeerd, welke verbindingen afkomstig zijn van ongebruikelijke locaties en wanneer regels of beleid zijn gewijzigd. Beveiligingstools zoals endpoint protection, e-mailbeveiliging en webfilters bieden waardevolle informatie over bedreigingen en de bijbehorende reacties.

Beheertools en jump hosts die door uw engineers worden gebruikt, verdienen speciale aandacht. Acties die worden uitgevoerd via RMM-platforms, tools voor privileged access management, bastionhosts en cloudbeheerconsoles moeten gedetailleerd worden vastgelegd om te laten zien welke acties op welke systemen en onder welke identiteit zijn uitgevoerd. Tot slot bieden belangrijke serviceplatforms zoals gehoste Microsoft 365, de kernapplicaties die u beheert en uw ticketing- of PSA-systeem belangrijke context over wijzigingen en klantinteracties.

Als een van deze categorieën ontbreekt, zult u moeite hebben met het beantwoorden van basisvragen tijdens incidenten en audits. Uit commentaar in de sector op incidentrespons en inbreukonderzoeken blijkt regelmatig dat het ontbreken van identiteits-, netwerk- of beveiligingstoollogs het zeer moeilijk maakt om gebeurtenissen te reconstrueren en gedetailleerde vragen van onderzoekers of auditors te beantwoorden. Door deze categorieën verplicht te stellen in uw A.8.15-ontwerp, creëert u een solide basis en zijn verdere verbeteringen gemakkelijker te rechtvaardigen.

Handige bronnen en wanneer je ze moet toevoegen

Naast de essentiële logs zijn er veel logbronnen die waarde kunnen toevoegen, maar die niet in alle gevallen gerechtvaardigd zijn. Generieke applicatielogs van desktopsoftware, gedetailleerde debuglogs van ontwikkelomgevingen en uitgebreide statistieken van systemen met een laag risico kunnen snel opslag- en analysetijd in beslag nemen zonder uw vermogen om incidenten te detecteren of te onderzoeken significant te verbeteren.

Dat betekent niet dat ze altijd buiten het bereik vallen. Voor klanten met een hoog risico, maatwerkapplicaties of gereguleerde workloads kunt u besluiten dat aanvullende logging noodzakelijk is. De sleutel is om die reden vast te leggen in uw risicobeoordeling en verklaring van toepasbaarheid, en om verzameling en retentie bewust in te stellen in plaats van sporadisch.

Een nuttige techniek is het definiëren van logbronniveaus in uw servicecatalogus. Een basisniveau kan alle onmisbare bronnen bevatten en geschikt zijn voor standaardklanten. Hogere niveaus kunnen applicatiespecifieke logs, gedetailleerdere audit trails of langere bewaartermijnen toevoegen. Elk niveau moet niet alleen de hoeveelheid data beschrijven, maar ook de detectiedekking en onderzoeksdiepte die het mogelijk maakt. Zo kunnen sales, operations en klanten begrijpen wat ze winnen naarmate ze hogerop komen.

Een kleine vergelijkingstabel kan uw team helpen pragmatisch over bronnen na te denken:

rij	Typische bronnen	Primair doel
Kern (must-have)	Identiteit, firewalls, VPN, EDR, RMM, beheertools	Detectie en basisforensisch onderzoek
Verbeterde	Belangrijke applicatielogboeken, cloudworkloadlogboeken	Diepere analyse van de grondoorzaak
Specialist	Debug-logs, niche-systeemlogs	Zeldzame, complexe of gereguleerde gevallen

Dit is slechts ter illustratie; uw daadwerkelijke niveaus en bronnen moeten uw eigen risicoprofiel en diensten volgen. Het belangrijkste is dat A.8.15 een gestructureerde set keuzes wordt in plaats van een impliciet neveneffect van de systemen waarvoor logging is ingeschakeld. Wanneer u deze keuzes kunt uitleggen, worden ze veel gemakkelijker te verdedigen tegenover auditors, klanten en toezichthouders.

ISMS.online ondersteunt meer dan 100 normen en voorschriften, waardoor u één platform krijgt voor al uw compliancebehoeften.

Boek uw demo

Hoe lang bewaren: een risicogebaseerd retentiemodel voor MSP's

Het kiezen van bewaartermijnen is een van de meest gevoelige onderdelen van A.8.15 voor een MSP. U weegt de verwachtingen van de regelgeving, de behoeften aan incidentonderzoek, privacyregels en opslagkosten af, en uw keuzes worden beoordeeld op hoe risicogebaseerd en verdedigbaar ze zijn. Zowel klanten als auditors zullen deze beslissingen nauwlettend volgen tijdens reviews.

Het ontwerpen van een gelaagd retentiemodel

Een praktische manier om retentie aan te pakken, is door logs in klassen te groeperen en niveaus toe te wijzen. U kunt bijvoorbeeld beveiligings- en beheerlogs als één klasse behandelen, klantenservice- en ticketlogs als een andere en technische logs met een lage waarde als een derde. Voor elke klasse bepaalt u hoe lang gegevens snel doorzoekbaar moeten zijn, hoe lang ze beschikbaar moeten blijven in tragere of gearchiveerde vorm en wanneer ze moeten worden verwijderd of geanonimiseerd.

Om die beslissingen te nemen, moet u terugwerken vanuit uw risico's en verplichtingen. Denk na over hoe lang aanvallen doorgaans onopgemerkt blijven bij uw klantenbestand, hoe lang onderzoeken en juridische procedures doorgaans duren en wat toezichthouders of contracten verwachten. Als uw klanten actief zijn in sectoren waar incidenten soms pas vele maanden na de eerste inbreuk aan het licht komen, zijn zeer korte bewaartermijnen moeilijk te verdedigen. De richtlijnen van cloudproviders voor het bewaren van logs bevelen doorgaans een vergelijkbaar patroon aan, waarbij waardevolle logs een tijdje actief en doorzoekbaar worden gehouden en vervolgens worden verplaatst naar goedkopere archiefopslag die nog steeds kan worden teruggehaald voor onderzoek of compliance-vragen.

Een veelvoorkomend patroon is om logs met een hoge waarde (identiteit, beveiliging, beheeracties) enkele maanden actief en doorzoekbaar te houden, en ze vervolgens te verplaatsen naar goedkopere opslag, waar ze een tot enkele jaren toegankelijk blijven. Logs met een lagere waarde hebben mogelijk een veel kortere bewaartermijn. Welke gegevens u ook kiest, documenteer hoe ze zijn verkregen, welke risico's ze aanpakken en wie ze heeft goedgekeurd. Dat maakt gesprekken met auditors, klanten en privacy officers veel eenvoudiger.

Stap 1 – Classificeer logtypen

Groepslogboeken worden ingedeeld in duidelijke categorieën, zoals beveiliging en beheer, klantenservice en ticketing, en technische of diagnostische gegevens met een lage waarde.

Stap 2 – Beslis over hot- versus archive-retentie

Bepaal voor elke klasse hoe lang de gegevens snel doorzoekbaar moeten blijven en hoe lang ze in tragere of gearchiveerde opslag moeten blijven.

Stap 3 – Documenteer de onderbouwing en goedkeuringen

Leg vast waarom u voor elke bewaartermijn hebt gekozen, welke risico's of verplichtingen hiermee worden aangepakt en wie hiervoor toestemming heeft gegeven. Zo kunt u dit tijdens audits toelichten.

Evenwicht tussen regelgeving, onderzoek en kosten

Retentie is niet alleen een technische of compliancebeslissing, maar ook een commerciële. Langere retentie betekent meer opslag, back-ups en indexering, wat uw marges kan beïnvloeden als de prijs niet goed is. Korte retentie kan nu geld besparen, maar verhoogt het risico dat u later geen onderzoek kunt ondersteunen of geen due diligence kunt aantonen.

Een ruime meerderheid van de organisaties in het rapport 'State of Information Security 2025' gaf aan dat de snelheid en omvang van de veranderingen in de regelgeving het moeilijker maken om aan de regelgeving te voldoen.

Uw servicecatalogus moet daarom retentie zichtbaar maken. Vermeld voor elk logniveau of servicepakket welke logklassen hoe lang en in welke vorm bewaard worden. Zo kunnen klanten kiezen op basis van hun risicobereidheid en regelgevingsprofiel. Het geeft uw financiële en operationele teams ook een duidelijker beeld van de kostenimplicaties van elke optie.

Privacyregels voegen daar nog een extra laag aan toe. Veel rechtsgebieden vereisen dat persoonsgegevens niet langer worden bewaard dan noodzakelijk is voor de doeleinden waarvoor ze zijn verzameld. Dit weerspiegelt principes zoals de beperking van de opslag in wetgeving inzake gegevensbescherming zoals de AVG, die expliciet stellen dat persoonsgegevens niet voor onbepaalde tijd mogen worden bewaard en moeten worden gewist of geanonimiseerd zodra ze niet langer nodig zijn voor de oorspronkelijk gedefinieerde doeleinden.

Dat kan ongemakkelijk zijn bij de wens om beveiligingslogs jarenlang te bewaren. Technieken zoals het pseudonimiseren van bepaalde velden na een bepaalde periode, het samenvoegen van gebeurtenissen tot aantallen of het weglaten van velden met een lage waarde kunnen u helpen deze druk te overwinnen.

De belangrijkste test is of uw retentiemodel redelijk en verdedigbaar zou lijken als een toezichthouder, klant of rechtbank u zou vragen het te rechtvaardigen. Als u de balans kunt uitleggen die u hebt gevonden tussen regelgeving, onderzoeksbehoeften, privacy en kosten, en kunt aantonen dat u deze consequent toepast, staat u veel sterker dan wanneer retentie simpelweg "de instelling van de tool is toen we deze installeerden".

Boek vandaag nog een demo met ISMS.online

Met ISMS.online kunt u A.8.15 omzetten van verspreide toolinstellingen naar een beheerde, auditklare controle voor al uw MSP-services, zodat u incidenten en audits kunt aanpakken met een duidelijke, verdedigbare logging-basis. Een goed ontworpen logging-architectuur en retentiemodel leveren alleen hun volledige waarde op als deze is ingebed in uw bredere managementsysteem en afgestemd blijft op de ontwikkeling van uw services.

Waarom structuur belangrijker is dan nog een tool

ISMS.online biedt u een gestructureerde plek om uw loggingontwerp voor al uw MSP-services vast te leggen, in plaats van te vertrouwen op een mix van spreadsheets, slides en individuele kennis. U kunt uw A.8.15-controlintent definiëren, logbronnen in de scope vermelden, uw vierlaagse architectuur beschrijven en vastleggen hoe multi-tenant verzameling, opslag en toegang voor elke aanbieding worden afgehandeld.

U kunt uw retentiestrategie ook expliciet modelleren. Voor elke logklasse en servicelaag documenteert u de overeengekomen bewaartermijnen, de gebruikte opslaglagen en de achterliggende reden. Wanneer auditors vragen waarom een bepaalde set logs gedurende een bepaalde periode wordt bewaard, kunt u verwijzen naar één enkel, beheerd record dat beslissingen koppelt aan risico's, contracten en privacyverplichtingen. Dit vermindert de tijd en stress van de auditvoorbereiding en helpt verrassingen te voorkomen.

Cruciaal is dat ISMS.online is ontworpen om te integreren met uw bestaande operationele tools, en deze niet te vervangen. Uw SIEM, RMM, ticketingplatform en cloudservices blijven de plek waar logging en monitoring plaatsvinden. Het ISMS biedt het raamwerk eromheen: wie is verantwoordelijk, welke procedures zijn van toepassing, hoe worden reviews vastgelegd en hoe worden verbeteringen bijgehouden. Deze scheiding maakt het eenvoudiger om uw tooling te ontwikkelen zonder de controle over uw logging te verliezen.

Wat u wint door uw loggingontwerp te centraliseren

Wanneer u uw A.8.15-aanpak centraliseert in ISMS.online, geeft u iedereen één enkel, gedeeld overzicht van hoe logging en retentie binnen uw MSP werken. Die duidelijkheid maakt verantwoordelijkheden, mogelijke hiaten en ontwerpprioriteiten veel duidelijker, en het wordt eenvoudiger om auditors en klanten te laten zien hoe uw aanpak in de praktijk werkt.

Beveiligingsmanagers kunnen in één oogopslag zien welke services volledig worden gedekt door de vierlaagse stack en waar er nog hiaten zijn. Managing directors kunnen zien hoe logging- en retentiekeuzes aansluiten op de risicobereidheid en commerciële prioriteiten van het bedrijf. Operationeel managers kunnen dagelijkse controles en reviews koppelen aan controles en bewijsmateriaal ordenen, zodat de last van de auditvoorbereiding over het jaar wordt gespreid in plaats van beperkt tot een paar stressvolle weken.

U kunt klein beginnen. Kies één toonaangevende service, zoals een beheerde Microsoft 365-omgeving of beheerde firewalls, en leg de logarchitectuur, logbronnen en retentie-instellingen ervan vast in het platform. Gebruik dit als pilot om inconsistenties, ontbrekende verantwoordelijkheden of ongedocumenteerde aannames te identificeren. Zodra u vertrouwd bent, past u hetzelfde patroon toe op andere services. Na verloop van tijd bouwt u een compleet, controleerbaar beeld op van de logging binnen uw MSP.

Kies ISMS.online wanneer u wilt dat logging en retentie deel uitmaken van een coherent, auditklaar informatiebeveiligingssysteem in plaats van een losse verzameling toolinstellingen. Als u waarde hecht aan snellere, rustigere audits, duidelijkere servicedefinities en de mogelijkheid om klanten en toezichthouders precies te laten zien hoe u voldoet aan A.8.15, is het boeken van een korte demonstratie een verstandige volgende stap. Het zal u helpen zien hoe de ideeën in deze handleiding zich vertalen naar praktische workflows, records en dashboards, afgestemd op MSP's zoals die van u.

Demo boeken

Veelgestelde Vragen / FAQ

Wat verandert ISO 27001 A.8.15 eigenlijk voor de manier waarop uw MSP logging aanpakt?

ISO 27001 A.8.15 verwacht dat uw MSP logging behandelt als een ontworpen controlemiddel dat beveiliging en verantwoording ondersteunt, en niet als een bijproduct van de tools die u gebruikt. In de praktijk betekent dit dat u moet bepalen wat er moet worden gelogd, waar, hoe lang, hoe het wordt beschermd en hoe uw team die records gebruikt om problemen bij alle klanten binnen het bereik te detecteren en te onderzoeken.

Hoe vertaal je A.8.15 naar een eenvoudige, bruikbare logstandaard?

Een werkbare aanpak is om A.8.15 om te zetten in een korte, eenduidige standaard die engineers, analisten en service-eigenaren daadwerkelijk kunnen volgen:

Definieer de omvang – welke klanten, omgevingen en diensten binnen uw ISO 27001-grens vallen.
Specificeren evenementcategorieën die altijd geregistreerd moeten worden, zoals administratieve wijzigingen, authenticatie- en toegangspogingen, beleids- en configuratiewijzigingen en beveiligingswaarschuwingen.
Maak een lijst van de minimale logbronnen per servicetype (bijvoorbeeld identiteit, firewalls/VPN's, EDR, M365, RMM, PSA).
Duidelijk krijgen verwachtingen voor logintegriteit – tijdsynchronisatie, beperkte toegang, onveranderlijkheid of eenmalig beschrijfbare opslag waar mogelijk, en back-upverwachtingen.
Beschrijven operationeel gebruik – wie welke logboeken controleert, hoe vaak, hoe uitzonderingen worden doorgevoerd en waar bevindingen worden vastgelegd.

Die standaard wordt dan het referentiepunt voor elke beheerde service. Wanneer een auditor vraagt hoe uw 'Managed Microsoft 365'- of 'Managed Firewall'-aanbod voldoet aan A.8.15, kunt u het volgende aantonen:

De loggingstandaard in uw ISMS.
Het serviceplan dat elk aanbod afstemt op de standaard.
Bewijs van echte beoordelingen en onderzoeken die verband houden met die diensten.

Door de normen, servicetoewijzingen en operationele registraties vast te leggen in ISMS.online blijft alles traceerbaar en wordt duidelijk dat logging is ingebed in uw informatiebeveiligingsbeheersysteem en niet verspreid is over toolinstellingen en afzonderlijke notitieboekjes.

Hoe kunt u snel testen of uw logging voldoet aan de bedoeling van A.8.15?

Een nuttige interne test is om een recente wijziging of een gebeurtenis die relevant is voor de beveiliging te selecteren en uw team te vragen deze te reconstrueren met behulp van alleen logs:

Wie heeft de handeling uitgevoerd?
Wanneer en waar gebeurde het?
Welke accounts, systemen of tenants zijn getroffen?
Wat was het resultaat en wat deed je team als reactie hierop?

Als u deze vragen met zekerheid kunt beantwoorden met behulp van gedefinieerde logbronnen en reviewprocessen, bent u op de goede weg. Als de antwoorden traag, onvolledig of inconsistent zijn tussen klanten, is dat een duidelijk signaal om uw standaard, dekking of reviewdiscipline aan te scherpen en deze verbeteringen vast te leggen als risico's en acties in ISMS.online, zodat u de voortgang in de loop van de tijd kunt laten zien.

Hoe moet een MSP multi-tenant logging ontwerpen zodat deze veilig, schaalbaar en auditklaar is?

Een praktisch MSP-loggingontwerp bestaat normaal gesproken uit vier lagen: Collectie, verwerking en normalisatie, opslag en beschermingen toegang en gebruikDoor in deze lagen te denken, kunt u klanten overzichtelijk scheiden, voldoen aan regionale gegevensvereisten en auditors een duidelijk verhaal bieden.

Welke ontwerpbeslissingen zijn het belangrijkst op elke laag voor multi-tenant ISO 27001-logging?

Op de verzamellaag, concentreer u op hoe de gebeurtenissen van elke tenant uw loggingplatform bereiken:

Kies per tool of u agents, API's of syslog wilt gebruiken.
Zorg voor regiospecifieke verzamelpunten, zodat logboeken uit de EU, het VK en de VS indien nodig in de regio kunnen blijven.
Zorg voor tijdsynchronisatie zodat tijdlijnen tijdens een onderzoek op elkaar aansluiten.

Op de verwerkings- en normalisatielaag, maak logs bruikbaar en veilig op een gedeeld platform:

Zorg ervoor dat elk record een betrouwbare bron bevat huurder-ID en, indien relevant, omgevings- of servicetags.
Normaliseer kernvelden (gebruiker, bron, doel, actie, resultaat) zodat analisten consistent in alle bronnen kunnen zoeken.
Behandel cross-tenant query's en globale zoekopdrachten als bevoorrechte operaties, met hun eigen toegangsregels en logging.

Op de opslag- en beschermingslaag, ontwerp voor scheiding en integriteit:

Partitioneer de opslag per tenant, regio of beide met behulp van indices, buckets of databases die zijn afgestemd op uw architectuur.
Pas integriteitsmaatregelen toe, zoals alleen-toevoegen-opslag, onveranderlijkheidsvlaggen of hash-chaining, wanneer de hulpmiddelen dit ondersteunen.
Koppel actuele en archiefretentie aan logklassen, contracten en sectornormen, zodat u uw keuzes kunt verdedigen.

Op de toegang tot en gebruik van de laagZorg ervoor dat de dagelijkse werkzaamheden nooit de grenzen met klanten vervagen:

Definieer welke rollen welke tenants kunnen zien. Zorg ervoor dat cross-tenant of globale rollen zeldzaam, gerechtvaardigd en bewaakt zijn.
Structureer waarschuwingswachtrijen, beoordelingen en onderzoeken zodat technici diepgaand binnen een tenant kunnen werken zonder de gegevens van een andere klant bloot te stellen.
Bepaal hoe vaak u samenvattingen, trends of incidenttijdlijnen deelt met klanten en hoe dat aansluit bij uw serviceniveaus.

Door deze beslissingen te documenteren als onderdeel van uw A.8.15-controle en ze vervolgens te koppelen aan concrete configuraties, playbooks en beoordelingsrecords in ISMS.online, verandert multi-tenant logging van iets dat u hoopt dat veilig is in iets dat u kunt beschrijven en verdedigen.

Hoe bewijst u scheiding van huurders aan accountants en grotere klanten?

U maakt de scheiding van huurders veel overtuigender als u een duidelijke grens kunt laten zien beleidsmaatregelen naar architectuur naar toegangscontrole naar echte onderzoeken:

Beleid en normen bepalen dat klantlogboeken logisch of fysiek gescheiden zijn en dat toegang door meerdere tenants strikt wordt beheerd en bewaakt.
Architectuurdiagrammen illustreren hoe dat werkt op het door u gekozen platform, inclusief regionale opslag voor gereguleerde klanten.
Toegangsrecords laten zien welke analisten welke tenantbereiken hebben, wie cross-tenantrollen goedkeurt en hoe deze rollen worden beoordeeld.
Incident- en onderzoekslogboeken laten zien dat uw team diepgaande analyses kan uitvoeren op de gegevens van één gebruiker, zonder dat dit gevolgen heeft voor die van anderen.

Als u deze documenten, registraties en koppelingen in ISMS.online onder A.8.15 beheert, hebt u één plek waar u auditors en klanten door uw verhaal kunt leiden, zonder dat u de ruwe loggegevens of alle details van uw tools blootstelt.

Welke logbronnen moet een MSP als niet-onderhandelbaar beschouwen volgens ISO 27001 A.8.15?

A.8.15 is opzettelijk flexibel en vraagt u om "activiteiten, uitzonderingen en informatiebeveiligingsgebeurtenissen" te loggen in overeenstemming met het risico. Voor managed service providers is er een kernset aan bronnen die bijna altijd binnen het bereik moeten vallen als u betrouwbare onderzoeken en een soepele ISO 27001-audit wilt.

Wat houdt een verstandige MSP-loggingbasislijn doorgaans in?

De meeste MSP-omgevingen profiteren van een basislijn die ten minste vijf categorieën omvat:

Identiteit en toegang: directoryplatforms, SSO, MFA, privileged access management en alle just-in-time beheertools.
Netwerk- en grenscontroles: firewalls, VPN's, beveiligde webgateways, belangrijke routers en omgekeerde proxy's die externe en interne toegang bewaken.
Eindpunt- en werklastbeveiliging: eindpuntbeveiliging of EDR, e-mail- en webbeveiliging en tools voor cloud-workloadbeveiliging.
Beheer- en orkestratiehulpmiddelen: RMM-platforms, hypervisors, cloudbeheerconsoles, jump hosts, bastions en automatiseringspijplijnen die de omgeving van klanten kunnen veranderen.
Kernklantenplatforms en uw eigen servicetools: grote SaaS-systemen zoals Microsoft 365 of Google Workspace, plus PSA- en servicedesksystemen die registreren wat er is gewijzigd en waarom.

Met deze tools kan uw team normaal gesproken de vraag beantwoorden: "Hoe is de aanvaller binnengekomen, wat hebben ze gedaan en welke klanten of systemen zijn getroffen?" Zonder deze tools vervallen zowel de afhandeling van incidenten als de audits al snel in speculatie, wat het vertrouwen in uw beheerde services en uw compliance ondermijnt.

Hoe kunt u logbronnen met een lagere waarde beheren zonder uw beveiligingsniveau te ondermijnen?

Niet elke potentiële logbron rechtvaardigt het verzamelen ervan voor elke klant. Een praktische manier om verspilling te voorkomen en tegelijkertijd verdedigbaar te blijven, is door optionele bronnen te groeperen in waardegebaseerde niveaus:

Logboeken met hoge waarde: die de vroege detectie of context tijdens de meeste incidenten aanzienlijk verbeteren.
Specialistische forensische logs: die vooral nuttig zijn bij complexe, impactvolle zaken.
Logs met een lage waarde of veel ruis: die volume en kosten toevoegen, maar slechts een beperkt onderzoeksvoordeel opleveren.

Vervolgens kunt u deze niveaus afstemmen op uw servicecatalogus:

Basisdiensten omvatten de niet-onderhandelbare bronnen.
Premium- of ‘verbeterde beveiligings’-diensten voegen specifieke, hoogwaardige en forensische niveaus toe.

Door deze niveaus en de op risico's gebaseerde rechtvaardiging voor elk niveau vast te leggen in ISMS.online volgens uw loggingstandaard, kunt u auditors en klanten duidelijk uitleggen waarom de ene service uitgebreidere logging bevat dan de andere. Bovendien kan uw commerciële team logging behandelen als een expliciet onderdeel van elke beheerde service in plaats van als onzichtbare kostenpost.

Hoe moet een MSP het bewaren van logs definiëren en beheren zodat het voldoet aan A.8.15 en de wetgeving inzake gegevensbescherming?

Omdat ISO 27001 geen bewaartermijnen voorschrijft, legt A.8.15 de verantwoordelijkheid bij u om te definiëren en te rechtvaardigen hoe lang u verschillende soorten loggegevens bewaart. Als MSP moet u een evenwicht vinden tussen onderzoeksbehoeften, verwachtingen van klanten en sectoren, contracten en privacyregels voor meerdere tenants en regio's.

Hoe kun je een retentiemodel bouwen dat redelijk en verdedigbaar aanvoelt?

In plaats van de retentie per individuele bron in te stellen, vinden de meeste MSP's het beter beheersbaar om met een handvol te werken. logklassenZoals:

Identiteits- en toegangsactiviteit.
Beveiligingsgebeurtenissen en waarschuwingen.
Administratieve en wijzigingsactiviteiten.
Service- en ticketgegevens.
Technische logs met een lage waarde.

Voor elke klasse kunt u dan het volgende beslissen:

Hoe lang logs doorzoekbaar blijven in uw primaire hulpmiddelen voor detectie en dagelijkse onderzoeken.
Hoe lang ze in archiefopslag blijven vanwege zeldzame, complexe gevallen, juridische beperkingen of contractuele redenen.

Deze periodes moeten gekoppeld zijn aan:

Typische detectie- en onderzoekstijdlijnen voor ernstige aanvallen.
Sectorverwachtingen en regelgevende richtlijnen in de sectoren waarin u actief bent.
Verplichtingen in klantcontracten en, indien relevant, cyberverzekeringspolissen.

Technische logs met een lagere waarde kunnen doorgaans korter worden bewaard om de opslag te beheren en onnodige blootstelling van persoonsgegevens te beperken, terwijl beveiligings- en toegangslogs met een hoge waarde doorgaans een langere bewaartermijn rechtvaardigen.

Hoe vindt u de juiste balans tussen gegevensbewaring en privacyvereisten, en hoe ondersteunt u tegelijkertijd diepgaande onderzoeken?

Bewaartermijnen worden een privacyprobleem wanneer ze worden verlengd, puur omdat opslag goedkoop is. Om zowel aan ISO 27001 als aan gegevensbeschermingsregimes zoals de AVG of CCPA te voldoen, kunt u:

Bepaal welke logklassen persoonsgegevens bevatten en zorg dat u, in risico- en juridische termen, kunt uitleggen waarom die bewaartermijnen ‘niet langer zijn dan noodzakelijk’.
Pas technieken als pseudonimisering of tokenisering toe voor langetermijnarchieven, zodat onderzoekers indien nodig nog steeds aan evenementen kunnen deelnemen zonder dat er duidelijke identificatiegegevens aan elke gebruiker of tool worden prijsgegeven.
Vervang gedetailleerde oudere gegevens door samengevoegde statistieken of samenvattingen wanneer deze niet langer realistisch gezien nodig zijn voor incidentrespons of juridisch bewijs.
Test regelmatig het ophalen en analyseren van gearchiveerde logboeken voor representatieve incidentscenario's. Zo weet u zeker dat uw retentieplan in de praktijk werkt, en niet alleen op papier.

Door uw logboekklassen, bewaartermijnen, risicoanalyses en goedkeuringen in ISMS.online te documenteren onder zowel A.8.15 als de relevante privacycontroles, beschikt u over een controletraject dat u kunt laten zien aan auditors, toezichthouders en klanten die willen begrijpen waarom een bepaald type logboek gedurende een bepaalde periode wordt bewaard.

Hoe kan een MSP overtuigend aantonen dat hij voldoet aan A.8.15 tijdens een ISO 27001-audit?

Auditors bekijken A.8.15 doorgaans vanuit drie perspectieven: om mooie tassen te ontwerpen, operatie en verbeteringU wordt niet beoordeeld op het feit dat u een bepaald SIEM bezit, maar op de vraag of u kunt aantonen dat de logging doelbewust is ontworpen, wordt uitgevoerd zoals beschreven en wordt beoordeeld.

Wat moet u voorbereiden vóór een audit gericht op A.8.15?

Een beknopt bewijspakket gekoppeld aan A.8.15 maakt het auditgesprek veel soepeler. Het bevat doorgaans:

Een registratiebeleid of -norm die expliciet verwijst naar A.8.15 en gerelateerde controles voor monitoring en afhandeling van incidenten.
Blauwdrukken voor logboekregistratie op serviceniveau waarin voor elke belangrijke beheerde service wordt uitgelegd welke logboekbronnen worden gebruikt, hoe scheiding van meerdere tenants werkt en hoe retentie wordt toegepast.
Een matrix voor logboekclassificatie en -retentie die laat zien hoe lang elke logboekklasse wordt bewaard en waarom.
Uw Verklaring van Toepasselijkheid met een duidelijk overzicht van alle met logboekregistratie verband houdende controles en uw implementatie- of uitsluitingsbeslissingen.

Voor de bediening kunt u het volgende voorbereiden:

Configuratieschermafbeeldingen of exporten die de belangrijkste bronnen, tenant-ID's, integriteitsopties en bewaarinstellingen bewijzen, zijn ingeschakeld.
Voorbeelden van geplande logboekbeoordelingen, waarschuwingswachtrijen en beveiligingsdashboards, inclusief wie deze heeft beoordeeld en wat er met de bevindingen is gedaan.
Een klein aantal onderzoeksrapporten waarbij logboeken een centrale rol speelden bij het begrijpen of oplossen van een probleem.
Notulen van managementbeoordelingen of verbeteringsrapporten waarin de registratie van prestaties, dekking of incidenten zijn besproken.

Als deze artefacten zich in ISMS.online bevinden en gekoppeld zijn aan A.8.15 en de relevante services, kunt u auditors op een logische manier van beleid naar werkende voorbeelden begeleiden, zonder dat ze in e-mail of lokale mappen hoeven te zoeken.

Hoe kunt u logging weergeven als een rijpende controle in plaats van een statische vereiste?

Auditors zijn doorgaans meer ontspannen wanneer ze zien dat logging onderdeel is van een continue verbetercyclus. U kunt dat aantonen door:

Het vastleggen van logboekgerelateerde risico's, problemen en wijzigingen als onderdeel van uw risico- en verbeteringsprocessen, met eigenaren en einddatums.
Hier ziet u een beoordelingsschema voor uw logboekstandaard, retentiemodel en servicetoewijzingen, plus bewijs dat beoordelingen tot updates leiden.
Het vastleggen van lessen die zijn geleerd uit onderzoeken waarbij de logging goed presteerde of een lacune aan het licht bracht. Deze lessen kunnen vervolgens worden gekoppeld aan wijzigingen in de configuratie, dekking of het proces.

Door deze elementen stapsgewijs in ISMS.online onder A.8.15 te doorlopen, kunt u de toon van de audit verschuiven van "hebt u dit vakje aangevinkt?" naar "hoe gebruikt u logging om uw beheerde services in de loop van de tijd te versterken?", wat de reputatie ondersteunt die u als serieuze MSP wilt.

Hoe helpt ISMS.online uw MSP om logging en retentie om te zetten in een herhaalbare, betrouwbare service?

Voor veel MSP's is de uitdaging met A.8.15 niet of een tool logs kan verzamelen, maar of logging en retentie goed zijn. consistent, uitlegbaar en commercieel duurzaam over klanten heen. ISMS.online helpt u door uw loggingaanpak te beschouwen als een beheerd onderdeel van uw managementsysteem in plaats van als een verzameling verspreide praktijken.

Hoe kan ISMS.online uw loggingontwerp, verantwoordelijkheden en bewijs ondersteunen?

Binnen ISMS.online kunt u A.8.15 onder dezelfde controle brengen als de rest van uw ISO 27001-werkzaamheden:

Leg uw logbeleid en -standaard eenmalig vast, koppel ze direct aan A.8.15 en bijbehorende controles en maak ze zichtbaar voor technici, analisten en service-eigenaren.
Koppel elke beheerde service aan die standaard, zodat u altijd weet welke logbronnen, architecturen en bewaartermijnen van toepassing zijn op 'Managed M365', 'Managed Firewall', 'Managed Endpoint' en vergelijkbare aanbiedingen.
Houd één enkele logclassificatie- en bewaarmatrix bij, gekoppeld aan risico's, contracten en regelgeving, waarbij goedkeuringen en beoordelingsdata duidelijk worden vastgelegd.
Wijs verantwoordelijkheden toe voor logboekbeoordelingen, uitzonderingsafhandeling en verbeteringstaken en volg de voltooiing ervan met ingebouwde workflows en herinneringen.
Voeg architectuurdiagrammen, beoordelingsrapporten, onderzoekssamenvattingen en notulen van managementvergaderingen rechtstreeks toe aan A.8.15 en aan afzonderlijke services, zodat accountants, verzekeraars of belangrijke klanten eenvoudig bewijs kunnen verzamelen.

Omdat alles zich in één beheerde omgeving bevindt, worden updates die u doorvoert in het ontwerp en de bewaartermijn van logboekregistratie automatisch afgestemd op uw bredere ISMS, in plaats van dat ze verloren gaan in spreadsheets of persoonlijke mappen.

Welke praktische voordelen zullen uw team en klanten in het dagelijks leven merken?

Wanneer logging en retentie worden beheerd via ISMS.online, werken beveiligingsleiders vanuit een enkele, herbruikbare blauwdruk voor A.8.15 voor alle tenants en regio's hanteren technici duidelijke standaarden en schema's in plaats van ad-hocgewoonten, en kunnen commerciële teams uitleggen hoe logging elk serviceniveau ondersteunt in plaats van te vertrouwen op vage beloften.

Na verloop van tijd verandert die combinatie vaak hoe klanten en auditors uw MSP zien. In plaats van te hopen dat "de tools standaard voldoende loggen", wordt u de provider die precies kan uitleggen hoe logging is ontworpen, uitgevoerd en verbeterd, en die dat verhaal duidelijk kan weergeven in uw ISMS. De tijd nemen om uw huidige loggingaanpak en toekomstige verbeteringen in ISMS.online vast te leggen, is een eenvoudige stap als u wilt dat A.8.15 uw reputatie ondersteunt in plaats van dat het aanvoelt als een nieuwe compliance-hindernis.

Wij zijn een leider in ons vakgebied

Regionale leider - Winter 2026 Middenmarkt EU

Regionale leider - Winter 2026 Middenmarkt EMEA

"ISMS.Online, uitstekende tool voor naleving van regelgeving"
— Jim M.

"Maakt externe audits een fluitje van een cent en koppelt alle aspecten van uw ISMS naadloos aan elkaar"
— Karen C.

"Innovatieve oplossing voor het beheer van ISO en andere accreditaties"
— Ben H.

A.8.15 Logging – MSP-logarchitectuur en bewaarvereisten