In Europa zijn er miljoenen kleine en middelgrote bedrijven die kaartbetalingen accepteren: online, telefonisch of in de winkel. De meesten weten dat ze aan een of andere norm voor gegevensbeveiliging moeten voldoen, maar slechts weinigen hebben zich werkelijk verdiept in wat PCI DSS concreet voor hun bedrijf betekent. Het goede nieuws: met de juiste architectuurkeuzes is de nalevingslast voor kleine bedrijven overzichtelijk. Het slechte nieuws: veel kleine en middelgrote bedrijven implementeren betalingen op een manier die de naleving onnodig ingewikkeld maakt.
De Europese context: AVG, PSD2 en PCI DSS
Kleine bedrijven in Europa opereren binnen een regelgevingskader dat meerdere overlappende vereisten omvat. AVG (Algemene Verordening Gegevensbescherming) regelt de omgang met persoonsgegevens van alle Europese burgers en geldt voor elk bedrijf dat Europese klanten bedient. PSD2 (tweede betaaldienstenrichtlijn) heeft de vereisten voor sterke klantauthenticatie (SCA) ingevoerd. PCI DSS is een privaatrechtelijke norm van de kaartnetwerken die via overeenkomsten met handelaren verplicht wordt gesteld.
Deze drie regelingen overlappen elkaar, maar zijn niet identiek. PCI DSS en AVG hanteren verschillende definities van gevoelige gegevens: de AVG beschermt persoonsgegevens (naam, adres, e-mail), PCI DSS beschermt kaartgegevens (PAN, CVV, PIN). Een datalek met kaartgegevens kan zowel PCI DSS-sancties als AVG-boetes tot gevolg hebben. Kleine bedrijven in Europa moeten beide vereisten in het oog houden.
Veelgemaakte fouten van kleine bedrijven bij de implementatie van betalingen
In de praktijk zien we regelmatig de volgende fouten die PCI DSS voor kleine bedrijven onnodig ingewikkeld maken:
- Kaartgegevens per e-mail of WhatsApp ontvangen: klanten sturen kaartnummers via onbeveiligde kanalen, wat rechtstreeks in strijd is met PCI DSS en het bedrijf tegelijkertijd blootstelt aan ernstige AVG-risico's.
- Kaartnummers in Excel-bestanden opslaan: veel kleine bedrijven die abonnementen of terugkerende betalingen beheren, bewaren kaartnummers in spreadsheets. Dat is een ernstige overtreding van PCI DSS.
- Kaartnummers in CRM of ERP invoeren: interne systemen zijn vaak niet ontworpen voor het veilig beheren van gevoelige betalingsgegevens en kunnen de volledige database binnen de PCI DSS-scope brengen.
- Maatwerk-betaalformulieren zonder veilige implementatie: JavaScript-betaalformulieren op het eigen domein die zonder de juiste beveiligingsmaatregelen worden geïmplementeerd, zijn kwetsbaar voor skimming-aanvallen.
De juiste architectuur voor kleine bedrijven
Voor de meeste kleine Europese bedrijven is dit de optimale PCI DSS-architectuur:
- Verwerk zelf geen kaartgegevens: besteed de volledige verwerking van kaartgegevens uit aan een PCI DSS Level 1-gecertificeerde aanbieder. Gebruik een hosted payment page of veilige token-API's.
- Bewaar intern alleen tokens: sla in plaats van het kaartnummer een token op in uw CRM/ERP. Het token kan worden gebruikt voor terugbetalingen, verlengingen van abonnementen en klantbeheer, zonder het PCI DSS-risico.
- Telefonische betalingen via veilige links: in plaats van kaartnummers telefonisch aan te nemen, stuurt de medewerker de klant een veilige betaallink. De klant voert de kaart zelf in.
Met deze architectuur komt het bedrijf in aanmerking voor SAQ A: de jaarlijkse nalevingsinspanning beperkt zich tot het beantwoorden van 22 vragen en de controle van de betaalpagina op scriptbeveiliging.
Praktische checklist voor kleine en middelgrote bedrijven
Controleer uw huidige nalevingsstatus met deze checklist:
- Bewaren wij kaartnummers in een eigen systeem (database, Excel, CRM)? → Onmiddellijk actie nodig
- Ontvangen wij kaartnummers per e-mail, fax of telefoon en voeren we ze handmatig in? → Onmiddellijk actie nodig
- Hebben wij een eigen betaalformulier op onze website dat kaartgegevens ontvangt? → Controleer of SAQ A-EP geldt in plaats van SAQ A
- Gebruiken wij een volledig gehoste betaalpagina van een gecertificeerde aanbieder? → Juiste architectuur, SAQ A mogelijk
- Hebben wij onze acquirer geïnformeerd over onze nalevingssituatie en de jaarlijkse SAQ ingediend? → Verplicht
Veelgestelde vragen
Mijn acquirer heeft mij nog nooit naar PCI DSS gevraagd. Moet ik toch compliant zijn?
Ja. Het ontbreken van een actief verzoek van de acquirer betekent niet dat er geen verplichting bestaat. De PCI DSS-verplichting is verankerd in de handelaarsovereenkomst die u bij het openen van de handelaarsrekening hebt ondertekend. Acquirers in Europa vragen met verschillende frequentie actief nalevingsbewijzen op bij kleine handelaren, maar de contractuele verplichting bestaat los daarvan. Bij een datalek worden ontbrekende nalevingsbewijzen verzwarende factoren bij de toewijzing van aansprakelijkheid.
Is PCI DSS hetzelfde als AVG-naleving?
Nee. PCI DSS en AVG hebben verschillende toepassingsgebieden, vereisten en sanctiekaders. De AVG beschermt persoonsgegevens van Europese burgers en wordt gehandhaafd door nationale gegevensbeschermingsautoriteiten. PCI DSS beschermt betaalkaartgegevens en wordt gehandhaafd via overeenkomsten met kaartnetwerken en acquirers. Beide regelingen gelden tegelijkertijd: een bedrijf kan AVG-conform zijn maar PCI DSS overtreden, en omgekeerd.
Klein bedrijf, grote verlichting op het gebied van naleving: PCI Proxy EU biedt de tokenisatie-oplossing die uw PCI DSS-naleving terugbrengt tot SAQ A. Ontdek PCI Proxy EU.
Hulp nodig bij PCI-naleving?
Ons team helpt u uw CDE in kaart te brengen, het juiste SAQ te kiezen en tokenisatie te implementeren met gegevensresidentie in de EU.
Neem contact op