Tag Archives: pci

Pop Quiz: PCI Compliance

This post was first published on the Idealware Blog in August of 2009.

The credit card industry is doing the right thing by consumers and enforcing proper security measures regarding the handling of credit card information.  You might have heard about this – a number of the popular vendors of donor databases are recommending upgrades based on their compliance with these regulations. The “Payment Card Industry Data Security Standard”, commonly known as PCIDSS, is a set of guidelines for securely handling credit card information.  The standard has been around for about four years, but early enforcement efforts focused on companies with a high volume of credit card transactions.  Now that they’re all in compliance, they’ve set their sites on smaller businesses and nonprofits. So, what does this mean? Here’s the simplest F.A.Q. that you’re likely to find on the topic:

  • Do you ever process online, phoned in, or mailed-in credit card donations in-house? e.g., do you maintain the credit card number, expiration date and name of a donor?

If no, you don’t have to worry about this.

  • If yes, do you have more than 20,000 such transactions annually?

Well, if you do, congratulations!  Most nonprofits don’t, so they qualify for level 4 of the PCI Compliance scale. That results in a Self Assessment Questionnaire (SAQ) Validation type of “4”.  Higher validation types are subject to stricter security standards.

The Self-Assessment Questionnaire will ask you all sorts of technical questions about your network and security procedures.  Do you have a firewall?  Are all of your transactions encrypted?  Do you use anti-virus software?  Is credit card information properly restricted to authorized staff?

Depending on your network, you might already comply with a lot of the requirements.  If you don’t, then it might require a significant investment to get there.

  • What will happen if I ignore this?

This isn’t government regulation (although your state might have laws in place that do mandate some similar response). Participation is not mandatory.  But, should your security be breached, two things will happen:

  1. The compliance requirements for your organization will be reassessed to level one or two, and they’ll be much more costly and complicated to meet.  The credit card companies might decline to do business with you if you don’t comply.  Can you afford to not take Visa?
  2. You will likely be indirectly fined for non-compliance.  The credit card companies will hold your bank liable for losses due to credit card theft in situations where your security was substandard.  Your bank will likely pass that fine on to you.
  • So what’s the easiest way to deal with this?

Simple: don’t handle credit cards.  There are a number of services that, for a price, will do this for you, from Paypal and Google Checkout to CharityWeb and Blackbaud’s BBNow. Outsourced ECRM software (NetCommunity, Convio, Democracy in Action, etc.) will also handle it. The cost is likely not as significant as that of maintaining compliance or suffering the consequences of a non-compliant breach.

I’ll share that, at the Goodwill where I used to work, outsourcing wasn’t an option, because we were both a charity and a retailer. Our frustration was not that we didn’t have good security in place.  It was that there were differences in how we had set up our security and the PCIDSS requirements.  So, while we had done a lot of work and made significant investments, we still had to reconfigure things and spend more in order to be compliant.  In addition to making our internal IT changes, we had to switch software programs in order to avoid storing credit cards unencrypted in our database, a typical problem.  We also engaged a consultant.  Once you are reasonably sure that you comply, then you must pay a security service to verify your efforts, another non-trivial expense.

Blackbaud has put together some good further reading on this topic (and they are one of the vendor’s whose latest software is compliant; ask your eCRM vendor!).

Complying with Data Security Regulation

This post was originally published on the Idealware Blog in November of 2008.
An article appeared in the NonProfit Times this week regarding a recent ruling in Nevada requiring that all personal information be securely transmitted, e.g. encrypted. The article, States Push To Encrypt Personal Data is by Michelle Donahue, and quotes, among others, me and our friend Holly Ross, Executive Director of NTEN — it’s a worthwhile read. The law in question is a part of Nevada’s Miscellaneous Trade Regulations and Prohibited Acts. I’ve quoted the relative pieces of this legislation below, but I’ll sum it up here:

Personal information can not be transferred to you by your customers (donors) without encryption. Personal information is defined as any transmittal of someone’s name along with their credit card number, driver’s license, or other data that could be used to access their financial records.

Nevada is the first state to pass legislation like this, but it’s a good bet that they are the first of fifty. Massachusetts is right behind them. And if the government won’t get you, the credit card industry might. The regulations that they impose on larger retailers for credit card security are even tougher. These initially applied to retailers bringing in far more money via credit card than most of us do, but they have lowered the financial threshold each year, bringing smaller and smaller organizations under that regulatory umbrella.

So, the question is, how many of you receive donations via email? If you do accept donations over the web, are you certain that they’re encrypted from the time of input until they land inside your (secured) network? What do you do with them when you receive them? Do you email credit card numbers within the office? Retain them in a database, spreadsheet or document?

Most nonprofits are understaffed and unautomated. We accept donations in any manner that the donors choose to send them, and get them into our records-keeping systems in a myriad of fashions. The bad news here is that this will have to change. The good news is, if you do it right, you should be able to adopt new practices that streamline the maintenance of your donor data and reduce the workload. Even better, if the solution is to move from Excel or Word to Salesforce or Etapestry, then you’ll not only have a better records-keeping system, you’ll also have good analytical tools for working with your donors.

Automating systems, refining business processes, improving data management and maintenance — these are all of the things that we know are important to do someday. It looks like the urgency is rising. So don’t treat this threat as an impediment to your operations — treat it like an opportunity to justify some necessary improvements in your organization.

The relevent snippet from the Nevada law:

” 1. A business in this State shall not transfer any personal information of a customer through an electronic transmission other than a facsimile to a person outside of the secure system of the business unless the business uses encryption to ensure the security of electronic transmission.

2. As used in this section:

(a) “Encryption” has the meaning ascribed to it in NRS 205.4742.

(b) “Personal information” has the meaning ascribed to it in NRS 603A.040.

“Personal Information” is defined as:

“Personal information” means a natural person’s first name or first initial and last name in combination with any one or more of the following data elements, when the name and data elements are not encrypted:

1. Social security number.

2. Driver’s license number or identification card number.

3. Account number, credit card number or debit card number, in combination with any required security code, access code or password that would permit access to the person’s financial account.

The term does not include the last four digits of a social security number or publicly available information that is lawfully made available to the general public.