Gids voor ISO 27001-auditbewijs voor toegangscontrole

Het is 09:10 op auditdag. Maria, de CISO van een snelgroeiend FinTech- en cloudplatform, heeft haar toegangscontrolebeleid openstaan. De IT-verantwoordelijke exporteert instellingen voor voorwaardelijke toegang uit de identiteitsprovider. HR zoekt naar het beëindigingsticket van een financieel analist die zes weken geleden is vertrokken. De interne auditor kijkt op en stelt de vraag waarvan iedereen wist dat die zou komen:

“Toon mij hoe toegang wordt aangevraagd, goedgekeurd, afgedwongen, beoordeeld en ingetrokken voor een gebruiker met geprivilegieerde toegang tot persoonsgegevens.”

Die ene zin kan blootleggen of een toegangscontroleprogramma auditgereed is of alleen op papier op orde lijkt.

Maria’s team had een volwassen managementsysteem voor informatiebeveiliging (ISMS), een jaarlijkse ISO/IEC 27001:2022-hercertificeringscyclus, multifactorauthenticatie, rolgebaseerde toegangscontrole in kernsystemen en spreadsheets voor kwartaalbeoordelingen van toegangsrechten. Maar deze audit was anders. De verzoekenlijst van de auditor omvatte ook voorbereiding op opkomende wettelijke en toezichteisen. Voor Maria’s organisatie betekende dat NIS2, DORA en GDPR, allemaal beoordeeld vanuit dezelfde operationele invalshoek: identiteit, toegang, authenticatie, privileges en bewijs.

Het probleem voor veel CISO’s is niet dat toegangscontrole ontbreekt. Het probleem is dat bewijs versnipperd is. Onboardinggoedkeuringen staan in Jira of ServiceNow. MFA-instellingen staan in Microsoft Entra ID, Okta of een andere identiteitsprovider. Machtigingen voor AWS, Azure en Google Cloud staan in afzonderlijke consoles. Geprivilegieerde handelingen kunnen in een PAM-tool worden gelogd, of helemaal niet. HR-statussen staan in BambooHR, Workday of spreadsheets. Toegangsrechtenbeoordelingen worden soms per e-mail goedgekeurd.

Wanneer een auditor IAM, MFA, PAM, gebeurtenissen voor instroom, doorstroom en uitstroom, persoonsgegevens, cloudbeheer en wettelijke verwachtingen met elkaar verbindt, valt versnipperd bewijs snel uiteen.

ISO/IEC 27001:2022-audits van toegangscontrole zijn niet alleen technische configuratiebeoordelingen. Het zijn toetsen van het managementsysteem. Zij beoordelen of risico’s rond identiteit en toegang worden begrepen, behandeld, geïmplementeerd, gemonitord en verbeterd. Wanneer NIS2, DORA en GDPR ook relevant zijn, moet hetzelfde bewijs risicogebaseerde toegangsgovernance, sterke authenticatie, traceerbare goedkeuringen, tijdige intrekking, beperking van privileges, bescherming van persoonsgegevens en verantwoordingsplicht van het management aantonen.

Het praktische antwoord is geen grotere ordner. Het is één bewijsmodel voor toegangscontrole dat begint bij het ISMS-toepassingsgebied en risico, doorloopt via beleid en ontwerp van beheersmaatregelen, landt in IAM- en PAM-tooling en helder mapt op ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST en COBIT.

Waarom toegangscontrole de regelgevende spil is

Toegangscontrole is een onderwerp op bestuursniveau en voor toezichthouders geworden, omdat compromittering van identiteiten inmiddels een veelvoorkomend pad is naar operationele verstoring, datalekken, fraude en blootstelling in de toeleveringsketen.

Onder NIS2 brengen Articles 2 en 3, gelezen in samenhang met Annex I en Annex II, veel middelgrote en grotere entiteiten in genoemde sectoren binnen de reikwijdte als essentiële of belangrijke entiteiten. Dit omvat digitale infrastructuur en aanbieders van ICT-dienstenbeheer, zoals cloudserviceproviders (CSP’s), datacenterdienstverleners, managed service providers en managed security service providers. Lidstaten moesten NIS2 uiterlijk in oktober 2024 omzetten en nationale maatregelen vanaf oktober 2024 toepassen, met entiteitenlijsten die in april 2025 moesten worden opgesteld. Article 20 maakt bestuursorganen verantwoordelijk voor het goedkeuren van maatregelen voor cyberbeveiligingsrisicobeheer en het toezicht op de implementatie. Article 21 vereist technische, operationele en organisatorische maatregelen, waaronder toegangscontrolebeleid, beheer van bedrijfsmiddelen, cyberhygiëne, incidentafhandeling, bedrijfscontinuïteit, beveiliging van de toeleveringsketen en MFA of continue authenticatie waar passend.

DORA voegt een sectorspecifieke laag voor operationele weerbaarheid toe voor financiële entiteiten en relevante externe ICT-dienstverleners. Articles 1, 2 en 64 stellen DORA vast als een uniform raamwerk dat van toepassing is vanaf 17 januari 2025. Articles 5 en 6 vereisen governance en een gedocumenteerd kader voor ICT-risicobeheer. Article 9 behandelt bescherming en preventie, waaronder ICT-beveiligingsbeleid, procedures, protocollen en tools. Articles 24 tot en met 30 voegen testen van digitale operationele weerbaarheid en ICT-risicobeheer voor derden toe. Voor financiële entiteiten wordt bewijs voor toegangscontrole daarmee bewijs voor weerbaarheid, niet alleen bewijs voor IT-beheer.

GDPR brengt het perspectief van persoonsgegevens. Articles 2 en 3 definiëren brede toepasselijkheid voor verwerking in de EU en bereik tot de EU-markt. Article 5 vereist integriteit, vertrouwelijkheid en aantoonbare verantwoordingsplicht. Article 25 vereist gegevensbescherming door ontwerp en door standaardinstellingen. Article 32 vereist passende technische en organisatorische maatregelen. In de praktijk betekent dit gecontroleerde toegang, veilige authenticatie, logging, beoordeling en tijdige verwijdering voor systemen die persoonsgegevens verwerken.

ISO/IEC 27001:2022 biedt organisaties de managementsysteemmotor om deze verplichtingen te verenigen. Clausules 4.1 tot en met 4.3 vereisen dat de organisatie context, belanghebbenden, wettelijke en contractuele eisen, interfaces, afhankelijkheden en het ISMS-toepassingsgebied begrijpt. Clausules 6.1.1 tot en met 6.1.3 vereisen informatiebeveiligingsrisicobeoordeling, risicobehandeling, vergelijking met Annex A, een Verklaring van Toepasselijkheid en goedkeuring van behandelplannen en restrisico. Clausule 8.1 vereist operationele beheersing, gedocumenteerde informatie waaruit blijkt dat processen volgens plan zijn uitgevoerd, wijzigingsbeheer en beheersing van extern geleverde processen.

De auditvraag is daarom niet: “Hebt u MFA?” De vraag is: “Kunt u voor identiteiten en systemen binnen de reikwijdte aantonen dat toegangsrisico wordt bestuurd, behandeld, geïmplementeerd, gemonitord en verbeterd?”

Bouw de bewijsruggengraat van ISMS-toepassingsgebied naar IAM-bewijs

Clarysec start de voorbereiding op audits van toegangscontrole door bewijs traceerbaar te maken vanuit de bedrijfscontext. ISO/IEC 27001:2022 verwacht dat het ISMS is geïntegreerd in organisatieprocessen en is afgestemd op de behoeften van de organisatie. Een SaaS-leverancier met 30 medewerkers en een multinationale bank hebben niet dezelfde toegangsarchitectuur, maar beide hebben een samenhangende bewijsketen nodig.

ISO/IEC 27005:2022 is nuttig omdat deze norm aanbeveelt om wettelijke, regelgevende, contractuele, sectorspecifieke en interne eisen te consolideren in een gemeenschappelijke risicocontext. Clausules 6.4 en 6.5 benadrukken risicocriteria die rekening houden met organisatiedoelstellingen, wetgeving, leveranciersrelaties en beperkingen. Clausules 7.1 en 7.2 staan gebeurtenisgebaseerde en assetgebaseerde scenario’s toe. Voor toegangscontrole betekent dit dat strategische scenario’s worden beoordeeld, zoals “geprivilegieerde SaaS-beheerder exporteert EU-klantgegevens”, naast assetscenario’s zoals “verweesde AWS IAM-sleutel gekoppeld aan productieopslag”.

In Clarysecs Zenith Blueprint: de 30-stappenroadmap voor auditors wordt deze bewijsruggengraat opgebouwd tijdens de fase Controls in Action. Stap 19 richt zich op technische beheersmaatregelen voor endpoint- en toegangsbeheer, terwijl stap 22 de organisatorische toegangslevenscyclus formaliseert.

De Zenith Blueprint instrueert teams te verifiëren dat toegangsverlening en deprovisioning gestructureerd zijn, waar mogelijk met HR zijn geïntegreerd, worden ondersteund door toegangsaanvraagworkflows en elk kwartaal worden beoordeeld. Ook instrueert de blueprint organisaties om identiteitstypen te documenteren, beheersmaatregelen af te dwingen voor individuele, gedeelde en service-identiteiten, sterke wachtwoordbeleidsregels en MFA toe te passen, inactieve accounts te elimineren en veilige kluisopslag of documentatie voor servicereferenties te onderhouden.

Dat is precies hoe auditors toegangscontrole toetsen: één identiteit, één systeem, één goedkeuring, één privilege, één beoordeling en één intrekking tegelijk.

Wat u moet verzamelen voor auditgereed bewijs voor toegangscontrole

Uw bewijsdossier voor toegangscontrole moet een auditor in staat stellen elke gebruiker te selecteren en de levenscyclus te volgen: aanvraag, goedkeuring, toewijzing, authenticatie, privilegeverhoging, monitoring, beoordeling en intrekking.

Een sterk bewijsdossier bevat:

1. Toegangscontrolebeleid en beleid voor gebruikersaccounts
2. Procedure voor instroom, doorstroom en uitstroom
3. Rollenmatrix of toegangscontrolematrix
4. Lijst van applicaties, platforms en gegevensrepositories binnen de reikwijdte
5. MFA-configuratie van de identiteitsprovider
6. Beleidsregels voor voorwaardelijke toegang en uitzonderingenlijst
7. Inventaris van geprivilegieerde accounts
8. Bewijs van PAM-workflows, waaronder goedkeuringen en sessielogboeken
9. Recente output van toegangsbeoordelingscampagnes
10. Voorbeelden van managementattesten en herstelmaatregelen
11. HR-beëindigingsrapport gekoppeld aan deactiveringslogboeken
12. Inventaris van serviceaccounts, eigenaren, rotatieregistraties en bewijs van kluisopslag
13. Procedure voor break-glass-beheerdersaccounts en testlogboek
14. Bewijs van incidenten of waarschuwingen rond mislukte aanmeldingen, privilege-escalatie of inactieve accounts
15. Vermeldingen in de Verklaring van Toepasselijkheid voor toegangsgerelateerde Annex A-beheersmaatregelen

Clarysec-beleid maakt deze verwachting expliciet. In het mkb-Toegangscontrolebeleid is de eis eenvoudig en auditgericht:

“Voor alle toegangsverlening, wijzigingen en verwijderingen moet een veilige registratie worden bijgehouden.”

Uit sectie “Vereisten voor beleidsimplementatie”, clausule 6.1.1.

Hetzelfde mkb-beleid koppelt RBAC en MFA ook direct aan rolverantwoordelijkheden:

“Implementeert rolgebaseerde toegangscontrole (RBAC) en dwingt sterke authenticatie af, bijvoorbeeld multifactorauthenticatie (MFA).”

Uit sectie “Rollen en verantwoordelijkheden”, clausule 4.2.3.

Voor grotere organisaties vereist het enterprise-Onboarding- en offboardingbeleid dat het IAM-systeem accountcreatie, rol- en machtigingstoewijzingen en deactiveringsgebeurtenissen logt, rolgebaseerde toegangssjablonen ondersteunt en integreert met HR-systemen voor triggers voor instroom, doorstroom en uitstroom. Die clausule helpt het auditverhaal op één plaats te vertellen: gestandaardiseerde onboarding, door HR getriggerde identiteitslevenscyclus en traceerbare IAM-gebeurtenissen.

Map IAM, MFA, PAM en beoordelingen op ISO/IEC 27001:2022-beheersmaatregelen

Clarysecs Zenith Controls: de gids voor geïntegreerde compliance behandelt toegangscontrole als een samenhangende familie van beheersmaatregelen, niet als een checklistitem. Voor ISO/IEC 27001:2022 zijn de meest relevante beheersmaatregelen:

• Beheersmaatregel 5.15, toegangscontrole
• Beheersmaatregel 5.16, identiteitsbeheer
• Beheersmaatregel 5.17, authenticatie-informatie
• Beheersmaatregel 5.18, toegangsrechten
• Beheersmaatregel 8.2, geprivilegieerde toegangsrechten
• Beheersmaatregel 8.3, beperking van informatietoegang
• Beheersmaatregel 8.5, veilige authenticatie
• Beheersmaatregel 8.15, logging
• Beheersmaatregel 8.16, monitoringactiviteiten

Voor authenticatie-informatie mapt Zenith Controls beheersmaatregel 5.17 als een preventieve beheersmaatregel die vertrouwelijkheid, integriteit en beschikbaarheid ondersteunt, met de operationele capaciteit Identiteits- en toegangsbeheer (IAM). De beheersmaatregel is direct gekoppeld aan identiteitsbeheer, veilige authenticatie, rollen en verantwoordelijkheden, aanvaardbaar gebruik en naleving van beleid. Beveiliging van referenties omvat de levenscyclus van authenticators, veilige uitgifte, opslag, reset, intrekking, MFA-tokens, privésleutels en servicereferenties.

Voor toegangsrechten mapt Zenith Controls beheersmaatregel 5.18 op formele toekenning, beoordeling, wijziging en intrekking. De beheersmaatregel is gekoppeld aan toegangscontrole, identiteitsbeheer, functiescheiding, geprivilegieerde toegangsrechten en compliancemonitoring. Dit is de beheersmaatregel die het principe van minimale privileges omzet in bewijs.

Voor geprivilegieerde toegangsrechten mapt Zenith Controls beheersmaatregel 8.2 op het bijzondere risico van verhoogde accounts, waaronder domeinbeheerders, root-gebruikers, cloudtenantbeheerders, database-superusers en CI/CD-controllers. De gids verbindt geprivilegieerde toegang met identiteitsbeheer, toegangsrechten, beperking van informatietoegang, veilige authenticatie, werken op afstand, logging en monitoring.

Eén goed ontworpen rapport voor toegangsrechtenbeoordelingen kan ISO/IEC 27001:2022, NIS2, DORA en GDPR ondersteunen als het toepassingsgebied, systeemeigenaar, beoordelaar, accountlijst, rolrechtvaardiging, aanduiding van geprivilegieerde toegang, besluiten, verwijderingen, uitzonderingen en voltooiingsdatum bevat.

MFA-bewijs is meer dan een screenshot

Een veelgemaakte auditfout is het tonen van een screenshot waarop “MFA ingeschakeld” staat. Auditors hebben meer nodig dan dat. Zij moeten weten waar MFA van toepassing is, wie is uitgesloten, hoe uitzonderingen worden goedgekeurd, of geprivilegieerde accounts zijn gedekt en of de technische configuratie overeenkomt met het beleid.

Vanuit de Zenith Blueprint, fase Controls in Action, stap 19, zullen auditors vragen hoe wachtwoord- en MFA-beleid worden afgedwongen, welke systemen zijn beschermd, op wie MFA van toepassing is en of kritieke applicaties met een voorbeeldaccount kunnen worden getest. Bewijs kan bestaan uit IdP-configuratie, beleidsregels voor voorwaardelijke toegang, MFA-inschrijvingsstatistieken en procedures voor wachtwoordreset.

Voor enterpriseomgevingen stelt Clarysecs Beleid inzake beheer van gebruikersaccounts en privileges:

“Waar technisch haalbaar is multifactorauthenticatie (MFA) verplicht voor: 6.3.2.1 Administratieve accounts en accounts op root-niveau 6.3.2.2 Toegang op afstand (VPN, cloudplatforms) 6.3.2.3 Toegang tot gevoelige of gereguleerde gegevens”

Uit sectie “Vereisten voor beleidsimplementatie”, clausule 6.3.2.

Dit creëert een directe auditbrug. Als MFA verplicht is voor beheerdersaccounts, toegang op afstand en gereguleerde gegevens, moet het bewijsdossier lijsten met administratieve accounts en accounts op root-niveau, configuratie voor toegang op afstand, beleidsregels voor voorwaardelijke toegang op cloudplatforms, lijsten met applicaties met gevoelige gegevens, MFA-inschrijvingsrapportages, goedkeuringen van uitzonderingen, compenserende beheersmaatregelen en recent bewijs van beoordeling van waarschuwingen voor mislukte aanmeldingen of MFA-bypasspogingen bevatten.

Voor NIST SP 800-53 Rev. 5 sluit dit aan op IA-2 Identification and Authentication, IA-5 Authenticator Management, AC-17 Remote Access en AU-2 Event Logging. Voor COBIT 2019 ondersteunt dit DSS05.04 Manage user identity and logical access en gerelateerde praktijken voor beveiligingsmonitoring.

Ondersteunende ISO-normen verbreden het beeld. ISO/IEC 27018:2020 breidt authenticatieverwachtingen uit voor publieke cloud die persoonsgegevens verwerkt. ISO/IEC 24760-1:2019 ondersteunt binding van authenticators en levenscyclusbeheer. ISO/IEC 29115:2013 introduceert niveaus voor authenticatie-assurance, nuttig bij het bepalen waar hardwaresleutels of phishingbestendige MFA noodzakelijk zijn. ISO/IEC 27033-1:2015 ondersteunt sterke netwerkauthenticatie voor toegang op afstand of tussen netwerken.

PAM-bewijs is de snelste route naar een majeure bevinding of een schone audit

Geprivilegieerde toegang is het punt waarop auditors sceptisch worden, omdat geprivilegieerde accounts beheersmaatregelen kunnen omzeilen, gegevens kunnen extraheren, persistentie kunnen creëren en logboeken kunnen wijzigen. In Zenith Blueprint, stap 19, staat:

“In elk informatiesysteem is geprivilegieerde toegang macht, en met die macht komt risico.”

De richtlijn richt zich op wie geprivilegieerde toegang heeft, wat deze toegang toestaat, hoe deze wordt beheerd en hoe deze in de tijd wordt gemonitord. Zij beveelt een actuele inventaris, het principe van minimale privileges, RBAC, tijdsgebonden of just-in-time-toegang, goedkeuringsworkflows, unieke persoonlijke accounts op naam, het vermijden van gedeelde accounts, break-glass-logging, PAM-systemen, rotatie van referenties, kluisopslag, sessieopname, tijdelijke privilegeverhoging, monitoring en periodieke beoordeling aan.

Clarysecs enterprise-Toegangscontrolebeleid vertaalt dit naar een vereiste voor beheersmaatregelen:

“Administratieve toegang moet strikt worden beheerst door: 5.4.1.1 Afzonderlijke geprivilegieerde accounts 5.4.1.2 Sessiemonitoring en -opname 5.4.1.3 Multifactorauthenticatie 5.4.1.4 Tijdsgebonden of workflowgestuurde privilegeverhoging”

Uit sectie “Governancevereisten”, clausule 5.4.1.

Dit citaat is bijna een audittestscript. Als het beleid afzonderlijke beheerdersaccounts voorschrijft, toon dan de lijst met geprivilegieerde accounts en bewijs dat elk account aan een persoon op naam is gekoppeld. Als het beleid sessiemonitoring voorschrijft, toon dan opgenomen sessies of PAM-logboeken. Als het beleid MFA voorschrijft, toon dan afdwinging voor elk pad voor geprivilegieerde toegang. Als het beleid tijdsgebonden privilegeverhoging voorschrijft, toon dan vervaltijdstempels en goedkeuringstickets.

De mkb-versie is even direct. Het Beleid inzake beheer van gebruikersaccounts en privileges voor het mkb stelt:

“Verhoogde of administratieve privileges vereisen aanvullende goedkeuring door de algemeen directeur of IT-verantwoordelijke en moeten worden gedocumenteerd, tijdsgebonden zijn en periodiek worden beoordeeld.”

Uit sectie “Vereisten voor beleidsimplementatie”, clausule 6.2.2.

Voor kleinere organisaties is dit vaak het verschil tussen “we vertrouwen onze beheerder” en “we beheersen geprivilegieerd risico”. De auditor vereist niet in elke mkb-organisatie enterprise-tooling, maar vereist wel bewijs dat in verhouding staat tot het risico. Een ticket, goedkeuring, tijdelijke groepstoewijzing, MFA-afdwinging en beoordelingsregistratie kunnen voldoende zijn wanneer de reikwijdte beperkt is en het risico lager is.

Toegangsrechtenbeoordelingen tonen aan dat het principe van minimale privileges werkt

Toegangsrechtenbeoordelingen laten zien of machtigingen ongemerkt opstapelen. Ze laten ook zien of managers begrijpen welke toegang hun teams daadwerkelijk hebben.

Het enterprise-Beleid inzake beheer van gebruikersaccounts en privileges vereist:

“Kwartaalbeoordelingen van alle gebruikersaccounts en bijbehorende privileges moeten door IT Security worden uitgevoerd in samenwerking met afdelingsmanagers.”

Uit sectie “Vereisten voor beleidsimplementatie”, clausule 6.5.1.

Voor mkb-organisaties hanteert het Beleid inzake beheer van gebruikersaccounts en privileges voor het mkb een proportionele cyclus:

“Elke zes maanden moet een beoordeling van alle gebruikersaccounts en privileges worden uitgevoerd.”

Uit sectie “Vereisten voor beleidsimplementatie”, clausule 6.4.1.

Een geloofwaardige toegangsrechtenbeoordeling bevat systeemnaam, toepassingsgebied, naam van de beoordelaar, exportdatum, beoordelingsdatum, identiteitseigenaar, afdeling, manager, arbeidsstatus, rol of entitlement, aanduiding van geprivilegieerde toegang, aanduiding van gegevensgevoeligheid, besluit, herstelmaatregelticket, sluitingsdatum, eigenaar van de uitzondering en vervaldatum van de uitzondering.

Voor Zenith Controls is toegangsrechten 5.18 het punt waarop dit bewijs geïntegreerde compliance ondersteunt. De gids mapt toegangsrechten op GDPR Article 25 omdat toegang door ontwerp en door standaardinstellingen beperkt moet zijn. De gids mapt op NIS2 Article 21(2)(i) omdat toegangscontrolebeleid en beheer van bedrijfsmiddelen risicogebaseerde toewijzing, tijdige verwijdering van onnodige toegang en formele intrekking vereisen. De gids mapt op DORA omdat financiële ICT-systemen rolgebaseerde toegang, monitoring en intrekkingsprocessen nodig hebben.

NIST-georiënteerde auditors toetsen dit vaak via AC-2 Account Management, AC-5 Separation of Duties en AC-6 Least Privilege. COBIT 2019-auditors kijken naar DSS05.04 Manage user identity and logical access en DSS06.03 Manage roles, responsibilities, access privileges and levels of authority. ISACA ITAF-auditors richten zich op de vraag of bewijs voldoende, betrouwbaar en volledig is.

Offboarding en intrekking van tokens zijn eenvoudig te bemonsteren

Uitstroom is een van de eenvoudigste plaatsen om te bewijzen of de levenscyclus werkt. Auditors selecteren vaak een recent vertrokken medewerker en vragen om de HR-beëindigingsregistratie, het ticket, het logboek van accountdeactivering, bewijs van SaaS-deactivering, VPN-verwijdering, MFA-intrekking, verwijdering van API-tokens en teruggave van bedrijfsmiddelen.

In het Onboarding- en offboardingbeleid voor het mkb stelt Clarysec:

“Beëindigde accounts moeten worden vergrendeld of verwijderd, en bijbehorende toegangstokens moeten worden ingetrokken, inclusief toegang op afstand (VPN), MFA-appkoppelingen en API-tokens.”

Uit sectie “Vereisten voor beleidsimplementatie”, clausule 6.3.3.

Dit is belangrijk omdat moderne toegang niet alleen uit een gebruikersnaam en wachtwoord bestaat. Toegang kan voortbestaan via refreshtokens, API-sleutels, SSH-sleutels, OAuth-toekenningen, serviceaccounts, lokale beheerdersrechten, mobiele sessies en portalen van derden. Een gedeactiveerde HR-registratie zonder intrekking van tokens is onvolledig bewijs.

De Zenith Blueprint, fase Controls in Action, stap 16, instrueert organisaties gereed te zijn met een gedocumenteerde beëindigingschecklist, bewijs van een recente uitstromer, een logboek van deactivering van gebruikersaccounts uit AD of MDM, een ondertekend formulier voor teruggave van bedrijfsmiddelen en offboardingdocumentatie die vertrouwelijkheidsverplichtingen omvat.

Maria’s auditor vroeg om een vertrekkende senior ontwikkelaar die geprivilegieerde toegang had tot productiedatabanken. Haar team presenteerde het Onboarding- en offboardingbeleid voor het mkb, de beëindigingschecklist die was opgebouwd vanuit Zenith Blueprint stap 16, het door HR getriggerde ITSM-ticket, het directorydeactiveringslogboek, de intrekking van het VPN-certificaat, de verwijdering uit de GitHub-organisatie, de verwijdering van de AWS IAM-sleutel en het afgesloten verificatieticket dat door de IT-manager was ondertekend. Het bewijs was volledig, tijdig en direct gekoppeld aan beleid.

Voer een bewijssprint met drie steekproeven uit voordat de auditor dat doet

Een praktische gereedheidsoefening is om vóór de audit drie steekproeven te kiezen:

1. Een nieuwe medewerker die in de afgelopen 90 dagen is gestart
2. Een geprivilegieerde gebruiker met beheerderstoegang tot cloud, database, productie of IAM
3. Een uitstromer of medewerker met rolwijziging uit de afgelopen 90 dagen

Verbind vervolgens elke steekproef met de ISMS-registraties: risicoscenario, behandelbesluit, selectie van beheersmaatregelen in de Verklaring van Toepasselijkheid, beleidsclausule, technische configuratie, beoordelingsregistratie en corrigerende maatregel als er een hiaat bestaat.

Dit verandert auditvoorbereiding van documentverzameling in verificatie van beheersmaatregelen.

Bereid u voor op verschillende auditperspectieven

Verschillende auditachtergronden leiden tot verschillende vragen, ook wanneer het bewijs hetzelfde is.

Bewijs voorbereiden dat aan al deze perspectieven voldoet, toont een volwassen complianceprogramma aan en vermindert dubbel werk.

Veelvoorkomende bevindingen en preventieve acties

Bevindingen rond toegangscontrole zijn voorspelbaar. De preventieve acties ook.

Het enterprise-Toegangscontrolebeleid voegt een bewaareis toe die een van de meest voorkomende bewijsfouten voorkomt:

“Goedkeuringsbesluiten moeten voor auditdoeleinden worden gelogd en minimaal 2 jaar worden bewaard.”

Uit sectie “Governancevereisten”, clausule 5.3.2.

Als goedkeuringen verdwijnen na e-mailopschoning, heeft de beheersmaatregel mogelijk gewerkt, maar kan de audit er niet op steunen. Bewaring maakt deel uit van het ontwerp van de beheersmaatregel.

Verantwoordingsplicht van management vereist toegangsmetrieken

NIS2 Article 20 en DORA Articles 5 en 6 maken toegangscontrole een managementaangelegenheid, omdat identiteitscompromittering kan leiden tot operationele verstoring, wettelijke meldingen, datalekken en schade voor klanten. ISO/IEC 27001:2022 clausules 5.1 tot en met 5.3 vereisen ook dat topmanagement het ISMS afstemt op de bedrijfsstrategie, middelen beschikbaar stelt, het belang communiceert, verantwoordelijkheden toewijst en voortdurende verbetering bevordert.

Nuttige metrieken voor toegangscontrole zijn onder meer:

• Percentage kritieke systemen dat door SSO wordt gedekt
• Percentage geprivilegieerde accounts met MFA
• Aantal permanente geprivilegieerde accounts versus JIT-accounts
• Voltooiingspercentage van toegangsrechtenbeoordelingen
• Aantal ingetrokken overmatige machtigingen
• Naleving van de SLA voor deactivering van uitstromers
• Aantal inactieve accounts
• Dekking van eigenaren van serviceaccounts
• Dekking van PAM-sessieopnamen
• Aantal en ouderdom van MFA-uitzonderingen

Deze metrieken helpen het management risicobehandeling goed te keuren en toezicht aan te tonen. Ze maken audits ook geloofwaardiger, omdat de organisatie kan laten zien dat toegangscontrole als levend risico wordt gemonitord en niet vóór elke audit opnieuw wordt ontdekt.

Zet versnipperd bewijs om in auditvertrouwen

Als ISO/IEC 27001:2022-bewijs voor toegangscontrole verspreid is over HR, ITSM, IAM, PAM, cloudconsoles en spreadsheets, is de volgende stap geen nieuwe herschrijving van beleid. De volgende stap is een bewijsarchitectuur.

Begin met deze volgorde:

1. Definieer systemen, identiteiten en gegevens binnen de reikwijdte.
2. Map NIS2-, DORA-, GDPR- en contractuele eisen naar de ISMS-context.
3. Gebruik risicoscenario’s in de stijl van ISO/IEC 27005:2022 om IAM, MFA, PAM en toegangsrechtenbeoordelingen te prioriteren.
4. Actualiseer de Verklaring van Toepasselijkheid en het risicobehandelingsplan.
5. Stem beleidsclausules af op feitelijke IAM- en PAM-workflows.
6. Voer de bewijssprint met drie steekproeven uit.
7. Los hiaten op voordat de auditor ze vindt.
8. Onderhoud een herbruikbaar bewijsdossier voor certificering, leveranciers-due diligence door klanten en wettelijke beoordelingen.

Clarysec kan u helpen dit te implementeren met de Zenith Blueprint: de 30-stappenroadmap voor auditors, eisen geïntegreerd te mappen met Zenith Controls: de gids voor geïntegreerde compliance en eisen operationeel te maken met de juiste Clarysec-beleidsset, waaronder Toegangscontrolebeleid, Beleid inzake beheer van gebruikersaccounts en privileges en Onboarding- en offboardingbeleid.

Auditgereedheid voor toegangscontrole gaat er niet om te bewijzen dat u een IAM-tool hebt gekocht. Het gaat erom te bewijzen dat processen voor identiteit, authenticatie, privileges en beoordeling echte bedrijfsrisico’s beperken en voldoen aan de normen en regelgeving die voor uw organisatie relevant zijn.

Download de Clarysec-toolkits, voer de bewijssprint met drie steekproeven uit en zet uw bewijs voor toegangscontrole om van versnipperde chaos naar een helder, herhaalbaar en verdedigbaar auditportfolio.