PCI DSS voor hotels: waarom naleving lastiger is dan het lijkt

PCI DSS is geen Nederlandse wet, maar wel contractueel verplicht

De Payment Card Industry Data Security Standard wordt niet vastgesteld door de wetgever en wordt niet direct gehandhaafd door een Nederlandse toezichthouder. Het is een private, contractuele standaard die is opgesteld door de grote kaartnetwerken (Visa, Mastercard, American Express, Discover en JCB) en via uw overeenkomst met uw acquirer of betaalverwerker aan u wordt doorgegeven. Dat onderscheid is minder belangrijk dan hoteliers soms aannemen, omdat het handhavingsmechanisme uw vermogen is om überhaupt kaartbetalingen te kunnen blijven verwerken.

Kaartmerken beboeten de acquirer, die maandelijkse boetes doorberekent aan de merchant. De kaartmerken publiceren de bedragen niet; ze hangen af van het merchant-niveau en de ernst van het tekort, en ze stapelen zich op naarmate de niet-naleving langer duurt. In de ernstigste gevallen, met name na een bevestigd datalek van kaartgegevens, kan de acquirer uw mogelijkheid om kaartbetalingen te verwerken opschorten of beëindigen. Voor een hotel is het verliezen van kaartverwerking bijna een existentiële bedreiging.

Versie 4 van de standaard heeft de oudere v3.2.1 in maart 2024 volledig vervangen, en sinds v4.0 op 31 december 2024 buiten gebruik ging, is v4.0.1 de enige actieve versie. Acquirers en betaalverwerkers beoordelen hotels nu tegen de eisen van v4.0.1, inclusief een aantal bepalingen die pas sinds maart 2025 verplicht zijn geworden.

Waarom de scope complexer is bij een hotel dan bij een gewone winkel

Een winkel op straat heeft meestal één kassa en één betaalkanaal. Een hotel heeft er meerdere, en elk daarvan is een apart punt waar kaarthoudergegevens kunnen worden vastgelegd, opgeslagen of verzonden:

• Boekingssysteem. Uw website of een boekingsplatform van derden legt kaartgegevens vast op het moment van reservering, vaak opgeslagen als garantie tegen no-shows.
• Receptie en check-in. Transacties met fysieke kaart bij check-in en check-out, plus handmatige kaartinvoer voor telefonische of walk-in boekingen.
• Restaurant, bar en spa. Elk verkooppunt met een eigen kassa of kaartlezer is een aparte kaarthouderdataomgeving, tenzij goed gesegmenteerd.
• Telefonische reserveringen. Personeel dat kaartnummers telefonisch ontvangt en handmatig invoert in een boekingssysteem, een van de risicovolste kanalen omdat point-to-point-encryptie hier vaak wordt omzeild.
• Terugkerende betalingen en vooraf geautoriseerde bedragen. Het bewaren van kaartgegevens voor incidentele kosten, schadeborg of no-showkosten verlengt de periode dat kaarthoudergegevens in uw systemen blijven staan.

Merchant-niveaus en welke SAQ van toepassing is op uw hotel

Uw merchant-niveau, vastgesteld door uw acquirer op basis van jaarlijks transactievolume, bepaalt samen met de manier waarop u betalingen verwerkt welke Self-Assessment Questionnaire (SAQ) u moet invullen. De meeste hotels vallen onder Merchant Level 4, het laagste volumeniveau, maar welke SAQ van toepassing is hangt volledig af van uw betaalarchitectuur.

De 12 PCI DSS-eisen toegepast op hotelactiviteiten

Ongeacht welke SAQ van toepassing is, rust de standaard op 12 kerneisen: installeer en onderhoud netwerkbeveiligingscontroles met firewalls die betaalsystemen scheiden van gasten-wifi en algemene hotel-IT; gebruik nooit standaardwachtwoorden van leveranciers op kassasystemen of backofficesystemen; bewaar nooit de kaartverificatiecode (CVV/CVV2) na autorisatie, een veelvoorkomend faalpunt wanneer personeel deze noteert bij telefonische boekingen; versleutel kaarthoudergegevens tijdens verzending en opslag; houd systemen gepatcht tegen bekende kwetsbaarheden, met name property management- en kassasoftware die vaak op verouderde versies blijft draaien; beperk toegang tot kaarthoudergegevens op basis van need-to-know per functie; ken elke medewerker met systeemtoegang een unieke inlognaam toe in plaats van gedeelde receptie-inloggegevens; beperk fysieke toegang tot kaartlezers, backofficeservers en elke locatie waar kaartgegevens worden verwerkt; log en monitor alle toegang tot systemen die kaarthoudergegevens verwerken; test beveiligingssystemen en -processen regelmatig, inclusief penetratietests passend bij uw SAQ-niveau; en onderhoud een gedocumenteerd informatiebeveiligingsbeleid voor al het personeel, inclusief seizoens- en uitzendkrachten die gebruikelijk zijn in de horeca.

Wat er is veranderd in versie 4

Versie 4 maakte multi-factor-authenticatie verplicht voor alle non-console-toegang tot de kaarthouderdataomgeving (vereiste 8.4.2), niet alleen voor externe of administratieve toegang zoals onder de vorige standaard. Als uw PMS binnen de kaartomgeving valt, vallen aanmeldingen van de receptie op het PMS via het netwerk onder deze regel. Het verhoogde de minimale wachtwoordlengte naar 12 tekens en introduceerde de mogelijkheid van gerichte risicoanalyse, waardoor organisaties specifieke controlefrequenties kunnen onderbouwen op basis van hun eigen risicobeoordeling in plaats van één vaste termijn voor elke handelaar.

De operationeel belangrijkste verandering voor hotels zijn eisen 6.4.3 en 11.6.1, die een inventaris vereisen van alle scripts die op betaalpagina's draaien en monitoring op ongeautoriseerde wijzigingen aan die scripts. Dit richt zich direct op Magecart-achtige skimmingaanvallen, waarbij een gecompromitteerd script van een derde partij (een chatwidget, een analyticstag, een boekingsplugin) stilletjes kaartgegevens vastlegt terwijl gasten deze intypen op uw boekingspagina. Deze twee eisen gelden voor checkouts onder SAQ A-EP of SAQ D. De herziening van SAQ A van januari 2025 haalde ze uit die vragenlijst, maar vraagt de merchant nu te bevestigen dat de website niet vatbaar is voor scriptaanvallen. Een hotel dat afhankelijk is van een boekingsplatform van een derde partij moet bevestigen dat dat platform zelf een scriptinventaris en wijzigingsmonitoring toepast, niet alleen het eigen systeem.

Hoe u uw nalevingsscope kunt beperken

De meest effectieve compliancestrategie voor een hotel is het beperken van de scope in plaats van het volledig beveiligen van een brede scope. Een gehoste checkoutpagina voor onlineboekingen, waarbij de gast kaartgegevens rechtstreeks invoert op de pagina van uw betaalprovider in plaats van uw eigen systeem, haalt uw systemen volledig buiten de PCI DSS-scope voor die transactie. Tokenisatie, waarbij het daadwerkelijke kaartnummer in uw systemen wordt vervangen door een niet-gevoelig token, heeft een vergelijkbaar effect voor opgeslagen garantie- en vooraf geautoriseerde gegevens.

Netwerksegmentatie, het isoleren van kassa- en betaalsystemen van gasten-wifi en algemene hotel-IT op aparte VLAN's, is vereist om aanspraak te maken op de beperktere scope van SAQ B-IP of SAQ C in plaats van standaard onder SAQ D te vallen. Voor meer detail over het isoleren van gastgerichte netwerken, zie onze gids over gasten-wifi netwerksegmentatie voor hotels. Bij de receptie haalt het gebruik van een gecertificeerde externe betaalgateway, in plaats van kaartnummers rechtstreeks in het property management-systeem in te voeren, nog een groot deel van de scope weg. Voor een breder overzicht van het dreigingslandschap in de sector, zie ons overzicht van cybersecurityrisico's in de horeca. Volledige technische details over alle huidige eisen zijn gepubliceerd door de PCI Security Standards Council.