You should take a look at Secure Messaging with S/MIME and OWA on Exchange Server 2007 SP1 If you want to encrypt the message. This solution also requires an extra step as the users must select the encrypt button (it's also probably not legal as you have to somehow assume that all of you users would never make a mistake and not encrypt an email that they should have.) Otherwise all you need to do is ensure that the destinations that you want to send Massachusetts PII are using TLS (you are required to have that information as you must vet everyone you might send Mass.PII to as per CMR 17.04). You should also probably write a transport rule that uses a regex to search for Mass PII. Massachusetts PII is defined as a combination of a resident's first and last name connected to one of the following: A driver's license number, a credit card number, or a Social Security number. You might want to BCC those messages for follow up in another mailbox or simply keep a count.
Off-topic but germaine...
Note for those reading this and thinking you are lucky not to live in MA, Suprise! If you store the personal information of a Massachusetts resident, regardless of whether or not you have a business presence in Massachusetts, you are subject to penalties set forth in 201 CMR 17.00. which could cost $100 record lost, with a maximum of $50K per "incident". MA General Law 93H states that there will be a $5,000 fine per "violation." What exactly does that mean? I don't think anyone knows and won't until someone gets hit with it.
It's important to note that this isn't an easy topic- here is the conent of a discussion between myself and Zypher about his answer:
me: Using any sort of end user option opens you up to liability, unlike PCI the law requires you to be on the hook for any reasonable issues (like joe user not using the technology)
Zypher: using pgp if the user doesn't give you a key, you don't send to them. Basically they are forced to use it - in this use case - otherwise they either A) Don't get the data or B) can't read the data.
me: how can you ensure that every user sending the data will encrypt every email? Just like an SMIME solution you must choose to encrypt your email it can't be forced - or am I missing something?
Zypher: It's pretty simple, if you send an email containing information that needs to be encrypted without encrypting it, your fired for cause (in at will states this means no unemployment). Not everything needs to be a technical solution. From the question this won't be done too often so a more involved solution probably isn't worth the cost/benefit. If they needed to do this all day every day i would advocate not using email at all, and moving to online forms over SSL.
me: IANAL - but I am stuck listening to them, the law is effectivly stating it has to be a techinical solution- "but I had a policy" is de facto evidence that one of those "reasonably foreseable" issues you are supposed to mitigate wasn't mitigated. Disciplining violators is also part of the law already. Take a look at this discussion informationweek.com/blog/main/archives/2009/02/…
Zypher: Actually if you read 17.03.2.b (here:mass.gov/Eoca/docs/idtheft/201CMR1700reg.pdf) I have a policy and trained my people on it, as well as having disciplinary measures is actually perfectly defensible. In fact the only mention of a technical solution is for preventing terminated employees from accessing records. IAANAL (I Am Also Not A Lawyer).
me:- 1,2,3 are simply things that are expected to be included not definitive solutions, 2b is the specific wording that applies (I cheated and asked a lawyer). If you have to say "I can defend that" the courts will probably crush you. With compliance issues you have to prove you are following the regs. The regs specifically say "foreseable". If you stand up in court and say "well if someone broke the policy they'd get fired" prosecution is simply going to say "So you admit that you foresaw a way for this policy to be violated, and took no reasonable measures to remove the issue?"
Zypher: Damn you for cheating. Well now we have to define reasonable as well, reasonable for my company (large multi-national w/ 100k+ employees) is not the same as for a mom and pop shop. But on that same token I think we are getting too far away from the Q&A mandate of the site... which is unfortunate because this discussion has provided some good insight.
me: it's "reasonably foreseable" not "reasonably secure" or even reasonable to implement. Remember that legally, using rot13 on the persons names and nothing else follows the standard becuase that is a form of encryption. This discussion is usefull so I'll edit my answer to include it so it's not lost.