Which PCI standard does a payment software vendor need to meet?
PA-DSS is retired for new listings, so a vendor seeking an active listing validates against the PCI Secure Software Standard and follows the Secure SLC Standard. PCI DSS still applies to the vendor's own environment wherever it stores, processes or transmits account data, and the vendor's developers and hosting systems must be assessed on that basis. Validated applications that were listed before 28 October 2022 now sit on the Acceptable Only for Pre-existing Deployments list, so a customer asking for a currently listed product should check the active Validated Payment Software list rather than rely on an older PA-DSS certificate.
The answer depends on how the product reaches the customer. A licensed application installed in merchant environments, a software-as-a-service offering, an app running on a consumer's own device, and bespoke code written for one client each raise different questions. A SaaS offering can be validated to the Secure Software Standard and listed if it meets the program's eligibility criteria at submission, so the vendor should confirm eligibility with the PCI SSC before committing to a listing timeline. For consumer-device apps, the developer's obligations under Requirement 6 and the device's scope status are separate questions, and the answer turns on whether the developer itself touches account data.
PCI SSC FAQ 1283 recommends the Software Security Framework standards, the Secure Software Standard and Secure SLC Standard, as a baseline for payment software. It also states that PCI DSS does not require validated payment software or a Secure SLC-qualified vendor, and that payment brands may impose their own requirements. Before scoping work, a vendor should ask each payment brand and acquirer customer in writing which program, listing or evidence they expect, and record the answers against the product line they cover.
How the software model changes the validation path
A licensed payment application is software the vendor sells or licenses for customers to install and run in their own environments. Since PA-DSS validated applications moved to the Acceptable Only for Pre-existing Deployments list after 28 October 2022, a vendor that wants an actively listed product must validate against the PCI Secure Software Standard. Validation is a separate track from the vendor's own PCI DSS compliance, and the vendor should ask its assessor which listing and version the product needs before development starts.
- Listing status: Confirm whether the product is on the active list or only on the pre-existing deployments list.
- Standard version: Validate against the Secure Software Standard in effect at submission, not an older PA-DSS version.
- Customer deployments: Document how customers install, configure and update the software, since assessors test those instructions.
- Secure SLC: Plan for the lifecycle standard alongside the product standard, because both are part of the Software Security Framework.
- Vendor ownership: Identify who pays for, submits and maintains the listing when customers deploy new versions.
Confirm with the PCI SSC's current program guidance and your assessor which listing applies to your product today.
A software-as-a-service offering runs in the vendor's infrastructure, so the customer never installs it. PCI SSC FAQ 1549 states that a SaaS offering can be validated to the PCI Secure Software Standard and listed as Validated Payment Software if it meets the program's eligibility criteria at the time of submission. Eligibility is therefore a point-in-time test, and a vendor that changes its architecture or hosting model may need to reassess whether it still qualifies.
- Eligibility at submission: Check the program's eligibility criteria against the exact service and hosting arrangement before submitting.
- Architecture changes: Re-review eligibility when hosting, tenancy or payment flows change.
- Hosting dependencies: Map which cloud services and subprocessors touch account data, since they shape the vendor's own PCI DSS scope.
- Customer responsibilities: Document which controls the customer keeps, such as user access and configuration.
- Operational evidence: Keep records of patching, release and incident handling, which assessors review for SaaS platforms.
Ask the assessor whether the service meets eligibility at submission, and separately confirm how the vendor's own PCI DSS scope is handled for the hosting environment.
A consumer-device app runs on a person's own phone or computer, and the person uses it to enter only their own card data. PCI SSC FAQ 1283 treats the consumer's device like the cardholder's card in that case, so the device itself is out of the organization's PCI DSS scope. The organization still owns the development work, which is in scope and should follow applicable requirements such as Requirement 6.
- Device scope: The consumer's device is not the organization's system component when the app only handles that person's own card data.
- Development scope: Secure coding, review, testing and vulnerability handling for the app remain the vendor's responsibility.
- Data handling: If the developer's servers store, process or transmit account data, PCI DSS applies to that environment.
- Baseline standards: FAQ 1283 recommends the Secure Software Standard and Secure SLC Standard as a baseline, but PCI DSS does not require validation.
- Payment brand rules: Payment brands may impose their own requirements, so check them before launch.
Confirm exactly which data flows through the vendor's back end, because that determines whether any part of the vendor's environment falls under PCI DSS.
Bespoke and custom code is developed by or for an entity rather than sold as a product, and the PCI DSS glossary separates two cases. Bespoke software is developed by a third party for the entity to its specifications. Custom software is developed by the entity for its own use. Requirement 6.2, the bespoke and custom software requirement, does not apply to third-party software, so the scope of that requirement depends on who wrote the code.
- Bespoke software: A third party builds it to the entity's specifications, so the entity must manage the contract, acceptance and security expectations.
- Custom software: The entity builds it for internal use, so Requirement 6.2 governs the entity's development process.
- Third-party components: Commercial and open-source libraries fall under other vendor and inventory duties, not Requirement 6.2.
- Contract terms: Specify security development expectations, vulnerability handling and evidence delivery in the statement of work.
- Ownership of records: Keep development, review and test records in the entity's control, because assessors ask for them.
Review the glossary definitions with your assessor and confirm which party's development process each piece of code falls under.
How Secure Software Standard validation runs
The sequence runs from confirming that a product is eligible, through preparing documentation and evidence inside the vendor, to assessment by a PCI-recognized assessor and a listing decision by the PCI SSC. Each phase produces a defined output that the next phase depends on.
Confirm product scope and eligibility
Start by defining exactly which software is being validated, including its versions, the deployment models it supports (on-premises, hosted, or software-as-a-service) and the payment functions it performs. Check the program's eligibility criteria against that definition. A software-as-a-service offering can be validated to the PCI Secure Software Standard and listed as Validated Payment Software if it meets the program's eligibility criteria at submission, so confirm this early with the PCI SSC program documentation. The output is a written scope statement that names the product, its components, its environments and the eligibility decision. Confirm current program requirements and timelines with the PCI SSC and your assessor before committing budget.
Map payment functions and sensitive assets
Document the payment functions, data flows and components that touch account data or affect its security. Identify the sensitive assets the product handles, such as keys, credentials and cardholder data elements, and record where each is stored, processed and transmitted. Under Secure SLC v2.0, a Sensitive Asset Identification Document is part of the lifecycle evidence, so build the asset inventory now in a form that can be reused. The output is a data-flow and asset map that your team and the assessor can both trace, with each component tied to an owner.
Prepare lifecycle and development evidence
Gather the evidence that your development lifecycle is controlled. This covers secure design and coding practices, code review, dependency and third-party component management, vulnerability handling, release and change records, and the tools used in the lifecycle. Where AI or other digital tools are part of your lifecycle, document their role and controls, since Secure SLC v2.0 adds requirements on digital tools, including AI. The output is an evidence set organized by requirement, with each artifact dated, owned and traceable to a specific release of the product.
Build the internal validation and test record
Run and record the security testing your program depends on, including code analysis, vulnerability scanning, penetration testing and remediation tracking for the product versions in scope. Record what was found, how it was fixed or accepted, and the retest that confirmed the fix. Internal teams or independent testers can perform this work, but the vendor owns the results. The output is a test report set that matches the scope statement and shows that identified issues were resolved or formally risk-accepted before submission.
Close gaps and conduct an internal readiness review
Compare the evidence set against each requirement of the Secure Software Standard and the lifecycle requirements of the Secure SLC Standard. Mark each item as met, partially met or not met, and assign an owner to every gap. Close gaps by fixing processes, updating documents or changing the product, then recheck the affected items. Ask whether a second person outside the delivery team can trace each requirement to evidence without help. The output is a signed readiness record that shows the gaps are closed or documented with a plan the assessor can review.
Assess with a PCI-recognized assessor
Engage an assessor recognized by the PCI SSC for the Secure Software and Secure SLC programs. The assessor examines your documentation, interviews the people who run the lifecycle, reviews code and test records and tests the product against the standard. The assessor decides whether each requirement is met and writes the assessment report. Your team answers questions and supplies missing evidence during this phase. The output is the assessor's report and a validation result that the vendor can review before submission. Confirm the assessor's qualifications and current program rules with the PCI SSC before engaging.
Submit for listing and maintain the validated status
Submit the assessor's report and the required program forms to the PCI SSC for review. The PCI SSC makes the listing decision, and a validated product appears on the program's public list only after that decision. Validation covers a specific product version, so plan for how changes, new releases and the Secure SLC transition from v1.1 to v2.0 will be handled. Confirm with the PCI SSC how the transition timeline applies to your product. The output is either a published listing or a documented set of review comments that must be resolved before resubmission.
What Secure SLC v2.0 changes for vendor lifecycles
The most important change in the Secure Software Lifecycle (Secure SLC) Standard v2.0 is that it is the first major revision of the standard, released by the PCI Security Standards Council on 28 September 2026. It is aligned with v2.0 of the Secure Software Standard, which was published earlier in 2026, so a vendor should read the two together rather than treat the lifecycle process as a separate exercise. The revision adds a Sensitive Asset Identification Document, which asks the vendor to record the assets that matter to payment software security, such as keys, account data handling components, signing infrastructure and build pipelines, before it designs or changes controls around them. Vendors should start this inventory now, because the assessor will expect to see that the list drives the lifecycle activities.
The revision also adds requirements on the digital tools used inside the vendor's lifecycle, including AI tools. In practice, this means listing the development, testing, code review and build tools your teams use, recording what each can access, and setting rules for how their output is reviewed before it reaches production. Ask your team which AI coding assistants, automated test generators or dependency tools are in use today, and whether any of them can see source code, secrets or customer data. Those answers will shape the tool inventory and access controls an assessor asks about.
The transition timing needs careful planning. The PCI SSC says a 12-month transition from Secure SLC v1.1 to v2.0 starts once assessor training is available, which it expected in the fourth quarter of 2026. Because the start date depends on that training, vendors should confirm the exact date with the PCI SSC before setting internal deadlines, and should ask their assessor which version they will validate against for any assessment scheduled during the transition. A vendor that plans its gap analysis and document updates around the confirmed date avoids running two lifecycle programs at the same time.
How Requirement 6 applies to bespoke and custom code
Requirement 6 turns on who wrote the code and for whom. The PCI SSC glossary separates bespoke software built by a third party from custom software an entity builds for itself, and that split decides which secure development duties sit with a payment software vendor and which sit with its customers.
Bespoke software defined
The PCI SSC glossary defines bespoke software as software a third party develops for the entity to that entity's specifications. A vendor that builds a payment application to a customer's written requirements is producing bespoke code for that customer. Check the statement of work and specifications to confirm which party set the requirements, because that record determines how the code is classified and who answers for it during assessment.
Custom software defined
Custom software, as the glossary defines it, is software an entity develops for its own use. If a merchant or service provider builds its own payment logic in-house, that code is custom and sits inside the entity's own development process. Vendors should confirm whether a customer's internal team extends their product, since code changes made by the customer are custom to that customer even when the base product came from a vendor.
What Requirement 6.2 covers
Requirement 6.2 concerns bespoke and custom software and asks entities to develop it securely, using defined practices throughout the software lifecycle. Assessors look for documented development processes, secure coding practices, and review of code before release. Ask the development team to show how each custom release was reviewed, tested and approved before it reached the cardholder data environment.
Why 6.2 excludes third-party software
Requirement 6.2 does not apply to third-party software, which means commercial products the entity buys and does not write. A merchant that licenses a payment application is not expected to show secure coding for that application's source code under 6.2. Responsibility for that product's security then shifts to vendor assurance, patching and configuration, which the entity must still manage under other requirements.
Allocating duties in developer contracts
A contract with an external developer should state who performs secure development, code review, vulnerability testing and patching for bespoke work, and who keeps the evidence. Illustrative example: a customer pays a developer to build a checkout module, and the contract assigns code review and retention of test records to the developer while the customer keeps approval of releases. Confirm these allocations in writing before work starts.
When a vendor's environment is in scope
Where a developer stores, processes or transmits account data in its own environment, PCI DSS applies to that environment. Build servers, code repositories holding card data, test systems using live account data and support tools with access to production all fall into this category. Ask which of these systems touch account data, and bring them into the scope review before the assessment begins.
Choosing a validation or assurance route
This table compares four routes a payment software vendor can take: listed validation, SaaS validation, Secure SLC qualification and internal adoption without validation. Read each row for when the route fits and, just as important, what it does not prove to a customer or assessor.
| Route | When it fits | What it does not prove |
|---|---|---|
| Secure Software Standard validation for a listed product | You ship a payment application as installed software and want it on the Validated Payment Software list. Confirm the current eligibility rules with your assessor before you start. | It does not prove that your development organization runs a secure lifecycle, and it does not make your customers PCI DSS compliant. Their own assessments still apply. |
| SaaS validation under the Secure Software Standard | You deliver the payment software as a hosted service and meet the program's eligibility criteria at submission (PCI SSC FAQ 1549). Confirm eligibility with the PCI SSC before committing effort. | It does not cover customer-side configuration or the merchant's own environment. Your hosting and operating controls still need evidence for your customers' assessors. |
| Secure SLC qualification | You want to show that your software development lifecycle is managed securely. Check the transition timing for Secure SLC v2.0 in the PCI SSC announcement before you plan the work. | It does not validate a specific product. A qualified vendor can still ship software that fails the Secure Software Standard. |
| Internal adoption without validation | You have no listing requirement yet, or a payment brand or customer accepts a documented baseline. Use the Software Security Framework standards as your internal reference, as PCI SSC FAQ 1283 recommends. | It does not satisfy a payment brand or customer that requires validation. Ask each contract counterparty in writing which route it accepts. |
| Requirement 6 for bespoke and custom code | Your own customers or internal teams run custom payment code, or you deliver bespoke software to a payment entity. Requirement 6 applies to the code that the assessed entity develops. | It does not replace software validation. Requirement 6.2 does not apply to third-party software, so the assessed entity still needs its own evidence for vendor-supplied code. |
| Payment brand or customer requirements | A contract, payment brand program or acquirer requires a specific validation or qualification. The brand decides which entities must comply and validate (PCI SSC FAQ 1004). | PCI DSS itself does not require validated payment software or a Secure SLC-qualified vendor (PCI SSC FAQ 1283). Brand rules can still require them, so confirm them before you choose a route. |
What a vendor should have ready before an assessment
An assessor will start by asking what the software is, what it touches and how it is built and maintained. The cards below cover the records a vendor should hold before engaging an assessor, and each one can be checked internally before any fee is agreed.
Current product and component inventory
List every product version in market, every module, library and third-party component each version ships with, and the hosting model for any SaaS offering. Check that the list matches what is actually deployed and that each component has an owner and a version history. Assessors compare the inventory against the software under review, so gaps here usually delay the engagement more than any technical finding.
Sensitive asset identification record
Write down which assets hold or can affect account data or sensitive authentication data, including keys, tokens, logs, test data and build secrets. The Sensitive Asset Identification Document is the record the updated lifecycle standard asks for, so it should be drafted now. Check that each asset has a defined data flow and a named owner who can confirm it.
Secure development and lifecycle documentation
Hold written procedures for design review, secure coding, code review, security testing and release approval, plus the training records that show staff follow them. Check that the documents describe what engineers actually do, by sampling two or three recent releases and tracing each step back to a record. Documents that describe an idealized process are a common reason assessors raise findings.
Vulnerability handling evidence
Keep a register of reported and discovered vulnerabilities with severity, remediation dates, fix versions and customer notifications. Check that the register shows closed items as well as open ones, and that patch timelines are applied consistently across releases. Assessors look for proof that the process runs over time, so a short register with complete history is more useful than a long document.
Control of digital tools and AI
List every tool used in the lifecycle, including code assistants, AI review bots, build systems and test generators. For each one, record who approved it, what data it can access, whether its outputs are reviewed, and how access is removed when it is no longer used. The lifecycle standard now addresses these tools, so vendors should confirm the list is complete before the assessor asks.
Account data ownership map
Document who holds account data in each deployment model, including customer-hosted installs, vendor-hosted SaaS, support engineers' laptops and log stores. Confirm which party is responsible for each control on that map, and put the answer in writing. Vague ownership between the vendor and its customers is one of the most frequent causes of scope disputes during assessments.
Who does what: vendor, implementation partner and assessor
The software vendor owns its product, its secure software development lifecycle and the controls that govern both. Those controls cover how requirements are set, how code is written and reviewed, how vulnerabilities are handled, how releases are approved and how customers receive updates. The vendor's own staff make the design decisions, maintain the lifecycle records and answer the assessor's questions about the product.
- Product and lifecycle ownership: Defining the software, its payment functions and the sensitive assets it handles.
- Development controls: Secure coding practices, code review, dependency management and build integrity.
- Vulnerability and release management: Triage, fixes, security testing results and documented release approvals.
- Customer-facing duties: Secure implementation guidance, updates and vulnerability disclosure to customers.
- Evidence ownership: Keeping lifecycle records current so they reflect how the product is actually built.
Before engaging anyone, confirm which Secure Software Standard and Secure SLC Standard version applies to your product and which of your existing lifecycle records the assessor will sample.
An implementation partner such as DeployOpen can help prepare the systems, documentation and evidence the vendor's assessment will examine. Under a written, fixed scope, a partner may build or harden the vendor's build and test infrastructure, set up logging and repository controls, draft procedure documents for the vendor to approve, and run security testing of the application. The partner works for the vendor and does not take over the vendor's controls.
- Environment preparation: Hardening build pipelines, repositories and test environments that the vendor operates in its own infrastructure.
- Documentation support: Drafting lifecycle procedures and evidence templates that the vendor's staff review and adopt.
- Security testing: Application and API testing, and code-level review, reported back to the vendor for remediation.
- Evidence collection: Organizing records so the vendor can show the assessor how controls operated.
- Limits: DeployOpen does not issue reports, attestations, listings or certificates, and it does not act as the assessor.
Ask any partner to put its deliverables, the systems it will touch and the handover of responsibility in writing before work starts.
Only an independent assessor recognized by the PCI Security Standards Council can evaluate the software and issue the validation outcome. The assessor tests the vendor's controls against the applicable standard, examines samples of lifecycle evidence, and documents its findings in the reporting templates the Council specifies. The assessor must remain independent of the work that helped the vendor prepare, so the preparation partner cannot also be the assessor.
- Independent testing: The assessor selects evidence and tests controls itself rather than accepting the vendor's summaries.
- Reporting: Findings are recorded in the required templates and the validation outcome is issued by the assessor.
- Independence: The assessor should not design or implement the controls it evaluates.
- Listing decisions: Confirm with the Council and the assessor how a validated product is listed and whether a SaaS offering meets eligibility at submission.
- Scope questions: Agree early on what counts as the product and what the vendor's own environment includes.
Before you sign, ask the assessor which assessor program it works under, what evidence it expects and how it treats work performed by outside preparation partners.
A clear responsibility matrix prevents the most common misunderstanding in software validation: assuming that someone else holds a control. Each lifecycle requirement should name one accountable owner inside the vendor, one party that performs the work and one party that checks it. The matrix should show the vendor as owner of every product decision and the assessor as the only issuer of validation outcomes.
- Named owners: One accountable person in the vendor for each control area.
- Performer and reviewer: Who does the work and who checks it, including any partner.
- Evidence trail: Where each record is kept, who approves it and how long it is retained.
- Change control: How partner-made changes to build systems are approved and recorded by the vendor.
- Gaps: Items no one has claimed, which must be resolved before the assessment begins.
Review the matrix with your assessor before fieldwork, and confirm that every control has a vendor owner.
Common mistakes that delay software validation
Most delays in payment software validation come from a few planning errors made early, before any assessor is engaged. Each mistake below looks minor at the start but changes which standard applies, what evidence exists, or who must sign off on the result.
Relying on PA-DSS listings for new releases
PA-DSS validated applications moved to the Acceptable Only for Pre-existing Deployments list after 28 October 2022, so an older listing does not cover a new release. Vendors that want an active listing must validate against the PCI Secure Software Standard instead. Before planning a release, confirm your current listing status with the PCI SSC and map which products, versions and deployments the listing actually covers. Treat any gap as a validation project with its own schedule, not a formality.
Treating SaaS as out of scope
Many vendors assume a hosted product falls outside software validation because the customer never installs it. A software-as-a-service offering can be validated to the PCI Secure Software Standard and listed as Validated Payment Software, but only if it meets the program's eligibility criteria at submission. Check those criteria against your architecture, hosting model and release process before you commit to a timeline, and ask your assessor to confirm eligibility in writing.
Missing consumer-device scope boundaries
Software that runs on a consumer's own device and takes only that person's card data can leave the cardholder's device outside your PCI DSS scope. Your development work still falls in scope, and Requirement 6 still applies to how you build the software. If your application stores, processes or transmits account data on your own systems, your environment is in scope in full. Document where the device boundary sits, which data flows cross it, and which systems you control on each side.
Weak evidence for custom code
Assessors test Requirement 6 against the code you write, so the glossary distinction matters. Bespoke software is built by a third party to your specifications, and Requirement 6.2 does not apply to third-party software. Custom software is built by your own team for your own use, and it needs evidence of secure development practice. Keep records of code reviews, testing, change approvals and vulnerability fixes for each release, and be ready to show which code belongs to which category.
Ignoring payment brand requirements
The PCI SSC recommends the Software Security Framework standards as a baseline for payment software, but it does not require validated payment software or a Secure SLC-qualified vendor. Payment brands can set their own requirements, and the brands decide which entities must comply and how enforcement works. Ask each acquirer, processor and payment brand you sell through which validation they accept and whether they require it, before you set your release date.
Starting Secure SLC without a transition plan
Version 2.0 of the Secure Software Lifecycle Standard was released on 28 September 2026 and adds a Sensitive Asset Identification Document along with requirements for digital tools, including AI, used in your lifecycle. The PCI SSC says a 12-month transition from v1.1 starts once assessor training is available. Inventory the AI and automation tools in your development pipeline now, and confirm with your assessor when v2.0 will apply to your qualification.
Frequently asked questions about payment software PCI standards
Does PA-DSS still count for payment software validation?
No, PA-DSS no longer gives a vendor an active listing. Validated PA-DSS applications moved to the Acceptable Only for Pre-existing Deployments list after 28 October 2022, which means existing customers may keep deploying them but new validations are not issued. A vendor that wants active listing must validate against the PCI Secure Software Standard instead. Check the current status of any existing PA-DSS listing in the PCI SSC list, and confirm with your acquirer or payment brands whether they still accept a legacy listing for your customers' deployments. Plan the move to the Secure Software Standard as a product project, since it changes how the software is designed, tested and documented.
PCI SSC FAQ 1547 explains the transition in detail.
Can a SaaS product be validated under the Secure Software Standard?
Yes, a software-as-a-service offering can be validated to the PCI Secure Software Standard and listed as Validated Payment Software, provided it meets the program's eligibility criteria at the time of submission. The criteria decide whether the offering can be assessed in the way the program describes, so read them before scoping the work. Ask the assessor how the hosted components, tenant separation, update process and customer-facing configuration will be evidenced. Hosting the product in your own cloud accounts or a customer's environment does not by itself change the validation question, but it does change which systems sit in the payment flow and which PCI DSS requirements your customers rely on you to meet.
The detailed eligibility rules are in PCI SSC FAQ 1549.
Is Secure SLC certification mandatory for payment software vendors?
No, PCI DSS does not require a payment software vendor to hold validated payment software or a Secure SLC-qualified vendor status. The PCI SSC recommends the Software Security Framework, made up of the Secure Software Standard and the Secure SLC Standard, as the baseline for payment software. Payment brands and acquirers may still set their own requirements, so confirm with the organizations that buy or host your software whether they expect validation or qualification. The PCI SSC released Secure SLC v2.0 on 28 September 2026, and it describes a 12-month transition from v1.1 that starts once assessor training is available, which it expected in the fourth quarter of 2026. Build your lifecycle controls to the version your assessor will use and confirm the transition dates with them.
What does PCI DSS Requirement 6 ask for custom and bespoke code?
Requirement 6 asks the entity to develop and maintain secure systems and software, which for code you write means a documented secure development process, secure coding practices, code review, and controls over changes and vulnerabilities. Two terms set the boundary. Bespoke software is built by a third party to your specifications, while custom software is built by your organization for its own use. Requirement 6.2 covers bespoke and custom software, and it does not apply to third-party software you simply install. Assessors usually look for evidence such as a secure development procedure, training records, peer review or code analysis results, and a record of how vulnerabilities in your own code are fixed. Confirm the exact sub-requirements and testing procedures against the current standard with your QSA, since they change the evidence you need.
How long does validation take, and what drives the effort?
The duration depends on the product's architecture, how mature its development lifecycle already is, and how much evidence exists in a form an assessor can review. No fixed duration applies to every product, so ask your assessor and any implementation partner for a timeline built from a written scope. The main drivers are the number of components and deployment models in scope, whether the product is validated as a SaaS offering or as a deployable package, the state of secure coding and testing records, how many release cycles must be shown as evidence, and how quickly the vendor can resolve findings. Expect the work to recur, because each significant release and the lifecycle change to Secure SLC v2.0 bring new evidence to produce.
Can an implementation partner do the validation work for us?
A partner can help you prepare, but it cannot validate your software. Your organization owns its product and its lifecycle controls. An implementation partner such as DeployOpen can help plan the scope, build or harden the development pipeline, produce and organize evidence, and support testing, all under a fixed-scope written agreement. Only an independent assessor recognized by the PCI SSC for the relevant program reviews the evidence and issues the validation result. Keep the roles separate in your contracts and in your records, so the assessor can test your controls without relying on the partner's conclusions. Ask any provider to state in writing what it will deliver and what remains with your team.
How DeployOpen prepares payment software for assessment
DeployOpen works with payment software vendors on the parts of the build that the Secure Software Standard and Secure SLC Standard ask for, and that PCI DSS Requirement 6 touches for bespoke and custom code. The work is fixed-scope and written in advance, and DeployOpen prepares systems, controls and evidence for an independent assessor, who alone issues any validation.
How we scope
- Agree in writing which products, components and hosted environments fall under the Secure Software Standard or Secure SLC Standard
- Confirm whether each product is a SaaS offering, a consumer-device app or a software package, since eligibility differs
- Identify which custom code falls under Requirement 6 and which third-party bespoke software does not
How we build
- Set up the secure development lifecycle tooling, code review gates and vulnerability tracking inside your own infrastructure
- Implement sensitive asset identification and inventory records that the Secure SLC Standard expects vendors to keep
- Test applications and APIs, then document findings and remediation so each control has traceable evidence
How we hand over
- Deliver written procedures, configuration records and evidence packs mapped to each requirement in scope
- Hand over source of administration, runbooks and access records so your team can run the lifecycle without us
- Provide a readiness summary that your independent assessor can review, while the assessment itself stays with the assessor
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after the fixed-scope work closes
- Review how digital tools, including AI tools, enter your lifecycle and update records as the standard changes
- Ask your team to confirm the current transition timing for Secure SLC v2.0 with your assessor before planning work
