Ten reasons you can rely on SharePoint to manage policies in your Compliance Management System
Policy management and compliance is something every company has to deal with at some point. All but the smallest of organizations have policies and procedures that they need employees to read, acknowledge and subsequently sign up to. Governance activities also creep into day to day company management – areas of HR, accounting, finance, and third party collaboration all create paperwork that need due attention. The good news is many organisations already have the right system in place to deal with policy management and compliance, they often just don’t realise it. The name of that system? Microsoft SharePoint.
SharePoint is an extremely capable platform, with a wide range of collaboration and document management features. It is already used in a huge number of enterprises as an Intranet or file management system. But it also makes for a powerful compliance and policy management tool, with a number of very specific features.
As is common for any SharePoint project the secret to success is knowing how best to utilise the out of the box features, and when to use third party add-ons to supplement functionality. In this post we will look at ten requirements of a good policy and compliance system, and how SharePoint functionality can be used to deliver them.
1. Policies need to be created in a collaborative environment
A well written policy is usually the result of teamwork. As well as multiple authors, policies tend to involve much discussion and review to get them to a stage where they represent the right viewpoint.
SharePoint is designed from the ground up to be a collaborative environment. At its core is the concept of self contained sites. Each site has its own set of users, permissions, documents, tasks, discussions and more. Using SharePoint, dedicated policy sites can be quickly created and used to manage the lifecycle of that entire document or process.
2. Policies need a unique name or ID number
By their very nature policies tend to be unique. They address a specific point, process or set of users. SharePoint offers a document ID service, which assigns a unique reference to a policy from the moment it is created. This has the additional benefit of giving every document a unique URL from which it can be tracked or linked.
3. Policies should only be accessible by those who need to see them
Policies have a specific audience, and should only be accessible by those people. This goes for authoring, reviewing and accepting a policy. One of SharePoint’s core strengths is it permissions model, which uses a combination of authentication and access control. Users can be assigned specific permissions individually, or as part of a group. This allows documents, or policy sites, to be accessible only to specific users.
4. Policies need to be subjected to version control
All policies are subject to version control, allowing them to be updated and maintained over the lifetime. Version control is also vital to ensure users are signing up to the correct copy of a given policy.
SharePoint supports major and minor version control out of the box. Major versions ensures there is always a clearly labelled ‘latest version’ for publication or wider use. Minor versions are invaluable during the policy creation or editing process.
5. It should be possible to track the audit history of a policy
Many policies are valid for a number of years, and along with version control it is important to be able to audit their history. Who created the policy? Who reviewed it? When was the last version created, and when was a record declared?
SharePoint records a history of all versions of a document, who was responsible for the changes and when. Additional details can be recorded via the SharePoint workflow engine.
6. A policy should only be published when it has been formally approved by all relevant stakeholders
The collaborative nature of policy making means that formal approval process is a must. A policy is generally only deemed ‘live’ when a number of stakeholders have signed it off. SharePoint supports a number of approval and publishing controls, not least via its powerful built in workflow engine. Building on top of the enterprise grade Windows Workflow Foundation, this allows almost any combination of approval process to be created and rigorously enforced.
7. It should be possible to save policies as read-only formal records
Once a policy has been published there is often a requirement to store it as a formal record. This means it is made read only, and is unalterable. This is important for auditing and governance purposes. SharePoint supports powerful Records Management functionality out of the box. This allows any document to be moved to a bespoke ‘Records Centre’, and that version set to read-only.
8. It should be possible to assign policies to users for formal acknowledgement
Once a document has been created and published, it is then ready for circulation to its audience. This audience is then generally asked to formally acknowledge and sign off on their acceptance. Our own DocRead add-on for SharePoint builds on the out of the box foundations, and adds the ability to assign documents to users for mandatory reading and acceptance.
9. It should be possible to track and report on who has and hasn’t read a policy
Once a policy has been circulated for acknowledgement, it is essential to track which users have and haven’t signed up. DocRead supports extensive reporting and tracking, making it simple to understand who has read and accepted a policy.
10. It should be possible to test how much of a policy users have understood
Sign off on reading a policy is often only half the job. What many organisations want to is reassurance that users have understood the policy detail. DocSurvey complements DocRead by adding advanced survey and questionnaire functionality to SharePoint. In-depth intuitive surveys can be assigned to users to quiz them on their understanding, and a full report produced to analyse the results.