Nalevingsnormen voor cloudbeveiliging – PCI DSS en AVG

Cloudbeveiligingsnormen zoals PCI DSS en GDPR stellen de beveiligings- en privacyverplichtingen vast die van toepassing zijn wanneer u gereguleerde gegevens opslaat, verwerkt of verzendt op AWS, Azure of GCP. Deze normen zijn belangrijk omdat de certificeringen van een cloudprovider slechts een deel van de gedeelde verantwoordelijkheid dekken; de rest blijft uw verantwoordelijkheid en het niet naleven ervan kan leiden tot aanzienlijke boetes. De aanbevolen aanpak: breng elke vereiste in kaart en bepaal wie er daadwerkelijk verantwoordelijk voor is, u of de cloudprovider, voordat u ervan uitgaat dat "de cloud voldoet aan de regelgeving" u dekt.

Gepubliceerd: november 2020. Bijgewerkt: augustus 2026. Beoordeeld door het Compliance Advisory Team van Encryption Consulting.

Dit bericht behandelt de algemene naleving van cloudcompliance voor PCI DSS en GDPR. Als uw specifieke zorg betrekking heeft op de fysieke locatie van PKI-sleutels, auditlogboeken en beheerdersrechten voor gegevenssoevereiniteitsdoeleinden, gaat onze handleiding over gegevenssoevereiniteit en regionale compliance dieper in op de mapping daarvan binnen GDPR, NIS2, DORA en FedRAMP.

Wat is het model voor gedeelde verantwoordelijkheid in de cloud?

Het model van gedeelde verantwoordelijkheid houdt in dat de taken op het gebied van beveiliging en compliance worden verdeeld tussen u en uw cloudserviceprovider (CSP) . Waar die grens precies ligt, hangt af van het servicemodel dat u gebruikt. Een CSP is altijd verantwoordelijk voor de fysieke beveiliging van zijn datacenters en voor de beveiliging van de infrastructuur die ten grondslag ligt aan de service die u afneemt. U bent altijd verantwoordelijk voor de configuratie en het gebruik van die service, uw gegevens, uw toegangsrechten en uw eigen complianceverplichtingen. De overstap van Infrastructure-as-a-Service (IaaS) naar Platform-as-a-Service (PaaS) naar Software-as-a-Service (SaaS) verschuift een groter deel van de technische verantwoordelijkheid naar de CSP, maar de complianceverantwoordelijkheid zelf blijft onveranderd. U moet nog steeds controleren of de CSP daadwerkelijk aan de vereiste normen voldoet en dit documenteren.

Hoe is PCI DSS van toepassing op cloudomgevingen?

PCI DSS (Payment Card Industry Data Security Standard) is van toepassing op uw cloudomgeving zodra kaartgegevens van klanten daar worden opgeslagen, verwerkt of verzonden. Het vereist validatie van zowel de infrastructuur van de cloudserviceprovider (CSP) als uw eigen gebruik ervan. PCI DSS is een reeks beveiligingsvereisten, momenteel versie 4.0.1, die in 2004 zijn opgesteld door de betaalkaartmerken en worden beheerd door de PCI Security Standards Council. De standaard is van toepassing op elk bedrijf dat betaalkaartgegevens verwerkt, ongeacht de omvang.

De verantwoordelijkheid voor elke vereiste wordt nog steeds verdeeld per servicemodel. De onderstaande tabel laat zien hoe die verdeling er doorgaans uitziet, hoewel de exacte verdeling altijd is vastgelegd in uw contract en de Verklaring van Naleving met de CSP, en niet louter op basis van het servicemodel kan worden aangenomen.

PCI DSS-vereiste				Verantwoordelijkheidstoewijzing voor het beheer van controles
				IaaS	PaaS	SaaS
Installeer en onderhoud netwerkbeveiligingsmaatregelen om kaartgegevens te beschermen.				Klant en CSP	Klant en CSP	CSP
Pas beveiligde configuraties toe op alle systeemcomponenten, gebruik geen door de leverancier geleverde standaardinstellingen.				Klant en CSP	Klant en CSP	CSP
Bescherm opgeslagen accountgegevens				Klant en CSP	Klant en CSP	CSP
Bescherm kaarthoudergegevens met sterke cryptografie tijdens de overdracht via open, openbare netwerken				Bedrijf	Klant en CSP	CSP
Bescherm alle systemen en netwerken tegen schadelijke software				Bedrijf	Klant en CSP	CSP
Ontwikkel en onderhoud veilige systemen en software				Klant en CSP	Klant en CSP	Klant en CSP
Beperk de toegang tot systeemcomponenten en kaartgegevens op basis van de noodzaak voor de bedrijfsvoering.				Klant en CSP	Klant en CSP	Klant en CSP
Identificeer gebruikers en authenticeer toegang tot systeemcomponenten				Klant en CSP	Klant en CSP	Klant en CSP
Beperk de fysieke toegang tot kaarthoudergegevens				CSP	CSP	CSP
Registreer en controleer alle toegang tot systeemcomponenten en kaarthoudergegevens				Klant en CSP	Klant en CSP	CSP
Test regelmatig de beveiliging van systemen en netwerken				Klant en CSP	Klant en CSP	CSP
Ondersteun informatiebeveiliging met organisatiebeleid en -programma's				Klant en CSP	Klant en CSP	Klant en CSP

PCI DSS v4.0.1 voegde twee vereisten toe die met name voor cloudimplementaties de moeite waard zijn om te vermelden. Versleuteling op schijfniveau kwalificeert niet langer als "versleuteling in rust", behalve op verwijderbare media. Dit betekent dat volledige schijf- of volumeversleuteling voor kaartgegevens die in de cloud zijn opgeslagen, een compenserende maatregel nodig heeft, zoals versleuteling op bestands- of kolomniveau. Daarnaast moeten organisaties nu minstens jaarlijks de daadwerkelijk gebruikte cryptografische suites en protocollen formeel beoordelen, inclusief actieve monitoring van algoritmen of protocollen die binnenkort niet meer ondersteund zullen worden. Deze beoordeling is gemakkelijk over te slaan in een cloudomgeving waar de TLS-configuratie gedeeltelijk door de cloudserviceprovider (CSP) wordt beheerd.

Hoe is de AVG van toepassing op cloudomgevingen?

De AVG (Algemene Verordening Gegevensbescherming) is van toepassing op elke organisatie, waar ook ter wereld, die persoonsgegevens verzamelt of verwerkt van mensen die zich in de EU bevinden. De AVG stelt u verantwoordelijk voor de manier waarop uw cloudserviceprovider (CSP) die gegevens namens u verwerkt, en niet alleen voor de manier waarop u ze zelf verwerkt. Niet-EU-bedrijven die gegevens van EU-ing ingezetenen verwerken, moeten een EU-vertegenwoordiger aanstellen en blijven aansprakelijk voor boetes en sancties, ongeacht waar het bedrijf zelf gevestigd is.

De belangrijkste vereisten van de AVG, waarvan er diverse directe technische implicaties hebben in een cloudomgeving, zijn:

1. Rechtmatige, eerlijke en transparante verwerking.
2. Doel, gegevens en opslagbeperkingen. Verzamel alleen de noodzakelijke gegevens en verwijder persoonsgegevens zodra de verwerking is voltooid.
3. Rechten van de betrokkene. Iemand kan vragen welke gegevens u over hem of haar bewaart en hoe deze worden gebruikt.
4. Toestemming. Voor verwerking die verder gaat dan legitieme doeleinden, moet u toestemming verkrijgen, en de betrokkene kan die toestemming te allen tijde intrekken.
5. Melding van een datalek met persoonsgegevens. Toezichthouders moeten binnen 72 uur op de hoogte worden gesteld zodra uw organisatie kennisneemt van een datalek. Dit is volledig afhankelijk van de registratie en monitoring die het lek tijdig detecteert.
6. Privacy is van ontwerp. Integreer gegevensbescherming vanaf het begin in nieuwe systemen en processen, en niet als een bijkomstigheid.
7. Gegevensbeschermingseffectbeoordelingen. Voer een dergelijke evaluatie uit bij de start van een nieuw project, een wijziging of een product waarbij aanzienlijke hoeveelheden persoonsgegevens worden verwerkt.
8. Gegevensoverdrachten. U blijft verantwoordelijk voor de naleving van de AVG, zelfs wanneer een derde partij (waaronder uw CSP) de gegevens namens u verwerkt.
9. Functionaris gegevensbescherming. Vereist wanneer uw organisatie aanzienlijke hoeveelheden persoonsgegevens verwerkt.
10. Bewustwording en training. Werknemers moeten de GDPR-vereisten begrijpen die relevant zijn voor hun functie.

Om daadwerkelijk aan deze eisen te voldoen in een cloudomgeving, moet u de volgende extra stappen nemen: weet precies waar uw cloudserviceprovider (CSP) de gegevens opslaat en verwerkt; bevestig welke CSP-services en -configuraties aan uw beveiligingsnormen voldoen en configureer deze dienovereenkomstig, aangezien GDPR-naleving niet automatisch is, zelfs niet als de CSP zelf gecertificeerd is; sluit een gegevensverwerkingsovereenkomst af met elke CSP en cloudapplicatie die u gebruikt; verzamel en verwerk alleen de gegevens die u nodig hebt; controleer of de gegevensverwerkingsovereenkomst daadwerkelijk wordt nageleefd en niet alleen is ondertekend; en bevestig dat u de gegevens van een persoon op verzoek kunt wissen uit elke gegevensbron binnen de CSP, niet alleen uit uw primaire database.

Welke invloed heeft het beheer van encryptiesleutels op de naleving van PCI DSS en de AVG?

De locatie van uw encryptiesleutel, en niet alleen of gegevens versleuteld zijn, bepaalt wie technisch gezien toegang heeft tot gereguleerde gegevens. Dit is precies waar zowel PCI DSS-auditors als GDPR-toezichthouders steeds vaker naar vragen.

Sleutelbesturingsmodel	Wat het betekent	Relevantie voor naleving
Native (cloud-beheerd)	De sleutel wordt gegenereerd en bewaard in de eigen sleutelbeheerservice van de CSP (AWS KMS, Azure Key Vault, GCP Cloud KMS).	Voldoet aan de PCI DSS-vereiste voor de bescherming van opgeslagen accountgegevens en het documenteren van sleutelbeheerprocedures; de CSP heeft technisch gezien toegang tot het sleutelmateriaal, dat u volgens sommige GDPR-gegevensverwerkingsovereenkomsten aan betrokkenen moet verstrekken.
BYOK (breng je eigen sleutel mee)	Je genereert het sleutelmateriaal en importeert het in de HSM van de CSP.	Toont de belangrijkste herkomst aan voor auditdoeleinden; er blijft na import nog steeds een bruikbare kopie in de CSP achter, zodat de CSP niet uit uw gegevensstroomdiagram wordt verwijderd.
HYOK (houd je eigen sleutel vast)	Sleutelmateriaal verlaat nooit uw eigen of een externe sleutelbeheerder; de CSP roept het bij elke bewerking aan.	Het meest overtuigende technische antwoord op de vraag "kan de CSP onze gegevens lezen?" is relevant wanneer een GDPR-gegevensverwerkingsovereenkomst of een specifieke PCI DSS-scopebepaling dit vereist, maar dit gaat ten koste van de beschikbaarheid van uw externe sleutelbeheerder, die daardoor voor elke transactie een vereiste wordt.

De meeste organisaties hebben HYOK niet nodig om een ​​PCI DSS-beoordeling te doorstaan ​​of aan de AVG te voldoen. Native cloud-sleutelbeheer met gedocumenteerde procedures dekt de vereisten voor de overgrote meerderheid van de gebruikssituaties. HYOK wordt met name relevant wanneer een contract, een toezichthouder of een gegevensverwerkingsovereenkomst bewijs vereist dat de cloudserviceprovider (CSP) helemaal geen toegang heeft tot de gegevens, en niet als standaardprocedure. Onze vergelijking tussen AWS KMS, Azure Key Vault en GCP KMS beschrijft hoe elke provider BYOK en HYOK daadwerkelijk implementeert, mocht u die gedetailleerde informatie nodig hebben.

Hoe ondersteunt IAM de naleving van PCI DSS en GDPR?

Beide standaarden vereisen dat de toegang wordt beperkt tot de noodzaak om de informatie te kennen, PCI DSS benoemt dit expliciet als een beheersmaatregel en artikel 32 van de AVG vereist "passende technische en organisatorische maatregelen", die toezichthouders interpreteren als inclusief toegangscontrole.

1. Inventariseer elke identiteit, zowel van personen als van diensten, die toegang heeft tot gereguleerde gegevens of de sleutels die deze beschermen.
2. Wijs aan elke persoon met systeemtoegang een unieke ID toe, nooit gedeelde inloggegevens, zoals PCI DSS expliciet vereist.
3. Beperk elke machtiging tot het specifieke systeem, de database of de sleutel die nodig is, en niet tot toegang voor het hele account of project.
4. Scheid de rollen die encryptiesleutels beheren van de rollen die ze gebruiken om gegevens te versleutelen of te ontsleutelen.
5. Controleer de toegang regelmatig en direct bij een functieverandering of beëindiging van de functie, aangezien zowel PCI DSS-auditors als GDPR-audits verouderde toegang als een tekortkoming beschouwen.

Wat vereisen PCI DSS en GDPR met betrekking tot het rouleren van sleutels en inloggegevens?

PCI DSS vereist dat u een cryptoperiode definieert, de tijdsduur dat een sleutel mag worden gebruikt, gebaseerd op het algoritme, de sleutellengte en de gevoeligheid van de gegevens die ermee worden beschermd. U moet sleutels vervangen voordat die periode verloopt of onmiddellijk als er een vermoeden bestaat dat een sleutel is gecompromitteerd. De AVG noemt geen specifiek rotatie-interval, maar de eis van artikel 32 voor "state-of-the-art" beveiligingsmaatregelen betekent dat een sleutelrotatiebeleid dat al jaren niet is herzien, op zichzelf een zwak punt is waar toezichthouders op kunnen wijzen. In de praktijk voldoet het definiëren van een gedocumenteerd rotatiebeleid per sleutel en het daadwerkelijk afdwingen ervan via de ingebouwde rotatiefunctie van uw cloud-KMS, in plaats van een handmatige kalenderherinnering, aan beide normen tegelijk.

Welke logboekregistratie is vereist door PCI DSS en GDPR in de cloud?

PCI DSS vereist dat u alle toegang tot systeemcomponenten en kaartgegevens registreert en monitort, en de 72-uurs meldingsplicht bij een datalek volgens de AVG is in de praktijk niet afdwingbaar zonder logboeken die gedetailleerd genoeg zijn om vast te stellen wanneer een datalek daadwerkelijk is begonnen.

• PCIDSS: Logboeken moeten de individuele gebruikerstoegang tot kaartgegevens vastleggen, alle acties van accounts met beheerdersrechten en elk gebruik van identificatie- en authenticatiemechanismen. Deze logboeken moeten worden bewaard en gecontroleerd volgens een schema waarvan uw QSA bewijs zal opvragen.
• GDPR: Artikel 30 vereist registratie van verwerkingsactiviteiten, en de 72-uurstermijn van artikel 33 begint te lopen vanaf het moment dat u op de hoogte bent van een inbreuk. Dit betekent dat uw logboekregistratie actief moet worden bijgehouden, en niet alleen bewaard, om die termijn op tijd te laten ingaan in plaats van weken later.
• In de praktijk op de belangrijkste cloudplatformen: AWS CloudTrail, de diagnostische logboeken van Azure Monitor en GCP Cloud Audit Logs leveren allemaal de benodigde gegevens, maar geen van de drie biedt standaard uitgebreide logboekregistratie; voor elk is een expliciete configuratiebeslissing per service vereist.

Wat zijn de kosten voor het naleven van cloudcompliance?

De kosten voor cloudcompliance bestaan ​​voornamelijk uit personeels- en proceskosten, niet uit licentiekosten, jaarlijkse PCI DSS-beoordelingen (zelfbeoordelingsvragenlijsten of een Qualified Security Assessor-opdracht, afhankelijk van het transactievolume), de doorlopende werkzaamheden voor het onderhouden van een gedocumenteerde cryptografische architectuur en sleutelbeheerprocedures, en de engineeringtijd die nodig is om logging correct te configureren en te bewaken voor elke cloudservice die onder de scope valt. De cloud-native services zelf, KMS-sleutelkosten, HSM-instantiekosten en logopslag vormen doorgaans slechts een klein deel van dat totaal in vergelijking met de inspanningen voor beoordeling en documentatie. Dit is een van de redenen waarom organisaties na de eerste succesvolle audit te weinig budget reserveren voor complianceonderhoud.

Hoe ziet een compliance-architectuur voor meerdere clouds eruit?

Het uitvoeren van gereguleerde workloads in meerdere clouds vermenigvuldigt de taak van het in kaart brengen van gedeelde verantwoordelijkheid met het aantal clouds dat u gebruikt, tenzij u het beleid voor belangrijke beheer-, IAM-, rotatie- en logboekregistratieregels centraal standaardiseert en consistent toepast, in plaats van elk cloudteam de PCI DSS- en GDPR-regelgeving onafhankelijk te laten interpreteren.

Voor de referentiearchitectuur achter een dergelijke gecentraliseerde aanpak, raadpleegt u onze Multi-Cloud PKIaaS Architecture Guide en het overzicht van sleutelbeheer in meerdere clouds van het Education Center.

Wat zijn de beperkingen van het vertrouwen op CSP-nalevingscertificeringen?

• De certificering van een CSP heeft betrekking op de eigen infrastructuur, niet op uw configuratie daarvan. Een AWS PCI DSS-conformiteitsverklaring maakt uw S3-bucketbeleid, IAM-machtigingen of applicatiecode niet conform aan de vereisten.
• SaaS beperkt uw verplichtingen, maar heft ze niet op. Ook bij SaaS blijft u verantwoordelijk voor de toegangscontrole tot accounts, de classificatie van gegevens en het controleren of de naleving van de leveranciersvoorschriften daadwerkelijk van toepassing is op uw specifieke gebruikssituatie.
• Niet alle clouddiensten binnen één CSP beschikken over dezelfde certificering. Dat een CSP in zijn geheel voldoet aan de PCI DSS- of GDPR-normen, betekent niet dat elke individuele dienst onder de reikwijdte van uw nalevingsverklaring valt; u moet dit per dienst controleren.
• Naleving is een momentopname, geen doorlopende garantie. Configuratieafwijkingen na een beoordeling komen vaak voor, en noch PCI DSS- noch GDPR-naleving is zelfonderhoudend.

Beslissingschecklist: Cloudcompliance voor PCI DSS en GDPR

1. Breng elke PCI DSS-vereiste en GDPR-verplichting in kaart en bepaal of u, uw CSP of beiden de controle hebben over deze vereisten, specifiek voor uw servicemodel (IaaS, PaaS of SaaS). Ga niet alleen uit van aannames op basis van het model.
2. Bepaal uw sleutelbeheermodel (native, BYOK of HYOK) op basis van een daadwerkelijke contractuele of wettelijke vereiste, niet op basis van de standaardinstellingen.
3. Documenteer uw cryptografische architectuur en sleutelbeheerprocedures nu, PCI DSS v4.0.1 vereist dit voor serviceproviders en verwacht het ook als bewijs van transacties van handelaren.
4. Schakel logboekregistratie in en routeer deze centraal voor elke relevante cloudservice voordat een beoordelaar of een inbreuk daartoe aanleiding geeft.
5. Als u in meer dan één cloudomgeving werkt, standaardiseer bovenstaande dan eenmalig centraal, in plaats van de nalevingsrichtlijnen per cloudteam te laten verschillen.

Wat zou Encryption Consulting aanbevelen?

Organisaties die worstelen met cloudcompliance missen zelden een specifieke controle, maar hebben nooit vastgelegd wie voor welke controle verantwoordelijk is en ontdekken de lacune pas tijdens een beoordeling in plaats van ervoor. We raden aan om de gedeelde verantwoordelijkheidsmapping te beschouwen als een dynamisch document dat u telkens moet herzien wanneer u een nieuwe cloudservice implementeert, in plaats van een eenmalige oefening bij de initiële cloudmigratie. Als het sleutelbeheer en de bijbehorende documentatie tekortschieten, vergelijkt onze Cloud Data Protection-beoordeling uw huidige positie met PCI DSS, GDPR en gerelateerde frameworks voor AWS, Azure en GCP. Ons HSM-as-a-Service- aanbod biedt u FIPS-gevalideerd, centraal beheerd sleutelbeheer dat alle drie de frameworks omvat.

Veelgestelde Vragen / FAQ

Als mijn CSP PCI DSS-gecertificeerd is, voldoe ik dan automatisch aan de eisen?

Nee. De nalevingsverklaring van een CSP heeft betrekking op de eigen infrastructuur en de diensten die deze rechtstreeks aanbiedt. U blijft verantwoordelijk voor de configuratie van die diensten, uw toegangsrechten, uw applicatiecode en elk onderdeel van de vereistenmatrix dat onder uw specifieke servicemodel voor rekening van de klant komt.

Vereist de AVG dat ik de gegevens van EU-burgers fysiek binnen de EU bewaar?

Niet automatisch. De AVG staat overdrachten buiten de EU toe via specifieke mechanismen (adequaatheidsbesluiten, standaardcontractbepalingen, bindende bedrijfsregels), maar u blijft verantwoordelijk voor de daadwerkelijke toepassing van deze beschermingsmaatregelen. Bovendien kunnen sectorspecifieke regels of klantcontracten vereisen dat gegevens in de EU worden opgeslagen, ongeacht wat de AVG zelf toestaat.

Moet ik HYOK gebruiken om te voldoen aan de PCI DSS- of GDPR-regelgeving?

Vrijwel nooit als standaardvereiste. Native cloud-sleutelbeheer met gedocumenteerde procedures voldoet in de overgrote meerderheid van de gevallen aan beide standaarden. HYOK wordt relevant wanneer een specifiek contract, een toezichthouder of een gegevensverwerkingsovereenkomst vereist dat wordt aangetoond dat de cloudserviceprovider (CSP) helemaal geen toegang heeft tot uw gegevens.

Wat is er in PCI DSS v4.0.1 veranderd dat specifiek van invloed is op cloudimplementaties?

Voor cloudomgevingen zijn twee belangrijke veranderingen van belang: encryptie op schijfniveau alleen is niet langer voldoende voor encryptie van gegevens in rust, behalve op verwijderbare media, en organisaties moeten hun cryptografische suites en protocollen nu minstens jaarlijks formeel evalueren, inclusief het monitoren van algoritmen die binnenkort niet meer ondersteund zullen worden.

Hoe snel moet ik een datalek daadwerkelijk opsporen om te voldoen aan de 72-uursvereiste van de AVG?

De termijn van 72 uur begint te lopen vanaf het moment dat uw organisatie op de hoogte is van de inbreuk, niet vanaf het moment dat deze plaatsvond. Een logboekregistratiesysteem dat incidenten pas dagen of weken later aan het licht brengt, ondermijnt deze vereiste echter. Centraal beheerde, actief gealarmeerde logboekregistratie is wat de termijn van 72 uur in de praktijk haalbaar maakt.

Heeft u een specifieke vraag over PCI DSS- of GDPR-compliance in de cloud? Neem dan contact op met ons team via [email protected].