While presenting at a SharePoint user group session in Germany last month, I had a conversation with an attendee about the new app model in SharePoint 2013, and how different the model was compared to all the work his company had done around sandbox solutions in 2010. He observed that purchasing an app through the Microsoft marketplace, while having gone through a technical review from Microsoft, could still open up his company’s environment to potential risk depending on the content it accessed and what company or individual information is stored in the cloud. It was a great point, and led to a conversation around risk management as part of any SharePoint deployment plan.
Central to any governance implementation is understanding and managing the risks involved with your SharePoint environment. Identifying risks associated with something like a 3rd party app is relatively simple: the app is separate from your system, and its impacts can be readily assessed. Unfortunately, most organizations fail to identify, assess, and prioritize the day-to-day risks with their SharePoint environments. Any governance strategy should include methods to measure and monitor potential impacts to the system, review and modify your strategy based on changing risks and impacts, and create policies that secure and protect, but are also flexible enough to meet the growing demands of your organization to collaborate.
These should not be foreign concepts to you. Risk can be driven by uncertainty in requirements or business outcome. Maybe someone in your organization wants to build out a new project management solution, using SharePoint as the presentation layer, with integration into a proprietary portfolio management solution. Risks might include downtime to the environment, permissions issues, sharing of data between platforms, or vendor support issues. Risk also comes at any stage of the project lifecycle, and from uncertain or unpredictable root-causes. That’s why most organizations employ the use of some kind of formal project management methodology — these methodologies are a form of risk management, helping you to organize yourself, prioritize your risks, and think through each potential outcome so that you are able to mitigate the risks.
Even something as common as a pending team reorganization will require changes to information architecture, and updates to taxonomy. To mitigate risks, you might consider clarifying changing roles and permissions, map out impacted content,
sites, teams, and users, and then review the information architecture to understand impacts to metadata, content types, and productivity enhancements such as workflows and forms. Of course, you can use SharePoint to help you manage basic risk mitigation, do basics, like tracking risks and issues using lists and document libraries for each project, setting up daily or weekly alerts to notify you about additions, deletions, and changes to lists, list items, and document libraries, and using document versioning and document check-in and check-out, creating a history of changes.
Risk management is proactive. The goal is to help you anticipate where a process or task may fail. If a vendor proposes 4 weeks for development, but the developer assigned to the task says it will take 8 weeks, a good risk management plan will take this gap into consideration and build contingency plans around this possible delay.
Risk management is about visibility. If you need to audit your environment, you can’t easily identify problems by looking at things on a site-by-site level — you need to have a view of data across the entire environment. The same can be said for risk management. Without the proper visibility, your administrators will be completely reactionary to any breach. The key to risk management is identifying those risks before they happen, and having plans in place for each potential problem. In short, you need to find security problems before they become a problem.
Take Christian’s Survey now>>
