Die entscheidenden Zahlen
Wenn Sie ein unabhängiges Hotel betreiben, sieht die Situation zum Zeitpunkt der Veröffentlichung dieses Artikels wie folgt aus: PCI DSS v4.0 wurde am 31. März 2024 verbindlich, als v3.2.1 vom PCI Security Standards Council außer Kraft gesetzt wurde. PCI DSS v4.0 selbst wurde dann am 31. Dezember 2024 außer Kraft gesetzt und durch v4.0.1 ersetzt, die derzeit einzige aktive Version des Standards. Und am 31. März 2025 wurden die 51 Anforderungen, die als „zukünftige Best Practice“ eingestuft worden waren, ohne Übergangsfrist verbindlich. Wenn Ihre letzte Selbstbewertung anhand einer früheren Version oder anhand von v4.0 durchgeführt wurde, wobei die zukünftigen Anforderungen als „nicht anwendbar“ markiert waren, sind Sie zum Zeitpunkt der Erstellung dieses Artikels nicht konform.
Die meisten unabhängigen Hoteliers, mit denen ich spreche, wissen das nicht. Diejenigen, die es wissen, haben meist nur eine vage Vorstellung davon, was es bedeutet, sodass sie es immer wieder aufschieben können. Sie wissen, dass „2025 etwas mit PCI passiert ist“. Sie sind sich nicht sicher, ob es auf sie zutrifft. Sie vermuten, dass ihr Zahlungsabwickler sich darum kümmert. In allen drei Punkten liegen sie meist falsch.
Die Mechanismen sind einfach. Die Kartennetzwerke (Visa, Mastercard, American Express, Discover, JCB) machen die Einhaltung der Vorschriften zu einer vertraglichen Bedingung für die Akzeptanz ihrer Karten. Ihre akquirierende Bank gibt diesen Vertrag an Sie weiter. Wenn Sie die Vorschriften nicht einhalten und Ihr Acquirer dies bemerkt, kann die Bank Ihnen Strafen für die Nichteinhaltung auferlegen, die in den Monaten eins bis drei bei 5.000 $ pro Monat beginnen, in den Monaten vier bis sechs auf 25.000 $ bis 50.000 $ pro Monat steigen und ab dem siebten Monat 50.000 $ bis 100.000 $ pro Monat erreichen, gemäß den veröffentlichten Tabellen, die aus Durchsetzungsmaßnahmen von Acquirern in den Jahren 2024 und 2025 zusammengestellt wurden. Wenn Sie die Vorschriften nicht einhalten und zudem eine Datenpanne haben, beginnen die Strafen für die Kompromittierung von Kontodaten allein von Visa bei 50.000 US-Dollar pro Vorfall für einen nicht konformen Händler und reichen bis zu 500.000 US-Dollar, wobei Mastercard parallele Strafen verhängt. Keine dieser Zahlen ist theoretisch. Der von der US-amerikanischen Federal Trade Commission am 20. Dezember 2024 abgeschlossene Vergleich zur Datenpanne bei Marriott und Starwood beinhaltete einen parallelen Vergleich in Höhe von 52 Millionen US-Dollar mit 49 Generalstaatsanwälten, und die damit verbundene DSGVO-Geldbuße in Höhe von 18,4 Millionen Pfund durch das britische Information Commissioner'. s Office im Jahr 2020 brachte den kumulierten Schaden aus dieser Datenpanne auf einen hohen neunstelligen Betrag, noch vor Rechts- und Sanierungskosten.
Das ist die Kehrseite. Die positive Seite ist, dass es für ein durchschnittliches unabhängiges Hotel mit 30 bis 150 Zimmern, das einen Zahlungsabwickler mit Tokenisierung nutzt, 1.500 bis 3.000 US-Dollar pro Jahr kostet, eine Person etwa 90 Tage benötigt, um die ersten Vorkehrungen zu treffen, und weder ein QSA noch ein Beratungshonorar noch eine Unternehmenssicherheitsplattform erforderlich sind. Der Unterschied zwischen 1.500 US-Dollar pro Jahr und einer fünfstelligen monatlichen Geldstrafe ist, wie Sie sich vorstellen können, der Kernpunkt dieses Artikels.
Dies ist die ehrliche Einschätzung zu PCI DSS 4.0 für unabhängige Hotels im Jahr 2026. Die vier Lügen, die sich Hoteliers darüber einreden, wie man den richtigen Selbstbewertungsfragebogen auswählt (was die wichtigste Entscheidung ist, die Sie treffen werden), die zehn neuen Anforderungen, bei denen Hotels am häufigsten scheitern, die sieben Stellen in Ihrem Hotel, an denen sich Kartendaten verstecken, die Sie vergessen haben, die tatsächlichen Kostenbereiche mit Quellenangaben und ein 90-Tage-Plan, den eine operativ denkende Person ohne externe Hilfe umsetzen kann.
Was sich geändert hat und warum Sie die Frist verpasst haben
Der Grund, warum Hotelbetreiber die PCI DSS 4.0-Frist verpasst haben, ist nicht Faulheit. Es liegt daran, dass das PCI Security Standards Council den Übergang schlecht kommuniziert hat und die Fachpresse der Hotellerie noch schlechter darüber berichtet hat. Hier ist der tatsächliche Ablauf, damit Sie nicht länger verwirrt sind, welche Version Sie eigentlich verwenden sollten.
PCI DSS v3.2.1 wurde im Mai 2018 veröffentlicht und blieb fast sechs Jahre lang die aktive Version des Standards. Die meisten zwischen 2018 und 2024 eingereichten SAQs von Hotels bezogen sich auf v3.2.1. PCI DSS v4.0 wurde am 31. März 2022 veröffentlicht, mit einer zweijährigen Übergangsphase, in der sowohl v3.2.1 als auch v4.0 gültig waren. v3.2.1 wurde am 31. März 2024 außer Kraft gesetzt. Ab diesem Datum mussten alle PCI-DSS-Bewertungen nach v4.0 durchgeführt werden.
v4.0 führte 64 neue Anforderungen ein. 13 davon traten sofort nach der Veröffentlichung in Kraft. Die übrigen 51 wurden als „zukünftige Best Practices“ mit einer dreijährigen Übergangsfrist ausgewiesen. Hotels und ihre Prüfer durften die 51 zukunftsorientierten Anforderungen bei Bewertungen, die zwischen dem 31. März 2022 und dem 31. März 2025 durchgeführt wurden, als „nicht anwendbar“ kennzeichnen, mit dem dokumentierten Vermerk, dass sie bis zum Stichtag umgesetzt würden. Die meisten Hotels taten genau das und vergaßen sie dann.
Im Juni 2024 veröffentlichte das PCI SSC die Version 4.0.1, eine begrenzte Überarbeitung von Version 4.0 mit Formatierungskorrekturen, präzisierten Anmerkungen zur Anwendbarkeit und ohne hinzugefügte oder entfernte Anforderungen. Version 4.0 wurde am 31. Dezember 2024 außer Kraft gesetzt, und Version 4.0.1 wurde zur einzigen derzeit aktiven Version. Die Frist vom 31. März 2025 für die 51 Anforderungen mit Zukunftsdatum blieb durch die Überarbeitung v4.0.1 unverändert, und das PCI SSC hat dies in seinen veröffentlichten FAQ ausdrücklich betont.
Diese Frist ist abgelaufen. Seit dem 1. April 2025 sind die 51 ehemals auf einen späteren Zeitpunkt datierten Anforderungen verbindlich und müssen bei jeder PCI-DSS-Prüfung durch Nachweise validiert werden. Es gibt keine Nachfrist, es werden keine vorübergehenden Abhilfemaßnahmen akzeptiert, und qualifizierte Sicherheitsprüfer wurden angewiesen, nicht nur zu überprüfen, ob die Kontrollen implementiert sind, sondern auch, ob sie bereits vor Ablauf der Frist funktionsfähig waren und nicht erst in der Woche davor hastig eingerichtet wurden. Wenn in der letzten SAQ Ihres Hotels diese 51 Anforderungen als „nicht zutreffend“ markiert wurden, sind Sie ab dem Zeitpunkt der Einreichung nicht mehr konform.
Die vier Kontrollbereiche, die den Betreiber am meisten Zeit kosten und am häufigsten übersehen werden, sind weiter unten näher beschrieben. Die nützlichste Zusammenfassung, die ich Ihnen hier geben kann, lautet jedoch: Wenn Sie Ihren letzten SAQ in den letzten 12 Monaten nicht geöffnet haben, müssen Sie mit ziemlicher Sicherheit einen neuen einreichen. Wenn Ihr letzter SAQ ein SAQ A war, haben sich die Regeln dafür, was für SAQ A qualifiziert, verschärft (mehr dazu weiter unten). Und wenn Ihr Hotel immer noch virtuelle Kreditkartendaten im Klartext per E-Mail versendet, verstoßen Sie seit dem Tag, an dem Sie Ihre Buchungsmaschine in Betrieb genommen haben, gegen Anforderung 4.2.1. Keine dieser Aussagen ist spekulativ. Es handelt sich um den veröffentlichten, aktuellen Text von PCI DSS v4.0.1.
Die vier PCI-Lügen, die sich Hotels selbst erzählen
Bevor ich zu den praktischen Hinweisen komme, hier die vier Selbsttäuschungen, die ich in fast jedem PCI-Gespräch mit einem unabhängigen Hotelier höre. Keine davon ist dumm. Es waren alles vernünftige Interpretationen von PCI DSS v3.2.1 und der lockeren Durchsetzungskultur von 2018 bis 2023. Unter v4.0.1 und der Durchsetzung ab 2025 treffen sie nicht mehr zu.
1. „Unser Zahlungsabwickler kümmert sich um die Compliance für uns“
Ihr Zahlungsabwickler kümmert sich um seine eigene PCI-Compliance. Er kümmert sich nicht um Ihre. PCI DSS zieht eine klare rechtliche Grenze zwischen einem Drittanbieter (TPSP) wie Ihrem Acquirer, Ihrem Gateway oder Ihrem Tokenisierungsdienstleister und Ihnen als Händler. Der TPSP ist für die Karteninhaberdaten verantwortlich, die durch seine Umgebung fließen, sowie für das Ausfüllen seines eigenen SAQ D für Dienstleister. Sie als Händler sind für die Karteninhaberdaten verantwortlich, die mit Ihrer Umgebung in Berührung kommen, für die von Ihnen betriebenen Integrationen und für das Ausfüllen Ihres eigenen SAQ. Die beiden Verantwortlichkeiten überschneiden sich nicht, und es gibt keine Version von „unser Abwickler kümmert sich darum“, die vertraglich zutreffend ist. Was Ihr Prozessor tun kann, ist, Ihnen eine Architektur zu verkaufen, bei der seine Umgebung den größten Teil des Umfangs der Karteninhaberdaten aufnimmt, wodurch Sie dann ein viel kürzeres SAQ ausfüllen können. Das ist der tatsächliche Wert der Nutzung eines Tokenisierungs-Prozessors, und es ist ein echter Wert, aber es ist nicht dasselbe wie die Auslagerung Ihrer Compliance.
2. „Wir qualifizieren uns für SAQ A, weil unsere Buchungsmaschine gehostet wird“
SAQ A ist die einfachste der acht SAQ-Arten und gilt für Händler, die die Speicherung, Verarbeitung und Übertragung von Karteninhaberdaten vollständig an einen PCI-DSS-konformen Drittanbieter ausgelagert haben, wobei keine elektronische Speicherung oder Übertragung auf den eigenen Systemen des Händlers stattfindet. SAQ-A-Händler dürfen Karteninhaberdaten nur in Papierform (gedruckte Berichte, Quittungen) aufbewahren, und diese Papierunterlagen dürfen nicht elektronisch empfangen werden. Speziell für einen E-Commerce-Kanal muss jedes Element der Zahlungsseite, das an den Browser des Kunden übermittelt wird, ausschließlich und direkt von einem PCI-DSS-konformen Drittanbieter stammen. Dies ist der wörtliche Wortlaut der Zulassungskriterien für SAQ A v4.0.1.
Das PCI SSC hat die Zulassungskriterien für SAQ A im Januar 2025 durch eine neue Bescheinigungsanforderung weiter verschärft, wonach die E-Commerce-Website des Händlers nicht anfällig für skriptbasierte Angriffe sein darf. In der Praxis bedeutet dies, dass selbst Hotels, die eine vollständig gehostete Buchungsmaschine mit iframe-basierter Zahlung nutzen, die Anforderungen 6.4.3 und 11.6.1 nicht mehr umgehen können, wenn der Rest ihrer Buchungsseite Skripte von Drittanbietern lädt, die grundsätzlich die Zahlungsseite beeinträchtigen könnten. Die meisten unabhängigen Hotelwebsites laden solche Skripte (Analytics, Chat-Widgets, Marketing-Pixel, Bewertungs-Widgets), sodass der SAQ-A-Weg schmaler ist, als es den Anschein hat. Wir werden im Abschnitt zur SAQ-Auswahl darauf zurückkommen.
3. „Wir sind zu klein, um ein Ziel zu sein“
Der „2024 Verizon Data Breach Investigations Report“ stuft das Gastgewerbe als eine der fünf Branchen mit den meisten Datenschutzverletzungen pro Organisation ein, und das typische Opfer ist keine Kette. Angreifer bevorzugen kleine, unabhängige Hotels aus einem einfachen wirtschaftlichen Grund: Der Ertrag pro Vorfall (etwa 12.000 Kartennummern pro Jahr für ein Hotel mit 60 Zimmern und einer Auslastung von 75 %) ist hoch genug, um den Aufwand zu rechtfertigen, während die Verteidigungsmaßnahmen in der Regel ein Jahrzehnt hinter dem zurückliegen, was ein Sicherheitsteam eines Großunternehmens einsetzen würde. Angreifer wissen zudem, dass ein durchschnittliches unabhängiges Hotel einen Magecart-ähnlichen Skimming-Angriff auf die Zahlungsseite monatelang nicht bemerken wird. Die durchschnittliche Verweildauer bei von Verizon untersuchten Sicherheitsverletzungen im Gastgewerbe beträgt über 200 Tage. Die Kombination aus „langer Verweildauer, schwacher Erkennung und hohem Kartenertrag pro Mitarbeiter“ ist genau der Grund, warum Hotels ins Visier genommen werden.
4. „Wir hatten noch nie einen Datenverstoß, also muss alles in Ordnung sein“
Dieser Mythos lässt sich am einfachsten widerlegen: Die mittlere Verweildauer bei einem Zahlungskarten-Datenleck im Gastgewerbe beträgt, wie bereits erwähnt, über 200 Tage. Das Fehlen eines bekannten Datenlecks ist kein Beweis für Sicherheit. es ist ein Beweis dafür, dass Sie nicht wissen, ob Sie angegriffen wurden - was eine ganz andere Aussage ist. Die meisten Hotels, bei denen ein Datenleck aufgetreten ist, erfuhren davon von ihrer akquirierenden Bank, die wiederum durch eine Common-Point-of-Purchase-Analyse darauf aufmerksam wurde, nachdem Betrugsfälle bei im Hotel verwendeten Karten gemeldet worden waren. Zu diesem Zeitpunkt beträgt die Verweildauer in der Regel neun bis zwölf Monate, und der Datenverstoß war während des gesamten Zeitraums unbemerkt aktiv. Die Anforderung 10.4.1.1 des PCI DSS 4.0.1 wurde speziell hinzugefügt, um die automatisierte Protokollüberprüfung an die Spitze der Erkennungskette zu rücken, damit Hotels nicht mehr von ihrer Bank über ihre eigenen Datenverstöße informiert werden müssen.
Wählen Sie Ihr SAQ richtig aus (darum dreht sich alles)
Die folgenreichste Entscheidung in Ihrem PCI-Programm ist die Wahl des SAQ, das Sie ausfüllen. Die falsche Wahl kostet Sie im schlimmsten Fall: eine nicht bestandene Bewertung (wodurch Ihr Hotel über Nacht nicht mehr konform ist), Zehntausende von Dollar pro Jahr an unnötigen Compliance-Kosten und eine viel größere Angriffsfläche für einen tatsächlichen Datenverstoß. Die richtige Wahl ist in der Regel offensichtlich, sobald Sie Ihren Kartendatenfluss abbilden - was die meisten Hotels tatsächlich noch nie getan haben.
Die acht SAQ-Typen in v4.0.1, mit der Anzahl der Fragen und dem typischen Hotelszenario, das jedem einzelnen entspricht:
- SAQ A (ca. 30 Fragen): Reiner E-Commerce, bei dem alle Kartendaten vollständig an einen PCI DSS-validierten TPSP ausgelagert sind. Keine elektronische Speicherung, Verarbeitung oder Übertragung auf Hotelsystemen. Die Buchungsmaschine, die Zahlungsseite und die Tokenisierung laufen alle auf der Infrastruktur des Zahlungsdienstleisters. Das Hotel erhält lediglich eine Token-Referenz zurück. Die meisten unabhängigen Boutique-Hotels, die Stripe, Adyen, Mews Payments, Cloudbeds Payments oder Prostay Pay mit einem iframe-basierten Checkout nutzen, fallen hierunter, sofern sie auch die neue Bescheinigung vom Januar 2025 erfüllen, dass die Website nicht anfällig für skriptbasierte Angriffe ist.
- SAQ A-EP (ca. 190 Fragen): Teilweise ausgelagerter E-Commerce. Die Website des Händlers beeinflusst die Sicherheit der Zahlungstransaktion (z. B. ein Redirect-and-Return-Ablauf, bei dem die Hotelseite den Browser an den Zahlungsabwickler übergibt und ihn zurückerhält), aber der Händler speichert, verarbeitet oder überträgt Karteninhaberdaten weiterhin nicht selbst elektronisch. Hier befinden sich heute die meisten Hotels, auch wenn sie glauben, sie seien SAQ A.
- SAQ B (ca. 40 Fragen): Ausschließlich eigenständige Dial-out-Terminals, keine elektronische Speicherung von Karteninhaberdaten. Ab 2026 praktisch überholt.
- SAQ B-IP (ca. 80 Fragen): Eigenständige, nach PIN Transaction Security zertifizierte Terminals mit IP-Anbindung, keine elektronische Speicherung von Karteninhaberdaten. Dies ist das richtige SAQ für ein Hotel, das die meisten Zahlungen über ein fest installiertes EMV-Terminal am Schalter abwickelt, das direkt mit dem Zahlungsabwickler verbunden ist und niemals in das PMS integriert wird.
- SAQ C (ca. 160 Fragen): Mit dem Internet verbundene Zahlungsanwendungssysteme, keine elektronische Speicherung von Karteninhaberdaten. Einige Hotel-POS-Implementierungen fallen hierunter.
- SAQ C-VT (ca. 80 Fragen): Manuelle Eingabe einzelner Transaktionen über ein von einem TPSP bereitgestelltes virtuelles Terminal. Dies passt zu einem kleinen Hotel, in dem die Rezeption Kartennummern einzeln in ein gehostetes Web-Terminal eingibt, ohne dass sonst elektronische CHD vorhanden sind.
- SAQ D (Händler) (ca. 330 Fragen): Alle anderen Fälle. Jede elektronische Speicherung von Karteninhaberdaten auf Hotelsystemen führt automatisch zu diesem Fall.
- SAQ D (Dienstleister) (ca. 330 Fragen): Für Dienstleister. Gilt nicht für Hotels, die als Händler auftreten.
Für ein typisches unabhängiges Hotel mit 60 Zimmern im Jahr 2026, das über eine gehostete Buchungsmaschine, ein EMV-Terminal an der Rezeption und keine im PMS gespeicherten Kartendaten verfügt, ist das richtige SAQ entweder SAQ A oder SAQ B-IP, je nachdem, welchen Zahlungskanal Sie als primär betrachten. Der falsche SAQ für dieses Hotel ist SAQ D, den die meisten Buchhalter instinktiv wählen würden, weil sie davon ausgehen, dass der längere Fragebogen „sicherer“ ist. SAQ D ist nicht sicherer. Er wendet einen viel umfassenderen Anforderungskatalog an, den Sie ohne Unternehmensinfrastruktur eigentlich nicht erfüllen können, und Prüfer sind mittlerweile darauf geschult, Händler durchfallen zu lassen, die sich ohne dokumentierten Grund für SAQ D entscheiden.
Das Wichtigste, was Sie in den nächsten 30 Tagen tun können, ist, Ihren Kartendatenfluss auf Papier abzubilden, das tatsächlich zutreffende SAQ zu identifizieren und zu dokumentieren, warum es zutrifft. Wenn diese Aufstellung ergibt, dass ein Hotelsystem Karteninhaberdaten elektronisch speichert, verarbeitet oder überträgt (was mit ziemlicher Sicherheit der Fall ist - mehr dazu im Abschnitt „Kartendaten verstecken sich in Ihrem Hotel“), besteht Ihre eigentliche Aufgabe vor dem Einreichen eines SAQ darin, dies zu beseitigen, und nicht darin, ein SAQ D einzureichen und mit dem größeren Risiko zu leben.
Die zehn neuen Anforderungen, bei denen Hotels am häufigsten scheitern
Die 51 zukunftsgerichteten Anforderungen, die am 31. März 2025 verbindlich wurden, decken den gesamten Standard mit 12 Anforderungen ab. Bei den Projekten, die ich 2025 und 2026 in unabhängigen Hotels gesehen habe, machen zehn Anforderungen etwa 80 % der Nachbesserungsarbeiten aus. Hier sind sie in der Reihenfolge, in der ich sie angehen würde, wobei der eigentliche Kontrolltext aus v4.0.1 in einfaches Englisch zusammengefasst und die typischen Fehlerquellen für jedes Hotel aufgeführt sind.
Anforderung 4.2.1: Beenden Sie das Problem mit VCC-E-Mails im Klartext
Anforderung 4.2.1 besagt, dass primäre Kontonummern nur über offene, öffentliche Netzwerke unter Verwendung starker Verschlüsselung übertragen werden dürfen. „Offene, öffentliche Netzwerke“ umfassen das öffentliche Internet, wozu jeder E-Mail-Server außerhalb Ihrer tokenisierten Umgebung gehört. Hotels erhalten regelmäßig Daten zu virtuellen Kreditkarten (VCC) von OTAs und Reiseveranstaltern in Klartext-E-Mails. Dies stellt seit PCI DSS v1.0 im Jahr 2004 einen Verstoß dar. Auch unter v4.0.1 ist dies weiterhin ein Verstoß. Die 2026 veröffentlichte Branchenumfrage von Antravia ergab, dass fast jedes dritte Hotel immer noch zumindest einige VCC-Daten in Klartext-E-Mails erhält und dies als normal betrachtet. Das ist es jedoch nicht. Beheben Sie dies, indem Sie die Übermittlung aller VCC-Daten über das sichere Extranet der OTA, eine API-Integration oder eine tokenisierte Inbox-Lösung vorschreiben. Die Kartennetzwerke prüfen diese Kontrolle zunehmend direkt über die OTA. Wenn Ihr Acquirer dies also noch nicht beanstandet hat, wird Ihr Lieferant dies mit ziemlicher Sicherheit tun.
Anforderungen 6.4.3 und 11.6.1: Sperren Sie die Skripte der Zahlungsseite
Diese beiden Anforderungen sind die Kernpunkte von v4.0.1 für den E-Commerce und gelten für jede Hotel-Website, die Zahlungen entgegennimmt. 6.4.3 ist präventiv: Jedes Skript, das auf einer Zahlungsseite im Browser des Kunden geladen und ausgeführt wird, muss autorisiert sein, auf seine Integrität überprüft werden und in einem Verzeichnis mit einer dokumentierten technischen oder geschäftlichen Begründung aufgeführt sein. 11.6.1 ist detektivisch: Es muss ein Mechanismus zur Erkennung von Änderungen und Manipulationen eingesetzt werden, der das Personal innerhalb von sieben Tagen alarmiert, wenn sich sicherheitsrelevante HTTP-Header oder der Inhalt von Skripten auf der Zahlungsseite ändern, wie sie vom Browser des Verbrauchers empfangen werden.
Der typische Fehlerfall bei Hotels besteht darin, dass die Buchungsseite mit acht bis fünfzehn Skripten von Drittanbietern (Analytik, Chat, Retargeting, Bewertungen, A/B-Test-Framework, Heatmap, Einwilligungsmanager, Social-Media-Pixel) geladen wird und das Hotel weder über ein Verzeichnis noch über einen Mechanismus zur Manipulationserkennung verfügt. Die Lösung ist konkret: Reduzieren Sie die Liste der Skripte von Drittanbietern auf ein Minimum, dokumentieren Sie die Rechtfertigung für jedes verbleibende Skript und setzen Sie entweder ein serverseitiges Tool zur Erkennung von Änderungen wie Visualping, Feroot oder PCI Pal oder ein clientseitiges Produkt zur Skriptverwaltung wie Source Defense ein. Content Security Policy-Header und Subresource Integrity-Hashes sind Teil der richtigen Lösung, aber die Leitlinien des PCI SSC stellen ausdrücklich klar, dass sie allein nicht ausreichen. Sie benötigen zusätzlich eine Überwachung.
Anforderung 12.5.2: Bestätigen Sie Ihren PCI-Umfang jährlich
Anforderung 12.5.2 schreibt eine jährliche Überprüfung vor, um den PCI-Umfang und die darin enthaltenen Komponenten zu bestätigen (bei Dienstleistern alle 6 Monate). Die Überprüfung muss alle Datenflüsse von Karteninhabern, alle Systeme, die Daten von Karteninhabern speichern, verarbeiten oder übertragen, sowie jedes System identifizieren, das mit der Sicherheit von Daten von Karteninhabern verbunden ist oder diese beeinträchtigen könnte. Der Verizon DBIR hat wiederholt festgestellt, dass 34 % der Sicherheitsverletzungen in Hotels auf Kartendaten zurückzuführen sind, die an unerwarteten Orten gefunden wurden. Die Überprüfung des PCI-Geltungsbereichs ist der Mechanismus, der diese unerwarteten Orte aufspürt, bevor es ein Angreifer tut.
Anforderungen 8.3.6 und 8.4.2: MFA für jeden Zugriff auf die CDE
Gemäß v4.0.1 ist eine Multi-Faktor-Authentifizierung für jeden Zugriff auf die Karteninhaberdatenumgebung (CDE) erforderlich, der nicht über die Konsole erfolgt, einschließlich des administrativen Zugriffs durch Hotelmitarbeiter und durch Drittanbieter. Dies geht über die Basisanforderungen von v3.2.1 hinaus (die MFA nur für den administrativen Fernzugriff von außerhalb des Netzwerks vorschrieben) und ist die Anforderung, die die Gewohnheiten der meisten Hoteladministratoren am stärksten verändert. Die Lösung besteht darin, eine phishing-resistente MFA (mindestens TOTP, FIDO2-Hardware-Schlüssel für Administratorkonten) für jedes PMS-Konto, jeden Zahlungsgateway-Login, jeden Router-Admin-Login und jedes Cloud-Backoffice-Konto zu implementieren, das mit der CDE in Berührung kommt.
Anforderung 11.4.7: Authentifizierte interne Schwachstellenscans
Interne Schwachstellenscans müssen nun unter Verwendung von Anmeldedaten durchgeführt werden, die einen authentifizierten Zugriff ermöglichen. Ein anonymer Scan Ihres Netzwerks reicht nicht mehr aus. In der Praxis bedeutet dies, dass Sie entweder selbst einen internen Scanner mit authentifizierten Anmeldedaten betreiben müssen (was den meisten Hotels nicht möglich ist) oder einen QSA-Partner beauftragen müssen, vierteljährlich einen Scan mit Anmeldedaten durchzuführen. Planen Sie hierfür zusätzliche Kosten von 500 bis 2.000 US-Dollar pro Jahr ein, falls Sie nicht über interne Kapazitäten verfügen.
Anforderung 12.6.3.1: Gezielte Schulungen zur Sensibilisierung für Sicherheitsfragen
Schulungen zur Sensibilisierung für Sicherheitsfragen müssen nun Bedrohungen und Schwachstellen abdecken, die die Sicherheit der Karteninhaberdatenumgebung beeinträchtigen könnten, mit spezifischen Inhalten für die betreffenden Technologien und Rollen. Ein allgemeines „Phishing 101“-Video erfüllt diese Anforderung nicht. Sie benötigen rollenspezifische Inhalte: ein anderes Modul für das Personal am Empfang (mit Schwerpunkt auf Social Engineering, dem Umgang mit Kartendaten und dem Problem der VCC im Klartext), ein anderes Modul für das Backoffice (mit Schwerpunkt auf der PMS-Zugriffskontrolle und dem Problem der Fax-Archivierung) und ein anderes Modul für die IT oder wer auch immer Ihre Buchungsmaschine verwaltet. Dokumentieren Sie die Bereitstellung und den Abschluss jährlich.
Anforderungen 3.3.2 und 3.5.1.1: Schlüsselgebundene kryptografische Hashes für PAN
Wenn Sie PAN-Daten in irgendeiner elektronischen Form speichern (bitte tun Sie das nicht), reichen Einweg-Hashes nicht mehr aus, um die PAN unlesbar zu machen. Sie müssen einen kryptografischen Hash mit Schlüssel und zugehörigen Schlüsselverwaltungsprozessen gemäß den Anforderungen 3.6 und 3.7 verwenden. In der Praxis trifft dies fast nie auf ein Hotel zu, das einen Tokenisierungs-Prozessor verwendet, da das Hotel keine PAN zum Hashen haben sollte. Die sauberste Lösung besteht darin, die PAN vollständig aus Ihrer Umgebung zu entfernen, wodurch Sie in den Geltungsbereich von SAQ A oder SAQ B-IP fallen und die Anforderungen 3.3.2 und 3.5.1.1 sowie den Großteil der übrigen Anforderungen 3 entfallen.
Anforderungen 6.3.2 und 6.3.3: Bestandsaufnahme und Patching von maßgeschneiderter und kundenspezifischer Software
Alle maßgeschneiderte und kundenspezifische Software muss inventarisiert und gepatcht werden. Für die meisten Hotels bringt dies eine unerwartete Verpflichtung mit sich: die WordPress- oder Squarespace-Seite oder die maßgeschneiderte Marketing-Website, die die Marketingagentur 2018 erstellt hat, seit 2021 nicht mehr gepatcht wurde und die Skripte in den Buchungsablauf lädt. Die Patch-Rhythmik unter v4.0.1 kehrte zur Formulierung von v3.2.1 zurück: Kritische Schwachstellen müssen innerhalb von 30 Tagen gepatcht werden. Die Lösung besteht darin, ein Software-Inventar zu führen (eine Tabelle reicht für einen Einzelunternehmer aus), jedem Bauteil einen Verantwortlichen zuzuweisen und das Bauteil entweder planmäßig zu patchen oder aus dem Verkehr zu ziehen.
Anforderung 10.4.1.1: Automatisierte Protokollüberprüfung
Eine manuelle Protokollüberprüfung ist für die täglichen Überprüfungsanforderungen von v4.0.1 nicht mehr zulässig. Sie benötigen einen automatisierten Mechanismus, der Protokolle aus der Karteninhaberdatenumgebung erfasst und Anomalien aufzeigt. Für ein kleines unabhängiges Unternehmen kann dies so einfach sein wie die Audit-Protokollfunktion in Ihrem Cloud-PMS (mit E-Mail-Benachrichtigungen bei verdächtigen Ereignissen) sowie die Benachrichtigungsfunktionen in Ihrem Zahlungsgateway-Dashboard. Sie benötigen kein SIEM für 50.000 Dollar pro Jahr, aber Sie müssen nachweisen, dass die Protokolle täglich überprüft werden.
Anforderung 12.10.7: Vorfallreaktionsverfahren für gespeicherte PAN, die an unerwarteten Orten gefunden werden
Wenn Ihre Umfangsbestätigung (12.5.2) PAN-Daten an einem Ort findet, an dem sie nicht sein sollten, benötigen Sie ein dokumentiertes Verfahren für Ihre Reaktion. Das Minimum umfasst: Eindämmung (Isolierung des Systems), Bewertung (Ermittlung, was offengelegt wurde und wie lange), Benachrichtigung (Ihrer Acquirer innerhalb der von ihnen geforderten Frist, oft 24 bis 72 Stunden) und Behebung (Entfernung der Daten und Behebung der Ursache). Schreiben Sie diese Vorgehensweise einmal auf, bewahren Sie sie an einem Ort auf, an dem das Bereitschaftspersonal sie um 3 Uhr morgens finden kann, und überprüfen Sie sie jährlich.
Die sieben Orte, an denen sich Kartendaten in Ihrem Hotel verstecken
Die von mir zuvor zitierte Zahl von 34 % aus dem Verizon DBIR ist nicht abstrakt. Bei jedem PCI-Projekt in unabhängigen Hotels, an dem ich in den letzten zwei Jahren beteiligt war, hat die Überprüfung des Umfangs mindestens drei der folgenden sieben Orte zutage gefördert, an denen Karteninhaberdaten gespeichert sind - oft Jahre, nachdem sie dort abgelegt und vergessen wurden. Hier ist die Liste, geordnet nach Häufigkeit. Nutzen Sie sie als Checkliste für Ihre eigene 12.5.2-Prüfung.
- E-Mail-Server-Archiv. Jede E-Mail mit VCC im Klartext, die von einer OTA gesendet wurde, oder von einem Gast, der einmal seine Kartennummer in eine E-Mail mit dem Betreff „Bitte belasten Sie meine Karte mit der Kaution“ eingegeben hat, befindet sich in Ihrem IMAP-Archiv. Suchen Sie nach „Kartennummer“, „CVV“, „Ablaufdatum“ und dem Muster „vierstellig, dann Leerzeichen“. Sie werden entsetzt sein über das, was Sie finden.
- Alte PMS-Datenbank-Backups. Jedes nächtliche PMS-Backup, das erstellt wurde, bevor Ihr Hotel auf einen Tokenisierungs-Prozessor umgestellt hat, enthält wahrscheinlich vollständige PAN-Daten. Überprüfen Sie Ihren externen Backup-Anbieter, das NAS Ihres Hotels, die externe Festplatte Ihres Front-Desk-Managers und den unverschlüsselten USB-Stick im Safe. Backups aus der Zeit vor 2019 enthalten besonders häufig rohe PAN-Daten.
- Faxarchiv. Jedes von einer OTA ausgestellte VCC-Fax, jedes Formular zur Gruppenbuchungsautorisierung, jedes Formular zur Kreditkartenzahlungsautorisierung, das Ihr Backoffice angefordert hat. Moderne Multifunktionsdrucker verfügen oft über ein Archiv für 500 Faxe im internen Speicher, das nie gelöscht wurde.
- Ausdrucke aus dem Folio-Archiv. Der Stapel gedruckter Folios im Backoffice, das gebundene Archiv mit Gäste-Folios aus der Zeit vor 2020, der Aktenschrank des Managers mit der Aufschrift „Audit-Kopien“. Diese enthalten gedruckte PAN-Daten, was gegen die Regel „Papier nur, wenn nicht elektronisch empfangen“ aus SAQ A verstößt, sobald man erkennt, dass die Folios von einem elektronischen PMS generiert wurden.
- Excel-Dateien für das Revenue- und Yield-Management. Die Tabelle „Einzahlungen in diesem Monat“, die jemand in der Buchhaltung pflegt. Der Tracker für „No-Show-Gebühren“. Die Arbeitsmappe „Ausstehende VCC-Zahlungen“. Diese enthalten oft Kartendaten, die aus E-Mails eingefügt wurden, manchmal schon seit Jahren.
- Handschriftliche Logbücher. Das Logbuch an der Rezeption, in das der Nacht-Auditor notierte: „Anzahlung von Frau Smith telefonisch entgegengenommen, Visa endend auf 4242, gültig bis 27.06., 400 $ belastet.“ Ja, das kommt auch im Jahr 2026 noch vor.
- Anbieterportale und Tools von Drittanbietern. Das CRM, das jemand so konfiguriert hat, dass OTA-E-Mails wortwörtlich importiert werden. Der gemeinsame Posteingang, über den das Spa Kartennummern per E-Mail unter den Mitarbeitern austauscht. Das Trello-Board, mit dem der Gruppenvertrieb Vertragsanzahlungen nachverfolgt. Der Slack-DM-Verlauf mit dem früheren Front-Office-Manager.
Der Aufdeckungsprozess ist unangenehm. Die Behebung ist größtenteils administrativer Natur: Identifizieren Sie die Daten, klassifizieren Sie sie (handelt es sich um aktive CHD oder historische Daten?), vernichten oder löschen Sie die historischen Daten sicher, gestalten Sie die aktiven Datenflüsse so, dass sie stattdessen durch den Tokenizer laufen, und dokumentieren Sie die neue Richtlinie, die verhindert, dass die Daten zurückkommen. Planen Sie drei bis zehn Mitarbeitertage für ein Hotel mit 60 Zimmern ein, das dies zum ersten Mal durchführt. Der Großteil davon besteht aus der Durchsuchung von E-Mail-Archiven und dem Vernichten von Folio-Backups.
Die tatsächlichen Kosten: Benchmarks statt Panikmache der Anbieter
Die PCI-Beratungsbranche hat ein starkes Interesse daran, die Kosten für die Compliance aufzublähen, denn so verkauft sie ihre Dienstleistungen. Die ehrlichen Kostenspannen, je nach SAQ-Pfad und Größe des Händlers, sind gut dokumentiert und konvergieren für ein unabhängiges Hotel im Jahr 2026 zu diesen Benchmarks.
SAQ-A-Pfad (vollständig ausgelagert, Tokenisierung durch den Zahlungsabwickler, kein elektronisches CHD auf den Hotelsystemen). Jährliche SAQ-Erfüllung: unter 300 $. Vierteljährliche externe Scans durch einen Approved Scanning Vendor (ASV): 500 bis 2.000 $ pro Jahr, je nach Anbieter. Jährliche Schulungsmaßnahmen zur Sensibilisierung für Sicherheitsfragen: 500 bis 1.000 $. Gesamt: 1.500 bis 3.000 $ pro Jahr. Dies ist der richtige Weg für die Mehrheit der unabhängigen Hotels, und genau darauf sollte das Onboarding-Team Ihres Zahlungsabwicklers Sie hinlenken.
SAQ-A-EP-Weg (teilweises Outsourcing, Umleitung des Zahlungsflusses, keine elektronische Speicherung von CHD-Daten, aber die Hotelseite kann die Transaktionssicherheit beeinträchtigen). Hinzu kommen: mehr Fragen (ca. 190 gegenüber 30), ein dokumentiertes Skriptinventar und ein Manipulationserkennungsmechanismus für 6.4.3 und 11.6.1 sowie wahrscheinlich ein kleiner Beratungsauftrag, um die Sicherheitslage im ersten Jahr richtig aufzustellen. Gesamt: 5.000 bis 15.000 US-Dollar pro Jahr.
SAQ B-IP-Pfad (eigenständige, PTS-zugelassene IP-Terminals, keine elektronische CHD-Speicherung). Gesamt: 1.500 bis 5.000 US-Dollar pro Jahr. Der Terminalhersteller bündelt die SAQ B-IP-Bescheinigungstools oft in seinen Service.
SAQ-D-Pfad (jede elektronische CHD-Speicherung oder jede Umgebung, die nicht unter einen spezifischeren SAQ fällt). Jährlicher SAQ: 330 Fragen, erfordert oft Beratungshilfe zur korrekten Bearbeitung (3.000 bis 10.000 $ im ersten Jahr). Vierteljährliche ASV-Scans: 500 bis 2.000 $. Penetrationstests: 3.000 bis 8.000 US-Dollar pro Jahr. Endpunktschutz und grundlegende SIEM-ähnliche Protokollüberprüfung: 2.000 bis 5.000 US-Dollar. Jährliche Schulung: 500 bis 1.500 US-Dollar. Gesamt: 15.000 bis 50.000 US-Dollar pro Jahr für einen kleinen unabhängigen Händler, mehr, wenn Sie mehrere Standorte haben.
QSA-geführter Compliance-Bericht (erforderlich für Level-1-Händler mit mehr als 6 Millionen Transaktionen). Gesamt: 30.000 bis 80.000 US-Dollar allein für die Bewertung eines mittelgroßen Händlers, zuzüglich aller zugrunde liegenden Kontrollen. Der Cybersicherheits-Benchmark „Hotel Tech Insight 2026“ für ein unabhängiges Hotel mit 60 Zimmern beziffert die Gesamtkosten für die Sicherheitsmaßnahmen im ersten Jahr auf 3.500 bis 5.000 Euro und danach auf 2.000 bis 3.500 Euro, was dem oben genannten SAQ-A-Pfad sowie grundlegenden Endpunkt- und Netzwerkkontrollen entspricht.
Auf der anderen Seite ist der von Antravia Advisory veröffentlichte Benchmark für 2025 erwähnenswert: Tokenisierte, PCI 4.0-konforme Reisehändler zahlten durchschnittlich 1,8 % Interchange-Gebühren, verglichen mit 2,9 % für nicht konforme Händler. Die Rückbuchungen sanken von 1,8 % auf 0,6 %, und die durchschnittlichen Auditkosten fielen um zwei Drittel. Für ein Hotel mit 60 Zimmern und einem jährlichen Kartenumsatz von 2 Millionen US-Dollar bedeutet allein die Differenz bei den Interchange-Gebühren eine wiederkehrende jährliche Einsparung von 22.000 US-Dollar - das ist das Zehn- bis Fünfzehnfache der Kosten für die SAQ-A-Compliance-Maßnahmen. Compliance ist keine Steuer. Sie ist ein Schutzwall, der Ihnen beim Bezahlen einen Preisvorteil verschafft.
Der 90-Tage-Plan, den eine Person umsetzen kann
Falls Ihr Hotel sich noch nicht mit PCI DSS 4.0.1 befasst hat, finden Sie hier den Plan, mit dem Sie in 90 Tagen „SAQ A mit einer dokumentierten Architektur bestehen“. Eine Person, die über die erforderlichen operativen Kompetenzen verfügt und angemessenen Zugang zum Geschäftsführer und zum IT-Anbieter hat, kann diesen Plan ohne externe Beratung umsetzen. Planen Sie für die beauftragte Person über die 90 Tage hinweg etwa 8 Stunden pro Woche ein.
Tage 1 bis 15: Umfang und Erfassung
Stellen Sie Ihren Kartendatenfluss auf Papier dar. Wo gelangt eine Kartennummer in Ihre Umgebung (Buchungssystem, EMV-Terminal an der Rezeption, E-Mail von OTA, Telefon, Gruppenverkaufsvertrag)? Wohin geht sie als Nächstes (Tokenizer, Gateway, PMS, Buchhaltungsexport)? Wo wird sie gespeichert, falls überhaupt (sie sollte nirgendwo gespeichert werden)? Führen Sie dann die Checkliste „Sieben Orte, an denen sich Kartendaten verstecken“ aus dem vorherigen Abschnitt durch. Dokumentieren Sie alles, was Sie finden, in einer einzigen Tabelle mit drei Spalten: Ort, Klassifizierung (aktiv oder historisch), geplante Abhilfemaßnahmen. Verfassen Sie eine Richtlinie, die jedes zukünftige Vorkommen ausdrücklich verbietet („Mitarbeiter dürfen keine VCC-Daten im Klartext per E-Mail annehmen. OTAs müssen das sichere Extranet nutzen“). Diese Phase liefert drei Ergebnisse: ein Diagramm zum Karten-Datenfluss, ein Erfassungsregister und eine schriftliche Richtlinie zum Umgang mit CHD.
Tag 16 bis 45: Umfang auf SAQ A reduzieren
Richten Sie jeden aktiven Kartendatenfluss, der ein Hotelsystem berührt, stattdessen auf den Tokenizer aus. Wenn Ihre Buchungsmaschine das Zahlungsformular auf Ihrer Domain anzeigt, wechseln Sie zur iframe-gehosteten Zahlungsseite des Zahlungsdienstleisters (die meisten Anbieter bieten beide Optionen an. fragen Sie nach). Wenn Ihre Rezeption Kartennummern per Telefon entgegennimmt und diese in ein virtuelles Terminal eingibt, stellen Sie sicher, dass dieses virtuelle Terminal vom Zahlungsabwickler und nicht vom Hotel gehostet wird. Wenn Ihr Gruppenverkaufsteam VCC-Daten per E-Mail entgegennimmt, verlagern Sie die Einzug der Anzahlungen auf das Secure-Link-Produkt des Zahlungsabwicklers. Vernichten Sie die in Phase 1 ermittelten historischen Kartendaten (Papierdokumente in den verschlossenen Aktenvernichter, elektronische Daten durch sichere Löschung mit Prüfprotokoll). Am Ende dieser Phase sollte Ihr Karten-Datenflussdiagramm zeigen, dass jede Kartennummer in die Umgebung des Zahlungsdienstleisters gelangt und diese wieder verlässt, ohne jemals ein hoteleigenes System zu berühren. Das ist die Architektur, die es Ihnen ermöglicht, ein SAQ A einzureichen.
Tag 46 bis 75: Implementieren Sie die noch für das SAQ A erforderlichen Kontrollen
SAQ A ist klein, aber nicht leer. Die 30 Kontrollen umfassen die Verwaltung des Mitarbeiterzugriffs, das Lieferantenmanagement Ihrer TPSPs, Schulungen zur Sicherheitssensibilisierung und (gemäß dem Update von v4.0.1 vom Januar 2025) die E-Skimming-Bescheinigung. Gehen Sie wie folgt vor: Aktivieren Sie MFA für jedes Cloud-Konto, das mit der Buchungsmaschine, dem Zahlungsgateway oder dem PMS in Berührung kommt. Dokumentieren Sie die von Ihnen genutzten TPSPs, rufen Sie deren aktuelle PCI-Konformitätsbescheinigung ab (jede sollte ihre eigene veröffentlichen oder zur Verfügung stellen) und speichern Sie diese in einem Lieferantenverwaltungsordner mit jährlichen Erneuerungserinnerungen. Führen Sie rollenspezifische Schulungen zur Sicherheitssensibilisierung (Rezeption, Backoffice, IT) mithilfe eines gehosteten Tools wie KnowBe4, Hoxhunt oder eines kostenlosen Äquivalents durch. Implementieren Sie eine Skript-Manipulationserkennung auf der Buchungsseite (Visualping, Feroot oder eine benutzerdefinierte CSP-Konfiguration mit Überwachung) und legen Sie das Verfahren zur Eskalation von Warnmeldungen fest. Führen Sie vierteljährliche ASV-Scans Ihrer externen IP-Adressen durch oder beauftragen Sie einen Dienstleister damit (sofern Sie solche haben. bei einem reinen SaaS-Hotel ist der Umfang hierfür möglicherweise gleich null).
Tag 76 bis 90: SAQ A einreichen und bestätigen
Füllen Sie SAQ A v4.0.1 unter Verwendung der Vorlagen von der PCI SSC-Website aus. Lassen Sie den Geschäftsführer oder Eigentümer Teil 3a der Konformitätsbescheinigung (Attestation of Compliance) unterzeichnen. Reichen Sie die AoC sowie den letzten bestandenen ASV-Scan-Bericht über das von Ihrer Acquiring-Bank angegebene Portal ein. Bestätigen Sie den Erhalt. Richten Sie Kalendererinnerungen für das nächste jährliche SAQ, die vierteljährlichen ASV-Scans, die halbjährliche Überprüfung des Anwendungsbereichs (12.5.2.1, wenn Sie ein Dienstleister sind, ansonsten jährlich), die Erneuerung der rollenspezifischen Schulungen und den Erneuerungszyklus der TPSP-Konformitätsbescheinigung ein. Dies sind die Maßnahmen, die Ihr Programm vorantreiben, ohne dass jemand in einem Jahr das Ganze neu entdecken muss.
Wo Prostay ins Spiel kommt - kurz und ehrlich
Ich schreibe für Prostay, daher ist dieser Abschnitt unvermeidlich, aber ich werde ehrlich bleiben. Prostay Pay ist ein Tokenisierungs-Zahlungsabwickler, der so konzipiert ist, dass Ihr Hotel standardmäßig im SAQ-A-Geltungsbereich bleibt. Wenn ein Gast über die Prostay-Buchungsmaschine bezahlt oder die Rezeption eine Karte über den Prostay-POS entgegennimmt, gelangt die Kartennummer selbst niemals in die Prostay-PMS-Datenbank. nur eine Token-Referenz wird übertragen. Diese Architektur ermöglicht den SAQ-A-Pfad für ein unabhängiges Hotel, das Prostay nutzt, und es ist dieselbe Architektur, die Stripe, Adyen, Mews Payments, Cloudbeds Payments und Profitroom Payments anbieten. Wählen Sie einen beliebigen Anbieter, einschließlich der Nicht-Prostay-Optionen, und Sie können innerhalb von 90 Tagen den SAQ-A-Pfad einschlagen. Wählen Sie einen Zahlungsabwickler, der sich durch das Einlesen von Kartennummern in Ihr PMS integriert, und Sie befinden sich auf dem SAQ-A-EP- oder SAQ-D-Pfad mit all den damit verbundenen Kosten und der Komplexität.
Die spezifischen Prostay-Entscheidungen, die für PCI von Bedeutung sind: Die Buchungsmaschine nutzt einen in einem Iframe gehosteten Checkout, der das SAQ-A-Kriterium „Jedes Element der Zahlungsseite stammt ausschließlich und direkt von einem PCI-DSS-konformen TPSP“ erfüllt. die API gibt niemals PAN-Daten an Integrationen zurück. die OTA-E-Mail-Integration analysiert VCC-Daten innerhalb der Prostay-Umgebung und übermittelt an das Hotel-Front-Office stets nur die tokenisierte Referenz. Nichts davon ist einzigartig für Prostay. Es ist jedoch einfacher, dies richtig umzusetzen, wenn die Buchungsmaschine, das PMS und der Tokenizer eine gemeinsame Audit-Grenze haben - was das eigentliche strukturelle Argument dafür ist, einen Single-Vendor-Stack einer Best-of-Breed-Zusammenstellung vorzuziehen.
Wenn Sie einen tieferen Einblick darin wünschen, wie Prostay Pay konkret mit der Tokenisierung und der PCI-SAQ-A-Architektur umgeht, finden Sie auf der Prostay Pay-Produktseite eine ausführliche Beschreibung. Wenn Sie von einem älteren PMS migrieren, bei dem Kartendaten in der Datenbank gespeichert sind (was Sie per Definition in den SAQ-D-Anwendungsbereich bringt), behandelt das Prostay-PMS-Migrationshandbuch den Schritt der Datenentfernung. Und wenn Sie Hilfe bei der Umsetzung des oben genannten 90-Tage-Plans in einem Telefonat mit unserem Zahlungsteam wünschen, buchen Sie eine Demo, und wir gehen alles mit Ihnen durch, ohne Ihnen ein separates Compliance-Beratungsprojekt verkaufen zu wollen.
Häufig gestellte Fragen
Die fünf Fragen, die mir unabhängige Hoteliers am häufigsten zu PCI DSS 4.0.1 stellen, beantwortet anhand der tatsächlich veröffentlichten Vorschrift und nicht anhand der Zusammenfassung in der Fachpresse.
