Last week, a security researcher discovered something very troubling on Docs.com, Microsoft's free document-sharing site. The search bar at the top of the page allowed him to search through hundreds of documents with highly sensitive information.
Users of the service had mistakenly shared these records publicly, even making them indexable by search engines. Clearly, this is a huge problem. Health information, social security numbers and even payment info were simply laying out there for anyone on Docs.com to search. This is an unfortunately common occurrence when employees try to share a document.
From an ars Technica article about this, here is a list of some of the information that was found:
- A list of maintenance logins and passwords for a number of devices, including metal detectors and other security devices.
- A list of names, addresses, social security numbers, bank account numbers, e-mail addresses and phone numbers, apparently passed to a debt collector on behalf of a number of payday loan and finance companies. (Ars attempted to contact those exposed by the document, but many of the numbers associated with the records were disconnected)
- Medical data, including one physician's treatment logs and photos, as well as credentials for logging into medical records systems.
- A new employee enrollment document with instructions on how to connect to a corporate intranet gateway for the first time (with default username and password information).
- Actual login and password information, saved as Word documents, from an administrator e-mail.
How This Affects SharePoint Records Management
Just like the unfortunate users that unknowingly shared these sensitive documents, many organizations struggle with employees saving or posting records in the wrong place. This is where policies and procedures come into play.
If you have been using SharePoint very long, you start to realize it has a great core platform, but it is not so good at the individual tasks that need to be accomplished with your information.
Whether it’s business process management, document capture, or records management, sometimes the SharePoint features just don’t cut it out of the box.
Here are 5 ways you can fix the records management feature deficiencies.
1. Events and Case Records
One of the first problems you are likely to encounter when trying to do records management in SharePoint is tying all retention policies back to a date column in SharePoint. While this might work for “Administrative Records” (time based records with a known retention date), it simply will not work for what are referred to as Case Records (more information can be found in a previous post on determining record types).
Perhaps the best example I can think of is employee files, in which the collection of files for this employee is considered a case. When you save an employee file you have no idea when the person will depart the organization, however, retention almost always starts at that departure time.
When trying to squeeze the right process into SharePoint, you may just think you can go back and change a date column to show the time, but there are two problems with this:
- It’s simply a pain to go change the date on all those files. However, you could automate this with some code and/or workflows.
- Meta data (SharePoint Columns) cannot be edited when using the in-place records management declare capabilities. If you declare a record in a SharePoint Library, you won’t be able to change any of the column values.
How do you fix this problem? If you are using SharePoint Server, you could build a custom event formula. You’ll need a competent SharePoint developer, and it won’t take too long, especially if they’ve done it before. If you are using SharePoint Online, this is not possible as you are not able to put these types of coded solutions in the cloud, and you’ll need a third-party solution.
In addition to the event itself, you will need a way to tie these records together so they can be treated as one single unit when working through the disposition process. How can you accomplish this with SharePoint? The simple answer is, it’s not every simple. You will need to call on your superhero workflow skills to build a process in which ties a set of records together. The other solution is, you guessed it, purchase a third-party solution.
2. File Plan
The process of records management requires a file plan or retention schedule with many categories defining the trigger/retention/disposition action for each. Information (records) that need retention policies will be classified against this file plan. Out of the box, SharePoint has no such concept.
You can create a taxonomy with Information Policy settings, and generate what is referred to as a file plan report, but make no mistake, this is not a file plan. Sticking with out of the box SharePoint capabilities, you can associate retention policies with Document Libraries or Content Types. This is a poor solution regardless because for records management to work, you need to separate the taxonomy from the file plan.
How do you fix this in SharePoint? You don’t. If you need this to work, you need to buy a software package that contains your File Plan and links it to SharePoint. One piece of advice though: if you have records that live outside of SharePoint, make sure the file plan is contained outside as well so you can apply it those records.
3. Email Records
Outside of transactional information that needs to have retention policies applied, Email is likely the number one source of records in your organization. How does this apply to SharePoint? If you’re using SharePoint as your primary location for records, you will need to figure out how to move these records to SharePoint. One caveat is that you’ll need to add meta data to know when you stored.
Without buying a tool, you’ll need to just get the Email message or attachment to SharePoint and edit the columns. The easiest way I can figure out is to drag the Email onto your desktop, and then drag it into the right SharePoint location. After you drop the Email into place, edit the properties and fill in the correct meta data.
You’ll quickly realize that you could save the organization a lot of wasted time if you had a better tool. Fortunately, there are at least 10 add-ins on the market to accomplish this. Consider deployment. Do you want to install this add-in on every computer, or do you want something that works within the Outlook App Model?
SharePoint Server and SharePoint Online both have the same functionality, so what’s the big deal, right? Not quite so easy. Since there is no synchronization between Content Types (not even with the Hub) between server and online, you will need to build your policies in both systems, and make any changes in both systems. There is no synchronization.
The fix? You need a records management add-in that can use a single file plan and a single set of rules for both SharePoint Online and SharePoint Server.
Lastly, the real purpose of those retention policies is to properly dispose of records when they are eligible. This requires a disposition process, which is much more than deletion. It is the systematic deletion, transfer, or permanent archiving of records with the ability to legally prove the policies were followed. In general, you will need to figure out how to accomplish the following:
- Know when all the records for a category are eligible for disposition.
- Approve the records using some type of automation. You may need more than one approval.
- Carry out the disposition action with an audit trail.
- Report on everything that just happened.
Yes, this can be done with SharePoint, however you will probably need those super hero workflow skills again. You’ll need the right folks to be notified when records are ready, and a way for them to approve the records, all while tracking exactly what happened. No problem.
Or you could use software that was built specifically for this job. Most third-party records management tools make this possible. The best software allows record managers to see a live view of what is ready for disposition, email those who need to approve records, and provide a great reporting tool to see what happened.
I mentioned five ways you can fix the problems with records management inside SharePoint. I’d like to tell you they stop here, but they just don’t. However, if you resolve these five, you will be well on your way to using SharePoint as your repository for corporate records.
By Shawn Cosby