How to answer
Are you PCI DSS compliant?
Most SaaS companies answering this have no cardholder data at all, and say so badly. The strong answer is not yes or no, it is why the question does not apply.
We do not store, process or transmit cardholder data. Payments are handled entirely by our PCI DSS Level 1 provider through their hosted checkout, so card details never reach our systems. Their Attestation of Compliance is available on request.
FillTrust grades an answer like this answered “no” from your documents when your documents support it.
- Answered from
- How payments actually work in your product. The answer comes from your architecture and your payment provider's attestation, not from a policy.
- Evidence to attach
- Your payment provider's current Attestation of Compliance, and your own SAQ if you completed one.
- Where it is asked
- SIG LiteBespoke vendor questionnaires
PCI DSS shows up in roughly as many questionnaires as ISO 27001, usually as four flat words: are you PCI DSS compliant. For most companies being asked, the honest answer is that they never touch cardholder data, and the whole difficulty is saying that in a way the reviewer accepts.
Work out your scope before you answer. PCI DSS applies to the storage, processing and transmission of cardholder data. If your customers pay through a hosted checkout or a payment provider's embedded fields, the card number goes from the customer's browser to the provider and never lands on your infrastructure. Your scope is not "small", it is nil, and that is the sentence to write. Naming the mechanism matters: a reviewer can verify a hosted checkout, and cannot verify an assurance.
Say what you have rather than claiming a status you do not hold. Your provider's Attestation of Compliance covers their systems. Referring to it is fine and useful; presenting it as your own compliance is not, and it is easy to spot. If you did complete a self-assessment questionnaire, name which one and when. If you did not, say that you were not required to and explain why. Merchants who fully outsource payment handling generally fall to the shortest self-assessment, but which one applies is a question for your acquiring bank, and their answer is the one that counts.
The leaks are operational, not architectural. Plenty of companies with a perfectly clean payment flow still end up with card numbers in their systems, because a customer emailed one to support, a salesperson took one over the phone, or someone pasted a full PAN into a ticket to explain a failed charge. If that happens, you are handling cardholder data regardless of what your checkout does. The fix is a documented rule that staff never accept card details through any channel you control, plus something that scans for and purges them when it happens anyway. Reviewers in payments ask about this specifically.
If you are in scope, give the level, the assessment route and the date, exactly as you would for a SOC 2: Level 4 with a completed self-assessment and a passing quarterly scan is a normal answer for a small merchant, and one a reviewer can work with.
We answer this one about ourselves the same way. FillTrust's checkout is hosted by our payment provider, card details never reach our servers, and our questionnaire answer says precisely that.
How this one goes wrong
Specific to this question, not general advice.
- Answering a flat no. Read literally it says card data is unprotected, when what you mean is that you never see it. Those land very differently with a reviewer.
- Answering yes because your payment provider is compliant. Their attestation covers them. If your scope is genuinely nil, say that instead: it is a stronger answer and it is the true one.
- Overlooking the places card data leaks into. Numbers read over a support call, pasted into a ticket or emailed by a customer put you back in scope, whatever the checkout page does.