Matrix voor gedeelde verantwoordelijkheid in de cloud voor ISO 27001, NIS2 en DORA

Een COO van een fintech belt de CISO op maandag om 07:15.

Een Europese bankklant vraagt om bewijs dat het SaaS-platform van het bedrijf kan voldoen aan de DORA-vereisten voor ICT-risico’s van derden. Het salesteam heeft het bekende leveranciersbeveiligingspakket al verzonden: ISO-certificaat, managementsamenvatting van de penetratietest, cyberverzekeringscertificaat, privacyverklaring en een assurance-rapport van de cloudprovider.

De bank komt terug met een scherpere vraag:

“Toon ons wie eigenaar is van elke beheersmaatregel in jullie cloudomgeving. Jullie, jullie cloudprovider, jullie managed database-provider, jullie identiteitsprovider, jullie loggingleverancier en eventuele subverwerkers. En toon daarna het bewijsmateriaal.”

Later die ochtend heeft de CISO een bestuursvergadering. De CEO zal dezelfde vraag in zakelijke taal stellen: “Weten we zeker dat dit platform veilig is, en wie is verantwoordelijk als er iets misgaat?”

Daar lopen veel programma’s voor cloudcompliance vast.

De organisatie kan een sterke cloudprovider, goede tooling, adequate beleidslijnen en een risicoregister hebben. Maar wanneer wordt gevraagd om verantwoordelijkheidsgrenzen aan te tonen, ligt het bewijsmateriaal verspreid. Inkoop heeft de contracten. Juridische Zaken heeft de verwerkersovereenkomst. Engineering heeft de architectuurdiagrammen. Security heeft de logs en cloudconfiguraties. Privacy heeft de lijst met subverwerkers. Compliance heeft de Verklaring van Toepasselijkheid. Niemand heeft één beheerst artefact dat per beheersmaatregel vastlegt wat de provider doet, wat de klant moet configureren, welke subverwerker betrokken is, welke clausule de verplichting afdwingbaar maakt en welk bewijsmateriaal een auditor mag verwachten.

Dat artefact is de matrix voor gedeelde verantwoordelijkheid in de cloud.

Niet de generieke hyperscaler-slide die zegt dat de provider de cloud beveiligt en de klant beveiligt wat zich in de cloud bevindt. Een echte matrix voor gedeelde verantwoordelijkheid in de cloud voor ISO/IEC 27001:2022, NIS2, DORA en GDPR is een governanceregistratie. Zij doorstaat customer due diligence, een ISO-audit, een DORA-beoordeling, een GDPR-verantwoordingsvraag en een incidentonderzoek.

Waarom gedeelde verantwoordelijkheid in de cloud een auditvraagstuk wordt

Het model voor gedeelde verantwoordelijkheid wordt meestal uitgelegd als een technische grens. Bij IaaS beheert de provider fysieke faciliteiten, hardware, virtualisatie en kerninfrastructuur. De klant beheert identiteiten, gegevens, workloads, netwerkregels, encryptiekeuzes en configuraties. Bij SaaS neemt de provider meer operationele verantwoordelijkheid op zich, maar de klant blijft eigenaar van gebruikerstoegang, gegevensgovernance, rechtsgrondslag, configuratie, monitoringverwachtingen en incidentescalatie.

Die uitleg is nuttig, maar onvolledig.

Auditors, toezichthouders en zakelijke klanten vragen meer dan “wie voert de beheersmaatregel uit?” Zij willen weten:

• Wie is verantwoordelijk voor het risico?
• Welke contractuele bepaling maakt die verantwoordelijkheid afdwingbaar?
• Welk beleid vereist de beheersmaatregel?
• Welke cloudservice, welk SaaS-platform of welke subverwerker valt binnen de scope?
• Welk bewijsmateriaal toont aan dat de beheersmaatregel tijdens de beoordelingsperiode effectief heeft gewerkt?
• Aan welke vereiste van welk raamwerk voldoet het bewijsmateriaal?
• Wat gebeurt er als de provider zijn dienst, locatie, onderaannemer of beheersingspositie wijzigt?

ISO/IEC 27001:2022 ISO/IEC 27001:2022 maakt hiervan een managementsysteemvraagstuk. Clausules 4.1 tot en met 4.4 vereisen dat de organisatie interne en externe kwesties, belanghebbenden, wettelijke en contractuele verplichtingen, het ISMS-toepassingsgebied, interfaces en afhankelijkheden begrijpt. Clausules 6.1.1 tot en met 6.1.3 vereisen risicobeoordeling, risicobehandeling, goedkeuring door de risico-eigenaar, acceptatie van restrisico en een Verklaring van Toepasselijkheid. Clausule 8.1 vereist operationele planning en beheersing, inclusief beheersing van extern geleverde processen, producten en diensten die relevant zijn voor het ISMS.

In gewone taal: als een cloudprovider, SaaS-leverancier of subverwerker een bedrijfsproces binnen de scope ondersteunt, kan deze niet buiten het ISMS blijven. De partij moet zichtbaar zijn in scope, risico, behandeling, contractuele beheersing en bewijsmateriaal.

NIS2 verhoogt de lat. Article 21 vereist dat essentiële en belangrijke entiteiten passende en evenredige technische, operationele en organisatorische maatregelen implementeren, waaronder risicoanalyse, incidentafhandeling, continuïteit, beveiliging van de toeleveringsketen, veilige verwerving, veilige ontwikkeling, kwetsbaarhedenafhandeling, beoordeling van de doeltreffendheid, cyberbeveiligingshygiëne, cryptografie, HR-beveiliging, toegangscontrole, beheer van bedrijfsmiddelen en multifactorauthenticatie of continue authenticatie waar passend. Article 20 legt governanceverantwoordelijkheid bij managementorganen.

DORA is nog explicieter voor financiële entiteiten. DORA is van toepassing vanaf 17 januari 2025 en vereist dat financiële entiteiten ICT-risico, melding van ernstige ICT-gerelateerde incidenten, testen van digitale operationele weerbaarheid en ICT-risico’s van derden beheren. Articles 28 tot en met 30 vereisen beheer van ICT-risico’s van derden, voorafgaande beoordeling van concentratierisico, contractuele waarborgen, audit- en toegangsrechten, zichtbaarheid op onderuitbesteding, beëindigingsrechten en exitstrategieën.

GDPR voegt de verantwoordingsproef toe. Article 5 vereist dat persoonsgegevens worden verwerkt met integriteit en vertrouwelijkheid, en Article 5(2) vereist dat de verwerkingsverantwoordelijke naleving kan aantonen. Article 28 regelt verwerkersovereenkomsten en subverwerkers. Article 32 vereist beveiliging van de verwerking. Articles 33 en 34 vereisen melding van inbreuken in verband met persoonsgegevens waar van toepassing.

De matrix voor gedeelde verantwoordelijkheid in de cloud vormt de brug tussen deze verplichtingen.

De Clarysec-definitie: een governanceartefact, geen diagram

In Clarysec-opdrachten is een matrix voor gedeelde verantwoordelijkheid in de cloud een beheerste ISMS-registratie die cloudservices, leveranciers, subverwerkers, beheersmaatregelen, beleidslijnen, contractuele verplichtingen, bewijsmateriaal en auditverwachtingen met elkaar verbindt.

De krachtigste uitleg staat in Zenith Blueprint Zenith Blueprint, in de fase Controls in Action, stap 23:

“Cloudproviders beveiligen de infrastructuur, maar u blijft verantwoordelijk voor uw gegevens, uw configuraties, uw toegangsbeleid en uw gereedheid voor incidentrespons.”

Dezelfde stap legt uit dat cloudgebruik als onderdeel van het ISMS moet worden behandeld, inclusief classificatie van cloudservices, inzicht in verwerkte of opgeslagen gegevens, beoordeling van providers, contractuele bepalingen en beheer van servicewijzigingen. Daarmee verandert gedeelde verantwoordelijkheid van een concept in een traceerbare beheersstructuur.

Zenith Controls Zenith Controls behandelt ISO/IEC 27001:2022 Annex A-beheersmaatregelen en ISO/IEC 27002:2022-richtsnoeren 5.20, 5.21 en 5.23 als centrale ankers:

• 5.20, informatiebeveiliging opnemen in leveranciersovereenkomsten.
• 5.21, informatiebeveiliging beheren in de ICT-toeleveringsketen.
• 5.23, informatiebeveiliging voor het gebruik van cloudservices.

Dit zijn geen losse checklistitems. Zij vormen de ruggengraat van de matrix.

Ondersteunende normen kunnen de matrix versterken. ISO/IEC 27017 helpt bij cloudspecifieke beveiligingspraktijken. ISO/IEC 27018 en ISO/IEC 27701 ondersteunen governance van PII en privacy. ISO/IEC 27005 ondersteunt risicobeoordeling. ISO 22301 ondersteunt continuïteit en weerbaarheid. ISO/IEC 27035 ondersteunt incidentbeheer. ISO/IEC 20000-1 kan helpen waar cloudservices deel uitmaken van beheerde dienstverlening.

De minimaal werkbare matrix voor gedeelde verantwoordelijkheid

Een volwassen matrix begint niet met 200 rijen. Zij begint met de cloudservices die het belangrijkst zijn.

Voor een SaaS-organisatie, fintech of gereguleerde mkb-onderneming begint Clarysec meestal met:

1. Publieksgerichte productiecloudomgeving.
2. Identiteitsprovider.
3. Beheerde databank- of opslagdienst.
4. Logging-, monitoring- en SIEM-platform.
5. Betalings-, KYC-, analytics- of klantondersteunings-SaaS.
6. Back-up- en hersteldienst na verstoringen.
7. Managed service provider of managed security service provider.
8. Subverwerkers die klantgegevens benaderen, opslaan of verwerken.

De eerste matrix moet de volgende kolommen bevatten.

Een praktische rij voor logging kan er als volgt uitzien.

Die rij is niet alleen documentatie. Zij vertelt security wat moet worden geconfigureerd, inkoop welke contracttaal moet worden gecontroleerd, privacy welke gegevensstroom moet worden vastgelegd en auditors welk bewijsmateriaal zij moeten opvragen.

Beleidsbasis: de matrix omzetten in een afdwingbare eis

Een matrix voor gedeelde verantwoordelijkheid in de cloud zonder beleidsbasis is slechts een spreadsheet. Clarysec-beleidslijnen maken de matrix afdwingbaar.

Voor mkb-ondernemingen vereist Beleid inzake gebruik van cloudservices - mkb Beleid inzake gebruik van cloudservices - mkb, sectie “Governancevereisten”, clausule 5.3:

“De IT-provider of GM moet een register van clouddiensten onderhouden. Het moet het volgende vastleggen:”

Dezelfde mkb-beleidslijn, clausule 5.2.3, koppelt cloudgovernance aan privacy- en locatierisico:

“Gegevensresidentie en privacypraktijken voldoen aan toepasselijke wettelijke vereisten (bijv. GDPR)”

Voor enterprise-omgevingen stelt Beleid inzake gebruik van cloudservices Beleid inzake gebruik van cloudservices, sectie “Governancevereisten”, clausule 5.1:

“De organisatie moet een centraal register van cloudservices onderhouden, eigendom van de CISO, met daarin:”

Clausule 5.4 maakt cloudverantwoordelijkheden vervolgens contractueel afdwingbaar:

“Alle contracten met CSP’s (Cloud Service Providers) moeten afdwingbare bepalingen bevatten voor:”

Leveranciersgovernance breidt de matrix uit voorbij de directe provider. Beleid inzake beveiliging van derden en leveranciers - mkb Beleid inzake beveiliging van derden en leveranciers - mkb, sectie “Governancevereisten”, clausule 5.3.5 vereist:

“Beperkingen op verdere onderuitbesteding zonder goedkeuring”

Dezelfde mkb-leveranciersbeleidslijn voegt in de sectie “Vereisten voor beleidsimplementatie”, clausule 6.3.1, periodieke beoordeling toe:

“Kritieke of risicovolle leveranciers moeten ten minste jaarlijks worden beoordeeld. De beoordeling moet verifiëren:”

Op enterpriseniveau stelt Beleid inzake beveiliging van derden en leveranciers Beleid inzake beveiliging van derden en leveranciers, sectie “Governancevereisten”, clausule 5.3:

“Contracten met leveranciers moeten het volgende bevatten:”

Voor persoonsgegevens vereist Beleid inzake gegevensbescherming en privacy Beleid inzake gegevensbescherming en privacy, sectie “Handhaving en naleving”, clausule 8.5.1:

“Contracten met verwerkers moeten het volgende bevatten:”

Voor zichtbaarheid op afhankelijkheden vereist Beleid inzake beheer van leveranciersafhankelijkheidsrisico’s Beleid inzake beheer van leveranciersafhankelijkheidsrisico’s, clausule 6.5.4:

“De leveranciersrelatie gebruiken om updates te verkrijgen over onderaannemers of afhankelijkheden in de toeleveringsketen één niveau downstream waar zij ons kunnen raken (bijvoorbeeld: als een kritieke softwareleverancier sterk afhankelijk is van een bibliotheek van een derde partij, moet dit worden vastgelegd).”

Voor logs biedt Beleid voor logging en monitoring - mkb Beleid voor logging en monitoring - mkb, sectie “Governancevereisten”, clausule 5.5.1.3, een concrete contractuele eis:

“Contracten moeten providers verplichten logs ten minste 12 maanden te bewaren en op verzoek toegang te verlenen”

Samen maken deze beleidslijnen de matrix tot een vereiste governanceregistratie die leveranciersgoedkeuring, cloudonboarding, privacyverantwoordingsplicht, jaarlijkse beoordeling en auditbewijsmateriaal ondersteunt.

De matrix mappen naar ISO/IEC 27001:2022, NIS2, DORA en GDPR

De klassieke fout is het maken van vier afzonderlijke compliancewerkboeken. Eén beheersmaatregel kan aan meerdere verplichtingen voldoen als verantwoordelijkheid en bewijsmateriaal traceerbaar zijn.

ISO/IEC 27001:2022 levert de ISMS-motor: context, belanghebbenden, scope, leiderschap, risicobehandeling, doelstellingen, operationele beheersing, prestatie-evaluatie en verbetering. Annex A biedt de praktische beheersstructuur.

NIS2 Article 21 sluit natuurlijk aan op dezelfde matrix via beveiliging van de toeleveringsketen, incidentafhandeling, continuïteit, toegangscontrole, beheer van bedrijfsmiddelen en veilige verwerving. Article 20 maakt de matrix relevant voor het bestuur, omdat managementorganen maatregelen voor cyberbeveiligingsrisicobeheer moeten goedkeuren en daarop toezicht moeten houden.

DORA maakt van de matrix een instrument voor ICT-risico’s van derden. Articles 5, 6 en 8 vereisen governance, gedocumenteerd ICT-risicobeheer en identificatie van activa, functies en afhankelijkheden. Articles 17 tot en met 19 vereisen incidentdetectie, classificatie, escalatie, communicatie en rapportage. Articles 28 tot en met 30 vereisen risicobeheer voor derden, analyse van concentratierisico, contractuele bepalingen, beheersmaatregelen voor onderuitbesteding, auditrechten, beëindigingsrechten en exitstrategieën.

GDPR voegt de persoonsgegevenslens toe. Elke rij voor een cloudservice moet aangeven of persoonsgegevens worden verwerkt, of de provider verwerker of subverwerker is, of gegevenslocatie relevant is en welk contractueel of verwerkersovereenkomst-bewijsmateriaal beschikbaar is.

NIST CSF 2.0 helpt dezelfde matrix in uitkomsttaal te communiceren. De GOVERN-functie behandelt organisatorische context, wettelijke en regelgevende vereisten, afhankelijkheden, risicobeheer, rollen, beleidslijnen en toezicht. GV.SC-uitkomsten zijn bijzonder bruikbaar voor cyberrisico’s van leveranciers, waaronder leveranciersrollen, criticaliteit, contractuele eisen, due diligence, monitoring, incidentcoördinatie en planning van beëindiging.

COBIT 2019 voegt een assurance- en governancelens toe. Het vraagt of verantwoordingsplicht, managementpraktijken, eigenaarschap, monitoring en herstel van issues herhaalbaar zijn en met bewijsmateriaal worden onderbouwd.

De matrix opbouwen van register naar bewijs

Stel u een SaaS-bedrijf voor dat gebruikmaakt van een hyperscale IaaS-platform, een beheerde databank, een identiteitsprovider van een derde partij, een SaaS-platform voor klantondersteuning en een extern SIEM. De implementatiestroom is overzichtelijk.

Stap 1: Begin met het register van cloudservices

Gebruik Beleid inzake gebruik van cloudservices of Beleid inzake gebruik van cloudservices - mkb als trigger. Registreer per cloudservice de eigenaar, het doel, gegevenscategorieën, locatie, bedrijfsfunctie, leveranciersniveau, contracteigenaar en beoordelingsdatum.

Als de dienst klantregistraties, authenticatielogboeken of supporttickets opslaat, markeer deze dan als privacyrelevant. Als de dienst productiebeschikbaarheid ondersteunt, markeer deze dan als operationeel kritiek. Als de dienst een kritieke of belangrijke functie van een financiële klant ondersteunt, markeer deze dan als DORA-relevant.

Stap 2: Voeg domeinen voor gedeelde verantwoordelijkheid toe

Definieer voor elke dienst de verantwoordelijkheden binnen de kerndomeinen.

Stap 3: Koppel beheersmaatregelen aan risico en de Verklaring van Toepasselijkheid

Zenith Blueprint, fase Risk Management, stap 13, legt de traceerbaarheidseis uit:

“Verwijs naar regelgeving: als bepaalde beheersmaatregelen specifiek zijn geïmplementeerd om te voldoen aan GDPR, NIS2 of DORA, kunt u dat noteren in het risicoregister (als onderdeel van de onderbouwing van de risico-impact) of in de SoA-notities.”

Het risico “ongeautoriseerde toegang tot productiegegevens van klanten door cloudmisconfiguratie” kan bijvoorbeeld worden gekoppeld aan toegangscontrole, cloudgebruik, logging, cryptografie, kwetsbaarhedenbeheer en leveranciersovereenkomsten. De SoA kan verwijzen naar ISO/IEC 27001:2022 Annex A 5.15, 5.16, 5.20, 5.23, 8.8, 8.15, 8.16 en 8.24, met notities voor GDPR Article 32, NIS2 Article 21 en DORA ICT-risicobeheer waar van toepassing.

Stap 4: Koppel bewijsmateriaal vóór het auditseizoen

Bewijsmateriaal moet in de matrix worden ontworpen, niet onder tijdsdruk worden verzameld.

De lijst met bewijsmateriaal zet verantwoordelijkheid om in bewijs. Zij helpt commerciële teams ook sneller te reageren op enterprise-due diligence, omdat zij niet alleen certificeringen kunnen tonen, maar ook eigenaarschap van beheersmaatregelen en operationeel bewijsmateriaal.

Subverwerkers: de blinde vlek in de meeste matrices

Subverwerkers zijn waar gedeelde verantwoordelijkheid een reëel risico in de toeleveringsketen wordt.

Een SaaS-provider kan onder GDPR uw verwerker zijn. Die provider kan afhankelijk zijn van een cloudhostingprovider, CDN, analyticsdienst, supportplatform, e-mailbezorgdienst, beheerde databank, observability-provider en betalingsverwerker. Sommige kunnen toegang hebben tot persoonsgegevens. Sommige ondersteunen kritieke dienstverlening zonder gegevens direct in te zien. Sommige kunnen buiten de EU gevestigd zijn. Sommige zijn vervangbaar. Andere kunnen concentratierisico veroorzaken.

DORA Article 29 vereist een beoordeling van concentratierisico voor kritieke of belangrijke ICT-diensten, waaronder vervangbaarheid, meerdere overeenkomsten met dezelfde of verbonden providers, onderuitbestedingsketens, onderaannemers in derde landen, insolventierecht, beperkingen voor gegevensherstel en afdwingbaarheid van gegevensbescherming binnen de Unie. DORA Article 30 vereist contractuele bepalingen over voorwaarden voor onderuitbesteding, locaties, gegevensverwerking en opslag, toegang en herstel, ondersteuning bij incidenten, samenwerking met autoriteiten, auditrechten, beëindiging en exit.

NIS2 Article 21 vereist eveneens beveiliging van de toeleveringsketen voor directe leveranciers en dienstverleners, plus aandacht voor leveranciersspecifieke kwetsbaarheden, cyberbeveiligingspraktijken van leveranciers en procedures voor veilige ontwikkeling.

Daarom behandelt Clarysec subverwerkersmapping als een vereiste uitbreiding van leveranciersgovernance, niet als uitsluitend een privacylijst. Het subverwerkersregister moet tonen welke leverancier de subverwerker gebruikt, van welke dienst deze afhankelijk is, of persoonsgegevens worden verwerkt, of een kritieke functie wordt ondersteund, welke verwerkingsregio relevant is, welke doorlegverplichtingen gelden, welke goedkeurings- of bezwaarrechten bestaan, welke assurance beschikbaar is, welke monitoringmethode wordt toegepast en welke exitoptie bestaat.

Zenith Blueprint, fase Controls in Action, stap 23 stelt:

“Identificeer voor elke kritieke leverancier of zij onderaannemers (subverwerkers) gebruiken die toegang kunnen hebben tot uw gegevens of systemen. Documenteer hoe uw informatiebeveiligingseisen aan deze partijen worden doorgelegd, via de contractvoorwaarden van uw leverancier of via uw eigen directe clausules.”

Dat is het bewijsniveau dat auditors verwachten wanneer zij vragen of cloudverantwoordelijkheden downstream worden beheerst.

Hoe auditors dezelfde matrix toetsen

Een sterke matrix voor gedeelde verantwoordelijkheid in de cloud doorstaat meerdere auditstijlen, omdat zij is opgebouwd rond eigenaarschap, afdwingbaarheid en bewijsmateriaal.

De matrix is niet het einddoel. Zij is de kaart die auditors gebruiken om te toetsen of het governancesysteem werkelijk functioneert.

Een ISO-auditor kan een hoog-impact cloudtoegangsrisico selecteren en dit traceren van risicoregister naar SoA en vervolgens naar toegangsrechtenbeoordelingen, MFA-bewijsmateriaal en monitoringwaarschuwingen. Een DORA-beoordelaar kan een kritieke ICT-provider selecteren en vragen om de exittest, analyse van onderuitbesteding en contractuele auditrechten. Een GDPR-beoordelaar kan zich richten op verwijdering, gegevensresidentie, melding van inbreuken en transparantie over subverwerkers.

Veelvoorkomende faalpatronen

De meest voorkomende fouten bij gedeelde verantwoordelijkheid zijn niet exotisch.

Ten eerste vertrouwen organisaties op assurance-rapporten van providers zonder deze te koppelen aan klantverantwoordelijkheden. Een cloudprovider kan fysieke beveiliging, infrastructuurweerbaarheid en platformbeheersmaatregelen aantonen, maar niet of uw opslagbucket privé was, IAM-rollen het principe van minimale privileges volgden of logs waren ingeschakeld.

Ten tweede bevatten contracten generieke beveiligingstaal, maar geen incidenttermijnen, rechten op toegang tot logs, auditrechten, beperkingen op onderuitbesteding, bepalingen voor teruggave van gegevens of exitondersteuning. Zenith Blueprint, fase Controls in Action, stap 23 benadrukt typische gebieden voor leveranciersovereenkomsten, zoals vertrouwelijkheid, toegangscontrole, technische en organisatorische maatregelen, incidenttermijnen, auditrechten, beheersmaatregelen voor onderaannemers en bepalingen bij einde contract.

Ten derde worden subverwerkers voor privacydoeleinden vermeld, maar niet gekoppeld aan beveiliging, continuïteit of concentratierisico. Een downstream-observability- of supportprovider verschijnt mogelijk nooit in het risicoregister, hoewel een uitval of inbreuk bij die partij de klantdienstverlening kan raken.

Ten vierde zegt de SoA dat een beheersmaatregel van toepassing is, maar kan niemand operationeel bewijsmateriaal overleggen. Cloudlogging kan als geïmplementeerd zijn gemarkeerd, maar de organisatie kan geen retentie-instellingen, toegangsrechtenbeoordelingen, afhandeling van waarschuwingen of toezeggingen van providers voor toegang tot logs aantonen.

Ten vijfde weerspiegelen incidentresponsplannen de providerafhankelijkheid niet. Als de provider een platformincident meldt, wie beoordeelt dan de impact voor klanten? Wie bepaalt of een melding op grond van NIS2, DORA of GDPR vereist is? Wie neemt contact op met getroffen klanten? Wat als de oorzaak bij een subverwerker ligt?

Verantwoordingsplicht van het management: waarom het bestuur dit belangrijk moet vinden

NIS2 Article 20 vereist dat managementorganen maatregelen voor cyberbeveiligingsrisicobeheer goedkeuren, toezicht houden op de implementatie en training ontvangen. DORA Article 5 vereist dat het managementorgaan ICT-risicobeheerregelingen definieert, goedkeurt, bewaakt en ervoor verantwoordelijk is, inclusief beleid voor ICT-derden, continuïteits- en herstelplannen, auditplannen, trainingen en rapportagekanalen.

Dit verandert het doel van de matrix. Zij is niet langer alleen een security-werkblad. Zij wordt bewijsmateriaal dat het management weet:

• Welke cloudservices kritieke activiteiten ondersteunen.
• Welke derde partijen en subverwerkers materieel zijn.
• Welke verplichtingen gelden op grond van klantcontracten, GDPR, NIS2 en DORA.
• Welke verantwoordelijkheden bij de organisatie blijven.
• Welke toezeggingen van providers contractueel afdwingbaar zijn.
• Welke hiaten financiering, herstelmaatregelen of risicoacceptatie vereisen.

Voor mkb-ondernemingen is proportionaliteit belangrijk. Een kleinere entiteit heeft geen zware bureaucratie nodig, maar wel documentatie, monitoring, weerbare systemen, detectie van ICT-risicobronnen, identificatie van belangrijke afhankelijkheden van derden, continuïteitsmaatregelen, testen, geleerde lessen en periodieke beoordeling waar dit binnen de scope valt.

De matrix is een van de meest efficiënte proportionele instrumenten, omdat zij verplichtingen consolideert in plaats van vermenigvuldigt.

Een sprint van 30 dagen om uw cloudmodel auditklaar te maken

Als u niet kunt beantwoorden wie eigenaar is van elke cloudbeheersmaatregel, welk bewijsmateriaal dit aantoont en welke subverwerker dit kan beïnvloeden, is uw model voor gedeelde verantwoordelijkheid nog steeds een diagram, geen governanceartefact.

Een praktische sprint van 30 dagen ziet er als volgt uit:

1. Maak of actualiseer het register van cloudservices met Beleid inzake gebruik van cloudservices of Beleid inzake gebruik van cloudservices - mkb.
2. Identificeer kritieke diensten, verwerking van persoonsgegevens, publieksgerichte systemen en relevantie voor DORA of NIS2.
3. Bouw de eerste matrix rond ISO/IEC 27001:2022 Annex A-beheersmaatregelen 5.20, 5.21 en 5.23 met Zenith Controls.
4. Koppel elke rij aan het risicoregister en de Verklaring van Toepasselijkheid met stap 13 van Zenith Blueprint.
5. Valideer leveranciers- en verwerkersclausules met Beleid inzake beveiliging van derden en leveranciers, Beleid inzake beveiliging van derden en leveranciers - mkb en Beleid inzake gegevensbescherming en privacy.
6. Voeg logretentie, incidentescalatie, goedkeuring van subverwerkers, auditrechten en exitbewijsmateriaal toe.
7. Beoordeel kritieke leveranciers jaarlijks, en na ingrijpende wijzigingen, incidenten, nieuwe subverwerkers of auditbevindingen.

Het doel is eenvoudig. Wanneer de klant, auditor, toezichthouder of het bestuur vraagt “wie is eigenaar van deze beheersmaatregel?”, zoekt u niet in contracten, tickets en mappen. U opent de matrix, toont de eigenaar, toont de clausule, toont het bewijsmateriaal en toont het downstream-spoor.

Clarysec kan u helpen assurance-pakketten van cloudproviders om te zetten in een geïntegreerde matrix voor gedeelde verantwoordelijkheid voor ISO/IEC 27001:2022-audits, NIS2-gereedheid, DORA ICT-risico’s van derden, GDPR-verantwoordingsplicht en due diligence door enterprise-klanten.

Begin met het register. Bouw de matrix. Koppel het bewijsmateriaal. Gebruik haar vervolgens als bestuursgereed bewijs dat cloudrisico niet wordt uitbesteed, maar wordt beheerst.