Hitting close to home, SC Governor Nikki Haley noted that after the SC Department of Revenue breach was reported, that the IRS didn't require the data to be encrypted:

“As I am sure you are aware, an international hacker recently breached the South Carolina Department of Revenue’s computer system exposing the personal information of all electronic tax filers in my state,” she wrote to IRS Acting Commissioner Steven T. Miller. “While this incident was entirely caused by a malicious criminal hacker, the investigation of how this breach occurred has unfortunately revealed that the IRS does not require encryption of stored tax data, only transmitted data.”

The IRS tried to refute this, saying they "had a long list of requirements." It turned out she was correct, and you can see the evidence in IRS Publication 1075, which states (for data at rest):

While encryption of data at rest is an effective defense-in-depth technique, encryption is not currently required for FTI while it resides on a system (e.g., in files or in a database) that is dedicated to receiving, processing, storing or transmitting FTI, is configured in accordance with the IRS Safeguards Computer Security Evaluation Matrix (SCSEM) recommendations and is physically secure restricted area behind two locked barriers. This type of encryption is being evaluated by the IRS as a potential policy update in the next revision of the Publication 1075.

Then we see that the Department of Homeland Security had a data breach, and once again, PII data was taken. That PII data was unencrypted. 

As a result of this vulnerability, information including name, Social Security numbers (SSN) and date of birth (DOB), stored in the vendor’s database of background investigations was potentially accessible by an unauthorized user.

This begs the question, "When are we going to get serious about encrypting personal information?" I know there are challenges to doing so, especially for older systems. Also, when it comes to SQL Server, not everyone can afford Enterprise Edition licenses where you get Transparent Data Encryption starting in SQL Server 2008. I also know there's concern because encrypted files don't compress well, so when you take a backup and it's encrypted and then try to pass it over to a system that dedupes data and attempts to compress, you don't get such good results. However, at some point we've got to accept that this is part of the cost of doing business and look to do a better job of encrypting data.

With respect to SQL Server we have options. Among them:

• Built-in encryption within the database (at the "field" level)
• Transparent Data Encryption at the database level (which also ensures native backups are encrypted)
• Third party backup products that support encryption
• Third party encryption products that offer similar capabilities to TDE

It's a matter of identifying what needs to be encrypted, the proper solution, and accepting the cost. To say it's not required, the excuse used by Haley, is just that, an excuse. As IT professionals we should press for the right solution. I realize this is ultimately a business proposition. However, if we're not bringing up the discussion, we're part of the problem.