Back in the 80s I worked for a company that did back office accounting systems. Then I moved to a large non-profit and was in charge of both back office and customer facing systems. This was when the Internet was for non-commercial traffic only, so "customer facing" meant a live operator at a dumb terminal hooked up to a minicomputer.
My new employer wanted me to develop a system that would among other things take credit cards from donors and volunteers. I was pretty confident on the technical end of things, but I wasn't sure about handing the financial data. So I called in a CPA friend I'd met at my prior job, and he looked over a the design documentation for the system to make sure everything was kosher.
"You can't store credit card information in the database," he said.
"Why not?"
"Because it's insecure," he said.
"But it's convenient," I said.
"That's the problem," he said. "Look, any of the operators will be able to look up credit card information on any donor. Some of these donors are rich. You'd be able to go on one hell of a shopping spree with just one of their credit cards."
"What if I make it harder to look up the data?"
"Then it's not convenient anymore," he said. "Look, you don't actually have a use for this data once you've processed the credit card transactions. And while you're keeping it around in case you might someday have a use for it, it leaves you wide open to theft. It'd be a disaster; customers won't do business with you because your reputation will be in the toilet. Get rid of it. Get it out of the database, any logs you have, and make sure it's not in any backup tapes."
And when I thought about it I realized he was right. There was no point in exposing my employer to risk for no real benefit. That's when I learned an important principle of security: don't hold onto sensitive data that you don't actually have a use for. I suppose you could generalize: don't keep sensitive data on any system where there is no compelling need to store it there.
Things have changed now; storing credit card data has come to be regarded as routine in the post-1 click, impulse buy Internet world. But even though it is the *norm*, that doesn't mean you should automatically do it. There's actually a use in a web store for storing credit card data which offsets the risk (which you should still minimize). There's no reason for a restaurant to store credit card information -- that's just blind habit. Waiter takes the customer credit card, runs the transaction, and hands the card back to the customer, and then restaurant no longer has the data. You can't lose what you don't have.
Of course in this case it's probably not P.F. Chang's fault. They bought a POS system which left them open. It probably is all slick and really very helpful at keeping things moving, like maybe taking the customers card at the table. It'd be interesting to know how the POS system vendor screwed this up, because clearly they did.
There is no encryption or security architecture that beats not having the data.