What’s the difference between PCI Secure Software Standard (SSS) and Secure SLC?
The PCI Secure Software Standard (SSS) validates individual payment software products. Specifically, it ensures each product protects sensitive assets like account data. However, the PCI Secure Software Lifecycle (Secure SLC) Standard takes a different angle. Instead of assessing products, it assesses vendors, meaning the processes and practices they use across every product they build.
Moreover, the two tracks are independent. For example, you can submit a product for SSS validation without SLC qualification. In the same way, you can achieve SLC qualification without a validated product. As a result, most vendors pursue both over time to maximise operational flexibility.
What changes to a validated SSS product require a full reassessment?
Not every modification triggers a full reassessment. Specifically, PCI SSC sorts changes into three categories, each with different compliance implications:
- Administrative Changes: updates to vendor or product names with no software change, which you simply notify PCI SSC about
- Tier 1 Delta Changes: non-security updates that require a version change. Importantly, Secure SLC-qualified vendors can also treat security-impacting bug fixes as Tier 1, which accelerates patch cycles
- Tier 2 Delta Changes: security fixes for non-SLC vendors, new sensitive assets, or unassessed modules, all of which require assessor review before relisting
In addition, wildcards in the versioning schema let you handle minor non-security changes without reporting to PCI SSC at all.
How long are SSS and Secure SLC listings valid?
Listings last three years from the date of PCI SSC acceptance. However, maintenance is not a single end-of-cycle event. Instead, vendors must submit an Annual Attestation at the 12-month and 24-month marks to confirm ongoing compliance and proper change handling.
Miss an Annual Attestation, and the listing enters Administrative Expiry, where PCI SSC may remove it. Therefore, renewal at the three-year mark requires a full reassessment to stay listed. In practice, mature vendors start the reassessment 6 to 9 months before expiry to leave room for remediation.
Can Secure Software controls be marked Not Applicable (N/A)?
Yes, if the control genuinely does not apply to your software or practices. For example, a control covering clear-text account data does not apply when your software never processes such data. In the same way, cryptographic key storage controls do not apply when you fully delegate cryptographic operations to a Hardware Security Module (HSM).
However, N/A is not a shortcut. Specifically, the assessor must verify non-applicability through adequate testing, and the Report on Compliance (ROC) or Report on Validation (ROV) must document the justification with supporting evidence. As a result, rubber-stamping an N/A creates findings during PCI SSC quality assurance review.
What if technical constraints prevent meeting a Secure Software requirement?
First, you must document the constraint thoroughly in the ROV and justify why redesign is not feasible. In addition, you must implement additional mitigations that reduce the residual risk to a reasonable level. If those mitigations rely on user configuration, you must also provide clear guidance so deploying parties apply them in production. Finally, the assessor must be able to verify that the mitigations meet the intent of the original control.
However, if the risk cannot be mitigated to a reasonable degree, the control stays Not In Place. Importantly, this technical constraint process is not the same as a PCI DSS-style Compensating Control, even though the concepts feel similar. In fact, assessors treat the two very differently during review.
