Many hoped that version three (V3) of Windows SharePoint Services (WSS) would help bring companies closer to compliance with Sarbanes Oxley (SOX) and/or the Health Insurance Portability and Accountability Act (HIPAA). I know from personal experience that my hopes were quite high when WSS V3 released, because I had worked with several organizations on the version two (V2) platform, and these organizations were enduring through pain because of their need to be mindful of such ordinances that would have an impact on SharePoint intranets. In fact, just the idea of a companywide collaboration tool sent most security departments down a path of fear and much concern. As you all now know, the c# statement "if (SharePoint == Compliant)" seems not likely to return "true" at any near point in the future. However, I did come up with a solution that proved very successful for one organization. It's no silver bullet, but it is a step in the right direction nevertheless.
THE PROBLEM
The unique struggle that one particular company I was working at had was that their taxonomy was geographically structured and their SharePoint team sites were built around what they called Geographic Units (GU) such as Upper Midwest, Mid-Atlantic, and the Desert Southwest. When employees would go to the
intranet, they would navigate to their GU, or more granular, their individual office within their GU. It is at these generic locations where they would go to find stuff that they needed to do their job (notice Figure 1). However, the company did have functions (or departments) like Tax, Audit, IT, and HR, which complicated the situation. Each function was represented within each GU and in every office within each GU. Where it gets complicated is that SOX compliance for them required that employees in the Tax function couldn't view documents that pertained to their Audit function, and vice versa. Conflict of interest concerns I guess (I'm definitely no SOX expert). Because of the geographical taxonomy (whereas most companies have a functional taxonomy), it was impossible to enact a security model that could account for the unique structure. That, and documents of all varieties are strewn all over the place. To further complicate the issue, they had over ten thousand MySites, and these same security rules needed to apply there as well in addition to the GU sites.
THE SOLUTION
The solution we went with, to help tame such a wild security model, heavily used content types, features, and event receivers. We started by editing the schema of the Document Library feature to include a custom content type. This way, every single document library created anywhere within the farm would come with our custom meta-data. The critical piece of meta-data that we tagged onto each
document was the "Function" that the document pertained to. The field had three options, Tax, Audit, and Generic. This piece of meta-data was required to be selected whenever the document was first uploaded. What's more is I wrote a custom document library event receiver that is deployed via a feature and is automatically activated upon site creation (you could use a console application to push this out to existing sites if needs be). This event receiver fired every time a document was uploaded or edited, and depending on the choice of the function dropdown, item level security on each document was set (see figure 2 for event flowchart).
With this meta-data and event handler present on every document in every library on every site in the entire farm, the client was satisfied to use SharePoint as the vehicle for their Document storage. Without which, they would have had to grow a new taxonomy for their organization, something that was definitely out of scope for my project J.
If you want extra reading material on SOX specifically, and SharePoint – Bill English (MVP) has an excerpt on his blog for a Whitepaper that is free to download off Mindsharp.com. Hopefully that paper can be of additional assistance.
FURTHER DISCUSSION
One thing I am curious, if you readers out there would be so generous to contribute, is if anyone knows of any performance impacts that may result on having item level security throughout the majority of a farm. Does that scale well in SQL, say if they get to a million documents? The company's initial load will barley hit a few hundred, so I'm not nervous for the foreseeable future, but if it doesn't scale, we'll need to prepare so to be safe.
Good luck everyone!
Phil