Waarom MSP-toegangscontrole cruciaal is voor ISO 27001-vertrouwen en -audits

Wanneer MSP-toegangscontrole een multi-tenant-verplichting wordt

Toegangscontrole voor MSP's wordt een multi-tenant-aansprakelijkheid wanneer dezelfde mensen en tools veel klanten kunnen bereiken zonder duidelijke, afgedwongen regels. In die situatie kan één zwakke identiteit of verkeerd gebruikte tool meerdere tenants tegelijk treffen, en is het lastig om klanten of auditors te laten zien dat de toegang daadwerkelijk onder controle is.

Wanneer u veel klanten beheert, kan onbeheerde toegang ongemerkt uitgroeien tot een multi-tenant-aansprakelijkheid die elke organisatie die u bedient, treft. Zelfs als u nog geen inbreuk of lastige audit hebt meegemaakt, zorgen de stijgende verwachtingen van toezichthouders en klanten ervoor dat uw toegangspraktijken al onder de loep worden genomen. Deze informatie is algemeen en vormt geen juridisch of professioneel advies; u dient altijd advies in te winnen bij een gekwalificeerde adviseur voor uw situatie.

Vertrouwen is kwetsbaar als veel mensen onzichtbare sleutels tot veel plekken in handen hebben.

Waarom toegang met meerdere tenants het risico vergroot

Toegang voor meerdere tenants vergroot het risico, omdat één zwakke identiteit of tool een brug kan vormen naar meerdere klantomgevingen tegelijk. Richtlijnen van nationale cybersecurityinstanties, zoals de inzichten van CISA over cyberrisico's in de MSP-toeleveringsketen, stellen dat aanvallers zich doelbewust richten op gedeelde MSP-tools en -identiteiten vanwege de invloed die ze bieden op meerdere klanten. Als die brug wordt misbruikt of gecompromitteerd, kan de impact snel van één tenant naar meerdere tenants overslaan en een lokaal probleem omvormen tot een systematische storing.

Een nuttige eerste stap is het in kaart brengen van alle manieren waarop uw medewerkers en tools in contact kunnen komen met clientsystemen. Denk hierbij aan privileged accounts in klantendirectory's, toegang tot cloudbeheerconsoles, gedeelde kluizen voor inloggegevens, platforms voor externe monitoring en beheer, back-upsystemen en ondersteuning voor jump hosts. Wanneer u deze relaties op één pagina schetst, ontdekt u vaak dat een kleine set identiteiten en tools een groot percentage van uw klantenbestand kan bereiken.

Deze visuele 'explosieradius'-weergave doet twee dingen. Het verscherpt het inzicht van leidinggevenden in waar toegangsrisico's zich werkelijk bevinden, en het maakt de businesscase voor investeringen in toegangsbeheer gemakkelijker uit te leggen. In plaats van abstract gepraat over zero trust, kunt u naar een concreet diagram wijzen en zeggen: "Als een van deze identiteiten wordt misbruikt, kan dit gebeuren."

Waar klanten en toezichthouders zich op richten

Klanten en toezichthouders richten zich steeds meer op MSP-toegang, omdat het een krachtige route is in de toeleveringsketen van veel organisaties. Ze willen niet alleen zien dat u ISO 27001 volgt, maar ook dat u precies kunt uitleggen en aantonen hoe MSP-medewerkers worden geauthenticeerd, geautoriseerd en gemonitord in hun systemen.

Uit de bevindingen van het ISMS.online State of Information Security-onderzoek uit 2025 blijkt dat klanten steeds vaker verwachten dat leveranciers zich houden aan formele kaders zoals ISO 27001, ISO 27701, AVG, Cyber Essentials en SOC 2, in plaats van dat ze alleen op algemene goede praktijken vertrouwen.

Zakelijke klanten nemen nu gedetailleerde toegangsvragen op in beveiligingsvragenlijsten en due diligence-pakketten. Het komt vaak voor dat u wordt gevraagd om te beschrijven hoe uw medewerkers worden geauthenticeerd in onze systemen of om uit te leggen hoe u de toegang van MSP's tot onze omgeving controleert en intrekt. Beoordelaars verwachten duidelijke antwoorden, onderbouwd met bewijs, geen algemene intentieverklaringen. Recent onderzoek naar naleving van informatiebeveiliging in serviceorganisaties, zoals studies naar nalevingspraktijken van serviceproviders, signaleert dezelfde trend: klanten vertrouwen sterk op gestructureerde beveiligingsvragenlijsten en -beoordelingen om de volwassenheid van providers te beoordelen.

Uit het ISMS.online State of Information Security-onderzoek van 2025 blijkt dat de meeste organisaties in het afgelopen jaar te maken hebben gehad met minimaal één beveiligingsincident gerelateerd aan een derde partij of leverancier.

Beveiligingsincidenten met MSP's in de afgelopen jaren hebben aangetoond hoe snel een inbreuk op één geprivilegieerde identiteit een gigantisch effect kan hebben. Samenvattingen van cases uit de sector van inbreuken op geprivilegieerde toegang, waaronder die verzameld door onafhankelijke waarnemers, laten zien hoe misbruik van één krachtige account kan leiden tot een bredere inbreuk op meerdere downstream organisaties. Zelfs als een incident niet in uw omgeving begint, kan uw toegangsmodel bepalen of een probleem van een klant lokaal blijft of zich verspreidt. Daarom is Bijlage A.5.15 niet alleen een interne compliance-eis; het is fundamenteel voor het vertrouwen dat klanten in u als dienstverlener stellen.

Een multi-tenant-context betekent niet dat u alles zo strikt moet beveiligen dat werken onmogelijk wordt. Het betekent wel dat u een doelbewust, gedocumenteerd model voor toegangsbeheer nodig hebt waarmee engineers hun werk kunnen doen en het veel moeilijker wordt voor fouten, shortcuts of aanvallers om die toegang om te zetten in een systemisch risico.

Demo boeken

Wat ISO 27001:2022 Bijlage A.5.15 werkelijk verwacht

ISO 27001:2022 Bijlage A.5.15 verwacht dat u duidelijke regels definieert voor het beheersen van fysieke en logische toegang tot informatie en activa, en vervolgens aantoont dat deze in de praktijk worden toegepast. Voor een MSP betekent dit een centraal toegangscontrolebeleid dat interne systemen en elk pad bestrijkt dat uw mensen en tools gebruiken om klantomgevingen te bereiken. ISO's eigen overzicht van ISO 27001:2022, inclusief Bijlage A, benadrukt dat toegangscontroles zoals A.5.15 moeten worden ondersteund door bewijs van implementatie en effectiviteit, en niet alleen door beleidsverklaringen. Daarom vragen auditors consequent hoe uw regels in de praktijk werken.

Uit het ISMS.online State of Information Security-onderzoek van 2025 blijkt dat vrijwel alle respondenten het behalen of behouden van beveiligingscertificeringen zoals ISO 27001 of SOC 2 als topprioriteit noemen.

De controle drijft u verder dan vage goede bedoelingen en brengt u tot systematische toegangsbeslissingen. Het vereist dat u expliciet bent over wie toegang heeft tot wat, onder welke voorwaarden, en hoe die toegang wordt verleend, aangepast en ingetrokken in alle klantomgevingen die u bedient.

De formele doelstelling van A.5.15

Het formele doel van A.5.15 is ervoor te zorgen dat toegang wordt geautoriseerd op basis van bedrijfs- en beveiligingsbehoeften, en dat ongeautoriseerde toegang wordt voorkomen. In de praktijk vragen auditors vaak niet alleen om uw beleid, maar ook om bewijs dat daadwerkelijke toegangsbeslissingen hieraan voldoen.

Het is niet voldoende om te zeggen dat u sterke wachtwoorden gebruikt of multifactorauthenticatie inschakelt. De norm verwacht dat u systematisch nadenkt over hoe toegangsbeslissingen worden genomen en uitgevoerd, en hoe u dat op een consistente manier kunt aantonen. Die verwachting komt overeen met ISO's eigen beschrijving van ISO 27001:2022, waarin de beheersmaatregelen uit Bijlage A worden gepresenteerd als eisen die zowel gedefinieerd als aantoonbaar geïmplementeerd moeten zijn.

Een toegangscontrolebeleid moet minimaal de reikwijdte van de activa definiëren die het bestrijkt, de principes die toegangsbeslissingen sturen en de betrokken rollen en verantwoordelijkheden. In een MSP omvat die reikwijdte uw interne systemen en elk pad naar clientomgevingen dat uw medewerkers of tools kunnen gebruiken. Het beleid moet ook vermelden hoe vaak het wordt beoordeeld, door wie en hoe wijzigingen worden goedgekeurd.

A.5.15 staat naast andere toegangsgerelateerde controles in de herziening van 2022. Identiteitsbeheer valt onder A.5.16 en geprivilegieerde toegang onder A.8.2, terwijl A.5.17 authenticatiegegevens behandelt. Samen vormen deze controles de ruggengraat van uw toegangsbeheer: het beleid bepaalt de regels, de identiteitscyclus implementeert ze en geprivilegieerd toegangsbeheer houdt de krachtigste rechten strikt onder controle. Onafhankelijke uitleg van de bijgewerkte controleset, zoals samenvattingen van de controles van ISO 27001:2022 Annex A, groeperen deze vereisten als de toegangsbeheerfamilie die nauw moet samenwerken.

Wat een goed toegangscontrolebeleid omvat

Een goed MSP-toegangscontrolebeleid vertaalt principes zoals "least privilege" en "need-to-know" in specifieke, herhaalbare regels. Mensen moeten het kunnen lezen en begrijpen hoe ze op een consistente manier toegang kunnen verlenen, gebruiken en intrekken.

Normaal gesproken verwacht je secties die het volgende behandelen:

reikwijdte en toepasbaarheid (services, systemen, tools en omgevingen)
toegangsprincipes (minimale privilege, scheiding van taken, standaard weigering)
standaard roldefinities voor kern MSP-functiefamilies
toegangscategorieën (gebruiker, administratief, noodgeval)
Levenscyclus van timmerman, verhuizer en vertrekker voor personeel en aannemers
goedkeuringsregels voor verschillende toegangstypen en wijzigingen
authenticatievereisten, inclusief multifactoriële toegang voor risicovolle toegang
logging en monitoring verwachtingen voor bevoorrechte activiteiten
frequentie en reikwijdte van interne en gezamenlijke toegangsbeoordelingen
uitzonderingsbehandeling, inclusief goedkeuring, documentatie en beoordeling

Voor Bijlage A.5.15 tonen deze elementen aan dat u op beleidsniveau over toegang hebt nagedacht en niet uitsluitend vertrouwt op standaardtools of informele normen.

Hoe A.5.15 verbinding maakt met identiteit en bevoorrechte toegang

In een MSP-omgeving werkt Annex A.5.15 alleen wanneer deze nauw verbonden is met identiteits- en privileged access management. Uw beleid moet de regels beschrijven en uw identiteits- en privilegeprocessen moeten deze betrouwbaar toepassen op meerdere tenants.

Identiteitsbeheer onder A.5.16 beschrijft hoe identiteiten van medewerkers worden aangemaakt, gewijzigd en verwijderd, en hoe deze identiteiten worden gekoppeld aan accounts en tokens in de systemen die u beheert. Als uw beleid voorschrijft dat de toegang onmiddellijk wordt ingetrokken wanneer medewerkers vertrekken, moeten uw identiteitsprocessen ervoor zorgen dat de toegang tot elke clientomgeving wordt ingetrokken wanneer iemand vertrekt of van rol verandert.

Bevoorrechte toegang onder A.8.2 richt zich op verhoogde rechten, zoals domeinbeheerders, eigenaren van cloudabonnementen of beheerders van beveiligingstools. Uw toegangscontrolebeleid moet definiëren wat als bevoorrecht wordt beschouwd, welke rollen dergelijke rechten kunnen hebben en onder welke waarborgen (bijvoorbeeld aparte benoemde beheerdersaccounts, multifactorauthenticatie en sessiebewaking).

Zonder een robuuste identiteitslevenscyclus en privileged access controls blijft Bijlage A.5.15 grotendeels theoretisch. Wanneer auditors uw implementatie beoordelen, verwachten ze dat het beleid, de identiteitslevenscyclus en de privileged access-praktijken elkaar versterken. Klanten verwachten dezelfde afstemming wanneer u uw verhaal over toegangsbeheer presenteert tijdens due diligence.

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

Het ontwerpen van één centraal MSP-toegangscontrolebeleid voor veel huurders

Eén centraal MSP-toegangscontrolebeleid biedt u één regelset voor alle klanten, terwijl u toch klantspecifieke add-ons kunt gebruiken waar contracten of regelgeving meer vereisen. Het vormt de ruggengraat voor elke toegangsbeslissing die uw teams nemen.

Het ontwerpen van één centraal toegangscontrolebeleid voor een MSP betekent het creëren van een regelset die van toepassing is op alle klantomgevingen, terwijl er toch duidelijke uitzonderingen mogelijk zijn. Goed uitgevoerd, wordt dit centrale beleid het ankerpunt voor elke toegangsbeslissing die uw teams nemen en het belangrijkste referentiepunt voor auditors en klanten.

Kiezen voor MSP-brede scope en structuur

Het kiezen van de juiste scope en structuur betekent schrijven vanuit het perspectief van uw eigen organisatie en vervolgens beschrijven hoe dat model van toepassing is op alle systemen van uw klanten. Het beleid moet aanvoelen als uw handleiding, niet als een abstracte standaard, en het moet de realiteit van multi-tenant tools weerspiegelen in plaats van die van één intern netwerk.

Een centraal MSP-toegangscontrolebeleid moet beschrijven hoe de identiteiten, rollen, processen en tools van uw medewerkers werken bij toegang tot elke clientomgeving binnen uw servicebereik. Dit omvat platforms voor externe monitoring en beheer, waarbij één console-account inzicht kan hebben in tientallen klanten tegelijk.

Een praktische aanpak is om het beleid te structureren rond uw services en roltypen. U kunt bijvoorbeeld standaardrollen definiëren zoals servicedeskanalist, netwerkengineer, cloudengineer, beveiligingsanalist en customer success manager. Beschrijf voor elke rol de soorten systemen waartoe ze toegang hebben, het maximale privilegeniveau en de voorwaarden waaraan moet worden voldaan.

In plaats van voor elke klant een apart beleid te schrijven, kunt u bijlagen of profielen gebruiken om variaties vast te leggen. Uw kernbeleid kan bepalen dat alle bevoorrechte toegang gebruik moet maken van multifactorauthenticatie en accounts met naam, terwijl een profiel voor een sterk gereguleerde financiële of zorgklant gedetailleerdere logging, kortere sessietime-outs of strengere goedkeuringsregels toevoegt. Zo behoudt u één consistente basis en kunt u flexibel inspelen op contractuele of wettelijke verplichtingen.

Het is ook belangrijk om te definiëren welke systemen en tools onder het beleid vallen: uw eigen interne systemen, gedeelde multi-tenant platforms zoals tools voor externe monitoring en directe toegang tot klantnetwerken en cloudomgevingen. Als uw medewerkers of tools ermee overweg kunnen, moet het binnen de scope vallen.

Het definiëren van basislijnen, uitzonderingen en eigenaarschap

Het definiëren van niet-onderhandelbare basislijnen, strak gecontroleerde uitzonderingen en duidelijk eigenaarschap maakt een centraal beleid afdwingbaar in plaats van ambitieus. Mensen moeten weten wat altijd geldt, wanneer je kunt afwijken en wie het moet goedkeuren.

Een centraal beleid werkt het beste wanneer het basislijnen vastlegt die van toepassing zijn op elke klant en elke omgeving. Typische basislijnen kunnen bestaan uit unieke accounts met een naam voor medewerkers, multifactorauthenticatie voor alle geprivilegieerde of externe toegang, tijdgebonden noodtoegang en logging van alle administratieve acties in systemen boven een bepaald risiconiveau.

U kunt vervolgens een proces voor uitzonderingen definiëren. Soms kan een klantomgeving of een verouderd systeem niet direct aan uw baseline voldoen. In die gevallen moet het beleid een gedocumenteerde risicobeoordeling, formele goedkeuring op het juiste niveau, duidelijke compenserende maatregelen en een verval- of beoordelingsdatum vereisen. Anders worden 'tijdelijke' uitzonderingen al snel permanent.

Eigenaarschap is net zo belangrijk. Het beleid moet duidelijk aangeven wie verantwoordelijk is voor het opstellen, goedkeuren en beoordelen ervan, en wie verantwoordelijk is voor de implementatie van specifieke onderdelen. In de praktijk kan dit uw CISO, informatiebeveiligingsmanager, hoofden van servicelijnen en teamleiders betreffen. Door deze verantwoordelijkheden in functiebeschrijvingen en doelstellingen te verankeren, voorkomt u dat het beleid "iedereens en niemands taak" wordt.

Het beleid levend en bruikbaar houden

Om het beleid levend en bruikbaar te houden, moet u het herzien wanneer uw services, tools of risico's veranderen, en het op een manier presenteren die engineers daadwerkelijk kunnen gebruiken. Een kleiner, duidelijk beleid met ondersteunende handleidingen is waardevoller dan een dik document dat niemand leest.

Een centraal toegangscontrolebeleid voegt alleen waarde toe als het weerspiegelt hoe uw MSP vandaag de dag werkt. Dit betekent dat het moet worden herzien en bijgewerkt naarmate services, technologieën en bedreigingen evolueren, en niet alleen volgens een vast schema.

Een eenvoudig mechanisme is om een beoordelingsritme in te stellen, bijvoorbeeld jaarlijks voor het volledige beleid en vaker voor onderdelen met een hoge impact. U moet echter ook triggers identificeren die een beoordeling buiten de cyclus rechtvaardigen, zoals de onboarding van een belangrijke nieuwe klant in een gereguleerde sector, de implementatie van een nieuw kernplatform of het vaststellen van toegangsgerelateerde bevindingen in een incident of audit.

Gebruiksvriendelijkheid is ook belangrijk. Lange, complexe beleidsdocumenten voldoen misschien wel aan een documentatievereiste, maar ze dragen weinig bij aan het dagelijks gedrag. Overweeg om korte, rolspecifieke handleidingen te maken die zijn afgeleid van het beleid en die in begrijpelijke taal uitleggen hoe een servicedeskanalist toegang moet aanvragen en gebruiken, hoe een engineer om moet gaan met noodwijzigingen of hoe een customer success manager vragen over toegang moet beantwoorden.

Een platform zoals ISMS.online kan u helpen dit centrale beleid 'levend' te houden door het direct te koppelen aan risico's, controles, taken en bewijs. Updates en verantwoordelijkheden worden op één plek bijgehouden in plaats van te verdwijnen in gedeelde schijven. Dit maakt het voor uw teams gemakkelijker om actie te ondernemen op basis van het beleid en auditors te laten zien dat Bijlage A.5.15 ingebed is in plaats van theoretisch.

Gedeelde verantwoordelijkheid met klanten werkelijkheid maken

Toegangscontrole voor MSP's is altijd een gedeelde verantwoordelijkheid: u bepaalt hoe uw mensen en tools zich gedragen, en klanten bepalen hun omgevingen en goedkeuringen. Bijlage A.5.15 komt goed van pas wanneer dit gedeelde model wordt vastgelegd, overeengekomen en regelmatig wordt herzien. Toezichthouders die verantwoordingsplicht benadrukken, zoals het Britse Information Commissioner's Office in zijn verantwoordingskader, benadrukken een duidelijke verdeling van verantwoordelijkheden tussen partijen op precies deze manier.

In het ISMS.online State of Information Security-onderzoek van 2025 gaf ongeveer 41% van de organisaties aan dat het beheersen van risico's van derden en het bijhouden van de naleving door leveranciers de grootste uitdagingen vormen.

Toegangsbeheer voor MSP's is altijd een gedeelde verantwoordelijkheid tussen provider en klant. Bijlage A.5.15 verwacht dat u uw kant van de regels duidelijk definieert, maar u kunt toegangsrisico's niet in uw eentje beheren. U hebt een gedeeld model nodig dat klanten begrijpen, accepteren en helpen handhaven via dagelijkse beslissingen en governanceforums.

Het ontwerpen van een model voor gedeelde verantwoordelijkheid

Een model voor gedeelde verantwoordelijkheid verduidelijkt wie verantwoordelijk is, wie de taken uitvoert en wie ze controleert binnen de servicegrens. Het zet vage verwachtingen om in specifieke 'wie doet wat'-ideeën voor elk belangrijk systeemtype, en dat is precies wat veel zakelijke klanten nu verwachten bij beveiligingsbeoordelingen.

Voor elk belangrijk systeemtype, zoals on-premise infrastructuur, cloudabonnementen, beveiligingstools en software-as-a-serviceplatforms, moet u het volgende verduidelijken:

wie de toegang voor MSP-personeel tot de omgeving van de klant goedkeurt
wie technisch gezien die toegang verleent en intrekt
wie verantwoordelijk is voor monitoring en logging
die periodieke toegangsbeoordelingen uitvoert
hoe verantwoordelijkheden veranderen in noodsituaties

In veel gevallen verleent en verwijdert u als MSP toegang tot uw eigen tools en tot klantsystemen waar u een administratieve rol vervult, maar de klant behoudt de bevoegdheid om toegangsverzoeken goed te keuren of af te wijzen. Het documenteren van deze verdeling helpt hiaten te voorkomen waarbij geen van beide partijen zich realiseert dat ze verantwoordelijk zijn.

Een eenvoudige manier om dit vast te leggen is door middel van een verantwoordelijkheidsmatrix die rollen zoals 'Verantwoordelijk', 'Verantwoordelijk', 'Geraadpleegd' en 'Geïnformeerd' aan beide partijen toewijst. Deze matrix vormt vervolgens een referentiepunt voor contracten, onboardingplannen en periodieke governance-evaluaties, waaronder regelmatige servicebeoordelingsvergaderingen of kwartaalbeoordelingen van de bedrijfsvoering.

Stappen om een model voor gedeelde verantwoordelijkheid op te bouwen

Lijst systeemtypen uw diensten raken, zoals on-premise, cloud, beveiligingstools en SaaS.
Definieer de belangrijkste activiteiten voor elk systeem, waaronder goedkeuren, verlenen, bewaken, beoordelen en reageren.
RACI-rollen toewijzen tussen uw organisatie en de klant voor elke activiteit.
Beoordeel en ga akkoord met het model Tijdens het onboardingproces kunt u deze bijwerken naarmate services en risico's veranderen.

Toegangsbeheer inbedden in contracten en relaties

Door het gedeelde model te verankeren in contracten en governance-vergaderingen, wordt ervoor gezorgd dat er actie op wordt ondernomen in plaats van dat het wordt vergeten. Contracten scheppen verwachtingen en regelmatige evaluaties zorgen ervoor dat beide partijen op één lijn zitten naarmate diensten en risico's zich ontwikkelen.

Zodra u een model voor gedeelde verantwoordelijkheid hebt, moet dit tot uiting komen in uw contractuele documenten en lopende interacties. Hoofdserviceovereenkomsten, werkomschrijvingen en overeenkomsten voor gegevensverwerking moeten allemaal beschrijven hoe de toegang wordt beheerd.

Dit kan verplichtingen omvatten om een centraal toegangscontrolebeleid te handhaven, benoemde accounts en sterke authenticatie te gebruiken, bevoorrechte toegang te registreren en te beoordelen en klanten op de hoogte te stellen van belangrijke wijzigingen of incidenten met betrekking tot toegang. Aan de kant van de klant kunnen contracten vereisen dat personeelswisselingen tijdig worden gemeld, toegangsrapporten tijdig worden beoordeeld en dat er wordt deelgenomen aan gezamenlijke toegangsbeoordelingen.

Tijdens de presales, onboarding en QBR's is het nuttig om deze onderwerpen expliciet te bespreken. Door klanten te vragen aan welke regelgeving, interne beleidslijnen of brancheverwachtingen ze moeten voldoen, kunt u zien waar uw standaardbasislijn voor hen moet worden versterkt. Door deze behoeften vanaf het begin duidelijk vast te leggen, vermindert u later de wrijving wanneer beveiligingsvragenlijsten of toezichthouders om bewijs vragen.

Regelmatige governancevergaderingen – elk kwartaal of halfjaarlijks – bieden de mogelijkheid om de werking van het model te evalueren. U kunt toegangsrapporten, uitzonderingen, incidenten en aankomende wijzigingen doornemen. Het vastleggen van acties en beslissingen uit deze sessies versterkt zowel de naleving van Annex A.5.15 als het vertrouwen van klanten.

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

Boek uw demo

Technische en procedurele controles voor toegang door meerdere huurders

Bijlage A.5.15 wordt werkelijkheid wanneer technische controles en procedures samenwerken om uw regels voor meerdere tenants af te dwingen. MSP's kunnen risico's aanzienlijk beperken met een sterke identiteitslevenscyclus, een zorgvuldig ontwerp van geprivilegieerde toegang en goed geconfigureerde multi-tenant tooling.

Een goed ontworpen beleid moet worden ondersteund door praktische technische en procedurele controles. Voor MSP's met meerdere tenants zijn controles die de besluitvorming centraliseren en tegelijkertijd scheiding tussen tenants afdwingen, bijzonder belangrijk, omdat één misstap gevolgen kan hebben voor een groot klantenbestand.

Identiteitslevenscyclus en de minste privileges in de praktijk

Identiteitslevenscyclusbeheer en minimale privileges zorgen ervoor dat de toegang afgestemd blijft op de rollen van gebruikers, van hun eerste tot hun laatste dag. Als u elke identiteit betrouwbaar kunt traceren en aanpassen, verkleint u de kans op vergeten toegangspaden tot klantsystemen aanzienlijk.

Identiteitslevenscyclusbeheer is essentieel om Bijlage A.5.15 in de praktijk te laten werken. Elke medewerker en elke contractant die toegang heeft tot klantomgevingen, moet een unieke identiteit hebben, waarbij alle toegang aan die identiteit gekoppeld moet zijn.

Processen voor toetreders, overnemers en afvallers moeten nauw geïntegreerd zijn met toegangsworkflows. Wanneer iemand toetreedt, bepaalt zijn of haar rol welke standaard toegangsrollen hij of zij krijgt. Wanneer iemand van team of verantwoordelijkheid wisselt, moet de toegang worden aangepast in plaats van alleen worden toegevoegd. Bij vertrek moet alle toegang tot uw eigen systemen en alle klantomgevingen onmiddellijk worden ingetrokken en geverifieerd.

Minimum privilege betekent in deze context het ontwerpen van rolgebaseerde toegang, zodat medewerkers alleen de rechten hebben die ze nodig hebben voor hun gebruikelijke taken. Eerstelijnsondersteuning heeft bijvoorbeeld mogelijk beperkte toegang nodig om de configuratie te bekijken en bepaalde taken te initiëren, terwijl senior engineers ingrijpendere wijzigingen kunnen uitvoeren, maar alleen in systemen waarvoor ze verantwoordelijk zijn. Generieke "super admin"-rollen moeten worden vervangen door beperktere scopes waar de technologie dit toelaat.

Een eenvoudige identiteitslevenscyclusreeks

Standaardrollen definiëren en wijs elke rol toe aan toegestane systemen en rechten.
Toegang verlenen per rol wanneer mensen zich aansluiten, en niet door ad hoc directe toestemmingen.
Rollen aanpassen bij zetten en verwijder toegang die niet langer overeenkomt met verantwoordelijkheden.
Toegang intrekken en verifiëren in alle systemen, inclusief huurders van klanten, wanneer mensen vertrekken.

Door rolgebaseerde toegang te combineren met geautomatiseerde provisioning, wordt het eenvoudiger om privilege creep en verweesde accounts te voorkomen. Het maakt periodieke toegangscontroles ook zinvoller, omdat reviewers kunnen zien of de toegang overeenkomt met gedefinieerde rollen, in plaats van te proberen lange lijsten met individuele rechten te interpreteren.

Sterkere controles voor bevoorrechte toegang

Privileged access vereist strengere controles, omdat fouten of aanvallen op dit niveau meerdere gebruikers tegelijk kunnen treffen. Named admin-accounts, multifactorauthenticatie en just-in-time-elevatie verkleinen de explosieradius en ondersteunen uw Annex A.5.15-verdieping.

Bij geprivilegieerde toegang staat de inzet het hoogst. Dit zijn de rechten waarmee u beveiligingsinstellingen kunt wijzigen, accounts kunt aanmaken of verwijderen, back-ups kunt wijzigen of toegang kunt krijgen tot gevoelige gegevens van meerdere gebruikers. Een fout of inbreuk op dit niveau kan veel andere controles ongedaan maken.

Een goede gewoonte is het gebruik van aparte accounts met een naam voor administratieve taken, los van de dagelijkse gebruikersaccounts. Deze beheerdersaccounts moeten altijd gebruikmaken van multifactorauthenticatie, idealiter met methoden die bestand zijn tegen phishingaanvallen. Gedeelde beheerdersaccounts moeten worden verwijderd of strikt worden beheerd met beveiligde kluisfuncties en gedetailleerde toegangslogboeken.

Just-in-time-toegang, waarbij verhoogde rechten tijdelijk worden verleend in reactie op goedgekeurde verzoeken en vervolgens worden ingetrokken, kan het aantal permanente rechten in uw omgeving aanzienlijk verminderen. Zelfs als volledige automatisering niet voor alle systemen mogelijk is, is het implementeren van tijdgebonden toegang voor de platforms met het hoogste risico een belangrijke stap.

Logging en monitoring moeten in verhouding staan tot het risico. Elke geprivilegieerde actie in kritieke systemen moet met voldoende detail worden vastgelegd om te begrijpen wat er is gedaan, door wie en wanneer. Waarschuwingen voor ongebruikelijke patronen, zoals wijzigingen buiten kantooruren, toegang vanaf onverwachte locaties of geprivilegieerde activiteiten buiten de normale servicevensters, helpen u misbruik vroegtijdig te detecteren en snel te reageren.

Multi-tenant toolingpatronen die A.5.15 ondersteunen

Multi-tenant tools kunnen uw implementatie van Annex A.5.15 versterken of juist ondermijnen, afhankelijk van hoe u ze configureert. Scheiding op tenantniveau, rolbereik en centrale identiteitsintegratie zijn eenvoudige ontwerpkeuzes die een groot verschil maken.

Veel MSP's vertrouwen op gedeelde tools zoals platforms voor externe monitoring en beheer, ticketsystemen, back-upservices en cloudbeheerconsoles. De manier waarop deze tools zijn geconfigureerd, kan uw Annex A.5.15-positie versterken of verzwakken.

Gebruik waar mogelijk segmentatiefuncties om klantomgevingen logisch te scheiden. Dit kan bestaan uit tenant- of site-constructies, aparte groepen of verschillende beheerbereiken per klant. Medewerkers binnen deze tools moeten de toegang beperken tot alleen de klanten die ze bedienen, zodat een engineer alleen systemen kan zien en gebruiken voor de organisaties die ze ondersteunen.

Door deze tools te integreren met een centrale identiteitsprovider, kunt u consistente authenticatie afdwingen, beleid voor voorwaardelijke toegang toepassen en offboarding vereenvoudigen. Wanneer iemand vertrekt, kunt u deze persoon verwijderen uit de identiteitsprovider en weet u zeker dat de toegang tot alle geïntegreerde tools en klantomgevingen verdwijnt.

Koppel uw technische controles procedureel aan ticketing- of workflowsystemen. Verzoeken om nieuwe toegang, wijzigingen in privilegeniveaus en noodtoegang moeten allemaal bijbehorende registraties met goedkeuringen hebben. Deze koppeling maakt het veel gemakkelijker om aan te tonen dat toegang is verleend volgens uw beleid en bedrijfsbehoeften, en niet ad hoc.

Wanneer u deze controles implementeert, zult u zien welke onderdelen sterk zijn en welke ontbreken of inconsistent zijn. Deze zwakke punten komen vaak duidelijk naar voren tijdens audits, waar veel MSP's voor het eerst de praktische impact van Bijlage A.5.15 ondervinden.

Veelvoorkomende MSP-lacunes en hoe deze tot uiting komen in audits

Veelvoorkomende tekortkomingen in MSP's rond Bijlage A.5.15 zijn meestal een onduidelijke reikwijdte, inconsistente behandeling van identiteitstypen en een afwijking tussen schriftelijk beleid en de praktijk. Auditors ontdekken deze tekortkomingen vaak snel, omdat ze zowel in documenten als in de dagelijkse gang van zaken voorkomen.

In het ISMS.online State of Information Security-onderzoek van 2025 gaf ongeveer tweederde van de organisaties aan dat de snelheid en omvang van de veranderingen in de regelgeving het moeilijker maken om aan de regelgeving te voldoen.

Zelfs ervaren MSP's ontdekken vaak hiaten wanneer ze Annex A.5.15 door een multi-tenant perspectief bekijken. Een typisch patroon is dat de concepten wel begrepen worden, maar de implementatie in de praktijk achterblijft, vooral wanneer er veel klantomgevingen en tools bij betrokken zijn.

Stel je een MSP voor waar het toegangscontrolebeleid jaren geleden is opgesteld voor interne systemen en nooit is bijgewerkt. Tijdens een ISO 27001-audit vraagt de assessor hoe dat beleid van toepassing is op een platform voor externe monitoring dat elke klant kan bereiken. Het team kan alleen informele werkwijzen en geïsoleerde toolinstellingen beschrijven. De waarschijnlijke uitkomst is dat het beleid geen echte toegangspaden dekt, zelfs als er geen incident heeft plaatsgevonden.

Typische beleids- en ontwerplacunes

Typische hiaten in beleid en ontwerp ontstaan wanneer uw centrale toegangscontrolebeleid niet expliciet de toegang van MSP tot klant dekt, of wanneer het contractanten en derde partijen met krachtige rechten negeert. Deze omissies zijn gemakkelijk te ontdekken door auditors en roepen vragen op over de mate waarin uw beleid overeenkomt met de realiteit.

Een veelvoorkomende lacune is dat het toegangscontrolebeleid niet expliciet de toegang van MSP tot client dekt. Het is mogelijk geschreven met interne systemen in gedachten en pas later informeel uitgebreid naar klantomgevingen. Auditors en klanten zullen het opmerken wanneer de beleidstekst generiek aanvoelt en niet beschrijft hoe uw medewerkers en tools omgaan met clientsystemen.

Een ander veelvoorkomend probleem is de inconsistente omgang met identiteitstypen op ontwerpniveau. De identiteiten van medewerkers kunnen duidelijk gedefinieerd zijn in het beleid, maar identiteiten van aannemers, tijdelijke medewerkers, offshore-medewerkers of externe partijen worden als speciale gevallen behandeld of weggelaten. In een MSP hebben deze populaties vaak aanzienlijke toegang en moeten ze worden opgenomen in het centrale beleid, het rolmodel en de risicobeoordelingen.

Beleid kan ook idealen beschrijven die niet in de praktijk tot uiting komen. Zo kan het beleid bijvoorbeeld bepalen dat multifactorauthenticatie vereist is voor alle externe toegang, maar oudere VPN's of serviceaccounts omzeilen die vereiste. Wanneer auditors documentatie vergelijken met de praktijk, leiden deze inconsistenties al snel tot bevindingen.

Operationele hiaten die auditors en klanten opmerken

Operationele tekortkomingen komen aan het licht wanneer auditors vragen hoe de toegang daadwerkelijk wordt beheerd en u alleen handmatige processen, verspreide spreadsheets of onregelmatige beoordelingen kunt beschrijven. Klanten zien dezelfde zwakheden wanneer u moeite hebt om te bepalen wie er vandaag toegang heeft tot hun omgeving en hoe die toegang is goedgekeurd.

Operationeel zullen auditors zoeken naar bewijs dat uw toegangsregels dagelijks worden nageleefd. Ze zullen vragen hoe snel de toegang wordt ingetrokken wanneer medewerkers vertrekken, hoe vaak er toegangscontroles plaatsvinden en hoe u de isolatie van gebruikers in gedeelde tools waarborgt.

Als uw antwoorden gebaseerd zijn op handmatige processen, spreadsheets en informele kennis, kan uw controle als zwak worden beoordeeld, zelfs als er geen incidenten hebben plaatsgevonden. Evenzo kunnen auditors concluderen dat overmatige of verwaarloosde toegang waarschijnlijk is als toegangsbeoordelingen onregelmatig, onvolledig of slecht gedocumenteerd zijn.

Klanten die risicobeoordelingen door derden uitvoeren, zullen merken dat u geen duidelijke rapporten kunt overleggen waaruit blijkt wie toegang heeft tot hun systemen, wanneer die toegang is goedgekeurd en wanneer deze voor het laatst is beoordeeld. Ze kunnen ook uw volwassenheid in twijfel trekken als u niet in eenvoudige bewoordingen kunt uitleggen hoe uw toegangsmodel voorkomt dat het probleem van de ene klant het probleem van een andere klant wordt.

Metrieken gebruiken om verbeteringen te prioriteren

Eenvoudige, gerichte meetgegevens helpen u om Bijlage A.5.15 te transformeren van een vage zorg naar concrete verbeterwerkzaamheden. Ze bieden u een manier om prioriteiten te stellen en de voortgang te tonen aan leidinggevenden en klanten.

In plaats van te proberen alles in één keer te repareren, is het vaak effectiever om een handvol toegangsgerelateerde meetgegevens te selecteren en deze te gebruiken om verbeteringen door te voeren.

Identiteits- en toegangshygiënegegevens kunnen het volgende omvatten:

percentage medewerkers met alleen toegang via gedefinieerde rollen
gemiddelde tijd om toegang in te trekken nadat een uittreder is geregistreerd
aantal bevoorrechte accounts per engineer of per klant

Meetgegevens voor het bestuursvak kunnen onder meer het volgende omvatten:

percentage toegangsbeoordelingen dat op tijd is voltooid
aantal open beleidsuitzonderingen en hun leeftijd

Door deze statistieken in de loop van de tijd bij te houden, kunt u zien of uw veranderingen een verschil maken. Het biedt u ook praktische gegevens die u met het management kunt delen bij het aanvragen van investeringen of bij het rapporteren over de voortgang. Bijlage A.5.15 is gemakkelijker te beheren wanneer u meetbare trends kunt aanwijzen in plaats van te vertrouwen op subjectieve oordelen over of toegangscontrole "beter aanvoelt".

Organisaties die toegangsbeheer op deze manier aanscherpen, melden vaak dat audits voorspelbaarder aanvoelen, het zoeken naar bewijsmateriaal minder tijdrovend is en klantgesprekken over toegang eenvoudiger en betrouwbaarder verlopen. Zodra u duidelijkere statistieken en minder hiaten hebt, is de volgende stap het ordenen van uw bewijsmateriaal zodat het een samenhangend verhaal vertelt.

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

Boek uw demo

Het aantonen van toegangsbeheer aan auditors en klanten

U bewijst Bijlage A.5.15 door een duidelijke lijn te laten zien van geschreven regels, via processen, naar praktijkbewijs dat toegang wordt verleend, gebruikt en beoordeeld zoals u beweert. Die lijn zou gemakkelijk te volgen moeten zijn voor auditors, klanten en uw eigen leidinggevenden.

Bijlage A.5.15 wordt uiteindelijk niet alleen beoordeeld op de tekst van uw beleid, maar ook op het bewijs dat uw regels worden geïmplementeerd en effectief zijn. Een weloverwogen aanpak van bewijsverzameling en -presentatie maakt audits en klantbeoordelingen aanzienlijk minder pijnlijk en voorspelbaarder. Richtlijnen van normalisatie-instellingen en certificeringsorganisaties, zoals overzichten van ISO 27001 van nationale normalisatie-instellingen, benadrukken hetzelfde punt: auditors kijken naar implementatie en effectiviteit op basis van bewijs, niet alleen naar beleidstekst.

Het ontwerpen van een bewijsbibliotheek voor toegangsbeheer

Een overzichtelijke bewijsbibliotheek zet een stapel screenshots en exports om in een samenhangend verhaal over hoe u toegang beheert. Elk belangrijk onderdeel van uw beleid moet overeenkomende procedures, registraties en toezichtdocumenten bevatten die u snel kunt vinden en presenteren.

Een handige manier om bewijs te zien, is als een gelaagde bibliotheek. Bovenaan staat uw toegangscontrolebeleid, dat beschrijft wat er zou moeten gebeuren. Daaronder staan procedures en standaarden die uitleggen hoe het beleid wordt geïmplementeerd in processen en tools. Daaronder staan workflows, tickets en andere records die laten zien wat er daadwerkelijk is gebeurd. Logs en rapporten van tools bieden een extra detaillaag. Tot slot tonen beoordelingsrecords en goedkeuringen van het management toezicht.

Een auditor kan bijvoorbeeld één lijn volgen van een beleidsregel over bevoorrechte toegang tot de cloud, naar een standaardwerkprocedure voor het verlenen van die toegang, naar een ticket waarin een genoemde engineer is goedgekeurd en ten slotte naar een logboekregistratie waarin staat hoe het account is gebruikt en later is beoordeeld.

Door deze bibliotheekstructuur op papier te zetten voordat u begint met het verzamelen van bewijs, wordt duidelijk wat u nodig hebt. Voor Bijlage A.5.15 wilt u ervoor zorgen dat elk belangrijk aspect van het beleid – zoals toegangsverlening, bevoorrechte toegang, identiteitslevenscyclus, noodtoegang en toegangscontroles – bijbehorende procedures en registraties heeft.

Zodra de structuur duidelijk is, kunt u uw bestaande systemen hieraan koppelen. Uw identiteitsprovider kan bijvoorbeeld toegangsrapporten verstrekken, uw ticketsysteem kan goedkeuringsgegevens bevatten, uw platform voor geprivilegieerde toegang kan sessielogs bevatten en uw ISMS-platform kan risico's, controles en bewijsstukken aan elkaar koppelen. Het doel is niet om alle gegevens te centraliseren, maar om een duidelijke, herhaalbare manier te hebben om te laten zien waar elk onderdeel zich bevindt.

Automatisering van bewijsmateriaal waar dat redelijk is

Door sleutelbewijsmateriaal waar mogelijk te automatiseren, blijft het actueel en wordt de drukte vóór audits of due diligence verminderd. Standaardrapporten, gemarkeerde tickets en geplande beoordelingen maken Bijlage A.5.15 gemakkelijker op aanvraag te demonstreren.

Vertrouwen op handmatige screenshots en eenmalige exports leidt tot verouderd en inconsistent bewijs. Probeer waar mogelijk het vastleggen van bewijsmateriaal te automatiseren of het op zijn minst op aanvraag reproduceerbaar te maken.

U kunt bijvoorbeeld standaardrapporten ontwerpen in uw tools voor identiteits- of toegangsbeheer die de huidige gebruikers en hun rollen per klant weergeven. U kunt uw ticketsysteem configureren om toegangsgerelateerde aanvragen te taggen, zodat deze snel kunnen worden gefilterd op goedkeuringen. U kunt regelmatige exports plannen vanuit logsystemen die de geprivilegieerde activiteiten voor specifieke platforms samenvatten.

Het automatiseren van periodieke toegangsbeoordelingen kan ook helpen. Als uw tooling reviewers een lijst met te certificeren accounts kan sturen, hun beslissingen kan vastleggen en de voltooiing ervan kan registreren, dan vormen die beoordelingsgegevens eenvoudig bewijs. Zelfs als de technologie geen volledige automatisering ondersteunt, is een consistente template en planning voor beoordelingen een grote verbetering ten opzichte van ad-hocbenaderingen.

Een platform zoals ISMS.online kan fungeren als de governancelaag die deze bronnen met elkaar verbindt. Door controles en beleid te koppelen aan specifieke bewijsstukken, taken en eigenaren, kunt u in één oogopslag zien of er hiaten zijn en waar u zich op moet richten vóór een audit of een belangrijke klantbeoordeling.

Verpakkingsbewijs voor verschillende doelgroepen

Verschillende doelgroepen hebben verschillende delen van dezelfde bewijsbibliotheek nodig: auditors willen traceerbaarheid, klanten willen specifieke zekerheid voor hun huurders en leidinggevenden willen inzicht in risico's en trends. Door vooraf een paar standaardpakketten samen te stellen, wordt elk gesprek gecontroleerder en efficiënter.

Externe auditors willen vaak traceerbaarheid. Ze verwachten een pad te volgen van controledoelstellingen en beleidsbepalingen, via procedures, naar voorbeelden van daadwerkelijke toegangsbeslissingen en uiteindelijk naar logs en beoordelingsverslagen. Zakelijke klanten willen doorgaans zekerheid per gebruiker: wie van uw organisatie heeft toegang tot hun systemen, wat mogen ze doen en hoe wordt die toegang beheerd? Intern management zal zich waarschijnlijk richten op risicoblootstelling en trends.

Het is de moeite waard om een kleine set standaard bewijspakketten samen te stellen die specifiek zijn afgestemd op deze doelgroepen. Een auditorpakket kan het centrale toegangscontrolebeleid, gerelateerde procedures, voorbeelden van toegangsaanvragen en goedkeuringen, beoordelingsgegevens voor een bepaalde periode en samenvattende rapporten van uw tools bevatten. Een klantpakket kan zich richten op hoe uw medewerkers specifiek toegang krijgen tot hun omgeving, wie er momenteel toegang heeft, hoe die toegang is goedgekeurd en hoe vaak deze wordt beoordeeld. Een intern leiderschapspakket kan de belangrijkste statistieken, recente verbeteringen en eventuele openstaande risico's benadrukken.

Door te oefenen hoe u deze pakketten bespreekt, kunt u hiaten in zowel het bewijs als de verhaallijn aan het licht brengen. Door interne mock audits of due diligence-sessies uit te voeren die zich uitsluitend richten op toegangsbeheer, kunnen uw teams zich op hun gemak voelen bij het uitleggen hoe Bijlage A.5.15 in uw MSP is geïmplementeerd. Organisaties die investeren in deze voorbereiding, merken doorgaans dat echte audits en klantbeoordelingen meer aanvoelen als een bevestiging van goede praktijken dan als een zoektocht naar zwakke punten.

Boek vandaag nog een demo met ISMS.online

ISMS.online helpt u om Bijlage A.5.15 om te zetten van een statisch beleidsdocument naar een meer dynamische praktijk voor toegangsbeheer die aansluit bij de manier waarop veel MSP's werken. In plaats van te jongleren met spreadsheets, verspreide documenten en toolspecifieke rapporten, kunt u uw toegangsregels, verantwoordelijkheden, risico's en bewijsmateriaal beheren in één verbonden werkruimte.

Bekijk uw centrale toegangsbeleid in actie

Wanneer uw centrale toegangscontrolebeleid gekoppeld is aan dagelijkse taken en bewijs, is het geen theorie meer en wordt het richtinggevend voor echte beslissingen. In ISMS.online kunt u uw centrale MSP-toegangscontrolebeleid hosten, direct koppelen aan Bijlage A.5.15, A.5.16 en A.8.2, en eigenaarschap toewijzen aan elk onderdeel, zodat verantwoordelijkheden altijd duidelijk zijn.

U kunt ook actueel bewijsmateriaal aan elke controle toevoegen: toegangsbeoordelingsgegevens, samenvattingen van identiteitsplatforms, rapporten over bevoorrechte toegang en notulen van klantbestuursvergaderingen. Wanneer een auditor of klant vraagt hoe u de toegang beheert, hoeft u niet te zoeken naar documenten; u leidt hen door een gestructureerd, actueel overzicht van uw bestuursmodel dat weerspiegelt hoe u vandaag de dag daadwerkelijk functioneert.

Als u het nuttig vindt om een uitgewerkt voorbeeld van dit soort bibliotheek voor toegangsbeheer in een live systeem te zien, kan het ISMS.online-team u uitleggen hoe andere MSP's hun Annex A.5.15-verdieping in de praktijk structureren en waar u vergelijkbare patronen kunt aanpassen.

Toegangsbeheer wordt veel eenvoudiger te handhaven wanneer beoordelingen, uitzonderingen en verbeteringen worden afgehandeld via een gedeelde workflow in plaats van ad-hocwerk. ISMS.online is ontworpen om die workflow te ondersteunen door u te helpen bij het plannen van beoordelingen, het volgen van uitzonderingen en het beheren van verbeteringen in de loop van de tijd.

U kunt terugkerende taken voor toegangsbeoordelingen instellen, deze koppelen aan specifieke systemen of klanten en beslissingen vastleggen op een manier die gemakkelijk terug te vinden is. Uitzonderingen op uw toegangsbeleid kunnen worden vastgelegd met risicobeoordelingen, goedkeuringen en vervaldata, zodat u controle kunt aantonen, zelfs wanneer u van de basislijn moet afwijken. Rolgebaseerde weergaven maken het voor oprichters, CISO's, compliancemanagers en accountmanagers eenvoudig om de aspecten van Bijlage A.5.15 te zien die voor hen het belangrijkst zijn.

Wilt u overstappen van beleidsmatig op papier of toolgestuurde maar onbeheerde toegang naar een governance-gestuurd, evidence-ready model? ISMS.online is ontworpen om u daarbij op een gestructureerde manier te helpen. Wanneer u er klaar voor bent, kunt u in een gesprek met het team zien hoe u uw huidige Annex A.5.15-realiteit kunt omzetten in een coherente werkruimte voor toegangsbeheer die ISO 27001, klantvertrouwen en dagelijkse werkzaamheden ondersteunt.

Demo boeken

Veelgestelde Vragen / FAQ

Wat verwacht ISO 27001:2022 Bijlage A.5.15 nu werkelijk van een MSP?

Bijlage A.5.15 verwacht dat uw MSP één samenhangende, op risico's gebaseerde aanpak hanteert bij het nemen van beslissingen wie heeft toegang tot wat, en om te kunnen bewijzen dat u zich eraan houdt. Dat geldt voor uw eigen platformen en elke route die uw mensen, partners en tools gebruiken naar klantgebruikers.

Wat betekent dit nu werkelijk voor de dagelijkse werkzaamheden van MSP?

In de praktijk verwachten auditors en zakelijke klanten dat twee dingen samenwerken:

A duidelijk, schriftelijk toegangscontrolebeleid waarin het volgende wordt uiteengezet:
Toepassingsgebied: interne systemen, gedeelde consoles, externe hulpmiddelen, VPN's en elke klant die uw personeel kan bereiken.
Principes: minimale privileges, scheiding van taken, benoemde accounts, sterke authenticatie en standaardweigering.
Rollen en toegangscategorieën: standaardgebruiker, beheerder, breekglas/noodgeval en derde partij, met maximale toegang voor elk.
Goedkeuringsregels: wie mag welke vorm van toegang goedkeuren, onder welke voorwaarden en voor hoe lang.
Beoordelingsritme: hoe vaak de toegang wordt gecontroleerd, door wie en voor welke systemen en tenants.

Bewijs dat deze regels worden nageleefd:
Toegangsaanvragen en goedkeuringen gekoppeld aan tickets of workflowitems, zodat u het beslissingstraject kunt weergeven.
Logboeken die aantonen dat bevoorrechte toegang gebruikmaakt van benoemde, MFA-beveiligde accounts in plaats van gedeelde inloggegevens.
Registraties van geplande toegangscontroles voor interne systemen en representatieve klanthuurders, met betrokkenheid van de klant voor omgevingen met een hoger risico.

Een auditor selecteert vaak een regel in uw beleid, traceert deze in uw proces en neemt vervolgens steekproeven van echte verzoeken, logs en controlegegevens. Als ze die lijn duidelijk kunnen volgen voor uw eigen platforms en een paar typische tenants, voldoet u aan de bedoeling van Bijlage A.5.15 in plaats van alleen maar de bewoordingen te herhalen.

Waarom is deze controle zo'n knelpunt voor MSP's?

Uw grootste blootstelling zit in de paden naar klantsystemen, niet alleen in uw backofficetools. In Bijlage A.5.15 toont u aan dat:

Toegang tot elke huurder is opzettelijk, gerechtvaardigd en regelmatig herzien, geen overblijfsel van oude projecten.
Voor contractanten, offshoreteams en externe NOC/SOC-providers gelden dezelfde toegangsregels als vast personeel.
Multi-tenant tools en consoles vertrouwen op benoemde, geregistreerde en tijdgebonden beheerderstoegang, nooit generieke accounts die binnen het team worden gedeeld.

Wanneer A.5.15 de hub wordt die identiteit, privileged access, leveranciersbeheer en logging met elkaar verbindt, kunt u uw toegangsmodel veel overtuigender uitleggen aan auditors en zakelijke kopers. Wilt u dat die hub op een praktische plek staat in plaats van in een statisch document? Dan biedt ISMS.online u één plek om beleid, taken en bewijs te koppelen, zodat u kunt laten zien, en niet alleen vertellen, hoe de toegang wordt beheerd binnen uw MSP en elke tenant die u ondersteunt.

Hoe moet een MSP één toegangscontrolebeleid ontwerpen dat voor meerdere tenants werkt?

U ontwerpt één enkel, werkbaar toegangscontrolebeleid door het te schrijven vanuit eerst het perspectief van uw MSP, en daarbovenop klantspecifieke vereisten. Het kernbeleid definieert hoe uw mensen en tools zich overal gedragen; lichtgewicht tenantprofielen registreren waar individuele klanten meer restricties nodig hebben.

Wat hoort in het kernbeleid voor toegangscontrole van MSP's?

Een praktische, MSP-vriendelijke structuur omvat doorgaans:

Doel en reikwijdte:

Geef aan dat het beleid betrekking heeft op uw platforms, gedeelde consoles, mechanismen voor externe toegang en alle klanttenants waarmee u in aanraking komt.

Principes en normen:

Leg uit hoe u de minimale privileges, scheiding van taken, geen generieke accounts en sterke authenticatie toepast en aan welke kaders of regelgevingen u zich houdt (bijvoorbeeld ISO 27001 en ISO 27002).

Standaardrollen en toewijzingen:

Beschrijf rollen zoals servicedesk-analist, netwerktechnicus, cloudtechnicus, beveiligingsanalist, projecttechnicus en accountmanager en stel de maximale toegang in die elke rol heeft tot verschillende soorten systemen.

Toegangscategorieën:

Definieer standaardtoegang, toegang met privileges, toegang voor noodgevallen/breekglas en toegang voor derden, met duidelijke regels voor hoe deze worden aangevraagd, verleend, gebruikt en vastgelegd voor alle tenants.

Goedkeuringsregels en bewijs:

Maak duidelijk wie welk type toegang kan goedkeuren, waar die goedkeuringen worden vastgelegd, hoe lang u ze bewaart en hoe ze aan tickets of wijzigingen worden gekoppeld.

Beoordelingsfrequentie en triggers:

Stel regelmatige beoordelingscycli in voor gebruikers- en beheerderstoegang en noteer extra triggers, zoals organisatorische wijzigingen, nieuwe services of grote incidenten.

Uitzonderingsafhandeling:

Leg uit hoe tijdelijke afwijkingen worden aangevraagd, op risico worden beoordeeld, aan een tijdslimiet worden gebonden en worden beoordeeld, zodat eenmalige toegang niet stilzwijgend permanent kan worden.

Je kunt dan korte huurdersprofielen die extra vereisten voor encryptie, scheiding, goedkeuring of registratie voor specifieke sectoren of klanten (bijvoorbeeld de publieke sector, de gezondheidszorg of de financiële sector) vastleggen.

Hoe kun je deze structuur gebruiksvriendelijk maken voor ingenieurs?

Een beleid dat alleen compliance en auditors kunnen begrijpen, zal nooit het dagelijks gedrag bepalen. MSP's behalen veel betere resultaten wanneer ze:

Maak korte, rolspecifieke handleidingen uit het hoofdbeleid (bijvoorbeeld “Toegangsregels voor medewerkers van de servicedesk” of “Hoe maak ik veilig gebruik van breekglastoegang”).
Spiegel het beleid in tooling door gebruik te maken van toegangsaanvraagtypen, wijzigingssjablonen en runbooks die overeenkomen met de categorieën en regels in het document.
Behoud het hoofdbeleid lean en principe-gebaseerden verplaats gedetailleerde ‘klik hier, dan hier’-instructies naar standaarden, procedures en draaiboeken.

Als een engineer een handleiding kan raadplegen en direct kan zien wat hij of zij in een bepaalde tenant mag doen, begint het beleid te werken als een echte tool voor toegangsbeheer. ISMS.online helpt u het kernbeleid, de richtlijnen per rolniveau en de tenantspecifieke vereisten in één omgeving te verbinden, zodat wijzigingen in uw toegangsmodel worden doorgevoerd in uw dagelijkse werkzaamheden in plaats van in een ongelezen document.

Hoe kunnen MSP's Bijlage A.5.15 combineren met identiteit en bevoorrechte toegang, zodat rechten niet uit de hand lopen?

U houdt de toegang onder controle door ervoor te zorgen dat: één set toegangsregels stuurt uw identiteitslevenscyclus, rolontwerp en privileged access-patronen aan. Bijlage A.5.15 beschrijft de verwachtingen voor "wie heeft toegang tot wat"; identiteitsbeheer en privileged access zijn de gebieden waar deze verwachtingen consistent worden gehandhaafd in elk systeem en elke tenant.

Hoe ziet een geïntegreerd identiteits- en toegangsmodel eruit voor een MSP?

Voor Bijlage A.5.15 zijn uw identiteits- en privileged access-processen de plek waar het beleid daadwerkelijke beslissingen vormt. Een geïntegreerd model omvat doorgaans:

A proces van toetreder, verhuizer en verlater dat iedereen omvat die klanthuurders kan bereiken, inclusief aannemers en langetermijnpartners.
Identiteiten gecreëerd en veranderd door gedefinieerde rollen, geen ad-hoc rechtenlijsten, waarbij deze rollen worden bijgewerkt wanneer services of technologieën veranderen.
Verhuizers die toegang hebben verwijderd en toegevoegd op uw eigen platforms en alle betrokken klanttenants, waarbij de wijzigingen worden vastgelegd en, waar nodig, worden goedgekeurd door zowel uw MSP als de klant.
Werknemers die vertrekken, worden volledig uit de interne systemen, gedeelde tools en alle klantentenants verwijderd. Een aangewezen persoon moet ondertekenen dat dit is gebeurd.

Aan de bevoorrechte kant zou een consistent model het volgende kunnen omvatten:

Benoemde beheerdersaccounts: met multifactorauthenticatie voor tenant-level of andere systemen met een hoog risico, nooit gedeelde inloggegevens.
Just-in-time of tijdgebonden hoogte: voor gevoelige taken, gekoppeld aan een wijziging, incident of onderhoudsvenster.
Strikte controle over wie bevoorrechte toegang mag goedkeuren, waarbij goedkeuringen worden vastgelegd in uw ITSM- of ticketplatform.
geplande toegang beoordelingen voor bevoorrechte rollen, gezamenlijk uitgevoerd met klanten voor kritische of gereguleerde huurders.

Wanneer deze elementen op elkaar zijn afgestemd, wordt het veel gemakkelijker om een auditor of klant te laten zien dat Bijlage A.5.15 door uw identiteits-, toegangs- en privileged access-tools loopt, in plaats van dat het op papier blijft staan. Platforms zoals ISMS.online vereenvoudigen deze traceerbaarheid door uw toegangsbeleid, controlegegevens en bewijsmateriaal te koppelen, zodat u met een paar klikken kunt aantonen hoe de levenscyclus van een individuele persoon is verlopen, van de eerste toegang tot de definitieve intrekking.

Welke zwakke punten op het gebied van toegangscontrole komen auditors en zakelijke klanten het vaakst tegen bij MSP's?

De meest voorkomende zwakheden komen naar voren waar vastgestelde regels en toegang in de echte wereld komen niet overeen, vooral op het snijvlak tussen uw MSP en klant-tenants. Lacunes in multi-tenant tools, gedeelde consoles en platforms voor externe toegang zijn bijzonder veelgebruikte onderzoeksgebieden.

Welke specifieke patronen komen steeds weer naar voren?

Terugkerende problemen zijn onder meer:

Beleid dat betrekking heeft op ‘alle medewerkers’, maar in de praktijk toezicht houden op aannemers, offshoreteams of operationele centra van derden.
Onvolledige of ongedocumenteerde offboarding: , met name van huurders van klanten en gedeelde tools wanneer medewerkers of contractanten van functie veranderen of helemaal vertrekken.
Gedeelde of generieke beheerdersaccounts: in tools voor bewaking op afstand, PSA, back-up of beveiliging die meerdere huurders bedienen.
Oude accounts in klantsystemen waarvan niemand duidelijk de eigenaar is en waarvoor geen geldige reden is voor de toegang die ze nog steeds hebben.
Beoordelingen van onregelmatige toegang: of beoordelingen die alleen betrekking hebben op interne systemen en klantgerichte platforms en tenants negeren.
Tijdelijke of noodtoegang die nooit goed is geregeld tijdgebonden, opnieuw goedgekeurd of ingetrokken, en is langzaam een permanent karakter gaan krijgen.
Heb je moeite met het beantwoorden van simpele vragen zoals: "Wie van jouw organisatie heeft vandaag administratief toegang tot onze productietenant?"

Zelfs als geen van deze hiaten tot nu toe tot een incident heeft geleid, maken ze zakelijke klanten nerveus. Veel MSP-toegang wordt nu beschouwd als onderdeel van hun bredere supply chain risico, dus zullen ze deze punten dieper onderzoeken in due diligence-, verlengings- en incidentresponsgesprekken.

Hoe beïnvloeden deze hiaten het commerciële risico?

Wanneer een klant of auditor inconsistente toegangscontrole constateert, gebeuren er meestal drie dingen:

Ze bevindingen verhogen en verwacht dat er herstelplannen worden opgesteld, wat tijd kost en de verkoopcyclus of verlenging kan vertragen.
Ze de reikwijdte beperken van systemen of gegevens die u kunt bereiken of extra controles kunt opleggen, waardoor het moeilijker wordt om efficiënte ondersteuning te bieden.
In ernstiger gevallen kunnen ze opnieuw aanbesteden of diversifiëren weg bij uw MSP als het vertrouwen in uw toegangsbeheer verder afneemt.

Het versterken van Bijlage A.5.15 is daarom ook een commerciële strategie. Als u kunt aantonen dat de toegang tot elke gebruiker wordt gecontroleerd, gerechtvaardigd en beoordeeld, is de kans veel groter dat u wordt behandeld als een langetermijnbewaker van de klantomgevingen in plaats van als een willekeurige verwisselbare leverancier.

Hoe kan een MSP aan auditors en zakelijke klanten laten zien dat zijn toegangsbeheer effectief is?

U toont effectief toegangsbeheer door een helder, consistent verhaal Hoe uw toegangsregels zich vertalen naar dagelijks gedrag, en door dat verhaal te onderbouwen met geordend bewijs. Verschillende doelgroepen kijken vanuit een iets andere hoek, maar ze willen allemaal bewijs dat uw aanpak gestructureerd, herhaalbaar en niet afhankelijk is van één of twee heldhaftige individuen.

Welk soort bewijsstructuur werkt goed voor Bijlage A.5.15?

Voor Bijlage A.5.15 maakt een "bewijsbibliotheek voor toegangsbeheer" het eenvoudig om te laten zien hoe beleid in de praktijk wordt omgezet. Een eenvoudige, gelaagde structuur ziet er als volgt uit:

Beleid en reikwijdte
Uw toegangscontrolebeleid is gekoppeld aan Bijlage A.5.15 en bijbehorende controles, waarbij de systemen en tenants die binnen het toepassingsgebied vallen duidelijk worden vermeld.
Procedures en normen
Documenten waarin wordt uitgelegd hoe u mensen aanneemt en afmeldt, hoe u bevoorrechte en noodtoegang beheert en toegangsbeoordelingen uitvoert.
Workflow-records
Toegangsaanvragen, goedkeuringen en wijzigingsrapporten voor vertegenwoordigers en huurders, waaruit blijkt dat de procedures in reële gevallen worden gevolgd.
Logboeken en rapportage
Logboeken van identiteitsproviders, hulpmiddelen voor externe toegang en beheerconsoles, plus periodieke rapporten over bevoorrechte toegang en resultaten van toegangscontroles.
Beoordelingen en bestuur
Notulen of verslagen van toegangsbeoordelingssessies, vergaderingen met klantbestuur en goedkeuringen door het management van belangrijke wijzigingen of uitzonderingen.

Als je eenmaal weet waar elk van deze zich bevindt, kun je beknopte overzichten maken bewijspakketten voor verschillende behoeften:

Een gericht pakket voor ISO 27001-auditors en andere assessoren.
Een klantgericht pakket ter ondersteuning van leveranciersbeveiligingsbeoordelingen en due diligence-vragenlijsten.
Een intern pakket voor leidinggevenden om te laten zien hoe toegangsbeheer risicomanagement, veerkracht en servicekwaliteit ondersteunt.

Hoe ga je hiermee om in een vergadering?

In gesprekken met auditors of zakelijke klanten is het nuttig om alles te baseren op echte voorbeelden:

Loop er een of twee door echte gebruikersreizen – bijvoorbeeld de toetreding van een nieuwe engineer, een rolwijziging en een vertrek van een engineer – en laat zien hoe toegang is aangevraagd, goedgekeurd, verleend, geregistreerd en beoordeeld in ten minste één intern systeem en één tenant.
Laat zien hoe uitzonderingen en noodtoegang worden aangevraagd, tijdgebonden en opgeruimd, met bewijs van goedkeuringen en opvolging.
Leg uit hoe je drift detecteren en corrigerenbijvoorbeeld door middel van geplande beoordelingen waarin de huidige toegang wordt vergeleken met de beoogde rollen en huurderspecifieke vereisten.

Deze walkthrough laat zien dat Bijlage A.5.15 is ingebed in het werkritme van uw MSP. Met ISMS.online kunt u dit verhaal met meer vertrouwen oefenen en presenteren, omdat het beleid, de taken en het bewijs voor elk van deze trajecten op één plek staan in plaats van verspreid over meerdere mappen, inboxen en tools.

Hoe kan ISMS.online een MSP helpen om Bijlage A.5.15 uit te voeren als een actieve praktijk voor toegangsbeheer?

ISMS.online helpt u om Bijlage A.5.15 van een statisch document naar een workflow voor verbonden toegangsbeheer Dat weerspiegelt hoe uw MSP daadwerkelijk mensen onboardt, toegang verleent en risicovolle tenants beoordeelt. In plaats van regels en bewijsmateriaal te verspreiden over bestanden, schijven en inboxen, beheert u ze in één ISMS, gebouwd voor ISO 27001:2022.

Hoe ondersteunt ISMS.online Bijlage A.5.15 in het dagelijks leven?

Binnen ISMS.online kunt u:

Houd uw centraal MSP-toegangscontrolebeleid op één plek, koppel het direct aan Bijlage A.5.15 (en gerelateerde controles zoals A.5.16 en A.8.2) en wijs eigenaren en revisiedata toe, zodat het aansluit bij de manier waarop u werkt.
creëren gekoppelde besturingselementen, acties en taken voor belangrijke activiteiten zoals provisioning, wijzigingen in bevoorrechte toegangsrechten, noodtoegang en geplande toegangscontroles, zodat verantwoordelijkheden duidelijk zijn.
Plannen en volgen terugkerend werk – kwartaallijkse toegangsbeoordelingen, jaarlijkse beleidsaanpassingen en klantspecifieke governancecontroles – met statusoverzichten die laten zien waar aandacht nodig is.
hechten bewijzen zoals bevestigingen van toegangsbeoordelingen, export van beheerdersrechten en notulen van vergaderingen rechtstreeks naar de relevante controles en taken. Zo zien auditors en klanten het volledige verhaal zonder dat u onder druk screenshots hoeft te maken.
vangen klantspecifieke vereisten door middel van aanvullende controles, projecten of notities, waardoor u duidelijk inzicht krijgt in welke huurders buiten de basislijn vallen en hoe u in de praktijk met die verschillen omgaat.

Hierdoor wordt het veel eenvoudiger om vragen te beantwoorden zoals 'wie heeft toegang tot deze tenant, hoe is die toegang goedgekeurd en wanneer is die voor het laatst gecontroleerd?', zonder dat je daarvoor allerlei tools hoeft te gebruiken.

Hoe beïnvloedt het gebruik van ISMS.online de manier waarop klanten en auditors uw MSP ervaren?

Wanneer uw toegangsbeheer duidelijk is vastgelegd, gekoppeld en bewaakt in ISMS.online, toont u aan dat:

Consistente normen: worden toegepast op alle tenants, in plaats van dat elke omgeving afzonderlijk wordt behandeld.
Uitzonderingen en noodtoegang: worden doelbewust vastgelegd en opnieuw bekeken, in plaats van dat ze stilletjes op de achtergrond blijven.
Toegangsbeheer wordt behandeld als onderdeel van uw kernkwaliteit van de dienstverlening, niet alleen een certificeringsselectievakje.

Dat is belangrijk als u wilt dat klanten uw MSP zien als een bewaker van hun omgeving op de lange termijn, en niet alleen als een extra paar handen. Wilt u een concreet beeld krijgen van hoe snel uw huidige Annex A.5.15-aanpak onder controle kan worden gebracht? Dan is het vaak het snelst om de tijd te nemen om een ISMS.online-werkruimte voor toegangsbeheer te doorlopen met een aantal van uw eigen gebruikers in gedachten. Zo kunt u bepalen of dit de juiste keuze is voor uw team en uw groeiplannen.