PCI DSS Audit Day for SaaS Platforms: The Penetration Testing Evidence Your QSA Expects

Why PCI DSS penetration testing evidence decides your audit day

Most SaaS platforms do not fail their PCI DSS assessment because they skipped testing. They fail, or scramble through remediation windows, because the PCI DSS penetration testing evidence they hand the QSA does not match what the standard asks for. A report exists, but it is 14 months old. External testing was done, but internal was not. Segmentation controls were never tested at all, even though the entire compliance argument rests on them.

This article covers the audit-day evidence specifically. For the full requirement, methodology and scoping picture, our PCI DSS penetration testing service page is the authoritative reference. Here we stay narrow: what a QSA actually pulls from a SaaS platform’s evidence pack, and how to walk in with nothing missing.

What PCI DSS actually requires from a SaaS platform

PCI DSS is maintained by the PCI Security Standards Council and enforced contractually by the card schemes and your acquirer wherever cardholder data is stored, processed or transmitted. It is one of the few frameworks with explicit, unambiguous penetration testing requirements, set out in Requirement 11 of the current standard.

• Internal and external penetration testing at least once every 12 months and after any significant change to the cardholder data environment (CDE).
• Testing performed using an industry-accepted methodology, covering the entire CDE perimeter and critical systems, at both network and application layers.
• Segmentation testing to confirm that controls isolating the CDE from other networks actually work. For service providers, which includes most multi-tenant SaaS platforms handling card data, this must happen at least once every six months.
• Exploitable vulnerabilities and security weaknesses found during testing must be corrected, and testing repeated to verify the fix.

Note the service provider distinction. If your SaaS product touches card data on behalf of your customers, the six-monthly segmentation cadence applies. Annual-only segmentation evidence is one of the most common gaps we see in first-time SaaS assessments.

The evidence pack your QSA expects to see

A QSA samples the evidence and validates it against the requirement. For a SaaS platform, a complete pack looks like this.

Evidence item	What the QSA checks
External penetration test report	Dated within 12 months, covers all internet-facing CDE systems including APIs, dated after your last significant change
Internal penetration test report	Tests from inside the network or VPC towards the CDE, not just an authenticated app test relabelled
Segmentation test results	Proof that out-of-scope networks, tenants and environments cannot reach the CDE; six-monthly for service providers
Methodology statement	Industry-accepted approach, tester qualifications, and organisational independence of the testers
Remediation and retest evidence	Every exploitable finding mapped to a fix and a documented retest confirming closure
Scope definition	A CDE diagram and asset list matching what was actually tested, with exclusions justified

The scope definition trips up SaaS teams more than anything else. In a cloud estate the CDE boundary is rarely a network diagram; it is a set of VPCs, security groups, IAM roles, serverless functions and third-party payment integrations. If your test report describes a boundary that does not match your architecture documentation, expect follow-up questions and possibly a re-test before the QSA signs off. Our penetration testing checklist covers the preparation steps that prevent exactly this mismatch.

How an audit-ready engagement runs

A typical SaaS engagement runs in five stages.

1. Scoping against the CDE. We map the tested boundary to your actual cardholder data flows: which services touch card data, which are segmented away, and which third parties (payment gateways, tokenisation providers) reduce your scope. This is where most of the audit risk is removed.
2. External testing. Internet-facing infrastructure, the web application, and the APIs your customers and payment providers call. For most SaaS platforms the API attack surface is now larger than the web front end.
3. Internal and cloud-layer testing. Testing from an assumed-breach position inside your cloud environment: can a compromised non-CDE workload, tenant or staff credential reach cardholder data?
4. Segmentation validation. Deliberate attempts to cross from out-of-scope segments into the CDE, producing the specific pass/fail evidence the QSA samples.
5. Reporting and retest. A report written for two audiences: engineers who need to fix findings, and a QSA who needs requirement-mapped evidence. Retesting after remediation closes the loop.

Timing matters. Book testing at least eight weeks before your assessment date so there is room to remediate and retest before the QSA arrives.

What it costs and how scope drives the price

UK penetration testing is priced by effort in days. The typical day rate is £1,200 to £1,400, and PCI-driven engagements for SaaS platforms usually land in these ranges.

Scope	Typical effort	Typical cost
External infrastructure and web application only	4 to 6 days	£4,800 to £8,400
Six-monthly segmentation testing (service providers)	2 to 3 days	£2,400 to £4,200
Full CDE: external, internal, API and segmentation	6 to 9 days	£7,200 to £12,600

The main cost drivers are the size of the CDE, the number of applications and APIs in scope, and how much of your estate you have segmented away. Good segmentation is the single biggest lever: a tokenised platform where card data never touches your own infrastructure can shrink scope dramatically. These are typical UK ranges; the exact price depends on your architecture, which is why we scope through a short quote form rather than quoting blind. For a broader market view, see our guide to penetration testing costs in the UK.

How EJN Labs approaches PCI evidence for SaaS platforms

EJN Labs is a CREST-accredited penetration testing firm, certified to ISO 27001 and Cyber Essentials Plus, using UK-based testers only. That matters for PCI DSS specifically: the standard requires testing by a qualified party with organisational independence, and QSAs consistently accept CREST accreditation as strong evidence of both.

When we scope a SaaS cardholder data environment, we start from the data flow, not the network diagram. We trace where a card number can physically travel: browser to your front end, front end to payment API, tokenisation callbacks, webhooks, logging pipelines and analytics exports. Logging is the one we flag most often; platforms that tokenise correctly at the edge still leak PANs into application logs through error handlers, and a QSA sampling log output will find it. Our reports map every finding to the PCI DSS requirement it affects, so your QSA reads evidence, not a generic vulnerability list. The retest report states explicitly which findings were verified as closed.

Because many SaaS platforms sell into regulated buyers, the same evidence pack usually serves double duty in customer security reviews and financial services due diligence. If your customers are banks or payment firms, our overview of cyber security for financial services explains what those buyers layer on top of PCI DSS.

Frequently Asked Questions

What penetration testing evidence does a QSA need on audit day?

A QSA expects internal and external penetration test reports dated within the last 12 months, segmentation testing results, a documented industry-accepted methodology showing tester qualifications and independence, and remediation plus retest evidence for every exploitable finding. The tested scope must match your documented cardholder data environment, including APIs and cloud infrastructure, with any exclusions clearly justified.

How often does a SaaS platform need PCI DSS penetration testing?

Internal and external penetration testing is required at least every 12 months and after any significant change to the cardholder data environment, such as a re-platform or new payment integration. Segmentation testing runs at least every six months if you are a service provider, which covers most SaaS platforms handling card data on behalf of their customers.

What does PCI DSS penetration testing cost for a SaaS platform?

Typical UK engagements run 4 to 9 days at a day rate of £1,200 to £1,400, so roughly £4,800 to £12,600 depending on scope. An external-only test sits around £4,800 to £8,400, while a full CDE engagement covering external, internal, API and segmentation testing runs £7,200 to £12,600. The exact price depends on your architecture.

Does tokenisation remove the need for penetration testing?

No, but it can shrink the scope substantially. If card data is tokenised at the edge and never touches your infrastructure, your cardholder data environment is smaller and testing effort drops with it. You still need to test the systems that initiate payments, handle tokens and receive webhooks, and you must prove the segmentation between those systems and the rest of your platform holds.

Can we use our own engineers to run the penetration test?

PCI DSS permits internal testers, but they must be qualified and organisationally independent from the teams that manage the systems being tested. Most SaaS platforms cannot demonstrate both, so QSAs generally expect an external report. Using a CREST-accredited firm with UK-based testers gives your assessor immediate, recognisable evidence of qualification and independence without further justification.

Walk into your assessment with the evidence complete

If your QSA assessment is on the calendar, work backwards from it now: scope the CDE, test, remediate and retest with weeks to spare. EJN Labs delivers requirement-mapped evidence from UK-based, CREST-accredited testing. Tell us about your platform through our penetration testing quote form and we will return a scoped proposal, usually within one working day.