By Dr. Heather Mark, CCEP
The complex puzzle of PCI DSS compliance can be made more challenging for merchants when they introduce the wide variety of service providers that they use in order to service their customers. Increasingly, Independent Software Vendors (ISVs) are working to simplifying their merchants’ burdens by introducing integrated payment functionality. In essence, the ISV is presenting a one-stop opportunity for merchants to support their business management objectives – be it through back office support, inventory management or billing – while also enabling payment functionality. In doing so, the ISV may inadvertently become the de facto resource for merchants on all things PCI DSS related. So, what are some things that ISVs can do to help support their merchants in achieving and maintaining PCI DSS compliance.
#1 – Understand your own PCI DSS compliance obligations and status
It isn’t uncommon for an ISV to be new to the payments ecosystem. Even for those companies that are deeply ingrained in the payments chain, the compliance and security obligations facing payments companies can sometimes get confusing. As an ISV, it is important to understand whether your integration of payment functionality renders you a Payment Service Provider, as defined by the PCI SSC. A Payment Service Provider is an entity that stores, processes, or transmits cardholder data on behalf of another entity, or can impact the security of the transaction. If the ISV integrates payments in such a way as to fall into that scope, then the ISV must validate compliance with the PCI DSS. Merchants must use PCI DSS compliant service providers, so it’s important that ISVs are prepared to provide their Attestation of Compliance (AOC) to their merchants.
If the ISV is able to offer payments functionality without falling into the Payment Service Provider scope, then the entity must be able to clearly articulate how they are able to maintain that status. For example, if the ISV has partnered with another PCI-compliant service provider to offer a hosted payment page, and the ISV does not host, nor does it redirect to that page, then it may be possible to remain out of scope. This is dependent on the ISV integration and the current guidance from the PCI SSC and the card brands.
#2 – Implement Industry Best Practice Even if You’re Not in Scope
Even if an ISV is able to maintain a posture that keeps it out of scope for PCI DSS, it is important to maintain industry best practice for data security and privacy. Having good security practice is not just necessary for those companies that are obligated to PCI DSS. Most states have data breach notification laws that offer safe harbor for encryption of sensitive data, as long as the encryption keys are not also exposed. Additionally, states are rapidly moving towards the adoption of privacy laws, most of which have data protection requirements. Maintain compliance with industry standards such as PCI DSS, even in the absence of card scheme requirements, can put an ISV, and by extension their clients, in good stead with respect to existing and forthcoming regulatory requirements.
#3 – Explain the Payment Integration Options that You Offer and their PCI Implications for Your Merchants
For ISVs that are looking to add payments functionality, it’s important to understand how that choices you make about the payment solutions you integrate cascade down to merchants. For instance, if an ISV integrates a hosted payment page the likelihood that the merchant will be able validate their own compliance using the SAQ-A is fairly high. However, if an ISV integrates and offers a redirected page, the merchant is more likely to be required to validate using an SAQ A-EP, which is a much longer questionnaire. Both may be valid choices for a variety of reasons, but ISVs should understand the implications on their merchants
#4 – Clearly Communicate Who Owns What Responsibilities
The interplay between merchants and service providers can be complex, particularly if merchants are able to select services and features a la carte. This can lead to uncertainty as to which entity might own responsibility for various security controls. ISVs can demonstrate partnership with their merchants by providing a “shared responsibility” matrix. The matrix doesn’t need to be very complicated, but it should clearly delineate which PCI responsibilities belong the ISV and which belong to the client. Since all merchants must comply, and any business with a Merchant Identifier (MID) must validation compliance, this documentation can significantly simplify their own process of PCI compliance management.
PCI DSS compliance is a fact of life for any participant in the payment system. Understanding how your decisions as an ISV can impact the compliance standing of your client portfolio can help you make more informed decisions about the solutions that you implement and may simplify the compliance and validation process for your merchants.
