0

Ok, so we do not store any cardholder data so I get confused by these questions.

"Is all access to any database containing cardholder data (including access by applications, administrators, and all other users) restricted as follows:"

8.7(a) Is all user access to, user queries of, and user actions on (for example, move, copy, delete), the database through programmatic methods only (for example, through stored procedures)?

Isn't this N/A for me?

user2091722
  • 17
  • 3
  • Which SAQ are you filling out? Why did you decide that SAQ was applicable? What is your role in the card process? What form of offloading, if any, do you do to Service Providers? – gowenfawr Oct 11 '19 at 18:11
  • We accept the card number and immediately transmit that to the service provider. We own the site. We do the same thing for Phone orders. We are filling out SAQ D 3.2.1 v1.0. We settled on this SAQ through the wizard questions. – user2091722 Oct 11 '19 at 18:54

1 Answers1

1

Isn't this N/A for me?

Yes. You'll want to review the section titled "Guidance for Non-Applicability of Certain, Specific Requirements" on page vi of SAQ D 3.2.1. To quote (emphasis mine):

While many organizations completing SAQ D will need to validate compliance with every PCI DSS requirement, some organizations with very specific business models may find that some requirements do not apply. For example, a company that does not use wireless technology in any capacity would not be expected to validate compliance with the sections of the PCI DSS that are specific to managing wireless technology.

Since you aren't storing card data in a database, the database questions would all be N/A. In addition to marking them N/A, you need to provide an explanation:

If any requirements are deemed not applicable to your environment, select the “N/A” option for that specific requirement, and complete the “Explanation of Non-Applicability” worksheet in Appendix C for each “N/A” entry.

gowenfawr
  • 71,975
  • 17
  • 161
  • 198