That happens a lot and there are ways to deal with it, ratting out your competitors to authorities with silent hopes of crippling them and taking their business in the name of protecting the consumer is bad form at best and will come back to bite you hard at worst.
The person I was responding to was taking the position that you should not take against against someone if they are not harming you. That money saving, regardless of how it came about, harms OP's business, and so justifies action.
Note I didn't say the action should be calling authorities. Contacting the competitor and letting him know there is a problem would be action, too.
It wasn't about cost cutting. It was about me being young and foolish (and, looking back, I'm not sure it's even the stupidest mistake I've deployed to production in my career, but I'm not sure I want to admit to the other candidates just now :).
Also: if you want to delve into counterfactuals, consider what most PCI-compliant encrypted card storage schemes look like. Design a straw-man system yourself. You'll see the problem within minutes of starting. Remember that any cryptographic engineering that requires even a minute's worth of 'tzs cleverness is probably utterly beyond the raw capability of a line-of-business programmer at a major retail chain.
To the parent commenter's point, it's worth making a list of the 5 largest credit card breaches of the last 5 years and noting who provided their PCI attestation; you may find the result interesting.
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.
How do you conclude that it didn't do much good? The Target breach involved installing malware on the point-of-sale terminals to grab the data as the customer was paying.
As far as I know, the attackers didn't get to the stored credit card data. I suspect that they didn't get to that data in large part because Target was mostly in PCI compliance, meaning that the stored data was encrypted, on database servers isolated from the databases not involved in payment processing, on separate networks with strong access restrictions.
If Target had been treating PCI the way OP's competitor is, the Target breach could have been much much much worse.
> But I am debating the ethics of reporting a competitor for an activity that is NOT illegal, nor is it directly harming your customers or your business.
For a small business that is doing its own credit card storage, PCI compliance costs can be significant. They can easily double or triple the number of boxes you need at the data center.
The competitor is saving a lot of money by completely ignoring credit card security, which gives him an unfair advantage over OP. I'd consider that sufficient harm to OP to justify taking action.