HTTPS. Firewall that prevents outside network access to servers with HIPPA data. Encryption of data in the db (eg, don't store plaintext social security numbe

HTTPS. Firewall that prevents outside network access to servers with HIPPA data. Encryption of data in the db (eg, don't store plaintext social security numbers in a table). All backups are encrypted. Files with PII (patient identifying information) are encrypted. Data access strictly limited to small set of people. Now that I've blown a bunch of stuff at you, I'll say that my experience is that most of HIPPA (and IRB study stuff, even stricter) is about defining and implementing a coherent policy to minimize risk. It is a colossal pain - where I work, we do medical research and integrate with actual clinical data collected from the hospital. It's not uncommon to find clinical staff keeping excel or word docs full of patient data on non-secured systems. Minimize the places where you get data from people so that you don't have to be accountable for those things - in other words, try not to have people emailing you excel sheets in the clear. We're putting https web apps in front of people to load data that way (parsing files on the fly) and not storing the files at all - during the parsing, we'll put the data into our backend and encrypt that data in our Oracle db. We're wrangling with key management right now - we want to load data automatically, but to not store keys in the db or on the OS in a way that would be easily accessed if the db server was literally loaded onto a truck and taken away. I'm not a MySQL experienced person, but I'm sure it probably has something similar. You're right to be cautious - I've seen estimates that notifying people when data is leaked and handling the cleanup (providing credit monitoring, etc) is huge, $3K to $5K per client.