PCI DSS

Does my SaaS need to be PCI DSS compliant?

If your SaaS stores, processes, or transmits cardholder data — or can affect the security of the systems that do — PCI DSS applies. Most SaaS keep scope small by fully outsourcing payments to a PCI-compliant processor (for example, a hosted checkout) so card data never touches their servers, which can reduce validation to the shortest self-assessment (SAQ A). You still have obligations, just far fewer.

PCI DSS follows the card data

The test is whether you store, process, or transmit the primary account number (PAN), or can impact the security of the cardholder data environment. If card data flows through your servers or API, you are in scope. If it never does, your scope is much smaller, but rarely zero.

Outsourcing to a processor shrinks scope

Using a PCI-compliant processor with a hosted payment page or tokenization (so the card is entered directly with the processor) keeps card data off your systems and typically qualifies you for SAQ A, the shortest self-assessment. Embedding a payment form that posts card data through your own systems increases scope.

You still have responsibilities

Even fully outsourced, you must complete the applicable SAQ, use processors that are themselves PCI-compliant, and manage the integration securely (for example, protecting the pages that redirect to the processor). Outsourcing reduces the work; it does not remove your accountability.

Where Keel fits

Keel helps you scope PCI DSS honestly and track the requirements that apply to your setup alongside the SOC 2 and ISO 27001 controls you already maintain, so a lean SAQ-A program is a by-product of your existing security work.

FAQ