Requirements & evidence

PCI Secure Software Standard

The PCI Software Security Framework standard for payment software design and development, replacing the retired PA-DSS lineage. Part of the family beyond bare PCI DSS that a payments-processing SaaS enterprise is routinely asked about.

Edition on record: v2.0
Issuing authority: PCI Security Standards Council — Software Security Framework (opens in a new tab)
Edition published: January 1, 2026
Source last checked: September 6, 2026

Understand the scope

What the framework covers.

The library records this framework for payments, software vendors, across global. The issuing authority determines applicability; your assessment scope should identify the organization, systems, services, and edition being assessed.

Areas of requirement

Secure software lifecycle
Threat and vulnerability management
Sensitive data protection
Software integrity

The library tracks the authority and edition. A normalized requirement catalog is not available for this framework, so a requirement count is not stated here.

Source access and licensing

Freely downloadable from PCI SSC; PCI SSC's terms permit identifiers and structure, not verbatim requirement text, without a separate license.

Prepare with context

The evidence behind
the requirements.

Evidence needs to demonstrate how a requirement is met within the assessment scope. Keep the source requirement, collection context, responsible owner, review decision, and period of applicability together.

A framework-specific collection workflow has not been activated. The reference material on this page can inform scoping and preparation; it does not establish evidence collection or assessment readiness.

ControlFrame availability

Framework reference available

Authority and version facts, with a parsed public catalog when available; no tenant blueprint or executable evidence method is activated.

How availability is determined

PCI Secure Software Standard is tracked in the registry — authority, version ledger, verification — and nothing else is modelled for it yet. Import its catalog to begin.

Catalog status: Planned. Tracked metadata: we record the regime and its issuing authority for review. Registry presence does not mean automated monitoring is active. No control or requirement model is implemented.

Named and tracked only; requirements not modelled as a control catalog.

Follow the source

Editions and transitions.

These are the editions recorded in the library, checked September 6, 2026. Confirm the applicable edition with the authority before beginning an assessment.

v2.0Current edition on record
January 1, 2026

Check the basis

Sources you can follow.

Corroborated through independent sources; direct verification with the authority was unavailable. Source verification was recorded on September 6, 2026.

PCI Security Standards Council — Software Security Framework (opens in a new tab)
Issuing authority and framework publication.
Edition reference: v2.0 (opens in a new tab)
The publication used to establish the recorded edition.

Catalog provenance and record details

Framework record: pci-ssf-secure-software-2-0.

Source artifact: acquisition required.

Parsed catalog: Not ingested.

Control families as published: Secure software lifecycle · Threat and vulnerability management · Sensitive data protection · Software integrity.

Record last updated: September 6, 2026.

Common questions

A closer look.

What is PCI Secure Software Standard?

Who does PCI Secure Software Standard apply to?

PCI Secure Software Standard applies to payments, software vendors, global, per PCI Security Standards Council — Software Security Framework.

What is the current version of PCI Secure Software Standard?

The current edition is v2.0, issued by PCI Security Standards Council — Software Security Framework and published 2026-01-01. Source: https://www.pcisecuritystandards.org/document_library.

What does an assessment under PCI Secure Software Standard require?

No control catalog has been ingested for PCI Secure Software Standard yet — the registry tracks it as planned (Tracked metadata: we record the regime and its issuing authority for review. Registry presence does not mean automated monitoring is active. No control or requirement model is implemented), so an assessment under this framework currently requires the authority's own catalog rather than a ControlFrame-parsed one.

At a glance