Am 28. September 2026 hat das PCI Security Standards Council (PCI SSC) die Version 2.0 des PCI Secure Software Lifecycle Standard veröffentlicht. Es handelt sich um die erste umfassende Überarbeitung seit Einführung des Standards.
Der PCI Secure Software Lifecycle Standard, kurz PCI SSLC, definiert Sicherheitsanforderungen und Prüfverfahren für die Softwareentwicklungsprozesse von Herstellern. Gemeinsam mit dem PCI Secure Software Standard bildet er das PCI Software Security Framework.
Dabei übernimmt das PCI SSC zentrale Begriffe aus dem PCI Secure Software Standard v2.0 und entfernt Überschneidungen zwischen beiden Standards. Neue Anforderungen betreffen unter anderem KI-gestützte Werkzeuge und Risiken entlang der Software Supply Chain.
Einblick in die wichtigsten Änderungen des PCI Secure Software Lifecycle Standard v2.0:
Neue Ausrichtung auf Sensitive Assets
Eine der zentralen Änderungen ist die Übernahme des Konzepts der „Sensitive Assets“ aus dem PCI Secure Software Standard v2.0. Softwarehersteller müssen die Sensitive Assets ihrer Softwareprodukte systematisch identifizieren und dokumentieren. Das begleitende PCI-Dokument „Sensitive Asset Identification“ unterstützt Unternehmen bei der Identifikation, Klassifizierung und Dokumentation.
Mit dem neuen Security Objective 4 müssen Unternehmen systematisch berücksichtigen und nachvollziehbar dokumentieren, wie die Anforderungen des PCI Secure Software Standards in den Lifecycle ihrer Softwareprodukte einfließen.
Neue Anforderungen für digitale Werkzeuge und KI
Erstmals adressiert der Standard die Risiken digitaler Werkzeuge innerhalb des Software Lifecycle Managements. Dazu gehören unter anderem:
- Entwicklungsumgebungen (IDEs)
- Designtools
- Build- und Compiler-Systeme
- Repositories
- KI-gestützte Werkzeuge
Unternehmen müssen klare Prozesse für die Auswahl und Nutzung digitaler Werkzeuge festlegen. Dazu gehören Vorgaben und Schulungen für die Beschäftigten ebenso wie eine angemessene menschliche Kontrolle und die Validierung der Ergebnisse. Auch die eingesetzten Werkzeuge und Prozesse müssen nachvollziehbar dokumentiert sein.
Neue Rolle des SSLC Steward
Mit Version 2.0 wird die Rolle des „SSLC Steward“ eingeführt. Sie kann von einer Person oder einer Gruppe wahrgenommen werden und trägt die übergreifende Verantwortung für den Secure Software Lifecycle. Zu den Aufgaben gehören unter anderem die Koordination von Schulungen und Freigabeprozessen sowie die Überwachung der definierten Sicherheitsmaßnahmen. Unternehmen sollten prüfen, ob eine bestehende Rolle diese Verantwortung übernehmen kann oder sie Zuständigkeiten neu bündeln müssen.
Neue Pflicht zur Bill of Materials
Wie bereits im PCI Secure Software Standard v2.0 verlangt der PCI SSLC künftig die Erstellung und Pflege einer Bill of Materials (BOM). Diese Übersicht hilft Unternehmen dabei, betroffene Komponenten schneller zu identifizieren, wenn Schwachstellen in Bibliotheken oder anderen Abhängigkeiten bekannt werden.
Neues Security Objective für die Außerbetriebnahme von Software
Mit dem neuen Security Objective 8 führt Version 2.0 erstmals Anforderungen für die sichere Außerbetriebnahme von Software ein. Hersteller müssen Prozesse definieren, die Kunden eine sichere Außerbetriebnahme der Software ermöglichen.
Erweiterte Anforderungen an Threat Management und Change Management
PCI SSLC v2.0 erhöht außerdem die Anforderungen an den Umgang mit Bedrohungen, Schwachstellen und Änderungen. Dabei rücken die zuvor identifizierten Sensitive Assets stärker in den Mittelpunkt. Die Unternehmen müssen geplante Änderungen bereits in der Planungsphase dokumentieren und analysieren, wie sie sich auf Sensitive Assets und relevante Anforderungen des PCI Secure Software Standards auswirken. Auch die zugehörigen Testergebnisse müssen eindeutig nachvollziehbar sein. Unternehmen müssen außerdem festlegen, wie sie bei Problemen sicher zu einer früheren Softwareversion zurückkehren.
Höhere Anforderungen an Softwareentwicklungsumgebungen
Neu ist auch die ausdrückliche Forderung, Pre-Production- und Produktionsumgebungen logisch oder physisch voneinander zu trennen. Echte beziehungsweise produktive zahlungstransaktionsbezogene Daten wie Primary Account Numbers (PAN) dürfen nicht für Testzwecke verwendet werden.
Darüber hinaus müssen Unternehmen alle Zugriffe und Zugriffsversuche durch Personen und Systeme auf die Codebasis nachvollziehbar aufzeichnen. Die Aufzeichnungen sind vor Manipulation zu schützen und für einen definierten Zeitraum aufzubewahren. Bevor eine Software produktiv eingesetzt wird, müssen vorhandene Testdaten entfernt werden.
Wegfall bisheriger Control Objectives
Das PCI SSC hat zugleich zwei bisherige Control Objectives nicht in Version 2.0 übernommen. So entfällt das bisherige Control Objective 2. Dieses enthielt umfangreiche Anforderungen an Software Security Policies, Strategien und Assurance-Prozesse.
Auch das bisherige Control Objective 7 wurde nicht in Version 2.0 übernommen. Es enthielt Sicherheitsanforderungen für den Umgang mit Produktivdaten, beispielsweise im Rahmen von Support- oder Troubleshooting-Prozessen.
Änderungen bei Reporting und Listing
Neben den technischen Anforderungen wurden auch verschiedene Programm- und Reporting-Dokumente angepasst. Künftig werden die bekannten Dokumente Report on Compliance (RoC) und Attestation of Compliance (AoC) analog zum PCI Secure Software Standard durch Report on Validation (RoV) und Attestation of Validation (AoV) ersetzt.
Ab wann gilt PCI SSLC v2.0?
Mit der Verfügbarkeit der Trainings für Secure Software Lifecycle Assessors beginnt eine zwölfmonatige Übergangsphase von Version 1.1 auf Version 2.0. Die Trainings sind derzeit für das vierte Quartal 2026 vorgesehen. Ein konkretes Startdatum für die Übergangsphase hat das PCI SSC noch nicht genannt.
Die bestehenden Validierungen nach PCI Secure Software Lifecycle Standard v1.1 behalten zunächst ihre Gültigkeit. Da Revalidierungen weiterhin im regulären Zyklus erfolgen, kann die Umstellung auf Version 2.0 für bereits validierte Unternehmen je nach individuellem Prüfzyklus erst zu einem späteren Zeitpunkt relevant werden.
Einschätzung unseres PCI-Experten
„Das Update auf den PCI SSLC v2.0 war nach den umfangreichen Änderungen im PCI Secure Software Standard v2.0 konsequent und notwendig. Beide Standards greifen nun deutlich besser ineinander und reduzieren bisherige Überschneidungen. Gleichzeitig adressieren die neuen Anforderungen aktuelle Herausforderungen wie den Einsatz von KI in Entwicklungsprozessen oder Risiken entlang der Software Supply Chain durch die verpflichtende Erstellung und Pflege einer Bill of Materials. Für Softwarehersteller wird es jetzt wichtig sein, ihre Entwicklungsprozesse frühzeitig auf diese Änderungen auszurichten und mögliche Lücken zu identifizieren, da Version 2.0 an mehreren Stellen neue Prozesse und Dokumentationen verlangt.“
Lorenz Heiler, Managing Consultant und PCI SSF Assessor, usd AG
Sie möchten klären, welche Anforderungen des PCI Secure Software Lifecycle Standard v2.0 für Ihr nächstes Assessment relevant sind? Unsere PCI-Expert*innen unterstützen Sie dabei, bestehende Prozesse und Dokumentationen zu prüfen, Lücken zu identifizieren und die nächste Validierung gezielt vorzubereiten. Kontaktieren Sie uns.
