Many of us who deal with Payment Card Industry (“PCI”) compliance on a regular basis take the associated terminology for granted. Yet, when I explain PCI to my mother, I describe it in its simplest form as “credit card processing security methods.” The topic came up recently because charges from a department store in California started showing up on her credit card statement, and she rarely ventures far from the family home in Virginia Beach. It is, of course, difficult to know how her card information was compromised, but it served as another reminder of how important and serious a role we play as financial professionals in protecting our customers’ sensitive information.
For any organization that processes credit cards (“merchants” in PCI-speak), the starting point for PCI compliance is to contact your credit card processor to find out their requirements and recommendations. Then visit the website of the PCI Security Standards Council to find out where you fit in the PCI compliance world. It can start to feel overwhelming pretty quickly as you try to determine if your organization should fill out a Self-Assessment Questionnaire A (“SAQ-A”), Self-Assessment Questionnaire D (“SAQ-D”), or determine if you need a Qualified Security Assessor (QSA) to audit you, or what a ROC (Report on Compliance) is and what version you’re on, anyway. I recommend starting with gaining an understanding of your basic credit card processing profile, such as your volume of annual transactions (in count and value) and what systems you use for processing. The PCI Security Standards Council has a very useful guide on where you can go from there available here on the PCI Security Standards website.
As CFO of Aptify, I have been tackling PCI compliance on two fronts: as a merchant and as a service provider. As a merchant, we use many of the same methods our association clients use. In fact, we use the Aptify software, which is a PA-DSS validated application, for our own invoice and payment processing; we like to say we drink our own champagne. Our methods include tokenization, which means we do not store credit card information in our database but rather substitute a non-sensitive data equivalent from our credit card processor. We also employ simpler methods like establishing and following policies prohibiting us from EVER writing a credit card number on a sticky note.
As a service provider, I have been really pleased with the evolution to the latest PCI Data Security Standard that requires a “responsibility matrix” so that there is clarity for our Aptify Cloud and SaaS clients about which PCI requirements are solely Aptify’s responsibility, which are solely our clients’ responsibility, and which are shared. This is obviously helpful from an audit perspective for our clients but most importantly, it reduces the risk that a vulnerability could arise from lack of clarity about who is responsible for ensuring particular controls are in-place and well managed.
No one is ever finished with PCI compliance. It is constantly evolving as new risks emerge, technologies evolve, and standards are clarified. I’d love to hear about your experiences. The more we know, the more we’re able to protect our clients and your members. Email me at kevin.friel@aptify.com for more information.
