One of the hotter topics that gets brought up when rolling out SharePoint within sensitive industry environments is the concept of business and regulatory compliance (it is something that I am pretty passionate about anyways, and if you are in a vertical that is subject to one you should be too whether you are an architect or developer). This becomes a concern for organizations that want to meet some sort of benchmark for operational and legal efficiency / excellence, as a result require the use of implementing a certain set of defined, empirical standards within the collaboration and communication framework that will achieve and maintain said standards. In the realm of SharePoint as a web framework, this becomes a huge concern since many organizations leverage it as an ECM (Enterprise Content Management) system, and the process of become compliant with an arbitrary standards is a relatively simple one.
Now, I bring up the concept of an ECM for an important reason. I am not restricting SharePoint to this very specific function. Rather, I am pointing out where SharePoint functionality related to regulations becomes the most ingrained. ECM within an organization is complicated, very complicated, as it integrates likely hundreds of preexisting processes for which may or may not have their risks already defined for them. Therefore, when choosing to extract and exploit the ECM functionality out of SharePoint for your business to leverage, you may be implementing solely the basics of SharePoint, however several sister controls will have to be developed to compensate for these ingrained processes.
1) Define Your Compliance Goals In The Realm Of SharePoint
The first action that you have to take when implementing compliance standards into SharePoint is to understand the benchmarks that you want to meet before, during, and following your deployment. This is when you look at the legal and business regulations that your organization must adhere to within your specific industry vertical, which can be include objects like the Sarbanes-Oxley Act which is tiered towards fiscal accountability for companies subscribed within the United States stock exchange, the United States Patriot Act (Providing Appropriate Tools Required to Intercept and Obstruct Terrorism Act) requiring implementing regulations so that businesses are aware of with whom they are doing business with (including several other required actions), and HIPAA (Health Insurance Portability and Accountability Act) which among several components verifies the privacy of patient information and insurance. This doesn’t mean that these are the only regulations that can affect a SharePoint environment, there are several. Among those that I have run into with past SharePoint projects are:
– Sarbanes-Oxley Act (SOX Compliance)
– Healthcare Services (HIPAA)
– California Senate Bill No. 1386
– NERC Cyber Security Standards
– Financial Services (GLBA)
– Visa Cardholder Information Security Program
– MasterCard Site Data Protection Program
– American Express Data Security Standard
And I am sure that there are others that others have run into since the verticals I consult in are relatively small. Regardless, within this phase, you really have to look at the purpose of your SharePoint environment, and how it is going to be used within the realm of your business operations. Also, you have to step back and not only look at the business operations that you are targeting to optimize, but, as well, investigate the processes that could be affected while optimizing other processes (also known as “optimization ripples” within efficiency theories) When you set these goals, you have to ensure that the there are actually buildable standards that will work within the SharePoint environment so that you are within legal boundaries. Sometimes strict regulations will kill the option of having a collaboration framework or not make it fiscally reasonable to even implement it. You have to consider all the ramifications of your organizational regulations, and then consider the limits and purpose of the technology. Start out with the limitations, then work your way towards optimizations, not the other way around. Flashy technology, while daunting and catchy, shouldn’t be as appealing as not ending up costing your technology a load of money and industry embrassement.
2) Commit To You Regulation, And Begin The SharePoint Pilot
In the first step, there was the action where the actual compliance was defined and the technology was studied at a high level for integration so that a cohesive framework could actually be constructed. Now, the rubber hits the road and the assumptions that were made previously regarding SharePoint begin to assimilate and adhere to the regulations that you found that your organization was privy to. This portion of compliance planning involves a lot of peoples fingers in the pot because you have to involve people from several divisions, background, and talents. For example, it would be prudent to bring in your legal department that is most familiar with your regulations and network security so that operations can be verified from many levels, from both security on the wire to visible surface information. If you don’t have one, hire a consultant. It is worth the money as opposed to legal costs.
The pilot is generally inclusive in a network enclave or silo away on closed ring so that each aspect of studying the relation between SharePoint and the compliance rule you are interested in examining can be scrutinized, studied, disseminated. Throughout this phase, there could as a result of a heavy committement to the technology breed a lot of development effort by your programming team, in order to tailor the framework to your regulation. This is important to realize. You can tailor a framework to a regulation, but you can never tailor a regulation to a framework, that is totally out of your control (unless you are the governing body of the arbitrary regulation I suppose). And why would you want to? You could be risking a huge financial obligation to your organization if you chose that route, so it is important to make the best technology baseline decisions that you can.
The most important thing to take from this is use an enclave. If you aren’t harnessing production data, you aren’t at risk for breaching regulation since you are on a closed segment. This pilot environment should remain throughout the lifecycle of SharePoint at your organization, in order to ensure that custom development efforts don’t effect any legal regulations.
3) Pushing SharePoint From Pilot To Staging, Staging To Production
In the pilot phase you examined the framework at a more detailed level getting all the required business units involved in the process that were required such as your legal and security teams, and pushed out a compliant pilot. Now that you are assured that you are adhering to your regulation, you can being to move the compliant framework into a staging, and, finally, to the production environment. Now why is this a two step process? This is for several reasons beyond the scope of this particular blog post. Most importantly however, this is because you need to firstly assimilate the new regulatory bound SharePoint environment into the production network without touching the complete organization user base and other sensitive systems that are on the same wire. While in staging, it is common that a small user base will be chosen to pound the machine and attempt to break the compliance procedure. I can’t stress how important this is because this is when you define “responses”, such as “scrubbing methods.” A scrubbing method is a term pulled from military computing tactics, which basically means a piece of classified data has been posted to a unclassified network, which can be accessed by those that aren’t appropriately cleared and therefore the machine environment must be scrubbed. Several frameworks are subject to this type of activity, and therefore, it either has to be guarded against, or procedures must be defined in order to maintaining clean-up activities for when this illegal action is performed. Basically, you want a user base that can try their hardest to both break the operations of the environment to catch problems before it goes into production, and also define all the cleanup portions.
After the selected user base has finished their testing of the pilot environment and you have found that you have satisfactory benchmarks of compliance for your system to go live (along with all necessary response actions as described above), the SharePoint environment can start to be pushed into a production environment where the final architecture is defined. This is generally when you can remove the pilot which is generally setup within a single server configuration into a production environment where you begin to use predefined network assets such as attaching to the organizational SQL cluster. This migration can take many forms, depending on the development that was put forward previously in the staging and development phases and other actions that you took to maintain compliance in your SharePoint environment.
4) Maintaining Compliance In Your SharePoint Environment
Irrevocably tied to step 3, you have to maintain and administer your compliant SharePoint environment. This doesn’t imply the general administrative tasks that you will encounter with your SharePoint environment. Just because you have a regulation compliant SharePoint environment now does not mean that you are going to have one following 6 months of activity. This process is “living”, in the sense that you will consistently have to compensate for new revisions of the software (such as Service Packs), arbitrary user activity, and extending the framework with your own custom development. Furthermore, just because you have achieved regulatory compliance one month, does not mean that the regulation is going to be the same in 2 days, 2 weeks, or 2 years. Regulations are always shifting, and therefore your SharePoint environment must also evolve and adapt to the changes that are required by the regulation. This type of shift can be slightly compensated for by defining processes to tackle these adjustments in step 3, however it is very difficult to now what changes lawmakers are going to put forward.
A lot of companies approach this effort by simply defining change templates that help to build up the change process and make the transition as smooth as possible as regulations are put forward.
This part also will tie back into your pilot when developing extensions of the SharePoint framework, doing Line of Business (LOB) integration into your environment, or just doing simple custom component development (i.e. WebParts). For each of these efforts, they should be put through the same cycles as the actual SharePoint environment went through, so that the integrity of the system can be maintained, tested throughly by the appropriate parties, and documented as much as possible in order to bring the customizations into objects like the previously defined change templates.
I know this is not a comprehensive guide to SharePoint compliance, that was not the aim of this post. It was solely done in order to attempt to bring to a light a simple process by which before doing your SharePoint deployment, you have some foundational building blocks to think of so that you are inline with business and legal regulations.