A previous answer pointed at ICO’s website, where you can find out about the rules that apply in the United Kingdom (which are essentially the same as those in other EU countries, give or take, since the Data Protection Act is the UK implementation of the EU Directive).
I just wanted to add, though, that as with many other similar things, the data protection legislation is generally used as a stick to beat you with when something has already gone wrong. That is, whatever measures you put in place, if you lose customers’ private information somehow, you’ll be guilty of a breach and you’ll very likely receive (at least) some “advice” on how you should have avoided the breach in question.
Put another way, the Data Protection Act doesn’t so much mandate things like encryption as set out general principles, which you will be held to have broken if you lose private information. At that point, you might be asked to agree to e.g. encrypt data in future (assuming, in the opinion of the probably non-technical-expert enforcement officer, that would have helped).
Finally, since you ask about it, as for encryption of stored data, you should consider
- How likely it is that the decryption key would be compromised at the same time as an attacker gained access to the data (if both are compromised together, there’s no point — other than satisfying someone’s checkbox mentality, where applicable — encrypting things).
- How sensitive the data is, and whether there are other requirements that mandate encryption (e.g. PCI-DSS).
- How often the data is accessed (which affects the performance implications as well as the likelihood that the key can be easily located by an attacker).
- How you propose to encrypt the data. Disk encryption, for instance, may mitigate some physical security issues, but won’t protect against server compromise.
- Where the data is stored and how it is accessed. e.g. Encrypting columns in an SQL table may make them hard to query, or it may not (depending on how they are encrypted).
- Physical security of your server, including, for virtualised set-ups, security of the disk images.
- Security of your back-ups. It may sometimes be worth encrypting back-ups even when encryption for live data is undesirable...
- How much you know about encryption. If you are going to encrypt things, you need to do it right. There’s little point adding encryption if it’s easily broken, and if you don’t know what you’re doing, it’s easy to make mistakes that make it much easier to read the data than it should be.
Basically, in order to gain any protection from encrypting data, you need to understand the threat you are trying to protect against, the trade-offs you will make in exchange for the encryption, and how to properly use the encryption primitives you are employing.
On a related note, I would always recommend hashing any password fields, preferably using a modern secure hash function like bcrypt, though at the very least with salted SHA256. Whatever you do, don’t use MD5 or historic UNIX crypt(), and don’t forget to add salt. Not only does this protect against password compromise, it means that users can’t accuse you of logging in to their bank account using the password they stupidly used on both your site and their bank’s.
