PCI DSS pentest: who needs one, and what requirement 11.4 asks for

Do you need a PCI DSS pentest? Find your SAQ first

PCI DSS is the card industry's security standard. Its current version, v4.0.1, puts penetration testing in requirement 11.4, and whether 11.4 applies to you depends on how you validate compliance. Most small merchants fill in a Self-Assessment Questionnaire (SAQ), which lists only the requirements matching how card data reaches the processor. Level 1 merchants (over 6 million Visa or Mastercard transactions a year, in Stripe's guide) need a yearly Report on Compliance (ROC) from a Qualified Security Assessor (QSA) instead.

The PCI Security Standards Council (PCI SSC) writes the forms but says card brands, acquirers and payment facilitators set validation requirements. On Stripe, the PCI wizard in your Dashboard looks at your integration and picks the form.

1. 1

   Does a card number ever reach your server?

   If your API, logs or database ever receive a full card number, even in a debug log, SAQ A and A-EP are out and you are on the SAQ D path. Stripe warns that handling card data can mean meeting each of PCI DSS's 300+ security controls.

2. 2

   Who builds the payment form?

   If every element of the form comes from your processor, by redirect or iframe, you are on the SAQ A path. If your own page or script shapes the form or how card data reaches the processor, it is SAQ A-EP.

3. 3

   Do you run checkouts for other businesses?

   Then you may be a service provider, and service providers self-assess only with SAQ D for Service Providers. Ask your acquirer.

Does Stripe make you PCI compliant?

No, but it makes the job much smaller. Stripe says an independent QSA certifies it yearly as a PCI Level 1 Service Provider, and calls compliance a shared responsibility: a business accepting payments must do so in a PCI-compliant way and attest to it every year. Its guide maps Checkout and Elements to SAQ A, the older Stripe.js v2 to SAQ A-EP, and card data sent straight to its API to SAQ D.

Stripe's certification covers Stripe. The page that sends customers to the payment form, your webhook handler and your secret keys are yours, and Stripe's integration security guide asks you to serve payment pages over TLS 1.2 or above.

Paddle works differently. As merchant of record, it is the legal seller to your customer, and its developer docs tell sellers they don't carry PCI scope. When a buyer's questionnaire asks about PCI, name Paddle as the party that holds it; the security questionnaire guide covers the wording.

The 2025 SAQ A change: payment page scripts

PCI DSS v4 added two requirements against skimming scripts on checkout pages, in force since 31 March 2025. Requirement 6.4.3: every script loaded on a payment page is authorized, has its integrity assured and is inventoried with a written reason. Requirement 11.6.1: a change- and tamper-detection mechanism alerts staff to unauthorized changes to the payment page and its HTTP headers as the browser receives them, at least once every seven days or as a targeted risk analysis sets.

On 30 January 2025, the PCI SSC announced a revised SAQ A. It drops 6.4.3, 11.6.1 and 12.3.1 (the risk analysis behind 11.6.1) and adds an eligibility criterion: the merchant must "confirm their site is not susceptible to attacks from scripts that could affect the merchant's e-commerce system(s)." It replaced the October 2024 SAQ A on 31 March 2025. The Council stressed that the underlying PCI DSS requirements are not removed or diminished.

FAQ 1588, announced on 28 February 2025, gives two ways to confirm it: protect the page holding the payment form with techniques such as those in 6.4.3 and 11.6.1, yours or a third party's, or get your PCI DSS compliant processor's confirmation that its solution, implemented per its instructions, protects your page from script attacks. It does not apply to redirects or payment links.

What PCI DSS requirement 11.4 asks for

Requirement 11.4 states that external and internal penetration testing is regularly performed, and that exploitable vulnerabilities and security weaknesses are corrected. CDE, the cardholder data environment, means the systems that handle card data or connect to them; for SAQ A-EP, the form applies it to your website.

Application layer and network layer

An application-layer test attacks your app the way a user could, covering at least the attacks in requirement 6.2.4: injection, attacks on data structures and cryptography, business logic abuse through APIs and client-side code (cross-site scripting and request forgery included), access control bypass, and high-risk vulnerabilities you have identified. The PCI SSC's penetration testing guidance (2017, written when pentests sat under requirement 11.3) asks testers to work from each role the app defines. A network-layer test covers exposed services, operating systems and network devices.

Who may run the test

A qualified internal resource or third party with organizational independence, not necessarily a QSA or an Approved Scanning Vendor (ASV). The guidance defines independence as being separate from the management of the systems tested, which in a small startup usually rules out the founder or developer who runs the app. Certifications such as OSCP or CREST are not required, and the guidance says they are not enough alone: ask about past web application engagements.

How often

At least once every 12 months, and after any significant infrastructure or application upgrade or change. PCI DSS leaves "significant" to your risk assessment. If you deploy daily, write down which changes trigger a new test (checkout, authentication, payment webhooks, hosting) and keep that rule with your reports.

ASV scans (11.3.2) vs penetration tests (11.4)

The two are easy to confuse, and an SAQ A merchant usually owes only the first.

In your first year, a passing most recent scan, a written policy of quarterly scans and rescans proving fixes can stand in for four passing scans. The pentest vs vulnerability scan guide covers the difference outside PCI.

What a PCI pentest report must contain, and what an assessor checks

PCI DSS fixes no report template. The PCI SSC's guidance suggests this outline:

• Executive summary: the scope and the major findings.
• Statement of scope: what was tested, which systems are in the CDE and which are not.
• Methodology and limitations, such as testing hours or excluded systems.
• Testing narrative and, when segmentation reduces your scope, segmentation results.
• Findings: for each, whether it could be used to reach card data, its severity, the affected targets, references such as a CVE or CWE, and a description.
• Tools used, and the clean-up of test accounts and data.

A retest report gives the dates of both tests, the original findings and the result for each. The assessor examines your methodology, the scope of work and the latest results, interviews the people responsible, and checks that exploitable findings were fixed and retested. Our sample pentest report shows the outline filled in.

• The methodology is written down and the report names it.
• The scope matches your SAQ: your website and payment pages for SAQ A-EP, every in-scope system for SAQ D.
• The report names the tester, their qualifications and how they are independent.
• Every exploitable finding has a fix and a dated retest, kept for at least 12 months.
• The test is less than 12 months old, with no significant change shipped since.

Payment risks that matter even when PCI asks for little

By the PCI SSC's count, an SAQ A merchant whose site redirects to or embeds the processor's form answers 27 requirements and owes no pentest. Yet several ways a Stripe app loses money sit in code the processor never sees.

Webhooks that skip the signature check

If your webhook handler skips the Stripe-Signature check, anyone who finds the route can post a fake checkout.session.completed event and get an order marked paid. Stripe says you must verify webhook signatures; the Stripe webhook security guide shows the check for Next.js, Express and Supabase Edge Functions, with a self-test.

Prices sent by the browser

Stripe's docs tell you to recalculate amounts on your server and not to trust client-provided prices or totals. To check your own app, start a checkout in test mode with the network tab open and read the request that creates the session: if it carries an amount your server uses as is, any visitor can choose what they pay.

// Avoid: the browser decides what it pays
const session = await stripe.checkout.sessions.create({
  mode: "payment",
  line_items: [{
    price_data: {
      currency: "eur",
      unit_amount: req.body.amount, // a visitor can send 50, so EUR 0.50
      product_data: { name: req.body.name },
    },
    quantity: 1,
  }],
  success_url: "https://your-app.example/success?session_id={CHECKOUT_SESSION_ID}",
});

// Better: the browser names a plan, the server picks the Price you created in Stripe
const PRICES: Record<string, string> = {
  pro: process.env.STRIPE_PRICE_PRO!,
  team: process.env.STRIPE_PRICE_TEAM!,
};

const plan = String(req.body.plan);
if (!Object.hasOwn(PRICES, plan)) return res.status(400).json({ error: "Unknown plan" });

const session = await stripe.checkout.sessions.create({
  mode: "payment", // "subscription" if the Price is recurring
  line_items: [{ price: PRICES[plan], quantity: 1 }],
  success_url: "https://your-app.example/success?session_id={CHECKOUT_SESSION_ID}",
});

Scripts and headers on the checkout page

Stripe's security guide warns that JavaScript from other sites makes your security depend on theirs: if one is compromised, an attacker could run arbitrary code on your page. Remove every script checkout does not need and set a Content Security Policy with the directives Stripe lists for Stripe.js or Checkout. With Elements, this is the ground SAQ A's script criterion covers. A first look at your headers:

# Your own checkout page only
curl -sI "https://YOUR-APP.example/checkout" | grep -i -E "content-security-policy|strict-transport-security"

The security headers guide explains each header and the security headers checker reads them for you. A sk_live_ secret key in your JavaScript is worse: by default it can make any Stripe API request on your account, refunds included. See API keys exposed in the frontend.

Where automated testing fits, and where you need a qualified tester

The PCI SSC's guidance is direct: penetration testing is "essentially a manual endeavor", and "simply running an automated tool does not satisfy the penetration testing requirement." No automated tool, Keybrum included, satisfies 11.4, and no tool makes you PCI compliant. You validate compliance with your acquirer or processor, on the form they accept.

Automated attacks are useful around that formal test:

• Between tests. A yearly test covers the build that existed on the days it ran; an attack on every deploy catches an open webhook or a leaked key the week it ships.
• Before the tester arrives. A tester's day spent on a leak a tool could have shown is a paid day, at €1,000 to €1,700 in Northern and Western Europe according to the pentest cost guide.
• When PCI asks for no pentest. An SAQ A merchant owes no 11.4 test, yet its webhooks and prices are still exposed to anyone who looks.

What a qualified tester brings that software does not: judgment on business logic across several steps, chained attacks, network-layer testing, and a signed report your assessor can accept as 11.4 evidence. The web application penetration testing guide covers what a full test includes.

Keybrum is an automated attack tool for apps built with AI. Once you prove you own your app, it attacks it live the way a stranger would: unsigned Stripe webhooks, Stripe secret keys in the bundle, other users' data across two accounts, missing security headers. Each finding comes with the request that worked and a fix your coding agent reads through Keybrum's MCP server.