A database administrator asked me, “If I’ve been working at a company subject to Sarbanes-Oxley regulations, and I needed to learn what was different about HIPAA regulations, what would be the difference between the two?”

First, in my answer, don’t think about credit card data or customer social security numbers.  That has its own security implications separate from HIPAA or SOX. In our cases, we’re going to assume there’s none of that involved, and later, you’ll see why I kept that out of the conversation.

HIPAA is designed to protect the patient’s confidentiality.

SOX is designed to protect the shareholder’s transparent view into the company.

I’ll keep coming back to those two points because it helps illustrate what we need to protect.

If you’ve been working at a SOX-affected company as a DBA, you implement safeguards to make sure that financial data doesn’t get inserted/updated/deleted without somebody knowing.  Your worst nightmare as a DBA is someone modifying profit & loss data without you being able to catch it, like sliding money around into different accounts.

With HIPAA, on the other hand, your worst nightmare is your database’s contents getting out into the public.  If somebody mucks with health data, sure, that’s a problem, but there’s not much motivation to do it.  The bigger concern is confidential patient data getting into the wrong hands.  In theory, you want tight security on ANY database server, of course, and you don’t want anybody doing unauthorized inserts/updates/deletes.  You still want that at HIPAA-affected companies, but the select auditing is a real pain in the butt, because off-the-shelf 2000/2005 databases aren’t set up for that.

There are some vendors who provide this by doing monitoring on the SQL Server with traces or with behind-the-scenes code analyzing what SQL Server is doing. Other vendors take the approach of a network appliance that sits between your SQL boxes and the rest of the network, and they sniff network traffic going into the SQL box.  Both approaches have their pros and cons, but you get the idea – we’re talking about infrastructure mods, not something DBAs take lightly.  (My employer, Quest Software, has solutions for HIPAA and SOX compliance for databases and Windows, but I’m not up to speed on that software yet.)

But it gets tougher: auditing is just the start.  In a SOX-affected company, you don’t lose that much sleep wondering what would happen if somebody stole your tape backups en route to an offsite location.  Sure, they’d get a copy of your balance sheets, but that stuff is pretty much public sooner or later anyway, because only public companies are really subject to SOX.  If you’re a private company and you’re choosing to abide by SOX regulations, then the tape theft scenario is a problem, but as the DBA, it’s not really technically YOUR problem.  If somebody gets the tape backup, they can restore it and read it, but it’s not like they’re going to set up a fake balance sheet and do something with it.

On the other hand, with HIPAA-affected data, we’re talking about patient health histories.  If somebody gets a tape backup with health insurance data for a million customers, finds out what people are sick with what diseases, there is a HUGE financial risk there.  The patients can sue, or the thief can sell that data to a private company who would do targeted advertisement at those customers.  Imagine getting a phone call from a spammer saying, “We hear you’ve got herpes, and we’ve got a great drug to treat it.”  Ugh.  Lawsuit city.

So not only do you have to protect the data, you have to make schema design decisions in an effort to abstract the customer from the treatment records.

I’ll give you an example: take a survey company that sends surveys to hospital patients.  The hospital would send over a list of patients, but not any information about their treatments whatsoever.  The survey company would email out the surveys, compile the data, and then return the raw survey data back to the hospital for their own processing.  See, the hospital wants to do reporting to find out if people who got a particular treatment were more or less satisfied than patients who got another treatment, but they can’t give that data out to the survey company because that might violate HIPAA. If the hospital wanted to give out that data, they would need to make sure that all of the survey company’s data was as secure as the hospital data, and that’s an auditing mess.

Something else you see in HIPAA-affected databases are app-level encryption – like encrypting a patient’s name/address/SSN/etc in the application, and then storing that encrypted data in SQL Server – but not the key.  That way, even if the DBA gets curious and selects patient data, he won’t be able to grab a list of people with broken arms or whatever.

Now you see why I left out the credit card data.  Sure, that’s private, and it can affect both HIPAA and SOX companies if they store that kind of thing, but it’s unrelated to either.

I’ve made a lot of grand sweeping generalizations in this post, but it’s just to illustrate the basic differences.  I know SOX people are having fits that I’d say they’re not worried about auditing select statements, for example, but it’s just not the top thing on their to-do list when they wake up in the morning.

Finally, this article is accompanied by a picture of a new ThinkGeek item.  I didn’t want to do a separate blog entry about it, but it’s hilarious, and I like pictures in my blog entries.  So there ya go.