What most struck me about PCI compliance is how far and how wide its tentacles ended up reaching beyond the obvious places.
For instance, suppose you allow orders over the telephone. A customer can call, talk to a salesperson, and then place an order. The customer will read their credit card information over the phone and the salesperson will enter it into the ordering system.
If your phone system is a VOIP system, congratulations! It's in scope for PCI! Since you probably don't want to have to deal with PCI for every phone in the company, you'll probably end up having to segment your system, so you can restrict sales calls to one segment.
If you are recording some sales calls so that managers can review them for training purposes, you either have to find a way to not record the parts of calls where credit card numbers are read, or you have to treat the recording as sensitive cardholder data and encrypt it. You might think you could just encrypt all the recordings and be done with it. Sadly, that's not good enough, because of the CSC code. You are not allowed to store the CSC code even if you do encrypt it.
Some people implement a system whereby the salesperson can press a button when the customer is about the give sensitive information, and that pauses recording for a few seconds. From what I've read, this is NOT sufficient for PCI compliance.
There are some approaches (aside from giving up on recording) that appear to be acceptable.
1. There is a system called CallGuard [1]. You integrate this with your phone system and your order entry system. When it is time for the caller to enter their card number and CSC, they do so with their phone keypad instead of by voice. CallGuard blocks the touch tones from the recording, interprets them, and enters them into your order system.
2. You can make it so that when a salesperson brings up the card number and CSC entry form, that automatically pauses recording until the form is submitted.
3. You can temporarily transfer the call to an interactive voice response system that gets the numbers and puts them in your order form, and then transfers the customer back to you.
Next up--email! A customer's recurring payment fails because they did not update their account when they got a new card. Your system sends them an email. The customer wants to update their card in response. Some will try to do this by email. They will fire of an email to your support address that tells you they have a new card and includes the number.
Now you've got a credit card number stored in the mailboxes of everyone who receives copies of support requests, and you'll have to do something about this. At least with a credit card in a mailbox, it's likely to be in a fairly standard and documented format.
If your company is big enough to have outgrown handling support requests by having a "support" mailbox that all your support people read, you probably have some kind of help desk system, and that's where that customer email with the credit card number ends up. So now you find yourself digging around in some big PHP codebase, and poking around a MySQL database that has a couple hundred tables whose names make no sense to you, trying to figure out how tickets are stored and what you have to do to modify a ticket to mask the credit card.
And somewhere in here, you should be thinking about how you will write a script to scan for these things, so you don't have to rely on support people noticing them and calling them to your intention. You'll have fun discovering the various ways people can vary the formatting of credit card numbers. When you make your credit card number recognizer handle enough weird formatting to work well, then you'll find someone that gave you a zip code (5 digits), and a phone number including the '1' for long distance, and formatted those so weirdly that your credit card recognizer flagged them.
...and let's not forget about chat. If you do support via chat, you will have people typing in credit card numbers. If you are lucky, your chat system is part of your help desk system, and so while you were reverse engineering that to deal with credit card numbers in ticket, you happened to figure out where and how it stores chat logs.
If you do NOT automate dealing with email and chat, at some point a support person is going to bring to your attention a ticket or chat log with a credit card number, and you'll go into the database and fix it. If you are lucky, the support people noticed it quickly. If you are unlucky, it was sitting there for a while--and so it is now on your backups.
[1] http://www.callguard.co