SQL Clone
SQLServerCentral is supported by Redgate
Log in  ::  Register  ::  Not logged in

The SQLAndy Rules for Storing Credit Card Numbers

I’ll try to write more about these over the next couple months, but I wanted to write down a quick reference for those that have to deal with storing credit card numbers. These rules cover the basics – the full topic of protecting card data is easily a book or two. These are my rules, when in doubt consult with your compliance team for final guidance.

  1. Don’t Store Them! PCI compliance is complex and expensive. Getting hacked and dealing with the consequences is more complex and more expensive. Offload the problem to a vendor.
  2. Encrypt The Card Number. If you insist on storing credit card numbers they must be encrypted at rest and you have to document a key management plan that will make your head hurt. Remember this applies to more than just databases – it’s batch processing and voice recordings too. No home grown XOR stuff either, you need big dog encryption.
  3. Do NOT Store Track Data, CVV, CVV2, or PIN. Store any of these and you are automatically “non-compliant” as far as PCI goes. Beyond that, you’re taking a risk that cannot be justified when a breach occurs.
  4. Tokenize Card Numbers. Tokens “don’t count” as long as the tokenization method used is sound. Tokens let you do things like process cancellations without needing the ‘real’ card number.  Tokens do not need to be encrypted.
  5. You Can Store Some Things. You can store first six/last four characters of the card number. You can store the expiration date and the card holder name. None of those require encryption. Don’t store it if you don’t need it.
  6. Log All Access. If someone stores OR retrieves a card number you need to know who, why, when, where, what, and how. If you use tokens, do the same for the tokenize/de-tokenize calls. Logs are incredibly important. They allow you to monitor and potentially detect hackers, and they are your best chance of determining the scope of a breach when it happens. Don’t skimp on this. You need 90 days online and the ability to get the past 12 months in a relatively short time.
  7. NULL When Done. As soon as you know you won’t need the card number, null it out or replace with some type of non-reversible artifact (xxxxxxxx-1234). PCI doesn’t require this. Common sense does.
  8. Never Use Live Cards In Development. Never. Even if you’re using encryption never land valid card numbers in any type of development/non-prod/non-PCI environment. That means no direct backup prod/restore to dev type operations, you have to change/erase those card numbers before it lands on disk in dev.
  9. Mind Your Tools. Profiler, third party monitoring tools, SSIS packages, they can all potentially capture and store card data as part of normal and seemingly routine activities. All the same rules apply to that data store too.


I'm Andy Warren, currently a SQL Server trainer with End to End Training. Over the past few years I've been a developer, DBA, and IT Director. I was one of the original founders of SQLServerCentral.com and helped grow that community from zero to about 300k members before deciding to move on to other ventures.


Leave a comment on the original post [sqlandy.com, opens in a new window]

Loading comments...