2

We are having a debate internally about which SAQ we need to fill in for PCI - our QSA questionnaire says D (and I tend to agree) but company director says SAQ C from reading the guidelines.

The way we process card data is:

  • We are a B2B Saas subscription business - we don't sell "goods" but users subscribe to use our service each month
  • We have a web form hosted on our server
  • User enters payment details and submits the form
  • The data gets posted to our server
  • We then securely transmit that data to an API hosted by our payment processor
  • We do not actually "store" the card data

The last point is where the confusion lies - whilst we do not store the data as in put it into a database and so on the data does actually reside on our servers (in memory for example) as it is posted from the form.

Does that class as "storing" data (in which case we are SAQ-D) or is that transmitting (hence we are SAQ-C)?

The crux of this seems to come down to the definition of "storing data" and I cannot find a definitive answer!

  • Keep in mind that SAQ C does not apply to e-commerce in PCI 3.0. Not sure if that is what you're doing. Under PCI 2.0 the SAQ C was likely the correct one. I would recommend checking out pcisecuritystandards.org/documents/…. – John Downey Oct 5 '15 at 14:42
  • John Downey - We are a B2B Saas subscription business - we don't sell "goods" but users subscribe to use our service each month so I assume that classes us as ecommerce so it is D? – bhttoan Oct 5 '15 at 14:52
  • Judging by your description, yes, it would point to SAQ D. Until you qualify as a Level 1 merchant and have to do an on-site report on compliance. Apparently the link didn't work, so lets try this one. I'd suggest reading the Understanding the SAQs for PCI DSS version 3. – John Downey Oct 5 '15 at 14:59
1

bhtloan, you've hit a couple of those areas where the PCI materials are vague and/or ambiguous. (Often deliberately vague & ambiguous; the payment counsel is as much a political institution as any other one that takes on topics of high importance to millions of people & entities, a lot of them with diverse and frequently-conflicting interests.). I'll just give you my read of where I think the opinion of the mass of PCI compliance interpreters is (for the "storage" question ) and where the guidance points (for "e-commerce" question.)

-On what "storage" means, I think it's fair to say that generally the practical line is drawn hereis this: is information held entirely in RAM vs. is it ever written to a drive (or other non-volatile storage medium). Now, in terms of application of those ideas, most cases are actually quite clear. If credit card info is held in a POS machine's RAM for a split second to encrypt it and address it and then sent on its way, that case is (almost) universally held not to constitute storage. At the other end of the spectrum, if cardholder data is written to a drive in order to keep should a customer want to buy something from you at some point in the indefinite future, that scenario would (almost) universally be regarded as storage, such that the data needs to be encrypted and you need SAQ D. The in-between is where things can get a little harder...

In practical terms, I would say that in almost any scenario where cardholder data is written to a non-volatile medium--like a hard drive, an SSD, or magentic tape--rather than RAM I'd advise a client that it was their responsibility to encrypt. Simply because even though it may be your intent to quickly delete said information (within minutes or hours, say), it physically can persist for a much longer time if you neglect to do what you intend. In contrast, the contents of RAM quickly vanish whenever a machine is rebooted or turned off, and thus--in theory-- info written merely in RAM gives an attacker a much, much shorter window to steal it. Thus, it is considered outside the policy purpose of not having in-the-clear info vulnerable to theft for any long period of time. (Alas, as we've seen with the endless data breaches of major retailers over the last few years even that short window is still far too long to prevent malware from grabbing cardholder data.) Now if you specifically pursue a policy of rebooting and powering off servers as rarely as possible so that data will be in RAM as long as possible, at that point are you "storing" it? Possibly. But I think the validity of the general rule/s stands.

To sum the topic of storage up: find out if anywhere in the process from where cardholder data enters your systems to the point it leaves your systems the data is written to, well, storage. If it stays wholly in RAM and gets discarded in a seconds, a few minutes, even a few hours you are very likely okay for SAQ C. If it is written to storage, you likely need to follow the rules on encryption or tokenization and go with SAQ D. Even if you write it to storage for some purposes besides using it future authorizations and have a highly-reliable software mechanism in place that makes sure it gets wiped in seconds, minutes, or hours...well, I'd follow the encryption/tokenization standards and use SAQ D to be on the safe side. But there might be some dissent among PCI interpreters about whether you or not you have really engaged in storage.

--Now, on the "e-commerce point", this are actually somewhat more clear cut. Not because the text of the SAQ rules/guidance itself is clear. (One part says "ecommerce channels" can't use SAQ C, but another part just above that one specifically contemplates that "e-commerce....merchants" can use it. Huh??.) However, while the text is oddly written there's a chart in the same guidance that seems to be unambiguous. The chart is on page 18 of the pdf, but let me blow-up the relevant part:

enter image description here

I think the "E-commerce Transactions" flow is pretty decisive: SAQ D is the only route you have. So regardless of how the storage issue turns out, the answer certainly seems to be SAQ D. To me, anyway. (Standard disclaimer: Remember, as far as you know I'm just some guy on the Internet...)

All of the above being said, your QSA is the guy or gal who is directly familiar with your situation, qualified to advise you on PCI, and professionally responsible for doing so. When in doubt, lean on his or her advice. (Which is also that you should use SAQ D, anyway. )

Hopes this helps. Cheers.

1

If you are e-commerce and the user's card data touches your server (in memory or on disk) then you are SAQ-D.

You can reduce your scope to SAQ-A-EP if the payment form on your site does a post directly to the payment processor's API, but if the card data touches your server - even though it isn't stored- you are SAQ-D.

Remember that if you are level 1 or level 2 (based on transaction numbers) your QSA will have to sign this off and their interpretation is the only one that counts.

  • You probably mean SAQ-A-EP and not SAQ-EP – WoJ Oct 5 '15 at 20:06
  • I do (I refer to it so often I tend to shorten it). Edit made, thanks. – David Scholefield Oct 6 '15 at 6:21
0

Whether your processing of data is storage or not is one thing. The more important is that in order to be eligible to SAQ C (all emphasis below mine)

Merchants with payment application systems connected to the Internet, no electronic cardholder data storage. Not applicable to e-commerce channels.

e-commerce is prone to interpretation, for what it is worth Wikipedia defines it as

E-commerce (...) is trading in products or services using computer networks, such as the Internet.

Since you say that "we don't sell "goods" but users subscribe to use our service each month" I would assume that you do not fall into SAQ C, and therefore you need to assess against SAQ D.

  • This too is my interpretation but there is still ambiguity especially around the definition of ecommerce - I spoke to our QSA again today and they asked where the shopping cart was hosted. When I said there wasn't one they said then it is not ecommerce but when I asked for confirmation they reversed that and said it was :/ – bhttoan Oct 5 '15 at 16:47
  • It is better to err on the side of security here. Anyways the assessment must be signed by a PCI-DSS certified assessor so he will ultimately decide. – WoJ Oct 5 '15 at 20:08
0

Talk to your acquirer. They own the relationship with you and are responsible for your PCI compliance (mandated as such by the card brands). Your account manager should be able to tell you what will be acceptable as an SAQ submission if you are unsure (it is their responsibility to tell you!).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.