RadioShack Rep Used Customer Data To File False Tax Returns. Why Is RadioShack Even Still Collecting SS Numbers?
Written by Evan SchumanWhen a Radio Shack call center representative was sentenced to prison on Monday (July 23), it was because she had pled guilty to filing false tax returns to collect refunds. The information she needed to create bogus tax returns, including valid Social Security numbers, came from Radio Shack customers with whom she had worked. But why was Radio Shack collecting and storing Social Security numbers in the first place?
Turns out the call center rep, Youlanda Rochelle Wright, was collecting Social Security numbers as part of RadioShack’s then deal with Dish Networks. Dish apparently required those numbers when giving new customers credit. Given the bad publicity coming from this 6.5-year prison sentence for a onetime RadioShack customer service rep accused of ripping off her customers, it might be time to call for strict IT rules on refusing to store ultra-sensitive data, such as Social Security numbers.
Why not borrow a tactic from payment security and use a token? Or perhaps require partners to collect such data themselves? Or send those customers to a site for capturing that data in a way customer service reps cannot access?
Wright’s attorney, Catherine Dunnavant, argued that if chains like RadioShack want to avoid such problems, deciding to never collect this type of data is a good place to start. “This was really tempting. It’s crazy easy,” Dunnavant said about her client’s ability to craft complete tax returns solely using what RadioShack gave to her. “I believe it was too easy.”
Chains such as RadioShack would never consider storing payment-card data in the clear, lest they be hit by both PCI and the Federal Trade Commission (FTC). Heck, the courts have even forced retailers to give up on asking for ZIP codes at checkout. But the absence of PCI-like rules for privacy data has left a huge vacuum. IT must deal with this issue through policy. By the way, encryption wouldn’t have helped in this case because the accused apparently wrote down the numbers as they were told to her. The only cure is to simply not accept the numbers.
-Marc
July 26th, 2012 at 7:51 am
Without knowing all of the details of the specific case, it seems more likely the defendant did not use previously-stored data – she simply captured what she wanted on a piece of paper on her desk as she was working with the customers to obtain the information in the first place. Thus, it isn’t a “data at rest” issue – but a “data capture” issue.
As alluded to, the best way to handle this sort of situation is to have the agent briefly transfer the customer to an IVR system when the appropriate time in the call occurs so that he/she can enter their SSN via their phone’s keypad – then have the call transferred back to the live agent when this is done. It’s fairly straight-forward to implement and takes the agent out of the loop on data capture.
July 26th, 2012 at 8:20 am
Agreed. As the story said: “Encryption wouldn’t have helped in this case because the accused apparently wrote down the numbers as they were told to her. The only cure is to simply not accept the numbers.”
July 26th, 2012 at 8:59 am
The problem is that identity data has value. If it wasn’t SSN, what would you have them ask for in order to extend credit to an unknown person? No matter what information the industry asks for, the same information can be copied and abused.
The technical answer is a chip embedded in your Orwellian identity card. Is the personal cost of privacy worth the price of corporate security?
July 26th, 2012 at 7:24 pm
Another issue apparently overlooked regarding social security numbers is the comfort level with giving/accepting the last four digits as some holy grail over identity validation. Anyone armed with this tidbit of info can wreak havoc on both consumer and data gatekeepers. I’m surprised more attention hasn’t been paid to this.