“Are you PCI compliant?”. It’s a frequently asked question and even more so, misstated. To be clear, PCI compliance is a catch-all term that ensures an entity has adhered to guidelines for secure handling of personal information in payment processing. PCI compliance generally refers to a merchant’s suitability to securely process payments. Nevertheless, the more accurate term is PCI DSS, which stands for Payment Card Industry Data Security Standard.
All entities that participate in the handling and processing of credit/debit card payments, must meet PCI DSS compliance, however each type of entity has a specific set of guidelines to satisfy. Banks, data centers, application developers, merchants, etc. must meet different, although often overlapping, standards.
Companies that develop point of sale applications, typically called ISVs, have two approaches to PCI DSS compliance. If the developer’s product directly collects, handles or processes personal payment information, it must be PA-DSS validated. PA-DSS is a specific set of guidelines for payment applications, hence its name, Payment Application – Data Security Standard. Keep in mind that not all POS products qualify as payment applications and not all payment applications are conventional POS products.
If a POS application never directly handles the credit/debit card information, it can still achieve PCI DSS compliance by using the “out of scope” designation. This classification of compliance allows the ISV to shift the burden of PA-DSS validation to a third-party product, which is typically installed as a component of the overall POS system. “Out of scope” is the easiest and fastest approach to PCI DSS compliance for an ISV.
PA-DSS validation, on the other hand, is a rigorous and exhaustive process that ultimately allows an ISV to directly handle personal payment information in its product.
Why Choose PA-DSS Validation?
The “out of scope” designation allows a third party to securely collect and process payment information on behalf of the POS application. The third-party application, of course, must meet the PA-DSS threshold. In some cases, the ISV developing the POS application will choose to undergo PA-DSS validation, rather than use the much easier “out of scope” designation.
In order for an ISV to achieve PA-DSS validation, it must submit to an exhaustive assessment by an independent Qualified Security Assessor or QSA. The QSA is required to inspect and assess the product against hundreds of security requirements and testing procedures combined. The process typically takes 2-4 weeks and almost always requires some remedial action by the ISV before submission to the PCI security council for final validation.
Speaking from my own experiences, the assessment is demanding, stressful and borderline combative. At times, it feels like an interrogation without representation or due process. It is invasive, exhausting and even condescending. Yet, in spite of my less-than-flattering language, I fully support the initiative.
PA-DSS emphasizes best-practices. The assessment exhaustively covers, not just the product’s security, but the entire software development process. This includes documentation procedures, development methodology, security vulnerability monitoring, key rotation, coding practices, password access, network segmentation, operational procedures, role and access management, internal auditing and so much more. In other words, PA-DSS values that the finished product is only as secure as its immediate and fringe influences. If a chain is as strong as its weakest link, then PA-DSS demands that each link be thoroughly inspected for integrity flaws.
As a byproduct of PA-DSS assessment, an ISV is forced to comply with software development best practices and in doing so, builds a better product. Not just the security, but the overall product integrity is fortified as well.
The highly invasive audit examines virtually every aspect and behavior that can influence the product outcome. It’s analogous to building a house where not only the construction is inspected, but every building material, every worker and every tool is evaluated for potential flaws or integrity compromise. The broad scope of PA-DSS assessment is designed to discover any potential weak link and remedy it before product release. In some cases, the guidelines are so far reaching, it compels developers and product managers to expand their comprehension of potential vulnerabilities. This change in thought process positively impacts all aspects of development and operations, ultimately delivering better solutions. The final result is that PA-DSS yields benefits that reach well beyond payment security.
As mentioned earlier, ISVs can choose to bypass the PA-DSS validation by using the “out of scope” approach. They do so by integrating with a third-party component that meets the validation requirements of PA-DSS and relieves them of PA-DSS burden. While this meets the minimum payment security requirements, the out-of-scope designated ISV misses out on the residual benefits of third-party review. Without an opportunity for best-practices evaluation, the developer forgoes feedback critical to process improvement. Moreover, there is no transparency or openness to any independent organization demonstrating best-practices compliance. While it’s common for businesses across all industries to voluntarily seek standards certifications such as ISO, SSAE, Six Sigma and many others, the point-of-sale domain has been long absent a standards program and PA-DSS closes the gap well. Regardless of PCI scope designation, all ISVs in this space should consider voluntary assessment for PA-DSS.
SoftTouch is proud to wear its PA-DSS designation as a badge of honor while enjoying the benefits of superior quality software.