If your nonprofit takes payments of any kind, then you need to be familiar with a scary, yet vital protocol called PCI.
PCI (payment card industry) compliance is a set of rules and regulations ensuring that payments are secure, and no cardholder data is at risk to hackers and scammers.
Nonprofits must abide by these rules, or face fines between $5,000 and $500,000. PCI compliance is a necessary part of your nonprofit's security plan.
If you use an e-commerce package or online donation tool, PCI compliance is often already done for you by the company providing the platform, but you should know how it works.
For now, we’re going to focus on the two most likely scenarios: those who outsource all of their payment processing to a third party and organizations who outsource most of their payment processing. All of the below solely applies to web transactions.
One of the first steps of PCI Compliance is determining where your nonprofit falls into the PCI Compliance spectrum. There are eight different classifications that are given confusing titles such as “SAQ B-IP.” The SAQ stands for Self-Assessment Questionnaire, and the vast majority of our lovely readers will fall into the first two categories: SAQ-A and SAQ A-EP.
This is for the group of nonprofits that outsource all of their payment processing to a third party.
Examples of organizations that fall into this category:
In these scenarios, you never touch the cardholder data, because these sites/services are doing the heavy lifting. This is the simplest way to go.
This is for the group of nonprofits that outsource most of their payment processing, but at some point during the payment process, the nonprofit’s site/ server is touched. The main difference between SAQ-A and SAQ A-EP is that SAQ A-EP controls how the information is passed to the PCI-compliant vendor.
Examples of organizations that fall into this category:
Well, my first and obvious suggestion would be to change your processes so you can fall into the SAQ-A category. But, if that’s not an option, let’s continue.
There are 12 requirements that you’ll need to pursue. Please note there’s a lot more to these, but here’s a good primer:
As you have deduced, SAQ-EP is a massive task and one that can consume energy, resources, and budget. If you’re completely overwhelmed by everything that’s needed to be accomplished to be fully compliant in this, consider what’s needed to move from SAQ-EP to SAQ-A.
I’m not a PCI Compliance specialist, just someone who knows enough to raise awareness on this important topic. For a comprehensive overview, please head over to the PCI Security Standards Council site.
Becoming PCI compliant is imperative, especially as more organizations’ data practices are under increased scrutiny. While all of this sounds extremely technical, PCI compliance is not just an IT function. Instead, it involves buy-in from your entire organization and support from the top.
Go forth, good people, and take these steps to ensure a better, more secure web!
PCI (payment card industry) compliance is a set of rules and regulations ensuring that payments are secure, and no cardholder data is at risk to hackers and scammers.
Nonprofits must abide by these rules, or face fines between $5,000 and $500,000. PCI compliance is a necessary part of your nonprofit's security plan.
If you use an e-commerce package or online donation tool, PCI compliance is often already done for you by the company providing the platform, but you should know how it works.
For now, we’re going to focus on the two most likely scenarios: those who outsource all of their payment processing to a third party and organizations who outsource most of their payment processing. All of the below solely applies to web transactions.
Define who you are
One of the first steps of PCI Compliance is determining where your nonprofit falls into the PCI Compliance spectrum. There are eight different classifications that are given confusing titles such as “SAQ B-IP.” The SAQ stands for Self-Assessment Questionnaire, and the vast majority of our lovely readers will fall into the first two categories: SAQ-A and SAQ A-EP.
SAQ-A
This is for the group of nonprofits that outsource all of their payment processing to a third party.
Examples of organizations that fall into this category:
- Donations made on a third-party site such as DonorBox or Classy.org.
- Donations made on your nonprofit’s site, but using a PCI-compliant solution such as Formstack with Stripe integration.
- Events payments made on sites such as EventBrite.
- E-commerce done on sites such as Shopify, or payments made on PayPal.com.
In these scenarios, you never touch the cardholder data, because these sites/services are doing the heavy lifting. This is the simplest way to go.
SAQ-A: What you should do
- Destroy all paper copies of cardholder data, if you’ve received it.
- Ask questions of your vendors to ensure they’re PCI compliant. Get it in writing, or take a screenshot on their site. It’s been known that some vendors have stated they’re compliant, but then oscillated to a “whoops, we weren’t compliant.” Not good.
- Monitor/ check-in with the vendors to ensure they’re maintaining PCI compliance.
SAQ A-EP
This is for the group of nonprofits that outsource most of their payment processing, but at some point during the payment process, the nonprofit’s site/ server is touched. The main difference between SAQ-A and SAQ A-EP is that SAQ A-EP controls how the information is passed to the PCI-compliant vendor.
Examples of organizations that fall into this category:
- Donations and other transactions made on your nonprofit’s site are using a gateway such as Authorize.net (non-hosted solution).
- Transactions made are using a solution such as PayPal’s PayFlow.
SAQ-EP: What you need to do
Well, my first and obvious suggestion would be to change your processes so you can fall into the SAQ-A category. But, if that’s not an option, let’s continue.
There are 12 requirements that you’ll need to pursue. Please note there’s a lot more to these, but here’s a good primer:
- Install a firewall. Get a solid hosting provider, and they should be able to do this for you.
- Be careful with your passwords. Don’t use vendor-supplied passwords, and don’t use "password123" or your dog’s name. You catch my drift.
- Protect cardholder data. Getting technical pretty quickly here, but you’re here because you’re smart! Ensure the stored data is fully encrypted, and be sure the encryption keys are protected. There are cases where the encryption keys are laying around, or are in a spreadsheet—that's not protected. Also, ensure the cardholder data isn’t laying around in a spreadsheet somewhere or on physical paper. This requirement item also requires a flowchart of cardholder data.
- Protect how cardholder data is transmitted. Before, we were talking about stored data. This item is all about protecting how the data is transmitted.
- Say no to the viruses! Ensure you have anti-virus software on any system and application that touches cardholder data (phones, tablets, computers, servers, etc.).
- Be current. Many, many breaches are due to outdated software installed on your machines or server. Ensure you’re constantly on the latest, most stable versions.
- Be choosy with who gets access. Not everybody needs access to your sensitive data. Be particular with who gets access to what.
- Be a fortress with your usernames and passwords. Ensure you have a solid policy for usernames/ passwords, and have logic in place to disallow usernames/ passwords that aren’t secure. Set password lockouts (such as “You’ve entered your password incorrectly 3 times, therefore I’m not letting you in"), as well as enabling multi-factor authentication (your password in addition to something only you have, such as your fingerprint or a hardware token).
- Your physical space must also be a fortress. Having all of the above in place is for naught if someone can walk into your office and change everything.
- Monitor all access to the data. Keep detailed logging of who’s accessing what information, as well as how and where they’re accessing it.
- Regularly test. How often does your technology seem to break for no reason? For a secure environment, regular testing controls are imperative.
- Have a policy. All of this is confusing, and your staff will find it equally confusing. Ensure you have a policy in place that clearly addresses security standards and procedures.
Limiting your PCI compliance scope
As you have deduced, SAQ-EP is a massive task and one that can consume energy, resources, and budget. If you’re completely overwhelmed by everything that’s needed to be accomplished to be fully compliant in this, consider what’s needed to move from SAQ-EP to SAQ-A.
In conclusion
I’m not a PCI Compliance specialist, just someone who knows enough to raise awareness on this important topic. For a comprehensive overview, please head over to the PCI Security Standards Council site.
Becoming PCI compliant is imperative, especially as more organizations’ data practices are under increased scrutiny. While all of this sounds extremely technical, PCI compliance is not just an IT function. Instead, it involves buy-in from your entire organization and support from the top.
Go forth, good people, and take these steps to ensure a better, more secure web!
