2 added 196 characters in body
source | link

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.

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.

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.

1
source | link

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.