Compliant and breached: what a PCI certificate actually measures
Zertifiziert und trotzdem kompromittiert: was ein PCI-Nachweis wirklich misst
A PCI DSS certificate is one of the most widely misread documents in payments. It is read as a statement that a company is secure. It is not. It is a statement that on one particular day, an assessor found a defined set of controls in place across a boundary the company itself drew. Everything that matters sits in the gap between those two readings — and there is a public dataset that measures the size of that gap.
What the document says, and what it is heard to say
The Payment Card Industry Data Security Standard is not law. It is a contractual standard written by the card networks and administered through a chain of contracts: network to acquirer, acquirer to merchant. A merchant validates compliance either through a Report on Compliance produced by a Qualified Security Assessor, or through one of several Self-Assessment Questionnaires, depending on how the merchant handles card data and how many transactions it processes.
Two things follow that are almost always lost in the retelling. The first is that validation is annual and point-in-time. It describes the state of a system on the date it was examined, in the same way an MOT certificate describes a car on the morning of the test. The second is that the assessment covers a scope, and the scope is defined by the assessed party. Systems outside the cardholder data environment are outside the report. If the boundary is drawn narrowly, the report is narrow, and it is still a valid report.
Neither point is hidden. Both are stated plainly in the standard’s own documentation. They are nonetheless routinely dropped when a certificate is quoted in a sales conversation, a due-diligence pack, or a press statement after an incident.
The number that measures the gap
For about a decade Verizon published an annual Payment Security Report, drawn from its own assessment practice. Its most useful figure was not the pass rate. It was interim compliance validation: assessors going back into organisations that had already been certified, and checking whether the controls were still fully in place.
That number has a striking history. In the 2017 edition, 55.4 per cent of assessed organisations were found in full compliance at interim validation. By the 2020 edition — reporting on 2019 assessments — it had fallen to 27.9 per cent. The following year it recovered to 43.4 per cent. Taken across the series, the drop from the 2016 peak was some 27.5 percentage points.
The regional spread in that period was wider than the headline. In the 2020 report, 8.5 per cent of assessed US organisations sustained full compliance, against 40.5 per cent in EMEA and 87 per cent in Asia-Pacific.
These figures need a caution attached, and we attach it rather than leave it to be found: this is not a random sample of the world’s merchants. It is the population of organisations that engaged one large assessor, weighted towards large enterprises with complex environments and, presumably, budget. A representative sample would very likely look different. But the direction of the finding survives the caveat, because the comparison is internal — the same organisations, assessed twice.
What it shows is that a certificate and a controlled environment are different things, and that the difference is not marginal. In the worst year of the series, roughly three in four certified organisations had drifted out of full compliance by the time someone looked again.
Why the gap opens
The mechanisms are ordinary rather than sinister.
Scope drift. A boundary is defined, agreed and documented. Then a new integration is added, a reporting tool is granted read access to a database, a support process is set up that copies a transaction file somewhere convenient. None of these are decisions to break the standard. Each of them moves the boundary, and the boundary is not re-drawn until the next assessment.
Compensating controls. The standard allows an organisation that cannot meet a requirement literally to meet its intent by another route, documented and justified. This is a sound provision. It is also a mechanism through which a difficult requirement can be converted into a paragraph of prose, and the paragraph carries forward from year to year long after the circumstances that justified it have changed.
Cadence. Annual assessment against continuous change is a structural mismatch. Nothing in a yearly certificate speaks to the other 364 days, and the standard’s requirements for continuous monitoring are themselves only verified once a year.
What version 4 changed — and what it did not
PCI DSS v4.0 arrived in 2022, refined to v4.0.1 in 2024. It brought 64 new requirements, of which 51 were future-dated: designated best practice until 31 March 2025, mandatory in assessments from that date onward. That deadline has now passed, so the 2026 assessment cycle is the first in which the full standard applies to everyone.
Two of those requirements deserve specific attention, because they respond to an attack that made the older standard look beside the point.
Requirement 6.4.3 obliges a merchant to inventory every script that executes in the consumer’s browser on a payment page, and to record an authorisation and a written justification for each. Requirement 11.6.1 obliges the merchant to run tamper- or change-detection that alerts when a script or HTTP header on a payment page is modified unexpectedly.
Both exist because of e-skimming — the family of attacks in which card data is captured in the shopper’s browser, by injected JavaScript, before it ever reaches the merchant’s systems. A merchant can be entirely compliant with the older standard and still lose every card number entered on its checkout page, because the theft happens outside the environment the standard was drawn around. That is the clearest available illustration of the scope problem: the controls were real, the certificate was honest, and the boundary was in the wrong place.
What version 4 did not change is the underlying structure. It is still annual, still scoped by the assessed party, still validated at a point in time.
What to ask instead of “are you PCI compliant?”
The question as usually posed can only be answered yes, and the answer carries almost no information. Five questions that do carry information:
Which validation type? A Report on Compliance and a Self-Assessment Questionnaire A are not comparable documents. SAQ A is a short self-declaration available to merchants who have outsourced their payment page. It is a legitimate route, and it establishes far less than a full assessment.
What date? Not the year — the assessment date. Eleven months old is a materially different answer from one month old.
What scope? Ask for the scope statement, not the certificate. The certificate is a cover sheet; the scope statement is the document.
Who assessed it, and are they still engaged? An assessor who returns for interim work is looking at a different question from one who returns once a year.
What has changed since? New integrations, new subprocessors, new payment methods, new scripts on the checkout page. This is the question the annual cadence cannot reach, and it is the one that predicts.
What this does not tell you
Three limits on the argument above, stated because the argument is weaker without them.
First, non-compliance is not the same as breach. Most organisations that drift out of full compliance are not breached, and the interim-validation figures say nothing about outcomes.
Second, the standard has demonstrably raised the floor. Practices that were routine before it existed — card numbers in plain text in application logs, shared administrative credentials, flat networks — are now rare in assessed environments. A weak measure applied broadly can still do considerable work.
Third, the causation is not clean in either direction. Organisations that sustain compliance are also organisations that invest in security generally, and it is not possible to separate the effect of the standard from the effect of the disposition that produces it.
The narrower conclusion is the defensible one. A PCI certificate is evidence about a bounded system on a stated date. Treated as that, it is useful. Treated as a statement that customer data is safe, it is being asked to carry a claim it was never built to make.
Ein PCI-DSS-Zertifikat gehört zu den am häufigsten falsch gelesenen Dokumenten des Zahlungsverkehrs. Gelesen wird es als Aussage, ein Unternehmen sei sicher. Das ist es nicht. Es ist die Aussage, dass ein Prüfer an einem bestimmten Tag eine definierte Menge an Kontrollen innerhalb einer Grenze vorgefunden hat, die das Unternehmen selbst gezogen hat. Alles Wesentliche liegt in der Lücke zwischen diesen beiden Lesarten — und es gibt einen öffentlichen Datensatz, der die Größe dieser Lücke misst.
Was das Dokument sagt und was gehört wird
Der Payment Card Industry Data Security Standard ist kein Gesetz. Er ist ein vertraglicher Standard, geschrieben von den Kartennetzwerken und durchgesetzt über eine Vertragskette: Netzwerk zum Acquirer, Acquirer zum Händler. Ein Händler weist die Einhaltung entweder über einen Report on Compliance eines qualifizierten Prüfers nach oder über einen der Selbstauskunftsbögen — je nachdem, wie er mit Kartendaten umgeht und wie viele Transaktionen er abwickelt.
Daraus folgen zwei Dinge, die in der Weitergabe fast immer verlorengehen. Erstens ist die Prüfung jährlich und stichtagsbezogen. Sie beschreibt den Zustand eines Systems an dem Tag, an dem es untersucht wurde — so wie eine TÜV-Plakette ein Auto am Morgen der Prüfung beschreibt. Zweitens deckt die Prüfung einen Geltungsbereich ab, und diesen Bereich definiert die geprüfte Partei selbst. Systeme außerhalb der Kartendatenumgebung stehen nicht im Bericht. Wird die Grenze eng gezogen, ist der Bericht eng — und trotzdem gültig.
Nichts davon ist versteckt. Beides steht ausdrücklich in der Dokumentation des Standards. Trotzdem fällt es regelmäßig weg, sobald ein Zertifikat in einem Verkaufsgespräch, in einer Due-Diligence-Mappe oder in einer Pressemitteilung nach einem Vorfall zitiert wird.
Die Zahl, die die Lücke misst
Verizon hat rund ein Jahrzehnt lang einen jährlichen Payment Security Report aus der eigenen Prüfpraxis veröffentlicht. Die brauchbarste Kennzahl darin war nicht die Bestehensquote. Es war die Zwischenprüfung: Prüfer gingen zurück in bereits zertifizierte Organisationen und sahen nach, ob die Kontrollen noch vollständig standen.
Diese Zahl hat eine bemerkenswerte Geschichte. In der Ausgabe 2017 waren 55,4 Prozent der geprüften Organisationen bei der Zwischenprüfung vollständig konform. In der Ausgabe 2020 — für die Prüfungen des Jahres 2019 — waren es 27,9 Prozent. Im Jahr darauf erholte sich der Wert auf 43,4 Prozent. Über die Reihe hinweg beträgt der Rückgang gegenüber dem Höchststand von 2016 rund 27,5 Prozentpunkte.
Die regionale Spreizung war in dieser Zeit größer als die Schlagzeile. Im Bericht 2020 hielten 8,5 Prozent der geprüften US-Organisationen die vollständige Konformität, gegenüber 40,5 Prozent in EMEA und 87 Prozent im asiatisch-pazifischen Raum.
Diese Zahlen brauchen einen Vorbehalt, und wir hängen ihn an, statt ihn suchen zu lassen: Das ist keine Zufallsstichprobe der Händler dieser Welt. Es ist die Grundgesamtheit der Organisationen, die einen großen Prüfer beauftragt haben — mit Übergewicht bei Großunternehmen mit komplexen Umgebungen und, vermutlich, Budget. Eine repräsentative Stichprobe sähe sehr wahrscheinlich anders aus. Die Richtung des Befunds übersteht den Vorbehalt allerdings, weil der Vergleich intern ist: dieselben Organisationen, zweimal geprüft.
Er zeigt, dass ein Zertifikat und eine kontrollierte Umgebung zwei verschiedene Dinge sind — und dass der Unterschied nicht marginal ist. Im schwächsten Jahr der Reihe war etwa jede vierte zertifizierte Organisation bei erneutem Hinsehen noch vollständig konform.
Warum die Lücke aufgeht
Die Mechanismen sind gewöhnlich, nicht finster.
Verschiebung des Geltungsbereichs. Eine Grenze wird definiert, abgestimmt, dokumentiert. Dann kommt eine neue Anbindung dazu, ein Auswertungswerkzeug bekommt Lesezugriff auf eine Datenbank, ein Supportprozess kopiert eine Transaktionsdatei an eine praktische Stelle. Keine dieser Entscheidungen bricht bewusst den Standard. Jede verschiebt die Grenze — und neu gezogen wird sie erst bei der nächsten Prüfung.
Kompensierende Kontrollen. Der Standard erlaubt es, eine Anforderung, die sich wörtlich nicht erfüllen lässt, auf anderem Weg dem Sinn nach zu erfüllen, dokumentiert und begründet. Das ist eine sinnvolle Regelung. Sie ist zugleich der Mechanismus, über den aus einer schwierigen Anforderung ein Absatz Prosa wird — und der Absatz wird Jahr für Jahr fortgeschrieben, lange nachdem die Umstände, die ihn rechtfertigten, sich geändert haben.
Taktung. Jährliche Prüfung gegen fortlaufende Veränderung ist ein struktureller Fehlschluss. Ein Jahreszertifikat sagt nichts über die übrigen 364 Tage — und die Anforderungen des Standards an laufende Überwachung werden selbst nur einmal jährlich verifiziert.
Was Version 4 geändert hat und was nicht
PCI DSS v4.0 kam 2022, verfeinert zu v4.0.1 im Jahr 2024. Der Standard brachte 64 neue Anforderungen, davon 51 mit späterem Stichtag: bis zum 31. März 2025 als bewährte Praxis empfohlen, ab diesem Datum in Prüfungen verpflichtend. Die Frist ist verstrichen, der Prüfzyklus 2026 ist damit der erste, in dem der vollständige Standard für alle gilt.
Zwei dieser Anforderungen verdienen besondere Aufmerksamkeit, weil sie auf einen Angriff antworten, der den älteren Standard beinahe gegenstandslos aussehen ließ.
Anforderung 6.4.3 verpflichtet den Händler, jedes Skript zu inventarisieren, das im Browser des Kunden auf einer Zahlungsseite ausgeführt wird, und für jedes eine Freigabe samt schriftlicher Begründung festzuhalten. Anforderung 11.6.1 verpflichtet ihn zu einer Manipulations- oder Änderungserkennung, die alarmiert, sobald ein Skript oder ein HTTP-Header auf einer Zahlungsseite unerwartet verändert wird.
Beide existieren wegen des E-Skimming — jener Angriffsfamilie, bei der Kartendaten im Browser des Käufers durch eingeschleustes JavaScript abgegriffen werden, bevor sie die Systeme des Händlers überhaupt erreichen. Ein Händler kann den älteren Standard vollständig einhalten und dennoch jede auf seiner Kassenseite eingegebene Kartennummer verlieren, weil der Diebstahl außerhalb der Umgebung stattfindet, um die der Standard gezogen war. Das ist die deutlichste verfügbare Illustration des Grenzproblems: Die Kontrollen waren echt, das Zertifikat war ehrlich, und die Grenze lag an der falschen Stelle.
Was Version 4 nicht geändert hat, ist die zugrunde liegende Konstruktion. Sie ist weiterhin jährlich, weiterhin von der geprüften Partei abgegrenzt, weiterhin stichtagsbezogen.
Was man statt „Sind Sie PCI-konform?” fragen sollte
Die übliche Frage lässt sich nur mit Ja beantworten, und die Antwort trägt fast keine Information. Fünf Fragen, die Information tragen:
Welche Nachweisart? Ein Report on Compliance und ein Selbstauskunftsbogen A sind keine vergleichbaren Dokumente. SAQ A ist eine kurze Selbsterklärung für Händler, die ihre Zahlungsseite ausgelagert haben. Das ist ein legitimer Weg — und er belegt erheblich weniger als eine vollständige Prüfung.
Welches Datum? Nicht das Jahr, das Prüfdatum. Elf Monate alt ist eine materiell andere Antwort als einen Monat alt.
Welcher Geltungsbereich? Fragen Sie nach der Bereichsbeschreibung, nicht nach dem Zertifikat. Das Zertifikat ist ein Deckblatt; die Bereichsbeschreibung ist das Dokument.
Wer hat geprüft, und ist er weiter beauftragt? Ein Prüfer, der für Zwischenarbeiten zurückkommt, beantwortet eine andere Frage als einer, der einmal im Jahr erscheint.
Was hat sich seitdem geändert? Neue Anbindungen, neue Unterauftragsverarbeiter, neue Zahlarten, neue Skripte auf der Kassenseite. Das ist die Frage, die die jährliche Taktung nicht erreicht — und die einzige mit Prognosewert.
Was daraus nicht folgt
Drei Grenzen der obigen Argumentation, genannt, weil sie ohne sie schwächer wäre.
Erstens ist Nichtkonformität nicht dasselbe wie ein Datenabfluss. Die meisten Organisationen, die aus der vollständigen Konformität herausdriften, werden nicht kompromittiert, und die Zahlen zur Zwischenprüfung sagen nichts über Ergebnisse.
Zweitens hat der Standard den Boden nachweislich angehoben. Praktiken, die vor ihm üblich waren — Kartennummern im Klartext in Anwendungsprotokollen, geteilte Administratorkennungen, flache Netze — sind in geprüften Umgebungen selten geworden. Ein schwaches Maß, breit angewandt, kann erhebliche Arbeit leisten.
Drittens ist die Kausalität in keine Richtung sauber. Organisationen, die Konformität halten, sind auch Organisationen, die generell in Sicherheit investieren — die Wirkung des Standards lässt sich von der Wirkung der Haltung, die ihn hervorbringt, nicht trennen.
Der engere Schluss ist der haltbare. Ein PCI-Zertifikat ist ein Beleg über ein abgegrenztes System an einem genannten Datum. So verstanden ist es nützlich. Als Aussage darüber, dass Kundendaten sicher sind, soll es eine Behauptung tragen, für die es nie gebaut wurde.
