What level of compliance do I need as a software vendor?

Question

I am having a bit a difficult time trying to assess to what level my business needs to be PCI compliant.

My business is developing eCommerce websites that are hosted by the client. The websites have an iFrame on the checkout which links to the payment gateway application that takes and processes the payment information. This payment gateway application is also developed by my business and handed over to the client who is hosting it on a PCI compliant server that my business does not have access to.

As my business is only providing software development services I was always under the impression that we don't need to be PCI compliant. However, my clients believe that I am falling under SAQ D.

I went through SAQ D but as my business is not in charge of hosting any of the applications I am struggling to fill in the questionnaire.

Does my business require PCI compliance? And if yes, what is the correct questionnaire?

Any help is appreciated!

Answer 1

As Bobson quoted but apparently didn't read, with emphasis added:

The PA-DSS is for software vendors and others who develop payment applications that store, process or transmit cardholder data and/or sensitive authentication data as part of authorization or settlement, when these applications are sold, distributed or licensed to third parties. Most card brands encourage merchants to use payment applications that are tested and approved by the PCI SSC

PA-DSS is the Payment Application Data Security Standard, an entirely separate document available on the PCISSC website -- click on the Filter box and select PA-DSS. (In the old Web1.0 days I could give a hyperlink but the brave new world requires manual interaction for everything even for the tiny fraction of websites not 'monetizing' their users.)

Nearly all the substantive requirements in PA-DSS are based on requirements in the normal DSS, the one applicable to merchants and service providers (and now issuers) who actually process cardholder data and transactions, but many are adjusted to reflect the software development process. For example, where DSS requires a merchant/etc to configure access privileges for different users based on business need, such as viewing unmasked PAN, PA-DSS requires the application vendor to support such privileges and provide guidance on how the merchant can assign them after installing the software. Where DSS requires the merchant/SP to monitor logs and respond to problems, PA-DSS requires the application provide suitable logs to be monitored. And so on. The requirements about actually operating the network (including quarterly external scans) and physical environment don't apply at all. The only substantive requirement unique to PA-DSS is that you must write and provide an Implementation Guide and some related documentation that the merchant/etc, or a reseller/integrator if applicable (sounds like not in your case), can use in ensuring and documenting their system using your software as a whole satisfies DSS.

The bad news is there is no self-assessment track for PA-DSS application vendors; you must have an audit by a QSA specifically for PA-DSS called a PA-QSA or Payment Application Assessor -- note this is a separate item under the 'Assessors & Solutions' tab which leads to this list.

A possible alternative is that if you are contracted sufficiently under the direction of the merchant(s), they could treat you as effectively in-house, i.e. part of their own development team(s), developing 'solely' for them. But in that case they must be able to produce on demand all your design documents, coding standards, logs showing code changes were reviewed by a second person, training qualifications and possibly background investigations of all staff, etc. This will be very intrusive.

For more on the relationship between DSS and PA-DSS, see page 9 of DSS, particularly the last paragraph, emphasis added:

PCI DSS may apply to payment application vendors if the vendor stores, processes, or transmits cardholder data, or has access to their customers’ cardholder data (for example, in the role of a service provider).

Answer 2

Edit: This actually is unlikely to be correct. See dave_thompson_085's answer about the PA-DSS instead.

---

Original answer:

Unfortunately, you do need to be PCI compliant, as a SAQ-D Service Provider.
Here is a link to the official PCI Quick Reference guide. Some quotes:

The standards apply to all entities that store, process or transmit cardholder data – with requirements for software developers and manufacturers of applications and devices used in those transactions. [page 6]

The PA-DSS is for software vendors and others who develop payment applications that store, process or transmit cardholder data and/or sensitive authentication data as part of authorization or settlement, when these applications are sold, distributed or licensed to third parties. Most card brands encourage merchants to use payment applications that are tested and approved by the PCI SSC. [page 7]

Think of it this way: If your network gets compromised, no one gets cardholder data. But a vulnerability could be inserted into your application without you being aware, which would then be distributed to all your clients. (This is known as a supply chain attack.)

This page even explicitly calls it out:

However, not all organizations recognize their role as a service provider, and this lack of awareness puts their business—and their customers’ businesses—at risk. The last part of the service provider definition (“also includes companies that provide services that control or could impact the security of cardholder data”) is what often causes confusion. If a company offers, for example, a managed network firewall, and their customer uses that firewall to protect their point of sale systems and back office computer that make up their card data environment, then they absolutely can impact the security of card data.

Examples of service providers that often don’t know they are service providers include hosting, billing account management, back office services and co-location providers, just to name a few.

I haven't had to fill out a SAQ-D SP myself, but I believe you should be able to mark large swaths of it N/A (with supporting explanation in appendix C). For example:

• The questions specific to application development and secure coding (Requirements 6.3 and 6.5) only need to be answered if your organization develops its own custom applications. You would need to fill out these sections, since you're developing software.

• The questions for Requirements 9.1.1 and 9.3 only need to be answered for facilities with “sensitive areas” as defined here: “Sensitive areas” refers to any data center, server room or any area that houses systems that store, process, or transmit cardholder data. You could N/A this section, since you aren't touching the data yourself.

_{As always, I am not a QSA. You should probably consult with one to confirm/help define what you need to assess, rather than relying on one random person on the internet. This should get you started, though.}

Answer 3

per @Bobson, requirements 6.3 and 6.5 are in scope. Outside of 6.3 and 6.5 everything can be not applicable.

You could include requirement 6.6 and have application security testing performed on the application prior to release to the client. Your client could do this but you'd still have to implement the fixes so it may be preferable to provide a more secure application in the first place. The client can also meet this requirement by having a WAF.

The payments organisation can mark requirements 6.3 and 6.5 as N/A or as In Place with a statement the requirements are met by a third party, that being you. You should report your compliance to the payments organisation to satisfy their requirement 12.8 - monitoring of compliance of service providers.