PCI DSS is the Payment Card Industry Data Security Standard, a baseline of technical and operational requirements for protecting payment account data. A founder gets the biggest win by shrinking scope: if card data never touches your systems, the work to validate compliance shrinks with it.
What is PCI DSS?
The PCI Security Standards Council describes PCI DSS as developed to encourage and enhance payment card account data security and to support consistent data security measures globally. It provides a baseline of technical and operational requirements designed to protect payment account data. The Council's resource hub lists documents for version 4.0 and 4.0.1, including a Report on Compliance template, Attestations of Compliance, Self-Assessment Questionnaires, scoping and segmentation guidance and targeted risk analysis guidance.
The Council sets the standard. Card brands and acquirers decide who must validate and how, so ask your payment provider or acquiring bank what they require of you.
Why does scope decide everything?
Requirements apply to the systems that store, process or transmit account data and to systems that can affect their security. The more systems that touch card data, the more you have to protect, test and document. The Council publishes scoping and segmentation guidance because scope is where most of the effort hides.
Constructed example: a subscription app builds its own checkout form that posts card numbers to its server and then forwards them to a payment provider. The founder believes the provider handles PCI. In fact, the app server, its logs, its database backups and the engineers' laptops that can reach them are now all candidates for scope. Switching to the provider's hosted fields, where card entry happens in the provider's own component, changes the question entirely, though you still need to confirm with the provider which questionnaire applies.
Which assessment form will you use?
Merchants and service providers validate with either a Report on Compliance by a qualified assessor or a Self-Assessment Questionnaire, depending on the card brand rules and their volume. The Council publishes several questionnaire variants. Which one fits depends on how your checkout is built, so the question to ask your acquirer is simple: which form applies to our integration, and by when?
What do you still owe if you outsource payments?
Even with a hosted payment page, you remain responsible for the security of the pages that lead to it, for your account access to the payment provider's portal, and for choosing providers who themselves validate. Keep their attestation on file and check it each year.
Where does software security fit?
The Council also runs standards for secure software and secure software lifecycles, listed on its standards page, and its resources address web application risks. If you write payment code, the practical items are the same as for any application: dependency hygiene, code review, secrets handling and tested change control.
What mistakes do small teams repeat?
The common ones are quiet. Card numbers pasted into a support ticket. Full request bodies written to application logs during a debugging session and never turned off. A test environment loaded with a copy of real data. None of them looks like a payments project, yet each one pulls another system into scope. A short rule helps: card numbers never appear in any system you own, and a scheduled search of logs and tickets proves it.
How to apply this
- Draw the payment data flow: where card data enters, where it goes and which systems see it.
- Remove card entry from your servers if possible, using a provider's hosted component.
- Ask your acquirer or provider which validation form you need and its deadline.
- Get and store your providers' attestations of compliance and set a yearly reminder.
- Lock down who can change the checkout page and the provider account.
- Keep logs and error reports free of card numbers, and test that they are.
- Read the Council's scoping and segmentation guidance before you build anything new around payments.
Quick check
Does using a payment provider remove all PCI duties?
No. It can reduce scope a lot, but you still have duties around your own pages, account access and vendor oversight. Confirm which questionnaire applies with your provider or acquirer.
Who decides whether I must submit a report?
Card brands and acquirers set validation requirements. The PCI Council publishes the standard and templates, so ask your acquirer.
Sources
Last reviewed: 18 October 2026.
