C5-attestatie: bereid bewijs voor cloud-assurance voor

Een cloudklant wil weten welke beschermingsmaatregelen de aanbieder uitvoert en welke de eigen verantwoordelijkheid van de klant blijven. Het Duitse Bundesamt für Sicherheit in der Informationstechnik (BSI) publiceert de Cloud Computing Compliance Criteria Catalogue, C5, als gestructureerde basis om die assurance te onderzoeken. Voor een CTO betekent voorbereiding dat de grens van de dienst, de implementatie van controls en de operationele registraties controleerbaar worden gemaakt, niet alleen dat er beleidsdocumenten worden verzameld.

C5 is een criteriacatalogus die wordt gebruikt voor onafhankelijke attestatie, geen certificering in ISO-stijl. De C5-documentatie van het BSI is de primaire referentie. Begin met het afspreken van de toepasselijke editie, het assurance-doel en de scope van het onderzoek met de onafhankelijke auditor.

Definieer precies welke dienst het rapport dekt

Beschrijf de clouddienst, de operationele locaties, de organisatorische grenzen en de afhankelijkheden. Een rapport dat één dienst dekt, dekt niet automatisch elk product onder hetzelfde merk. Benoem productiecomponenten, beheerinterfaces, supportactiviteiten en externe diensten die van invloed kunnen zijn op de assurance-claims.

De systeembeschrijving moet een buitenstaander laten begrijpen hoe klantgegevens de dienst binnenkomen, erdoorheen bewegen en hem verlaten. Neem beheerpaden, deploymentprocessen, beveiligingsmonitoring, back-ups en de verdeling van verantwoordelijkheden tussen teams op. Licht relevante kenmerken van de dienst en operationele omstandigheden toe in plaats van architectuurdiagrammen als vervanging voor een toelichting te gebruiken.

Beantwoord deze scopevragen voordat u bewijs verzamelt:

• Welke producten, regio's en omgevingen vallen erbinnen?
• Welke teams beheren de productieomgeving of hebben toegang tot klantinformatie?
• Welke onderliggende aanbieders ondersteunen de dienst en hoe worden hun controls behandeld?
• Welke configuraties en beveiligingstaken blijven bij klanten?
• Welke wezenlijke wijzigingen hebben tijdens de onderzoeksperiode plaatsgevonden of zijn gepland?

Geef uitsluitingen een expliciete onderbouwing. Als een legacy-deployment is uitgesloten, zorg dan dat verklaringen richting klanten niet de indruk wekken dat die is gedekt. Het resultaat is een geversioneerde systeembeschrijving, ondersteund door registraties van architectuur, afhankelijkheden en verantwoordelijkheden.

Kies het rapporttype voordat u de bewijskalender vaststelt

C5-assurance wordt doorgaans uitgedrukt in een attestatierapport van een auditor. Type 1 betreft het ontwerp en de implementatie van controls op een bepaald moment. Type 2 onderzoekt daarnaast de operationele effectiviteit over een bepaalde periode.

Type 1 kan een nuttige mijlpaal zijn bij het opzetten van een controlomgeving, maar beantwoordt niet dezelfde vraag als Type 2. Bevestig wat klanten werkelijk vereisen voordat u voor een tussentijds rapport kiest.

Spreek de periode en de verwachtingen over bewijs af met de auditor. Ga niet uit van een universele lengte van de observatieperiode. Een procedure die tegen het einde van een periode is geschreven, kan niet aantonen dat de control eerder werkte. Evenzo wist een geslaagde actuele test een historisch falen niet uit.

Bouw bewijs rond verantwoordelijkheid en uitvoering

Een praktische voorbereidingsmethode is een bewijsregister dat elk toepasselijk criterium verbindt met de geïmplementeerde control, de eigenaar, de grens van de dienst, de bewijsbron, de reviewfrequentie en openstaande lacunes. Leg toepasselijkheidsbeslissingen en hun onderbouwing vast; markeer een criterium niet als irrelevant alleen omdat de implementatie lastig zou zijn.

Scheid drie vragen: wat er zou moeten gebeuren, wat er is geïmplementeerd en wat er werkelijk is gebeurd. Een beleid beantwoordt de eerste vraag. Configuratieregistraties kunnen de tweede ondersteunen. Tickets, logs, goedkeuringen en testresultaten ondersteunen de derde.

Dit zijn praktische voorbeelden, geen volledige C5-checklist. Gebruik de afgesproken catalogus en scope om de vereiste dekking te bepalen, inclusief organisatorische, personele, fysieke en technische controls.

Maak bewijs reproduceerbaar

Bewaar voor elke export of screenshot het bronsysteem, de verzameldatum, de relevante periode, de filters en de verzamelaar. Leg uit of het de volledige populatie of een geselecteerd item weergeeft. Auditors moeten de populatie begrijpen waaruit zij steekproeven trekken; een map met alleen geslaagde voorbeelden volstaat niet.

Geef de voorkeur aan registraties die actor, tijdstempel, actie en uitkomst bewaren. Bescherm bewijs tegen ongeautoriseerde wijziging en voorkom onnodige blootstelling van klantgegevens. Waar redactie nodig is, behoudt u voldoende context zodat de reviewer begrijpt wat de registratie aantoont.

Scheid overgenomen controls van behouden plichten

De assurance van een infrastructuuraanbieder kan fysieke beveiliging of onderliggende platformcontrols ondersteunen. Zij stelt niet vast dat de tenantautorisatie van uw applicatie werkt. Documenteer de afhankelijkheid, de relevante rapportscope, de periode, uitzonderingen en de verantwoordelijkheden die uw team nog moet vervullen.

Ook complementaire controls van klanten hebben een praktische formulering nodig. ‘Klant verantwoordelijk voor beveiliging’ is te breed. Specificeer taken zoals het beheren van tenantgebruikers, het configureren van identiteitsfederatie of het reviewen van door de klant beheerd toegangsbeleid. Houd deze verantwoordelijkheden consistent in de systeembeschrijving, de dienstdocumentatie en de contractuele afspraken.

Voer de voorbereiding uit als een engineeringprogramma

Begin met een gapanalyse tegen de afgesproken criteria. Onderscheid ontbrekende implementatie van ontbrekend bewijs: die vereisen verschillende oplossingen. Een ongedocumenteerde review vraagt misschien om betere registraties; een toegangsreview die nooit heeft plaatsgevonden, vereist een operationele control.

Wijs elke lacune een eigenaar, een remediatieactie, een afhankelijkheid en een streefdatum toe. Geef voorrang aan problemen die van invloed zijn op tenantscheiding, geprivilegieerde toegang, productiewijzigingen, incidentrespons en herstelbaarheid, afhankelijk van de risico's van de dienst, en niet alleen aan de gemakkelijkste documentatietaken.

Controleer vóór de Type 2-periode of terugkerende controls een werkbare planning en duurzame registraties hebben. Bevestig wie ze uitvoert bij afwezigheid of personeelsverloop. Zorg er bij gebeurtenisgestuurde controls, zoals het beëindigen van accounts, voor dat de populatie van triggers kan worden geïdentificeerd.

Voer een gereedheidswalkthrough uit met representatief bewijs. Volg één wijziging van verzoek tot deployment, één vertrekkende beheerder tot de intrekking en één hersteloefening tot de corrigerende maatregel. Zo komen gebroken overdrachten aan het licht die bij een beleidsreview kunnen worden gemist.

Houd tijdens het onderzoek een verzoekenregister bij met eigenaren en de status van antwoorden. Houd originele registraties beschikbaar, licht afwijkingen open toe en volg remediatie afzonderlijk van historisch bewijs. Herschrijf oude registraties niet om ze compliant te laten lijken. De auditor bepaalt hoe bevindingen het testen en het oordeel beïnvloeden.

Uitgewerkt voorbeeld: een beheerde applicatie op externe infrastructuur

Stel ter illustratie dat een aanbieder een multi-tenant applicatie in één regio draait, een externe infrastructuuraanbieder gebruikt en Type 2-assurance nastreeft. Het team beheert applicatiereleases, tenantrechten, productiebeheer en herstelprocedures.

De scopebeschrijving benoemt de applicatie, de database, het beheervlak, de supporttooling en de afhankelijkheid van de infrastructuur. Zij legt uit welke onderliggende controls worden overgenomen en welke bij de applicatieaanbieder blijven.

Voor tenantisolatie legt het team het autorisatieontwerp, geautomatiseerde negatieve tests, bevindingen uit beveiligingstests en releasegoedkeuringen vast. Het bewaart ook wijzigingsregistraties die laten zien wanneer de autorisatielogica is gewijzigd. Het infrastructuurrapport is ondersteunend bewijs over een afhankelijkheid, geen bewijs van applicatie-isolatie.

Voor geprivilegieerde toegang bewaart het team de populatie beheerders, goedkeuringen van toekenningen, reviewbeslissingen en registraties van verwijderingen. Stel dat een review een ongebruikt supportaccount aan het licht brengt. Het team legt de ontdekking, de intrekking, de beoordeling van de blootstelling en de preventieve maatregel vast. Dat is geloofwaardiger dan alleen de opgeschoonde accountlijst indienen.

Voor herstel bewaart het team een resultaat van een hersteltest dat laat zien wat er is hersteld, hoeveel tijd dat kostte, welke integriteitscontroles op de gegevens zijn uitgevoerd en welke beperkingen nog openstaan. Een geconfigureerde back-uptaak alleen toont geen herstelbaarheid aan. Elke bewijsset heeft een eigenaar en een gedefinieerde periode, zodat de auditor de registraties kan verbinden met de onderzochte control.

Hergebruik assurance-werk zonder gelijkwaardigheid te claimen

ISO/IEC 27001 betreft een afgebakend managementsysteem voor informatiebeveiliging. SOC 2 is een attestatierapport met eigen criteria en een eigen rapportagecontext. C5 richt zich op assurance voor clouddiensten op basis van de BSI-catalogus.

Bestaande risicobeoordelingen, toegangscontrols, incidentprocedures en operationele registraties kunnen meer dan één programma ondersteunen. Hergebruik ze via versie- en scopespecifieke mappings en controleer daarna op verschillen in eisen of rapportage. Een gedeelde control betekent niet automatisch gelijkwaardigheid tussen frameworks.

Kies het assurance-portfolio op basis van werkelijke klanteisen en risico's van de dienst. C5 is niet voor elke cloudaanbieder verplicht; eisen uit aanbestedingen, contracten of toepasselijke sectorregels vragen om een afzonderlijke review. Noch een C5-rapport noch een ander assurance-document stelt op zichzelf naleving van de AVG of NIS2 vast.

Bereid het rapport voor op beslissingen van klanten

Klanten hebben de systeembeschrijving, de datum of periode, het werkelijke oordeel, uitzonderingen en de grenzen van verantwoordelijkheden nodig, niet alleen het label van het rapport. Respecteer bij het delen van rapporten de contractuele vertrouwelijkheid en geef context voor de beoordeling door de klant.

Licht de status van remediatie toe zonder te suggereren dat latere oplossingen het historische oordeel veranderen. Als de rapportperiode voorafgaat aan een grote architectuurwijziging, benoem die beperking dan. Spreek terugkerende onderzoeken af op basis van klantverwachtingen en operationele wijzigingen, in plaats van attestatie als een tijdloos keurmerk te behandelen.

Secani helpt teams de implementatie van controls en bewijs te verbinden met gereviewde eisen. Modelleer de dienst en de afhankelijkheden, wijs eigenaren en reviewers toe, koppel ondersteunende registraties en zet lacunes in bewijs om in taken. Houd menselijke goedkeuring expliciet voor mappings en conclusies. Het model voor auditgereedheid helpt de scope en verantwoordelijkheid achter elke claim te bewaren.

Vragen om op te lossen vóór het eerste onderzoek

Geeft het BSI het rapport af?

Het BSI publiceert de catalogus. Een onafhankelijke auditor voert het onderzoek uit en geeft het attestatierapport af; bevestig het toepasselijke assurance-framework en de opdrachtvoorwaarden met die auditor.

Wat als er geen echt incident heeft plaatsgevonden?

Verzin geen incidentregistratie. Bewaar bewijs dat het proces is geïmplementeerd en, waar passend, is geoefend. Spreek met de auditor af hoe het ontbreken van gebeurtenissen het testen beïnvloedt.

Wat moet het team nu doen?

Neem één representatieve productiedienst en stel de scopebeschrijving, de verantwoordelijkhedenmatrix en het bewijsregister ervan op. Review die drie resultaten met de beoogde auditor voordat u een groot bewijspakket samenstelt.