PCI Secure SLC - 10 Control Objectives for Assessment

Updated: 3 September 2026

What is PCI Secure SLC, and what exactly gets assessed? PCI Secure Software Lifecycle is one of the two standards forming the PCI Software Security Framework. The object of assessment is not a product but the way an organisation builds and maintains software: security governance, engineering, change control and communication with stakeholders. The assessor is not asking “is this version secure” but “does your process produce secure versions repeatably”.

Canonical definition: PCI Secure SLC is the PCI SSC standard setting requirements for a vendor’s software development and maintenance processes, assessed by a Secure SLC Assessor and evidenced by the organisation’s listing as a Secure SLC Qualified Vendor.

PCI Secure SLC – in brief:

The requirements form 4 security objectives and 10 control objectives. Every control objective must be met, while the vendor chooses the tools and methods used to meet them.
The qualification is organisational, not product-level. It does not replace assessment of a specific product under the PCI Secure Software Standard.
Qualification is valid for 3 years, subject to annual attestation and continued compliance with programme requirements. PCI SSC flags overdue attestations on its public list.
Version 1.1 of the standard, published in February 2021, expanded eligibility beyond payment software vendors to vendors developing software products for the payment card industry.
The main operational benefit: Secure SLC Qualified Vendor status simplifies change handling for listed software, shortening the path for low-impact changes.
PCI SSC has announced the first major revision of the Secure SLC standard as a complement to PCI Secure Software Standard v2.0, published on 15 Jan 2026, which is worth factoring into your schedule.
Patronusec, an accredited QSA, helps vendors prepare their development processes for assessment under our PCI SLC service.

What does a Secure SLC assessor actually examine?

The assessment covers processes, evidence that they are applied, and the people accountable for them, rather than the code of a single product version. The assessor checks whether declared practices operate in reality and whether they leave a trail that can be verified after the fact.

Four security objectives define the scope:

Software Security Governance. A formal software security governance programme reflecting the organisation’s commitment to building secure software and protecting the data and resources that software handles. It requires accountability and resources assigned at leadership level.
Secure Software Engineering. Software is designed and developed to protect critical assets and resist attack. This objective covers threat identification alongside vulnerability detection and mitigation.
Secure Software and Data Management. The confidentiality and integrity of the software and its critical assets are maintained throughout the lifecycle, covering change management, integrity protection and sensitive data protection.
Security Communications. The vendor provides timely information to stakeholders, including customers and those installing the software.

The design is deliberately flexible. Control objectives describe the required outcome, and the vendor selects its own tools, methods and techniques. That is an advantage for organisations with a mature process and a trap for those hoping for a ready-made checklist to tick off.

Secure SLC assesses repeatability, not a one-off state. The evidence is not the procedure itself but the trail showing it was applied across successive releases.

How are the control objectives structured, and where does the work concentrate?

Ten control objectives distribute across the four security objectives. The first seven cover governance, engineering, and software and data management; the remainder address security communications.

Security objective	Control objective	Typical project risk
Software Security Governance	1. Security Responsibility and Resources	accountability assigned on paper without real time or budget
Software Security Governance	2. Software Security Policy and Strategy	policy written for the assessment, diverging from team practice
Secure Software Engineering	3. Threat Identification and Mitigation	threat modelling done once, unconnected to the release cycle
Secure Software Engineering	4. Vulnerability Detection and Mitigation	scanning without a decision process or remediation deadlines
Secure Software and Data Management	5. Change Management	no record of the reasoning behind test scope for a change
Secure Software and Data Management	6. Software Integrity Protection	releases signed without controlled access to key material
Secure Software and Data Management	7. Sensitive Data Protection	live data present in development environments
Security Communications	objectives covering stakeholder communication	no channel for vulnerability reports or update notifications

Preparation effort concentrates on objectives 3, 4 and 5. The reason is the same in all three cases: organisations have these processes but leave no trail in a verifiable form. Threat modelling lives in a slide deck, the decision on a vulnerability’s priority in a chat thread, and change impact analysis in a ticket title with no reasoning attached.

Patronusec Insight: Vendors approaching Secure SLC rarely have a technology problem. They have an evidence problem. The team can describe how release decisions get made but cannot point to them in a system six months later. Our first recommendation in these projects is always the same: before changing anything in the process, walk through your last three releases and establish what could be evidenced today. That exercise usually identifies two or three control objectives needing real work and eliminates several the team assumed were problems. We run that review as part of a gap analysis before the formal project begins.

What does Secure SLC Qualified Vendor status actually get you?

Beyond the public PCI SSC listing, the status delivers a measurable operational benefit in maintaining product certification. A Secure SLC qualified vendor handles changes to listed software through a simpler path than a vendor without the status.

Four benefits that translate into cost and time:

Shorter change handling. Low-impact changes to listed software follow a simpler route, which matters where release cycles are short.
An argument in procurement. A Secure SLC Qualified Vendor listing is publicly verifiable, so it answers part of any vendor security questionnaire on its own.
Scaling across products. The development process is assessed once for the organisation rather than separately for each product, which matters as a portfolio grows.
Process discipline as a side effect. The evidence requirement enforces a discipline engineering teams rarely sustain unaided under deadline pressure.

Keep the proportions right, though. Organisational status does not replace product assessment under the PCI Secure Software Standard where a customer or acquirer requires a specific product to appear on the list. Choosing between the product route and the process route, or running both, is a separate question covered in our asset on PCI SSF certification.

Wondering whether your development process would survive a Secure SLC assessment?

We run a readiness review: checking evidence from your recent releases against the ten control objectives and identifying which need process change and which need only a tidier evidence trail. The output is a prioritised gap list and a realistic schedule.

Book a Secure SLC readiness call

What does the assessment process look like step by step?

The assessment is performed by a Secure SLC Assessor employed by a company qualified by PCI SSC. The output is a report submitted to PCI SSC, after acceptance of which the organisation appears on the Secure SLC Qualified Vendors list.

Readiness review. Internal or run by an independent adviser. It identifies gaps before the formal assessment, while fixing them is still cheap.
Selecting the assessment firm. The vendor picks a company from the PCI SSC list and agrees terms. Fees are not set by PCI SSC; they are negotiated between the parties.
Agreeing scope. The vendor and the assessment firm jointly determine which teams, products and development processes the assessment covers.
The assessment itself. Documentation review, interviews with teams, and verification of evidence from actual releases. The assessor tests whether the process is applied, not how it is described.
Closing gaps. Where the report does not confirm that all control objectives are met, the vendor addresses the gaps and the assessment firm re-verifies them.
Submission and listing. The report goes to PCI SSC. On acceptance, PCI SSC signs and returns the attestation and the organisation appears on the public list.

Step three is routinely underrated and yet determines the effort across the whole project. A scope covering every development team in the organisation looks ambitious; a scope limited to the unit that actually builds software for the payments industry produces the same listing for a fraction of the work.

How do you maintain the qualification once listed?

Qualification runs for three years, subject to annual attestation and continued compliance with programme requirements. Neglecting the attestation is publicly visible, because PCI SSC flags overdue entries on its list and highlights delays exceeding ninety days.

Three maintenance duties that most often slip once the project closes:

Annual attestation. It requires confirming that processes still meet the control objectives, which means maintaining evidence throughout the year rather than reconstructing it before the deadline.
Maintaining compliance through organisational change. Team reorganisation, tooling changes or an acquisition all affect the assessed scope and require analysis.
Tracking programme changes. PCI SSC has announced the first major revision of the Secure SLC standard as a complement to Secure Software Standard v2.0. Organisations holding a current listing should assume it will reach them.

Public visibility of an overdue attestation carries a commercial consequence, not only a formal one. An enterprise customer checking the list sees the delay flag before they get a chance to ask about it.

How do you prepare the development process for assessment?

A checklist from the assessor’s perspective. Each item corresponds to a question actually asked during assessment, and each requires evidence rather than a statement.

Is accountability for software security assigned to a named individual, with allocated time and standing in the organisation?
Does the software security policy match what teams actually do, and can that be demonstrated against recent releases?
Is threat modelling connected to the release cycle, with its output influencing test scope?
For discovered vulnerabilities, is there a documented decision on priority and remediation deadline, rather than only a scanner report?
Is change impact analysis recorded together with the reasoning behind the test scope applied before release?
Are releases signed, with access to key material controlled and logged?
Is sensitive data absent from development and test environments, with the data generation process documented?
Is there a channel for receiving vulnerability reports and a documented method of informing customers about security updates?
Is evidence from these processes available across at least several recent releases, rather than produced for the assessment?

The last item usually decides the outcome. The assessor verifies that the process is applied, so documentation created a month before assessment looks exactly like what it is.

Planning Secure SLC alongside product certification and want to avoid doing the work twice?

We sequence PCI SLC and PCI SSS projects so evidence is produced once. As an accredited QSA we can assess your environment against PCI DSS in parallel where customers require both.

Book a free consultation

What most often delays a Secure SLC assessment?

❌ Writing policies for the assessment instead of describing the existing process – the gap between document and practice surfaces in the first interview.

❌ Setting the scope too wide – covering every development team raises cost with no benefit where only part of the organisation builds software for the payments industry.

❌ Treating scanning as satisfying the vulnerability objective – what is required is a decision process with priorities and deadlines, not a tool report.

❌ No record of test scope decisions for changes – impact analysis conducted in conversation is not evidence.

❌ Deferring evidence tidy-up to the end of the project – evidence has to come from real releases, so the collection clock runs in parallel with preparation.

❌ Forgetting the annual attestation after listing – the overdue flag is publicly visible on the PCI SSC list.

FAQ – PCI Secure SLC

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

Secure SLC assesses an organisation’s software development and maintenance processes; the Secure Software Standard assesses a specific product. Secure SLC qualification is organisational and does not replace a product listing where a customer or acquirer requires product-level validation.

Who is eligible for a Secure SLC assessment?

Version 1.1 of the standard expanded eligibility beyond payment software vendors to vendors developing software products for the payment card industry. Eligibility in any specific case is worth confirming with your chosen assessment firm before work begins.

How long does Secure SLC qualification last?

Three years, subject to annual attestation and continued compliance with programme requirements. PCI SSC flags overdue attestations on its public list, highlighting delays that exceed ninety days.

Does Secure SLC shorten product certification?

Yes, for change handling. A Secure SLC Qualified Vendor handles low-impact changes to listed software through a simpler route than a vendor without the status, which matters where release cycles are short.

Is it worth waiting for the announced revision of the standard?

Usually not. Preparation concerns evidence from real releases and takes time regardless of the standard version. A version change affects how the assessment is conducted; it does not remove the process discipline you have to build either way.

How long does preparation for a Secure SLC assessment take?

It depends on process maturity and evidence availability. An organisation with a disciplined release process typically needs several months to complete its evidence trail. An organisation building the process from scratch should plan longer, because evidence must come from real releases.

How does Patronusec support Secure SLC preparation?

We start by reviewing evidence from recent releases against the ten control objectives and separating gaps into those needing process change and those needing only better record-keeping. We then run the preparation work and coordinate it with your chosen assessment firm.

Blog space

PCI Secure SLC – preparing your development process for assessment across 10 control objectives

In this article you will learn:

Table of Contents