Auditbewijs voor cloudomgevingen voor ISO 27001, NIS2 en DORA

Maria, de CISO van een snelgroeiend bedrijf voor financiële analytics, had nog zes weken voordat drie deadlines samenkwamen. Haar ISO 27001:2022-surveillance-audit stond al gepland. NIS2 had het bedrijf als belangrijke entiteit in een nieuwe laag van managementverantwoordelijkheid gebracht. DORA zou toetsen of haar fintechactiviteiten digitale operationele weerbaarheid konden aantonen. Tegelijkertijd hield een grote zakelijke klant een contract tegen totdat haar team een gedetailleerde security-assurancebeoordeling kon doorstaan.

Het bedrijf was niet onveilig. Het draaide productieworkloads in AWS en Azure, gebruikte Microsoft 365 en meerdere kritieke SaaS-platformen, dwong MFA af, maakte back-ups van gegevens, scande op kwetsbaarheden en verzamelde cloudlogboeken. Het probleem was het bewijs.

Het bewijs was verspreid over Slack-screenshots, wiki-pagina’s van ontwikkelaars, exporten uit cloudconsoles, inkoopmappen, juridische contracten en mondelinge bevestigingen van platformeigenaren. Wanneer een auditor vroeg: “Laat zien hoe u uw cloudomgeving beheerst”, was een link naar de compliancepagina van een cloudprovider niet genoeg. De certificaten van de provider bewezen de beheersmaatregelen van de provider. Ze bewezen niet Maria’s deel van het model voor gedeelde verantwoordelijkheid.

Daar lopen veel cloudbeveiligingsaudits vast op bewijs. Niet omdat beheersmaatregelen ontbreken, maar omdat de organisatie niet op een gestructureerde en traceerbare manier kan aantonen welke verantwoordelijkheden bij de provider liggen, welke bij de klant liggen, hoe SaaS- en IaaS-beheersmaatregelen zijn geconfigureerd, hoe leveranciersverplichtingen worden afgedwongen en hoe bewijs wordt bewaard voor auditors, toezichthouders en klanten.

Cloudcompliance is geen technische bijlage meer. Voor een SaaS-aanbieder onder NIS2, een financiële entiteit onder DORA, of elke ISO 27001:2022-organisatie die IaaS, PaaS en SaaS gebruikt, maakt cloudgovernance deel uit van het ISMS-toepassingsgebied, het risicobehandelingsplan, de leverancierslevenscyclus, het incidentproces, de verantwoordingsplicht voor privacy en de directiebeoordeling.

Het praktische doel is eenvoudig: bouw één cloudbewijsarchitectuur die gereed is voor toezichthouders en vragen over ISO 27001:2022, NIS2, DORA, GDPR, klantassurance en interne audit beantwoordt zonder voor elk kader nieuw bewijs samen te stellen.

Cloud valt altijd binnen het toepassingsgebied, ook wanneer infrastructuur is uitbesteed

De eerste auditvalkuil is de aanname dat uitbestede infrastructuur buiten het ISMS valt. Dat is niet zo. Uitbesteding verandert de grens van de beheersing, maar neemt verantwoordingsplicht niet weg.

ISO/IEC 27001:2022 vereist dat de organisatie haar context, belanghebbenden, ISMS-toepassingsgebied, interfaces, afhankelijkheden en processen definieert. In een cloud-first organisatie zijn de identiteitsprovider, het cloudhostingaccount, CRM, het e-mailplatform, datawarehouse, de CI/CD-pijplijn, de ticketingtool en de back-updienst vaak kerninfrastructuur voor de bedrijfsvoering.

Clarysec’s Zenith Blueprint: een 30-stappenroadmap voor auditors Zenith Blueprint maakt dit punt in de fase ISMS Foundation & Leadership, stap 2, behoeften van belanghebbenden en ISMS-toepassingsgebied:

“Als u uw IT-infrastructuur uitbesteedt aan een cloudprovider, sluit dat deze niet uit van de scope; u neemt juist het beheer van die relatie en de cloudactiva op in de scope (omdat de beveiliging van uw gegevens in de cloud uw verantwoordelijkheid blijft).”

Die uitspraak is een auditanker. Uw toepassingsgebied hoort niet te zeggen: “AWS is uitgesloten omdat Amazon het beheert.” Het toepassingsgebied moet aangeven dat informatieactiva en processen die verband houden met op AWS gehoste diensten binnen het toepassingsgebied vallen, inclusief het beheer van cloudbeveiligingsmaatregelen, identiteit, logging, encryptie, back-up, leveranciersassurance en incidentrespons.

Voor ISO 27001:2022 ondersteunt dit clausules 4.1 tot en met 4.4 over context, belanghebbenden, toepassingsgebied en ISMS-processen. Voor NIS2 ondersteunt dit de verwachtingen van Article 21 voor risicoanalyse, incidentafhandeling, bedrijfscontinuïteit, beveiliging van de toeleveringsketen, veilige aanschaf en onderhoud, toegangscontrole, beheer van bedrijfsmiddelen, cryptografie, doeltreffendheid van beheersmaatregelen en MFA waar passend. Voor DORA ondersteunt dit het beginsel dat financiële entiteiten verantwoordelijk blijven voor ICT-risico, ook wanneer ICT-diensten zijn uitbesteed.

De vraag is niet of uw cloudprovider veilig is. De vraag is of u het gebruik van de provider bestuurt, uw eigen kant correct configureert, de dienst bewaakt, leveranciersverplichtingen beheert en bewijs bewaart.

Gedeelde verantwoordelijkheid moet gedeeld bewijs worden

Cloudproviders leggen gedeelde verantwoordelijkheid uit. Auditors toetsen of u die operationeel hebt gemaakt.

Bij IaaS beveiligt de provider doorgaans fysieke faciliteiten, kerninfrastructuur en de hypervisor. De klant beheerst identiteit, workloadconfiguratie, hardening van besturingssystemen, applicatiebeveiliging, gegevensclassificatie, encryptie-instellingen, netwerkregels, logging, back-ups, patching en incidentrespons.

Bij SaaS beheerst de provider de meeste platformoperaties, maar de klant beheerst nog steeds tenantconfiguratie, gebruikers, beheerdersrollen, integraties, gegevensdeling, retentie, loggingopties en escalatieprocedures.

Clarysec’s Zenith Controls: de gids voor cross-compliance Zenith Controls behandelt ISO/IEC 27002:2022 beheersmaatregel 5.23, informatiebeveiliging voor het gebruik van clouddiensten, als een centrale beheersmaatregel voor cloudgovernance met een preventieve doelstelling voor vertrouwelijkheid, integriteit en beschikbaarheid. De beheersmaatregel koppelt clouddiensten aan leveranciersrelaties, veilige informatieoverdracht, inventaris van bedrijfsmiddelen, preventie van gegevenslekken, endpoint- en netwerkbeveiliging en veilige ontwikkelpraktijken.

Een belangrijke interpretatie in Zenith Controls stelt:

“Cloud Service Providers (CSP’s) functioneren als kritieke leveranciers, waardoor alle beheersmaatregelen voor leveranciersselectie, contractering en risicobeheer onder 5.19 van toepassing zijn. 5.23 gaat echter verder door cloudspecificieke risico’s te adresseren, zoals multi-tenancy, transparantie over gegevenslocatie en modellen voor gedeelde verantwoordelijkheid.”

Dat onderscheid is essentieel. Leverancierscertificaten alleen voldoen niet aan Bijlage A.5.23. U hebt klantzijdig bewijs nodig dat aantoont dat de clouddienst wordt bestuurd, geconfigureerd, bewaakt en beoordeeld.

Dit is het verschil tussen cloudbeheersmaatregelen hebben en cloudbeheersmaatregelen hebben die auditgereed zijn.

Begin met een register van clouddiensten dat auditors kunnen gebruiken

De snelste manier om de gereedheid voor cloudaudits te verbeteren is het opzetten van een volledig register van clouddiensten. Het mag geen inkooplijst of financiële export zijn. Het moet clouddiensten verbinden met gegevens, eigenaren, regio’s, toegang, contracten, criticaliteit, regelgevende relevantie en bewijs.

Clarysec’s mkb-variant Cloud Usage Policy-sme Cloud Usage Policy-sme geeft in clausule 5.3 een compacte en auditvriendelijke baseline:

“Een Cloud Service Register moet worden onderhouden door de IT-provider of GM. Het moet vastleggen: 5.3.1 De naam en het doel van elke goedgekeurde clouddienst 5.3.2 De verantwoordelijke persoon of het verantwoordelijke team (Applicatie-eigenaar) 5.3.3 De soorten gegevens die worden opgeslagen of verwerkt 5.3.4 Het land of de regio waar gegevens worden opgeslagen 5.3.5 Gebruikerstoegangsrechten en beheerdersaccounts 5.3.6 Contractgegevens, verlengingsdatums en ondersteuningscontacten”

Voor enterprise-omgevingen stelt Clarysec’s Cloud Usage Policy Cloud Usage Policy het bredere mandaat vast:

“Dit beleid stelt de verplichte vereisten van de organisatie vast voor veilig, conform en verantwoord gebruik van cloudcomputingdiensten binnen de leveringsmodellen Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS) en Software-as-a-Service (SaaS).”

De Cloud Usage Policy vereist een centraal register onder eigenaarschap van de CISO en goedgekeurde baselineconfiguraties voor cloudomgevingen. Dat register wordt de bewijsbasis voor meerdere verplichtingen tegelijk.

Voor ISO 27001:2022 ondersteunt het de inventaris van bedrijfsmiddelen, governance van cloudgebruik, leveranciersrelaties, toegangscontrole, wettelijke en contractuele eisen, risicobehandeling en gedocumenteerde informatie. Voor NIS2 ondersteunt het beveiliging van de toeleveringsketen, beheer van bedrijfsmiddelen, risicoanalyse, incidentafhandeling en continuïteit. Voor DORA ondersteunt het ICT-asset- en afhankelijkheidsmapping, ICT-registers van derde partijen, mapping van kritieke of belangrijke functies en analyse van concentratierisico. Voor GDPR identificeert het of persoonsgegevens worden verwerkt, waar deze zich bevinden, welke provider als verwerker optreedt en welke overdrachts- of verwerkingsvoorwaarden van toepassing zijn.

Als het register geen gegevenscategorieën en regio’s identificeert, is privacy- en weerbaarheidsbewijs onvolledig. Als het geen applicatie-eigenaren identificeert, raken toegangsbeoordelingen verweesd. Als het geen contracten en verlengingsdatums identificeert, kunnen beveiligingsclausules van leveranciers niet worden getoetst.

Maak van ISO 27001:2022 de ruggengraat voor cloudbewijs

ISO 27001:2022 is de beste ruggengraat voor cloudbewijs omdat deze norm bedrijfscontext, risico, beheersmaatregelen, operationeel bewijs, monitoring en verbetering aan elkaar koppelt.

Belangrijke cloudrelevante eisen van ISO 27001:2022 zijn onder meer:

• Clausules 4.1 tot en met 4.4 voor context, belanghebbenden, ISMS-toepassingsgebied, interfaces, afhankelijkheden en processen.
• Clausules 5.1 tot en met 5.3 voor leiderschap, beleid, rollen, verantwoordelijkheden en verantwoordingsplicht.
• Clausules 6.1.1 tot en met 6.1.3 voor risicobeoordeling, risicobehandeling, vergelijking met Bijlage A, Verklaring van Toepasselijkheid en acceptatie van restrisico.
• Clausule 7.5 voor beheerste gedocumenteerde informatie.
• Clausules 8.1 tot en met 8.3 voor operationele planning, uitvoering van risicobeoordelingen en uitvoering van risicobehandeling.
• Clausules 9.1 tot en met 9.3 voor monitoring, meting, interne audit en directiebeoordeling.
• Clausule 10 voor non-conformiteit, corrigerende maatregelen en voortdurende verbetering.

De beheersmaatregelen uit Bijlage A die het meeste gewicht dragen voor cloudbewijs zijn A.5.19 Informatiebeveiliging in leveranciersrelaties, A.5.20 Informatiebeveiliging adresseren binnen leveranciersovereenkomsten, A.5.21 Beheer van informatiebeveiliging in de ICT-toeleveringsketen, A.5.22 Monitoring, beoordeling en wijzigingsbeheer van leveranciersdiensten, A.5.23 Informatiebeveiliging voor het gebruik van clouddiensten, A.5.24 tot en met A.5.27 incidentbeheer, A.5.29 Informatiebeveiliging tijdens verstoring, A.5.30 ICT-gereedheid voor bedrijfscontinuïteit, A.5.31 Wettelijke, statutaire, regelgevende en contractuele eisen, A.5.34 Privacy en bescherming van persoonlijk identificeerbare informatie (PII), A.5.36 Naleving van beleid, regels en standaarden voor informatiebeveiliging, A.8.8 Beheer van technische kwetsbaarheden, A.8.9 Configuratiebeheer, A.8.13 Back-up van informatie, A.8.15 Logging, A.8.16 Monitoringactiviteiten, A.8.24 Gebruik van cryptografie, A.8.25 Veilige ontwikkelingslevenscyclus, A.8.29 Beveiligingstesten tijdens ontwikkeling en acceptatie, en A.8.32 Wijzigingsbeheer.

In Zenith Blueprint legt de fase Controls in Action, stap 23, clouddiensten uit in taal die bij auditors aansluit:

“De overstap naar clouddiensten brengt ingrijpende veranderingen in het vertrouwensmodel met zich mee. U beheerst de server, de netwerkperimeter of de hypervisor niet meer. Vaak weet u niet eens waar de gegevens fysiek staan. Wat u wel beheerst, en wat deze beheersmaatregel afdwingt, is de governance van die relatie, de zichtbaarheid van wat u gebruikt en de beveiligingsverwachtingen die u aan uw providers stelt.”

Een sterke vermelding in de Verklaring van Toepasselijkheid voor A.5.23 hoort niet alleen te zeggen: “Van toepassing, cloudprovider gecertificeerd.” Zij moet uitleggen waarom de beheersmaatregel van toepassing is, welke risico’s ermee worden behandeld, hoe zij is geïmplementeerd en waar het bewijs wordt opgeslagen.

Voeg een kolom voor de bewijsopslaglocatie toe aan de SoA of de tracker voor beheersmaatregelen. Auditors zouden niet in e-mail, ticketingsystemen en gedeelde schijven hoeven te zoeken om bewijs te vinden.

Gebruik één bewijsmodel voor ISO 27001:2022, NIS2 en DORA

NIS2 en DORA vereisen beide gedocumenteerde, risicogebaseerde en door het management gestuurde cyberbeveiliging. De overlap is aanzienlijk, maar de toezichtdruk verschilt.

NIS2 is van toepassing op veel essentiële en belangrijke entiteiten in de EU, waaronder aanbieders van digitale infrastructuur, managed service providers, managed security service providers, banken, financiëlemarktinfrastructuren en digitale aanbieders. Article 21 vereist passende en evenredige technische, operationele en organisatorische maatregelen, waaronder risicoanalyse, incidentafhandeling, bedrijfscontinuïteit, beveiliging van de toeleveringsketen, veilige aanschaf en onderhoud, behandeling van kwetsbaarheden, beoordeling van de doeltreffendheid van beheersmaatregelen, cyberhygiëne, training, cryptografie, toegangscontrole, beheer van bedrijfsmiddelen en MFA of beveiligde communicatie waar passend.

Voor auditbewijs voor cloudbeveiliging vraagt NIS2 of cloud- en leveranciersrisico’s worden beheerd als onderdeel van het risico van dienstverlening. NIS2 introduceert ook gestructureerde melding van significante incidenten, waaronder een vroege waarschuwing binnen 24 uur, een incidentmelding binnen 72 uur en een eindrapport binnen één maand.

DORA is vanaf 17 januari 2025 van toepassing op veel financiële entiteiten in de EU en creëert uniforme eisen voor ICT-risicobeheer, melding van majeure ICT-incidenten, testen van digitale operationele weerbaarheid, informatie-uitwisseling en ICT-risico bij derde partijen. Voor financiële entiteiten die ook onder NIS2 zijn aangewezen, wordt DORA behandeld als de sectorspecifieke Unierechtshandeling voor overlappende operationele verplichtingen.

Voor cloud is DORA direct. Financiële entiteiten blijven verantwoordelijk voor ICT-risico wanneer diensten zijn uitbesteed. Zij hebben ICT-strategieën voor derde partijen, contractregisters, precontractuele beoordelingen, due diligence, audit- en toegangsrechten, beëindigingstriggers, analyses van concentratierisico, beheersmaatregelen voor onderaanneming en geteste exitstrategieën nodig.

Zenith Controls mappt ISO/IEC 27002:2022 beheersmaatregel 5.23 naar EU NIS2 Article 21 en DORA Articles 28 to 31. Het wijst ook op ondersteunende normen zoals ISO/IEC 27017 voor cloudbeveiligingsrollen en monitoring, ISO/IEC 27018 voor bescherming van PII in publieke cloud, ISO/IEC 27701 voor privacybeheer in relaties met cloudverwerkers, ISO/IEC 27036-4 voor monitoring van clouddiensten en leveranciersovereenkomsten, en ISO/IEC 27005 voor cloudrisicobeoordeling.

De praktische implicatie is eenvoudig. Bouw geen afzonderlijke bewijspakketten voor ISO 27001:2022, NIS2, DORA en GDPR. Bouw één cloudbewijsarchitectuur met kaderspecifieke mappings.

Leverancierscontracten zijn bewijs van beheersmaatregelen, geen juridische archieven

Auditbewijs voor cloudomgevingen breekt vaak op de contractlaag. Security heeft een leveranciersvragenlijst. Juridische Zaken heeft de MSA. Inkoop heeft de verlengingsdatum. De DPO heeft de DPA. Niemand heeft één overzicht of de overeenkomst de beveiligingsclausules bevat die door ISO 27001:2022, NIS2, DORA en GDPR worden vereist.

Clarysec’s mkb-variant Third-Party and Supplier Security Policy-sme Third-Party and Supplier Security Policy-sme stelt in clausule 5.3:

“Contracten moeten verplichte clausules bevatten over: 5.3.1 Vertrouwelijkheid en geheimhouding 5.3.2 Verplichtingen inzake informatiebeveiliging 5.3.3 Meldtermijnen voor datalekken (bijv. binnen 24–72 uur) 5.3.4 Auditrechten of de beschikbaarheid van nalevingsbewijsmateriaal 5.3.5 Beperkingen op verdere onderaanneming zonder goedkeuring 5.3.6 Beëindigingsvoorwaarden, inclusief veilige teruggave of vernietiging van gegevens”

Vertaal deze clausules voor auditconsistentie naar een contractbeoordelingsmatrix. ISO 27001:2022 Bijlage A.5.20 verwacht dat beveiligingseisen met leveranciers worden overeengekomen. GDPR Article 28 vereist verwerkersvoorwaarden over vertrouwelijkheid, beveiligingsmaatregelen, bijstand, subverwerkers, verwijdering of teruggave van gegevens en auditondersteuning. DORA Article 30 vereist gedetailleerde contractuele bepalingen voor ICT-dienstverleners van derde partijen, waaronder dienstbeschrijvingen, gegevenslocatie, beveiliging, ondersteuning bij incidenten, samenwerking met autoriteiten, auditrechten, toegangsrechten, beëindiging en transitieregelingen. NIS2-beveiliging van de toeleveringsketen vereist ook afdwingbare samenwerking met leveranciers.

Zenith Controls mappt ISO/IEC 27002:2022 beheersmaatregel 5.20 naar leveranciersovereenkomsten en benoemt verbanden met 5.19 leveranciersrelaties, 5.14 informatieoverdracht, 5.22 leveranciersmonitoring, 5.11 teruggave van bedrijfsmiddelen en 5.36 naleving.

Het kernpunt is operationalisering. Als een cloudcontract toegang geeft tot SOC 2-rapporten, kunnen auditors vragen of u het rapport hebt verkregen, uitzonderingen hebt beoordeeld, herstelmaatregelen hebt gevolgd en het risico opnieuw hebt beoordeeld. Als het contract melding van inbreuken belooft, kunnen zij vragen of uw incidentdraaiboek het leverancierscontactpad en de beslispunten voor regelgeving bevat. Als wijzigingen bij onderaannemers goedkeuring of kennisgeving vereisen, kunnen zij vragen of meldingen over subverwerkers vóór acceptatie op risico worden beoordeeld.

Een contract zonder beoordelingsbewijs is een archief. Een contract dat is gekoppeld aan leveranciersrisico, monitoringregistraties en incidentworkflows is een beheersmaatregel.

SaaS-logging en -configuratie zijn veelvoorkomende blinde vlekken bij audits

Cloudbevindingen komen vaak uit SaaS, niet uit IaaS. Infrastructuurteams hebben doorgaans engineering-eigenaren, loggingpijplijnen, baselinebeheersmaatregelen en wijzigingsregistraties. SaaS-platformen zijn verspreid over sales, HR, finance, customer success, marketing en operations. Elk daarvan kan gevoelige of gereguleerde gegevens verwerken.

Clarysec’s Logging and Monitoring Policy-sme Logging and Monitoring Policy-sme adresseert dit rechtstreeks in clausule 5.5:

“5.5 Clouddiensten en logging door derde partijen 5.5.1 Voor platformen waarbij logging niet onder directe IT-controle valt (bijv. SaaS-e-mail), gelden de volgende eisen: 5.5.1.1 Logging moet worden ingeschakeld en geconfigureerd waar beschikbaar 5.5.1.2 Alerts moeten naar de IT-supportverlener worden gerouteerd 5.5.1.3 Contracten moeten vereisen dat providers logboeken ten minste 12 maanden bewaren en op verzoek toegang verlenen”

Voor enterprise-omgevingen voegt de Cloud Usage Policy toe:

“Clouddiensten moeten worden geïntegreerd in het SIEM van de organisatie voor continue monitoring.”

Deze eis verplaatst SaaS van “business tool” naar “gemonitord informatiesysteem.” Bewijs moet exporten van logginginstellingen, bewijs van SIEM-connectoren, alertregels, triagetickets, retentie-instellingen en beoordelingen van beheerdersrechten omvatten.

Bereid voor kritieke SaaS bewijs voor over het aanmaken van beheerdersaccounts, verdachte aanmeldingen, massale downloads, publiek delen, uitschakeling van MFA, aanmaak van API-tokens, externe gastactiviteit en privilege-escalatie. Bereid voor IaaS CloudTrail of gelijkwaardige control-plane-logging, toegangslogboeken voor opslag, IAM-wijzigingen, flow logs waar passend, CSPM-bevindingen, kwetsbaarheidsscans, patchbewijs, encryptie-instellingen, back-upstatus, beoordelingen van network security groups en wijzigingstickets voor.

De auditmethodologie van Zenith Controls voor beheersmaatregel 5.23 merkt op dat een ISO/IEC 27007-achtige audit AWS S3-bucketrechten, encryptie, IAM-beleid en CloudTrail-logging kan inspecteren. Een COBIT-georiënteerde auditor kan alertconfiguraties, DLP-beheersmaatregelen, gebruik van Microsoft 365 Secure Score en wijzigingsbeheerlogboeken beoordelen. Een NIST SP 800-53A-perspectief kan accountbeheer en monitoring toetsen, inclusief de vraag of cloudworkloads met dezelfde strengheid als interne systemen worden gepatcht, gescand en gemonitord.

Verschillende auditors spreken verschillende dialecten. Uw bewijs moet hetzelfde zijn.

Bouw een bewijspakket dat gereed is voor toezichthouders voor één SaaS- en één IaaS-dienst

Een praktische workflow begint met één kritisch SaaS-platform en één kritieke IaaS-omgeving. Bijvoorbeeld Microsoft 365 voor samenwerking en AWS voor productiehosting.

Stap 1: Werk het register van clouddiensten bij

Leg voor Microsoft 365 doel, eigenaar, gegevenstypen, regio, beheerdersaccounts, contract, DPA, ondersteuningscontact, verlengingsdatum en criticaliteit vast. Leg voor AWS het productieaccount, regio’s, gegevenscategorieën, workloads, accounteigenaar, root-accountstatus, supportplan, contractvoorwaarden en gekoppelde bedrijfsdiensten vast.

Gebruik de velden uit Cloud Usage Policy-sme als minimale dataset. Voeg criticaliteit, regelgevende relevantie en bewijsopslaglocatie toe.

Stap 2: Documenteer gedeelde verantwoordelijkheid

Voor Microsoft 365 omvatten klantverantwoordelijkheden de gebruikerslevenscyclus, MFA, conditional access, delen met gasten, retentielabels, DLP waar gebruikt, logging en incidentescalatie. Voor AWS omvatten klantverantwoordelijkheden IAM, netwerkregels, workloadhardening, encryptieconfiguratie, back-up, logging, patching en applicatiebeveiliging.

Voeg documentatie over gedeelde verantwoordelijkheid van de provider toe en map vervolgens elke klantverantwoordelijkheid naar een eigenaar van de beheersmaatregel en een bewijsbron.

Stap 3: Leg configuratiebewijs vast

Exporteer of maak screenshots van MFA- en conditional access-beleid, beheerdersrollen, instellingen voor extern delen, auditlogging, retentieconfiguratie en acties voor security score voor Microsoft 365. Exporteer voor AWS het IAM-wachtwoordbeleid, de MFA-status voor geprivilegieerde toegang, CloudTrail-configuratie, S3 public access block, encryptiestatus, beoordeling van security groups, back-upjobs en status van kwetsbaarheidsscans.

De Cloud Usage Policy vereist dat cloudomgevingen voldoen aan een gedocumenteerde baselineconfiguratie die is goedgekeurd door de Cloud Security Architect. Uw bewijspakket moet zowel de baseline als bewijs van afstemming bevatten.

Stap 4: Koppel leveranciers- en privacybewijs

Voeg het contract, de DPA, lijst van subverwerkers, meldingsvoorwaarden voor inbreuken, auditassurancerapporten en bewijs over gegevenslocatie toe. Als persoonsgegevens worden verwerkt, leg dan vast of de provider als verwerker optreedt, hoe verwijdering wordt afgehandeld, hoe ondersteuning bij verzoeken van betrokkenen werkt en welke overdrachtswaarborgen van toepassing zijn.

Bepaal voor DORA of de clouddienst een kritieke of belangrijke functie ondersteunt. Zo ja, koppel het bewijs aan het ICT-register voor derde partijen, het due-diligence-dossier, auditrechten, het exitplan en de beoordeling van concentratierisico.

Stap 5: Verbind logging met incidentrespons

Toon aan dat logboeken zijn ingeschakeld, gerouteerd, beoordeeld en gebruikt. Voeg SIEM-dashboards, alertregels en ten minste één gesloten alertticket toe. Map vervolgens de workflow naar de beslispunten voor rapportage onder NIS2 en DORA.

Voor NIS2 moet het incidentproces een vroege waarschuwing binnen 24 uur, een incidentmelding binnen 72 uur en een eindrapport binnen één maand voor significante incidenten ondersteunen. Voor DORA moet het ICT-incidentproces incidenten classificeren op basis van getroffen klanten, transacties, duur, downtime, geografische spreiding, gegevensimpact, servicecriticaliteit en economische impact.

Stap 6: Sla bewijs gedisciplineerd op

Clarysec’s Audit and Compliance Monitoring Policy-sme Audit and Compliance Monitoring Policy-sme clausule 6.2 definieert praktische discipline voor bewijs:

“6.2 Verzameling en documentatie van bewijsmateriaal 6.2.1 Al het bewijsmateriaal moet worden opgeslagen in een centrale auditmap. 6.2.2 Bestandsnamen moeten duidelijk verwijzen naar het auditonderwerp en de datum. 6.2.3 Metadata (bijv. wie het heeft verzameld, wanneer en uit welk systeem) moeten worden gedocumenteerd. 6.2.4 Bewijsmateriaal moet ten minste twee jaar worden bewaard, of langer waar certificering of klantovereenkomsten dit vereisen.”

De enterprise Audit and Compliance Monitoring Policy Audit and Compliance Monitoring Policy formuleert de doelstelling:

“Verdedigbaar bewijsmateriaal en een audittrail genereren ter ondersteuning van verzoeken van toezichthouders, gerechtelijke procedures of klantassuranceverzoeken.”

Een screenshot met de naam “screenshot1.png” is zwak bewijs. Een bestand met de naam “AWS-Prod-CloudTrail-Enabled-2026-05-10-CollectedBy-JSmith.png” is sterker omdat het het systeem, de beheersmaatregel, de datum en de verzamelaar beschrijft. Metadata zijn belangrijk omdat auditors moeten kunnen vertrouwen wanneer bewijs is verzameld, wie het heeft verzameld en uit welk systeem het afkomstig is.

Hoe auditors dezelfde cloudbeheersmaatregel toetsen

De sterkste cloudbewijspakketten zijn ontworpen voor meerdere auditlenzen. ISO 27001:2022-auditors toetsen of de beheersmaatregel in het ISMS, de risicobeoordeling, de risicobehandeling en de SoA staat. NIST-georiënteerde beoordelaars toetsen de technische implementatie. COBIT 2019-auditors toetsen governance, leveranciersprestaties en procesintegratie. Privacyauditors richten zich op verwerkersverplichtingen, gegevensresidentie, paraatheid voor inbreuken en rechten van betrokkenen. DORA-toezichtbeoordelingen richten zich op ICT-risico bij derde partijen en weerbaarheid.

Zenith Controls omvat deze verschillen in auditmethodologie voor clouddiensten, leveranciersovereenkomsten en leveranciersmonitoring. Voor 5.22, Monitoring, beoordeling en wijzigingsbeheer van leveranciersdiensten, benadrukt het dat auditors kwartaalnotulen van leveranciersbeoordelingen, KPI-rapportages, evaluaties van SOC-rapporten, wijzigingslogboeken, risicobeoordelingen, leveranciersincidenten en issue tracking kunnen inspecteren. Voor 5.20, Informatiebeveiliging adresseren binnen leveranciersovereenkomsten, benadrukt het contractsteekproeven voor vertrouwelijkheid, beveiligingsverplichtingen, meldplicht bij inbreuken, auditrechten, goedkeuring van onderaannemers en beëindigingsvoorwaarden.

Cross-compliancebeheersmaatregelen die de cloudaudit dragen

Een cloudbewijsmodel dat gereed is voor toezichthouders wordt gebouwd rond een klein aantal beheersmaatregelen met grote impact. Deze beheersmaatregelen dragen veel van de nalevingslast over ISO 27001:2022, NIS2, DORA, GDPR, NIST en COBIT 2019 heen.

NIST SP 800-53 Rev.5 voegt technische diepgang toe via accountbeheer, externe systeemdiensten, continue monitoring, systeemmonitoring en grensbeveiliging. COBIT 2019 voegt governancediepgang toe via beheer van leveranciersrelaties, leveranciersrisico, gegevensuitwisseling, netwerkbeveiliging en gereedheid voor wijzigingen.

Ondersteunende ISO-normen scherpen het bewijsmodel aan. ISO/IEC 27017 biedt cloudspecificieke richtlijnen voor gedeelde rollen, configuratie van virtuele machines en monitoring van klantactiviteiten. ISO/IEC 27018 richt zich op bescherming van PII in publieke cloud. ISO/IEC 27701 breidt privacyverplichtingen uit naar verwerkers- en verwerkingsverantwoordelijke activiteiten. ISO/IEC 27036-4 ondersteunt leveranciersovereenkomsten en monitoring voor cloud. ISO/IEC 27005 ondersteunt cloudrisicobeoordeling.

Directiebeoordeling moet cloudrisico zien, niet alleen cloudbeschikbaarheid

Een van de meest over het hoofd geziene audit artefacten is de directiebeoordeling. ISO 27001:2022 verwacht dat de directiebeoordeling wijzigingen, behoeften van belanghebbenden, prestatietrends, auditresultaten, status van risicobehandeling en verbetermogelijkheden beschouwt. NIS2 vereist dat bestuursorganen maatregelen voor cyberbeveiligingsrisicobeheer goedkeuren en toezicht houden op de implementatie. DORA vereist dat het bestuursorgaan ICT-risicobeheer definieert, goedkeurt, bewaakt en daarvoor verantwoordelijk blijft.

Een kwartaaldashboard voor cloudbeveiliging en leveranciers moet tonen:

• Aantal goedgekeurde clouddiensten.
• Kritieke clouddiensten en eigenaren.
• Diensten die persoonsgegevens verwerken.
• Diensten die kritieke of belangrijke functies ondersteunen.
• Openstaande cloudmisconfiguraties met hoog risico.
• Status van MFA en beoordeling van geprivilegieerde toegang.
• Loggingdekking voor kritieke SaaS- en IaaS-platformen.
• Ontvangen en beoordeelde leveranciersassurancerapporten.
• Contractuitzonderingen en geaccepteerde risico’s.
• Cloudincidenten, bijna-incidenten en geleerde lessen.
• Resultaten van back-up- en hersteltests.
• Status van concentratierisico en exitplan.

Dit dashboard wordt bewijs voor leiderschap en prestatie-evaluatie onder ISO 27001:2022, governance onder NIS2 en managementverantwoordelijkheid onder DORA.

Zenith Blueprint beveelt in de fase Risicobeheer, stap 14, aan om regelgevende eisen te kruisen wanneer risicobehandelingen en beleid worden geïmplementeerd. Het stelt dat het mappen van belangrijke regelgevingseisen naar ISMS-beheersmaatregelen een nuttige interne oefening is en “ook indruk maakt op auditors/beoordelaars omdat u beveiliging niet in een vacuüm beheert, maar zich bewust bent van de juridische context.”

Dat is de volwassenheid die toezichthouders en zakelijke klanten verwachten.

Veelvoorkomende cloudauditbevindingen en hoe u ze voorkomt

Bij werk aan gereedheid voor cloudaudits zijn terugkerende bevindingen voorspelbaar:

1. Het register van clouddiensten bestaat, maar SaaS-tools ontbreken.
2. Gegevenslocatie is niet vastgelegd of is gekopieerd van marketingpagina’s in plaats van uit contractueel bewijs.
3. MFA wordt afgedwongen voor werknemers, maar niet voor alle beheerders- of break-glass-accounts.
4. Cloudlogboeken zijn ingeschakeld maar worden niet beoordeeld, bewaard of gekoppeld aan incidentrespons.
5. Leveranciers-SOC-rapporten worden gearchiveerd, maar niet beoordeeld.
6. Contractclausules bestaan voor nieuwe leveranciers, maar niet voor legacy kritieke diensten.
7. Meldingen van subverwerkers worden per e-mail ontvangen, maar niet op risico beoordeeld.
8. Back-upjobs draaien succesvol, maar hersteltests worden niet met bewijs onderbouwd.
9. Gedeelde verantwoordelijkheid wordt door engineers begrepen, maar niet voor auditors gedocumenteerd.
10. De SoA markeert cloudbeheersmaatregelen als van toepassing, maar koppelt ze niet aan risico-items, bewijs of eigenaren.

Dit zijn traceerbaarheidsproblemen. De oplossing is beleid, risico, beheersmaatregel, eigenaar, bewijs en beoordeling met elkaar verbinden.

Toen Maria de auditdag bereikte, vertrouwde zij niet langer op verspreide screenshots. Ze opende een centraal dashboard met het register van clouddiensten, risicobeoordelingen, SoA-vermeldingen, bewijs voor baselineconfiguraties, leveranciersbeoordelingsdossiers, loggingbewijs en de DORA-beoordeling van concentratierisico. Toen de auditor vroeg hoe cloudrisico’s werden bestuurd, liet zij het ISMS zien. Toen de auditor vroeg hoe diensten veilig waren geconfigureerd, liet zij de baseline en het CSPM-bewijs zien. Toen de auditor vroeg naar ICT-risico bij derde partijen, liet zij de contractbeoordeling, leveranciersmonitoring en exitplanning zien.

Het resultaat was geen perfecte omgeving. Geen enkele cloudomgeving is perfect. Het verschil was dat risicobesluiten waren gedocumenteerd, bewijs verdedigbaar was en verantwoordingsplicht zichtbaar was.

Bouw uw cloudbewijspakket voordat de auditor erom vraagt

Als uw organisatie afhankelijk is van SaaS, IaaS of PaaS, zal uw volgende audit “de provider regelt dat” niet accepteren als voldoende antwoord. U moet gedeelde verantwoordelijkheid, klantzijdige configuratie, leveranciersclausules, logging, paraatheid voor incidenten, weerbaarheid en managementtoezicht aantonen.

Begin deze week met drie praktische acties:

1. Maak of actualiseer uw register van clouddiensten met Clarysec’s Cloud Usage Policy Cloud Usage Policy of Cloud Usage Policy-sme Cloud Usage Policy-sme.
2. Map uw vijf belangrijkste clouddiensten naar ISO 27001:2022 Bijlage A-beheersmaatregelen, NIS2 Article 21, DORA ICT-verplichtingen voor derde partijen waar van toepassing, en GDPR-verwerkersvereisten.
3. Bouw een centrale bewijsmap met de retentie- en metadatadiscipline uit Audit and Compliance Monitoring Policy Audit and Compliance Monitoring Policy of Audit and Compliance Monitoring Policy-sme Audit and Compliance Monitoring Policy-sme.

Gebruik vervolgens Zenith Blueprint Zenith Blueprint om het werk in de 30-stappenroadmap voor ISMS-audits te plaatsen, en Zenith Controls Zenith Controls om cross-compliancemappings, ondersteunende ISO-normen en verwachtingen uit auditmethodologieën te valideren.

Clarysec kan u helpen verspreide cloudscreenshots, leveranciersdossiers en SaaS-instellingen om te zetten in een bewijspakket dat gereed is voor toezichthouders en standhoudt bij ISO 27001:2022-certificeringsaudits, toezichtvragen onder NIS2, DORA-beoordelingen van ICT-dienstverleners van derde partijen en assurance-eisen van zakelijke klanten.