Any organization that stores, processes, or transmits payment card data, or any entity that could have an impact on the security of payment card data, is required by the card brands to comply with PCI DSS. Many merchants, however, only find out about their PCI footprint when an assessment forces the question. By then, the platform decisions that created that scope were made far in advance.
For many merchants, payment architecture and solution decisions made by their software platform partner (ISV) have a profound impact on the rigor of the merchant’s PCI annual compliance validation. This can range from a 22-questionnaire requirement to a 328-questionnaire requirement and can influence whether the merchant’s website is in-scope for external vulnerability scans. For this reason, it’s important for ISVs to partner with a payments provider that has deep experience and expertise as early as possible to consult on payment architecture.
PCI DSS compliance remains the merchant’s responsibility, but the amount of work involved can vary substantially. ISVs play a significant role in determining how much PCI scope their merchants ultimately inherit. This makes platform architecture an important compliance consideration in addressing the risk to the merchant’s business.
Related Content: PCI 4.0.1: What Every Business Needs to Know
How architecture reduces PCI scope
There are many ways to get payment data from point A to point B and considerations related to which entity hosts which pieces impact both PCI scope and, ultimately, security. As a result, payment architecture should be part of early planning for ISVs. By doing so, ISVs can limit PCI scope for their merchant customers handily and, instead, take on the technical requirements of PCI themselves. A good payment partner will provide full visibility to ISVs in understanding the payment industry requirements and the risk.
What PCI compliance for ISVs requires
Merchants often assume compliance is settled once a processor is PCI-validated, but that’s not the case. Only 14.3% of organizations achieved full PCI DSS compliance during interim validation in 2023. PCI compliance covers people, processes, and technology, and a validated processor only accounts for one part of that.
The split typically looks like this:
- The ISV and processor cover the systems piece, provided their own infrastructures are validated.
- The merchant remains responsible for how their own staff and workflows handle card data and for confirming that their partners are compliant.
If hosting payment pages, many ISVs are not aware of their PCI scope as a service provider. If credit card transaction volume going through their payment page reaches a certain volume, they become a Level 1 Service Provider which requires the most stringent PCI controls in the industry and must be assessed annually by a third-party certified entity. Recent changes in PCI have increased their responsibilities related to monitoring scripts and http, for instance.
If the ISV is not fulfilling these payment industry requirements, then all of their customers are defaulting on their requirements which can put their businesses at risk.
The best time to understand PCI scope is before payment architecture decisions are locked in. ISVs don’t need to become PCI experts, but they should understand how their technology choices affect both their merchants’ compliance burden and their own responsibilities. If you are an ISV with embedded payments or are considering a payment integration, make sure you can confidently answer these five questions:
- Do we know what PCI scope our payment architecture creates for our merchants?
- Do we know whether our software or infrastructure puts us in PCI scope as a service provider?
- Do we know exactly where cardholder data travels, and which systems can affect its security?
- Are responsibilities between us, our payment provider, and our merchants clearly understood?
- Are we involving PCI expertise early enough to reduce scope rather than trying to address it after the architecture is already built?
"*" indicates required fields