I agree OP should report them, though.
Unless a law is being broken AND it's creating an unsafe situation for your customers or your company, leave it alone. In my opinion it's a classless move to go after your competitors in that fashion. Beat them with a better product. In this case, a "better" product would seem to be one with PCI compliance.
As far as the "toxic waste" analogy -- I've never heard of anyone getting cancer and dying from a lack of PCI compliance. In fact, there are likely more important things to worry about than PCI compliance -- Target and all of the other high profile retailers that were credit-card hacked -- they were all allegedly PCI compliant, yet it still didn't do much good. I'm not hear to debate the value of PCI compliance -- if it's a requirement of your business, then obviously you have to do it. 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.
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.
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.
This is not true. As a vendor, I assume costs associated with PCI compliance and other industry-standard best practices. If my competitor is ignoring these I am fundamentally disadvantaged. It's not an equal marketplace at that point.
Whether intentional on the competitor's part or not, this is saving them money and placing their customers at risk of identity theft, financial fraud and who knows what else depending on what's stored in that database.
> But reporting him to the authorities? That's very Stasi-esque.
Holy hyperbole, Batman. As a customer, I deserve to know if my vendor is eschewing industry-standard security practices. And they should be mercilessly shamed if they are.
Actually, no. If the CC numbers are used fraudulently, the clients of that company will just issue chargebacks; at most, they'll need to get new cards. The people who'll have to pay are the merchants who will get hit with those chargebacks - and indirectly everyone else, since prices are raised to pay for those losses.
Are you advocating that unless you're black, you shouldn't have supported (or got involved with) the black civil rights movement?
Edit:: I have not made up my mind yet. Admittedly, at the time of posting I was leaning more toward that side.
After reading everyone's advice, I'm leaning more toward a multi-tiered approach as @jacquesm suggested. It seems to avoid bad karma and burning bridges. Also, it seems as though the PCI Industry rarely acts on reports. So, working with the competitor to fix their issues could be the best thing down the road. It's a very small industry, and the possibility of a buy-out could exist in a few years.
Similarly, I find it to be insanely frustrating when people ask for advice, but are not willing to listen when they get it. It feels dishonest.
(b) It seems to me that the customer in question is in a much better position to file a complaint than you are. I can't see anything wrong (but see (a)) with writing them a detailed letter explaining the implications of what you found during the transfer. They will probably not want to act on it, but if they do, they can't be accused of ulterior motives.
(c) You could try the tack of advertising very loudly that you're PCI compliant, without ever mentioning your competitor. (Is there third-party PCI certification? If so, you might want to get it.) Yes, everyone who handles credit cards is supposed to be PCI compliant, but customers don't necessarily know that; you could perhaps make it a differentiator. If your competitor is so unscrupulous as to advertise themselves as compliant when they're not, possibly (see (a)) you could then report them yourself.
For it to actually really hurt your competitor, you'd have to probably astroturf some forums, acting like concerned customers, and get other customers upset. And even then, you're just going to cost them a week or so. Maybe if you timed it for maximum damage, but just don't waste too much time on it.
Regardless, I still feel reporting is the ethical thing to do.
You should report him for the same reason that you should report a competitor that is dumping toxic waste in a stream.
They are externalizing costs to society as a whole to maximize their gain.
There is no malice is demanding that everyone respect the law that safeguards us all.
If the competitor does not wish to follow the law then they can move to a locale that does not have that law.