PCI Secure SLC-compliant development process

What is a PCI Secure SLC-compliant development process? It is a documented and maintained software development lifecycle in which security is built in from the outset and sustained throughout the product’s life, validated against the PCI Secure Software Lifecycle Standard v1.1. The standard assesses not a single application but how a vendor designs, develops, updates and retires software.

Canonical definition: PCI Secure Software Lifecycle (Secure SLC) is a PCI Software Security Framework standard validating a software vendor’s development process – its secure lifecycle, vulnerability and change management practices – rather than a specific product.

The current standard version is v1.1 (18 Feb 2021). This article explains how to build a process that meets its four objective areas and what distinguishes it from validating a single piece of software.

PCI Secure SLC development process – key takeaways:

PCI Secure SLC is one of the two PCI SSF standards; the other is the Secure Software Standard, which validates a specific product.
The current version is v1.1 (18 Feb 2021), which expanded programme eligibility beyond payment software vendors to vendors of software for the payment card industry.
The standard organises its requirements around four objective areas: software security governance, secure software engineering, secure software and data management, and security communications.
The approach is objective-based and methodology-agnostic – it works with Agile, CI/CD and DevSecOps, assessing security outcomes rather than rigid phases.
A Secure SLC validation is valid for three years, provided an annual attestation confirms the practices have not degraded and remain in continuous operation.
Patronusec, an accredited QSA, supports software vendors in building and validating a Secure SLC process – from gap analysis to assessment readiness.

What is PCI Secure SLC and how does it differ from the Secure Software Standard?

PCI Secure SLC validates a software vendor’s development process, not a single product. It is the first PCI standard focused not on the application but on how it is built: the secure lifecycle practices that keep software secure even under frequent updates and evolving threats.

The PCI SSF (Software Security Framework) replaced the former PA-DSS and comprises two complementary standards:

Secure Software Standard (SSS) – validates a specific product: whether a given piece of software is secure. The result is the product’s entry on the Validated Payment Software list.
Secure Software Lifecycle (Secure SLC) – validates the vendor’s process: whether the way software is built is secure. The result is Secure SLC Qualified Vendor status.

Version 1.1 of the standard (18 Feb 2021) expanded programme eligibility: beyond payment software vendors, it covered vendors of software and components for the payment card industry that may share resources within a payment environment. This broadened the pool of organisations able to use Secure SLC Qualified Vendor status.

Secure SLC answers a different question from the Secure Software Standard: not “is this product secure”, but “does the process you build it with guarantee the security of tomorrow’s versions too”.

Which four objective areas does the standard cover?

The standard organises its requirements around four security objective areas that together cover the whole software lifecycle: from culture and governance, through engineering, to data management and communication. Each area contains control objectives with assigned assessment procedures.

The four objective areas, per PCI SSC documentation:

Software Security Governance. A formal governance programme reflecting the vendor’s commitment to building secure software and protecting sensitive data. It covers policies, security strategy, leadership accountability and a security culture.
Secure Software Engineering. Threat identification and risk management built into the development lifecycle: threat modelling, secure coding, vulnerability reduction. This is the “how we design and write” layer.
Secure Software and Data Management. Managing change, releases, configuration and data across the software lifecycle, including protecting the sensitive data the software processes.
Security Communications. How the vendor communicates security matters: reporting and handling vulnerabilities, informing about updates, providing security guidance to customers and integrators.

The foundation binding all areas is robust risk management as part of the business routine. The standard requires the vendor to adapt its software security controls in response to newly identified threats – not a one-off checklist but a living process.

The four Secure SLC areas form an arc: governance sets “why and who”, engineering “how we build”, management “how we maintain”, and communications “how we respond and inform” – together a closed cycle, not a task list.

How to build a process meeting the governance and engineering objectives?

Governance and engineering are the process’s first two pillars: governance establishes the framework, accountability and policy, and engineering builds security into design and coding. Without working governance, engineering controls remain local team practices rather than an organisational process.

The governance elements the standard expects:

A formal programme and policy for software security, approved by leadership and genuinely enforced, not merely documented.
Assigned accountability – clear roles for security in the development lifecycle, with the authority to enforce decisions.
Risk management as a routine – regular identification and assessment of software threats and adaptation of controls.

The engineering elements to build into the lifecycle:

Threat modelling at the design stage – before code exists, the team understands what it protects and against what.
Secure coding – coding standards, reviews, static and dynamic analysis tools woven into the pipeline.
Vulnerability reduction – security testing and vulnerability triage as part of development, not an after-the-fact task.

The fix: a Secure SLC process is not about buying a tool but about binding policy, roles and engineering practices into a coherent, enforceable system. The standard’s objective-based character gives freedom here – the vendor chooses practices fitting its own SDLC, as long as they genuinely meet the security objective.

Patronusec Insight: In our project experience, organisations with mature DevSecOps often have most engineering controls in place but fall short on governance. Static analysis, code reviews and security testing work within teams, but a formal programme, assigned accountability and evidence that risk management is a routine rather than a one-off are missing. The Secure SLC standard assesses the process as a whole – the most common gap is not a lack of practices but the lack of governance binding them together. It is worth starting preparation with precisely that layer.

How to meet the software management and communications objectives?

Secure software and data management and security communications are the two maintenance pillars: the first covers security across the change and release cycle, the second covers vulnerability handling and informing recipients. Together they answer the standard’s key question: will security survive updates.

Secure software and data management covers:

Change and release management – a controlled process for introducing changes so that an update does not weaken security; this is the area where most compromises stem from uncontrolled changes.
Configuration management – the consistency and integrity of versions, artefacts and dependencies.
Protection of sensitive data the software processes across the lifecycle.

Security communications covers:

Vulnerability handling – a reporting channel, a triage process, patch issuance and distribution; the standard explicitly flags maintaining security under updates as critical, because it is a frequent cause of compromise.
Informing about updates – clear, accessible and accurate messaging about changes to the software’s recipients.
Guidance for customers and integrators – conveying the information needed to deploy and use the software securely.

The standard stresses that patches are a critical security control – and the ability to issue and distribute fixes securely and on time is a test of the whole process’s maturity. A vendor that can respond quickly to a vulnerability without breaking security in other areas meets the essence of Secure SLC.

The Secure SLC maintenance pillars check what validating a single product cannot see: whether the vendor can ship the hundredth update as securely as the first version.

What does validation and Secure SLC Qualified Vendor status look like?

Secure SLC validation confirms that a vendor’s development process meets the standard’s four objective areas and confers Secure SLC Qualified Vendor status. The status is valid for three years, provided an annual attestation confirms the practices have not degraded and remain in continuous operation.

The elements of the validation process:

Assessment by a qualified Secure SLC assessor – examining evidence, observing and verifying that the process genuinely meets the objectives across the four areas.
Secure SLC Qualified Vendor status – confirmation that the development lifecycle has been validated for strong security practices; it gives recipients assurance that the software is produced to an industry standard.
Three-year validity with annual attestation – the vendor annually confirms continuity of practices; process degradation can undermine the status’s validity.

The practical benefit of the status extends beyond compliance itself. A Secure SLC Qualified Vendor can use a streamlined path for changes to software validated under the Secure Software Standard – a mature, validated process speeds up product change handling. This makes Secure SLC not only a quality confirmation but also an operational lever.

Patronusec guides software vendors through this process within its PCI SLC service – from a gap analysis across the four areas, through remediation, to assessment readiness and status maintenance.

FAQ – PCI Secure SLC-Compliant Development Process

How does PCI Secure SLC differ from the Secure Software Standard?

Secure SLC validates a vendor’s development process – its secure lifecycle practices. The Secure Software Standard validates a specific product – its security and integrity. They are two separate, complementary PCI SSF standards. A vendor may validate the process (Secure SLC), the product (SSS) or both.

What is the current version of the Secure SLC standard?

The current version is v1.1, published 18 Feb 2021, which expanded programme eligibility beyond payment software vendors. Work on a next version is under way as part of the SSF framework’s evolution, but v1.1 remains the version in force for validating the development process.

Does Secure SLC work with Agile and DevOps?

Yes. The standard is objective-based and methodology-agnostic – it assesses security outcomes rather than rigid development phases. This makes it naturally adaptable to Agile, CI/CD and DevSecOps. The vendor chooses practices fitting its own pipeline, as long as they genuinely meet the objectives of the standard’s four areas.

How long is a Secure SLC validation valid?

The validation is valid for three years, provided an annual attestation in which the vendor confirms its secure lifecycle practices have not degraded and remain in continuous operation. Process degradation between attestations can undermine the validity of Secure SLC Qualified Vendor status.

Who can obtain Secure SLC Qualified Vendor status?

Software vendors wanting to validate their development lifecycle for strong security practices. Since v1.1, eligibility covers not only payment software vendors but also vendors of software and components for the payment card industry that may share resources within a payment environment.

How does Patronusec help build a Secure SLC process?

We start with a gap analysis across the standard’s four objective areas, with particular attention to governance – the most common gap for mature teams. We then support remediation, documentation and assessment readiness. After a free scope-assessment call we present a fixed-price quote covering the full scope of support.

Blog space

A PCI Secure SLC-Compliant Development Process – How to Build a Secure Software Lifecycle

In this article you will learn:

Table of Contents