What Compliance Directors Ask Payment Software Vendors About PCI SSF

Why PCI SSF security assurance questions decide payment software deals

PCI SSF questions decide deals because buyers’ own obligations flow down to you. Their PCI DSS assessors, card scheme relationships and resilience obligations all turn on evidence that deployed payment software was built and tested securely, so the questionnaire lands before the contract.

If you sell payment software into UK banks, acquirers, PSPs or fintechs, PCI SSF security assurance is now the questionnaire section that stalls deals. The PCI Software Security Framework, published by the PCI Security Standards Council, replaced the old PA-DSS programme, and buyers have rewritten their vendor due diligence around it.

At EJN Labs, a UK-based CREST-accredited penetration testing firm, we increasingly test payment applications because a prospect’s compliance director asked a question the vendor could not answer with evidence. This post covers the most common questions, what a credible answer looks like, and where testing fits.

What PCI SSF actually asks of a software vendor

PCI SSF asks vendors for secure software validation and testing evidence: proof that the software has been built and verified to resist attack, assessed by a qualified SSF assessor. It contains no clause demanding an annual penetration test, and no UK statute requires the framework at all.

Its force is contractual. Card brands, acquirers and merchant buyers often insist on validated payment software, and the PCI SSC publishes a list of validated products that procurement teams check, which is why compliance directors verify both points before a deal progresses.

The framework has two pillars:

• The Secure Software Standard, which assesses a specific payment software product: how it protects account data, authenticates users, manages sensitive functions and resists common attack classes.
• The Secure Software Lifecycle (Secure SLC) Standard, which assesses the vendor’s development practice: threat modelling, secure coding, security testing, vulnerability handling and update integrity across the whole lifecycle.

Both pillars expect security testing to be evidenced. That is where independent penetration testing earns its place: it is the cleanest artefact a vendor can hand over to prove the testing pillar is real.

The questions compliance directors actually ask

Across financial services buyers, due diligence questions cluster into five themes. Answer all five with documents rather than sentences and your sales cycle shortens.

Question	What they are really probing	Evidence that satisfies them
Is your product SSF validated, or on a path to validation?	Whether deploying you creates a gap in their own PCI DSS position	PCI SSC listing entry, or an assessor engagement letter and timeline
When was the software last penetration tested, and by whom?	Independence and recency of technical assurance	A report from a CREST-accredited firm, less than 12 months old
How do you handle vulnerabilities found after release?	Secure SLC maturity: triage, patch SLAs, disclosure	A published vulnerability management policy with defined remediation timescales
What was in scope of your last test?	Whether the test covered the parts they will actually use: APIs, admin planes, integrations	Scope statement listing APIs, web components, mobile SDKs and hosting
Can we see the retest evidence?	Whether findings were fixed or just filed	A retest letter confirming closure of high and critical findings

Three of the five questions are answered by a well-scoped penetration test with a retest. Validation status and policy documents matter, but the pen test report is the artefact buyers read first.

What to test in a payment software estate

Payment software rarely means one application. When we scope these engagements, we map the estate the buyer will actually touch. A typical scope includes:

• Payment and merchant-facing APIs: authentication, authorisation, rate limiting, and how tokens and account data move between services. Our API penetration testing service is usually the core of the engagement.
• Web components: merchant dashboards, admin consoles and back-office portals, where access control flaws concentrate.
• Mobile SDKs or apps, where local storage of secrets and certificate pinning failures are the recurring findings, covered by mobile application penetration testing.
• The hosting layer, assessed through cloud penetration testing: IAM configuration, secrets management and segmentation of cardholder-adjacent workloads.
• The external perimeter, where the software is delivered as a service.

One first-hand detail from our scoping calls: the gap we find most often in payment products is not the payment flow itself, which teams defend well, but the supporting surfaces around it, such as webhook receivers, reporting exports and partner integration endpoints. These handle the same sensitive data with a fraction of the scrutiny, so we include them in scope by default.

How a vendor assurance engagement runs

A vendor assurance engagement runs in five stages: scoping, testing, reporting, retest and attestation. A short scoping call maps the application, APIs and environments, from which days and price are fixed, and testing happens in staging or pre-production against the current release candidate.

Testing against the release candidate means findings map to the version your buyers will run. Reporting gives each finding severity, evidence and remediation guidance, a retest of high and critical findings produces the closure evidence buyers ask for, and an attestation letter lets you answer due diligence without circulating the full technical report.

Vendors preparing for a formal SSF assessment often align the test window with their assessor’s timetable, so the evidence is fresh at validation. If you are earlier in the journey, our penetration testing checklist sets out what to prepare first.

What it costs and how scope drives the price

Penetration testing for payment software is priced by effort, and effort follows scope: API endpoints, user roles, integrations and environments. UK day rates for CREST-accredited testing typically run £1,100 to £1,400, never a flat fee. Typical ranges we see:

Engagement shape	Typical effort	Typical UK cost
Core payment API plus merchant web portal	4 to 6 days	£4,400 to £8,400
API, web, plus mobile SDK or app	6 to 9 days	£6,600 to £12,600
Full estate: API, web, mobile and cloud configuration review	8 to 12 days	£8,800 to £16,800

These are typical UK ranges rather than quotes; the exact figure is confirmed after scoping. Our guide to penetration testing costs in the UK breaks down the pricing drivers in more depth.

How EJN Labs approaches PCI SSF assurance testing

EJN Labs is a UK-based, CREST-accredited penetration testing firm, certified to ISO 27001 and Cyber Essentials Plus, with all testing delivered by UK-based testers. We test against the attack classes the Secure Software Standard cares about: account data exposure, broken authentication and authorisation, injection into payment flows, insecure update mechanisms and weak cryptographic handling. Reports serve two audiences at once: technical detail for your engineers, and an executive summary plus attestation letter a buyer’s compliance director can read in five minutes.

Because many of your buyers are regulated financial firms, we also understand their side of the table; our overview of cyber security for financial services covers the pressures shaping their due diligence. All engagements run under our CREST penetration testing methodology.

Frequently Asked Questions

Is PCI SSF validation mandatory for payment software vendors?

No law requires it. PCI SSF is a voluntary framework from the PCI Security Standards Council, and its force is contractual: card brands, acquirers and merchant buyers increasingly prefer or require validated software, and procurement teams check the PCI SSC list of validated products.

In practice, unvalidated vendors face longer due diligence and more demanding evidence requests, including independent penetration test reports.

Does PCI SSF explicitly require a penetration test?

Not in those words. What the framework asks for is evidence of security testing rather than a named test: secure software validation covers the product, the Secure SLC Standard covers the development lifecycle, both are judged by a qualified SSF assessor, and PCI SSC’s Secure SLC Program Guide lists penetration test results among the evidence that software security controls are working. An independent penetration test is, in our experience, the most common way to evidence that testing.

A test from a CREST-accredited firm carries the most weight, and it is what buyers’ compliance directors ask to see regardless of validation status.

What does a penetration test for payment software cost in the UK?

UK day rates for CREST-accredited testing typically run £1,100 to £1,400, never a flat fee. A core payment API plus merchant portal is usually 4 to 6 days, around £4,400 to £8,400; adding a mobile SDK takes it to 6 to 9 days, around £6,600 to £12,600. Exact pricing depends on scope, confirmed via a short scoping call.

How recent does a pen test report need to be for buyer due diligence?

Less than 12 months old is the working rule for most financial services buyers, and the report must cover the current major version of the software. Significant releases, new payment APIs or a change of hosting platform usually reset the clock.

Pairing an annual full test with retests after major changes keeps your evidence continuously presentable and avoids scrambling mid-procurement.

Can we share the full penetration test report with prospects?

You can, but most vendors should not circulate raw technical detail. The better pattern is an attestation letter or executive summary confirming scope, methodology, tester accreditation and that high and critical findings were remediated and retested, which compliance directors generally accept.

Reserve full report access for later-stage due diligence under NDA.

Turn buyer questionnaires into a sales advantage

If PCI SSF questions keep stalling your pipeline, the fastest fix is fresh, independent evidence. Get a CREST pentesting quote and we will come back with a fixed scope and price for your estate, retest and attestation included.