UK PCI DSS compliance checklist for SaaS

What PCI DSS means for UK SaaS taking card payments (and why it matters)

PCI DSS (Payment Card Industry Data Security Standard) is the security framework that applies when your SaaS accepts, processes, stores, or transmits cardholder data. In the UK, it’s not a law, but it’s a contractual requirement set by the card schemes and enforced through your payment provider and acquiring bank. For SaaS businesses, the practical question is: how much of the card data environment touches your systems? The less it does, the smaller your compliance burden and the lower your risk exposure.

Why it matters: non-compliance can lead to higher processing fees, account restrictions, chargeback friction, and costly incident response if card data is exposed. It also affects customer trust and procurement—many UK buyers will ask how you handle card data and whether you can evidence controls.

• Reduce scope first: use hosted payment pages, payment links, or tokenisation so card data never hits your servers.
• Confirm your SAQ type: most SaaS using redirect/hosted fields fall under simpler SAQs; custom handling increases requirements.
• Document data flows: map where payment data could pass (web app, mobile, logs, support tools, analytics, webhooks).
• Secure your environment: patching, vulnerability scanning, least-privilege access, MFA for admin panels, and strong change control.
• Protect secrets: store API keys in a vault, rotate regularly, restrict by environment, and monitor usage.
• Logging & monitoring: centralise logs, alert on suspicious admin actions, and avoid logging PAN/CVV.
• Third-party checks: verify your PSP and any embedded payment components are PCI compliant and keep evidence on file.

Before you start: map your payment flow and define your PCI scope

Before you touch policies or scans, get a clear picture of how card data moves through your SaaS. This is the fastest way to avoid over-scoping your PCI DSS work (and your costs). Start by drawing a simple payment-flow diagram that covers every step from checkout to settlement, including retries, refunds, chargebacks, and customer support actions.

Document:

• Where payment details are entered (hosted payment page, in-app form, mobile SDK, phone payments).
• Which systems touch cardholder data (your app, APIs, web servers, databases, logs, analytics, support tools).
• Which third parties are involved (PSP/acquirer, gateway, tokenisation provider, fraud tools), and what data they receive.
• What you store (ideally nothing), what you transmit, and what you display (last 4 digits, expiry, tokens).

Then define your PCI scope: the people, processes, and technology that store, process, or transmit cardholder data, plus anything that can impact the security of those systems. In practice, even “no card data stored” SaaS can be in scope if your website can affect a payment page (for example, embedded iFrames, scripts, or redirects).

For UK SaaS, aim to reduce scope by using hosted checkout or fully outsourced payment fields, and by keeping payment pages on the provider’s domain where possible. Record your chosen approach and keep evidence ready: contracts, service descriptions, and your providers’ Attestation of Compliance (AOC). This map becomes the backbone of your SAQ choice and your ongoing compliance tasks.

Choose the right SAQ for your setup (A, A-EP, D) and avoid common mis-scoping

For UK SaaS teams, picking the correct PCI DSS Self-Assessment Questionnaire (SAQ) is less about company size and more about how your product touches cardholder data. Mis-scoping is common—and it can create gaps (too small a scope) or unnecessary work (too big a scope).

• SAQ A: Use this when your SaaS does not store, process, or transmit card data and customers pay via a fully outsourced payment page or redirect (e.g., hosted checkout) where your site doesn’t handle payment fields. You may still have requirements around policies and vendor management.
• SAQ A-EP: Use this when you outsource payment processing but your website does affect the security of the payment transaction—typically when you host the checkout page and embed a payment form/iframe or load payment scripts. You don’t handle card data directly, but your web environment can be a stepping stone for attacks.
• SAQ D: Use this when you store, process, or transmit card data in any way, or when your setup doesn’t cleanly fit the SAQ A/A-EP criteria. It’s the most comprehensive and often applies to complex integrations or custom payment flows.

Common mis-scoping traps: assuming SAQ A while hosting checkout pages; forgetting that third-party JavaScript on checkout can expand scope; overlooking admin panels, logs, or support tools that could expose payment data; and treating “we use Stripe/Adyen” as automatic SAQ A. Map your payment journey end-to-end, list all domains and scripts involved, and confirm responsibilities with your payment provider and any hosting/CDN vendors.

UK PCI DSS compliance checklist for SaaS: step-by-step actions and evidence to collect

• Confirm your PCI scope and SAQ type (what card data touches your product, if at all). Evidence: data flow diagram, system inventory, list of payment pages/redirects, SAQ decision notes, contracts showing use of a PCI-compliant payment provider.
• Minimise card-data exposure by using hosted payment pages, tokenisation, and avoiding storage of PAN/CVV in logs or databases. Evidence: architecture diagrams, tokenisation design, log samples/redaction rules, secure coding standards.
• Harden and segment environments so the cardholder data environment (CDE) is isolated from the rest of your SaaS. Evidence: network diagrams, firewall/security group rules, segmentation test results, cloud configuration exports.
• Implement strong access control (least privilege, MFA, unique IDs, timely offboarding). Evidence: IAM policies, MFA enforcement screenshots, access reviews, joiner/mover/leaver tickets.
• Secure systems and apps with patching, vulnerability management, and secure SDLC practices. Evidence: patch reports, vulnerability scans (internal/external as applicable), remediation tickets, dependency scanning results, change records.
• Encrypt data in transit and at rest where relevant, and manage keys securely. Evidence: TLS configuration reports, certificate inventory, KMS/key rotation logs, encryption settings for storage.
• Centralise logging and monitoring with alerting for suspicious activity. Evidence: SIEM/log retention settings, sample alerts, incident runbooks, time sync (NTP) configuration.
• Run required testing (e.g., ASV scans, penetration testing, segmentation checks) based on your scope. Evidence: attestation reports, test scopes, remediation evidence, re-test results.
• Maintain policies and training aligned to PCI DSS and your UK operations. Evidence: security policies, annual training logs, supplier due diligence, incident response tabletop notes.

How to reduce PCI scope in SaaS: Stripe/Braintree/Adyen patterns that keep card data out of your systems

If you want a smaller PCI DSS footprint, the quickest win is designing payments so your app never handles raw cardholder data (PAN, expiry, CVC). Most SaaS teams in the UK do this by using a PSP’s hosted components and keeping their own systems limited to tokens, customer IDs and payment status.

• Hosted Checkout (lowest scope): Redirect users to a PSP-hosted page (e.g., Stripe Checkout, Braintree Hosted Pages, Adyen Hosted Payment Pages). Your site receives only a success/failure result and a reference ID.
• Embedded fields via iFrame/Elements: Use provider-controlled fields (e.g., Stripe Elements, Braintree Hosted Fields, Adyen Drop-in). Card data posts directly to the PSP; your backend stores a token or payment method ID.
• Tokenisation and vaulting: Save a PSP customer/payment method token for renewals, upgrades and add-ons. Avoid storing PAN “for convenience” in your database, logs or analytics.
• 3DS/SCA handled by the PSP: Use the PSP’s built-in Strong Customer Authentication flows so challenge screens and authentication data stay outside your app.
• Webhooks and server-side confirmation: Treat webhooks as the source of truth for subscription state. Verify signatures and store only event IDs, timestamps and statuses.
• Operational hygiene that prevents scope creep: Block card data in support channels (forms, chat, ticketing), redact request/response logs, and ensure error monitoring tools don’t capture payment fields.

In practice, these patterns often align SaaS businesses with a lighter self-assessment route (commonly SAQ A or A-EP depending on integration), but your exact scope depends on how your checkout is implemented and what touches your domain.

Operationalising PCI: owners, cadence, tooling, and audit-ready documentation

Make PCI DSS “business as usual” by assigning clear owners and a repeatable rhythm. Nominate a PCI owner (often Security or Compliance) accountable for scope, evidence, and assessor comms, plus named deputies in Engineering (technical controls), IT (endpoints/identity), and Customer Support (incident intake). Create a simple RACI so every checklist item has one accountable person and one evidence location.

Set a cadence that matches SaaS change rates: weekly vulnerability triage and patch SLAs review; monthly access reviews for privileged roles, log sampling, and backup restore checks; quarterly risk review, incident tabletop, and third-party/service-provider attestations; annually full PCI scope validation, policy refresh, and penetration test scheduling (as required by your environment). Tie all of this to change management: every release that touches payment flows should trigger a mini-scope check and updated diagrams.

Tooling should reduce manual evidence. Use a ticketing system (Jira/ServiceNow) for control tasks and approvals, a central evidence repository (SharePoint/Confluence/Google Drive) with versioning, and automated exports from your IdP (Okta/Azure AD), cloud (AWS/Azure), EDR, and vulnerability scanners. Standardise evidence packs: screenshots with timestamps, CSV exports, signed change records, and configuration baselines.

Keep audit-ready documentation lightweight but complete: current network/data-flow diagrams, asset inventory for the cardholder data environment, written scope rationale, policies mapped to PCI requirements, and an evidence index that links each requirement to artefacts and owners.

Common SaaS pitfalls: billing portals, invoicing, support workflows, logs, and refunds

Most UK SaaS PCI DSS headaches come from “side channels” where card data can accidentally appear. Start with your billing portal: if you embed payment fields, ensure they’re hosted/iframes from your PCI-compliant payment provider and you never capture PAN, CVV, or full track data in your app. Misconfigured reverse proxies, analytics tags, or session replay tools can still record payment page inputs, so disable them on checkout routes and verify with testing.

Invoicing is another trap. PDFs and email templates sometimes include masked card details or payment links that expose identifiers in URLs. Keep invoices free of card data, use tokenised references, and ensure payment links are short-lived and tied to customer authentication. If you accept card payments over the phone, don’t improvise with “type it into a note then delete it”; use a compliant virtual terminal and document the workflow.

Support workflows frequently break scope. Tickets, live chat, and screen-sharing can capture card details unless you actively block them. Add “never share card details” prompts, redact patterns automatically, restrict attachments, and train agents to move customers to secure payment pages.

Logs are a silent scope expander. Audit application logs, web server logs, and error traces for accidental request/response bodies, headers, or query strings containing payment data. Turn off verbose logging on payment endpoints and implement log retention and access controls.

Refunds and chargebacks can also leak data if staff export reports to spreadsheets or share screenshots. Use role-based access, export controls, and a single approved process for refunds through your provider dashboard—no manual storage of card details “for later.”

PCI DSS v4.0 in practice for SaaS: what changed and what to prioritise

PCI DSS v4.0 shifts SaaS teams from “annual audit mode” to continuous security outcomes. For UK SaaS handling card data (or touching payment flows), the practical change is clearer expectations around modern threats, plus more flexibility in how you meet them—if you can evidence results.

What changed in v4.0 that SaaS feels first:

• Targeted Risk Analyses (TRAs): more controls now require you to document risk-based decisions (e.g., frequency of certain activities). This is often new work for product-led teams.
• Stronger authentication expectations: tighter focus on MFA, especially for administrative access and access into the cardholder data environment (CDE).
• Anti-phishing and user awareness: security awareness becomes more measurable and role-specific, not just “annual training”.
• Customised approach option: you can meet objectives with alternative controls, but you must produce defensible evidence and testing.

What to prioritise in a UK PCI DSS compliance checklist for SaaS:

• Reduce scope first: use hosted payment pages, tokenisation, and keep PAN out of your app, logs, and support tooling.
• Map data flows: document where card data could enter (web forms, APIs, webhooks, error logs, analytics, session replay).
• Access control hygiene: MFA everywhere admin, least privilege, short-lived access, and joiner/mover/leaver automation.
• Evidence-ready monitoring: central logs, alerting, and regular reviews aligned to TRAs.
• Vendor responsibility clarity: confirm what your PSP and cloud provider cover, and what remains yours.