>protect sensitive information if the database is ever hacked, stolen or mislaid.

This is a very broad requirement.

Encryption comes at the cost of CPU cycles, so better load test your application if the outcome is acceptable to your application performance.

There are areas to explore and combination of them will get you want you want.

 - Encrypting data at rest - this is done using TDE (Transparent data encryption). I have written about [my experience embracing TDE in our environment here][1].
 - Encrypting all connections to SQL Server using [Force Encryption][2]. This is done using loading certificate on the database server, enabling force encryption (will require sql server service restart !) and granting read access to sql server service account to the certificate. You can verify using `sys.dm_exec_connections` --> column `encrypt_option` will be `TRUE`.
 - [Column level encryption][3] - protecting sensitive data - see [this article][4].
 - If you are going to upgrade to SQL Server 2016, you can explore [Always Encrypted][5] option.

On the other hand, make sure you follow the [security best practices][6] (warning: its word doc !) with regards to sql server service accounts, logins & users, port allocation, etc.


  [1]: http://dba.stackexchange.com/a/140889/8783
  [2]: https://msdn.microsoft.com/en-us/library/ms191192.aspx?f=255&MSPPError=-2147217396
  [3]: https://technet.microsoft.com/en-us/library/ms179331%28v=sql.110%29.aspx?f=255&MSPPError=-2147217396
  [4]: https://www.mssqltips.com/sqlservertip/2431/sql-server-column-level-encryption-example-using-symmetric-keys/
  [5]: https://msdn.microsoft.com/en-us/library/mt163865.aspx
  [6]: https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=5&cad=rja&uact=8&ved=0ahUKEwizxueOkZTPAhWDFT4KHVpCCHQQFgg2MAQ&url=http%3A%2F%2Fdownload.microsoft.com%2Fdownload%2F8%2Ff%2Fa%2F8fabacd7-803e-40fc-adf8-355e7d218f4c%2Fsql_server_2012_security_best_practice_whitepaper_apr2012.docx&usg=AFQjCNGAn9dpIsjWTiEmtf1xpV-833aOPQ&sig2=pcxar-nwMx33V0jcqJhk4A