Sarbanes-Oxley, a set of rules that were put in place to combat corporate scandals, fraud, and improper financial reporting, has had a big impact on how corporations do business, and the impact reaches all the way across the board. While SOX is targeted at the money guys on the top floor, ultimately, it’s the IT guys in the back office that are responsible for implementing it and keeping the suits on the straight and narrow.

The most relevant part of SOX is the internal controls requirement, which mandates that several controls be put in place with regard to how financial reporting is done. At first glance, it would seem that email doesn’t pertain, but in reality, it does: SOX isn’t just about how financial data is stored, it’s also about how it’s transmitted–and a good Sarbanes-Oxley audit will almost always suggest security enhancements to the email infrastrucure to include encryption, and more rigorous adherence to policy and good practices. IT is mostly concerned with section 404 of the Sarbanes-Oxley Act, which deals with internal controls and how they are enforced.

So why does the email admin have to be worried about it? Besides the obvious reason of job preservation, Sarbanes-Oxley does mandate that access control be put into place to prevent “unauthorized use” of financial information. On the email side, that means, to begin with, making encryption available to any user who deals in financial information. Yes, it’s true–the bean counters do sometimes get careless and forget the sensitive nature of all those spreadsheets, and ship them around the Internet without much regard to whether or not somebody might see them who really shouldn’t.

Of course, along with the technology is the creation and enforcement of a good email usage policy. This policy will be reviewed by a third party conducting a Sarbanes-Oxley audit, and a good policy can go a long way towards helping to prevent big fines and corporate liability. More on creating a good policy in a later post–but the policy must deal with encryption specifically. That is, just having encryption available doesn’t mean it will be used–and so the policy must state specifically who must use encryption and under what circumstances, and for what kind of data.