There are a lot of myths and misinformation about SharePoint 2010 and its records management capabilities and the general response is to dismiss it entirely. Which is a pity because most IT departments (and the web team too) are likely to be implementing it without using any of its recordkeeping functionality. Records managers cannot, in my opinion turn a blind eye to it.
To understand how well SharePoint 2010 meets recordkeeping requirements, I would recommend reading a report published in April 2010 by John Wise from Wise Technologies titled ‘Analysis of MOSS 2007 and SharePoint 2010 against ICA ERMS Requirements’.
The report (which can be be found on the Microsoft site via a search engine) analysed the capability of SharePoint 2010 against the ICA ERMS requirements that became ISO 16175 Parts 1 and 2.
The 12% ‘gap’
The Wise report stated the following on page 5 (of 125 pages):
‘With an 88% compliance result, SharePoint 2010 is shown to be largely compliant, albeit with configuration still required to address specific records management functions, and some add-ons for requirements such as security classifications and physical records.’
It noted that SharePoint, out of the box, only ‘partially’ met the remaining 12% of requirements.
The ICA document had 275 requirements. SharePoint 2010 met 242 of the requirements. Of the 33 remaining requirements (the 12%):
- The management of security classifications and caveats made up 4 items or 1.5%. For those working in the Government space, this *does* require an add-on. No choice here.
- The management of physical records made up 9 items or 3.3%. The report suggested that physical records be registered and tracked using Lists; not as good as TRIM but better than using a spreadsheet or Access database.
The remaining 20 items (or 7.2%) can be addressed in different ways described below.
Additionally, the report noted that, while emails could be saved to SharePoint 2010 (via Save As – which saves the email in .msg format), it did not have the ability to drag and drop. However you can email enable libraries in SharePoint sites.
ICA Requirements that are ‘partially met’ by SharePoint 2010
Legend: [M] Mandatory, [S] Should, [PR] Physical Records, [SC] Security Classifications
Security classifications (4 out of 275 requirements, or 1.5%)
Reqt 110 – Allow access-permission security categorisation to be assigned: at group level (be able to set up group access to specific aggregations, record classes security or clearance levels); by organisational role; at user level; and in combination(s) of the above. [M][SC]
Reqt 113 – Enable its security subsystem to work effectively together with general security products. [M][SC]
Reqt 116 – Restrict access to electronic aggregations/records that have a security classification higher than a user’s security clearance. [M][SC]
Reqt 117 – If security classifications are assigned to aggregations as well as individual records (as per Requirement 107), then the electronic records management system must:
Be capable of preventing an electronic aggregation from having a lower security classification than any electronic record within that aggregation. [M][SC]
Physical records (9 out of 275 requirements, or 3.3%)
Reqt 132 – Record information about movements including: unique identifier of the aggregation or record; current location as well as a user-defined number of previous locations (locations should be user-defined); date item sent/moved from location;date item received at location (for transfers); user responsible for the move (where appropriate). [M][PR]
Reqt 135 – Allow both kinds of record to be managed in an integrated manner. [M][PR]
Reqt 139 – Include features to control and record access to non-electronic aggregations, including controls based on security category, which are comparable with the features for electronic aggregations. [M][PR]
Reqt 141 – Support the printing and recognition of bar codes for non-electronic objects (for example, documents, files and other containers), or should support other tracking systems to automate the data entry for tracking the movement of such non-electronic records. [S][PR]
Reqt 142 – Support the retention and disposal protocols and routinely apply to both electronic and non-electronic elements within hybrid aggregations. [S][PR]
Reqt 143 – Where aggregations have security categories, the electronic records management system must: Ensure that a non-electronic record is allocated the same security category as an associated electronic record within a hybrid records aggregation. [S][PR]
Reqt 193 – Alert the administrator to the existence and location of any hybrid non-electronic aggregation associated with a hybrid electronic aggregation that is to be exported or transferred. [M][PR]
Reqt 197 – Be able to export and transfer records management metadata of non-electronic records and aggregations. [M][PR]
Reqt 198 – Support the application of a review decision taken on a group of aggregations to any non-electronic aggregations within that group, by notifying the administrator of necessary actions to be taken on the non-electronic aggregations. [S][PR]
Requirements that are ‘partially’ met, and options to address them
Reqt 43 – Allow the format of the unique identifier to be specified at configuration time. [M]
Options – SharePoint allows for the configuration of unique identifiers, up to a point. A 4 – 10 character prefix can be assigned at the Site Collection level, which is then applied to all documents and Document Sets in sites in the Site Collection. The unique document ID is PREFIX-(site number)-number (e.g., PROP-23-342).
Reqt 53 – Support the allocation of unique identifiers to records within the classification structure. [M]
Options – This depends how the classification scheme is structured and where it is located. Libraries can be assigned numbers as part of their name. If it is based on folders in a library structure, ‘unique’ numbers can be added to the folder names. Unique names (aside from GUIDs, which are generally not visible) are otherwise only generated for documents.
Reqt 54 – Where the unique identifiers are based on sequential number, the electronic records management system should: Have the capacity to automatically generate the next sequential number within the classification scheme for each new electronic aggregation. [S]
Options – SharePoint will assign a unique number to an aggregation if it is a Document Set. Therefore, if the classification structure is built into the naming of the Document Set, that will have a unique number.
Reqt 84 – Automatically include in the metadata of new volumes those attributes of its parent aggregation’s records management metadata that assign context (for example, name, classification code). [M]
Options – SharePoint does not create ‘volumes’ (sequential, related aggregations); instead, aggregations may be document libraries or document sets.
Reqt 85 – Support the concept of open and closed volumes for electronic aggregations, as follows: only the most recently created volume within an aggregation can be open; and all other volumes within that aggregation must be closed (subject to temporary exceptions required by Requirement 68). [M]
Options – This is achieved by making Libraries or Document Sets read only.
Reqt 86 – Prevent the user from adding electronic records to a closed volume (subject to the exceptions required by Requirement 68). [M]
Options – By making a Library or Document Set read only, it is not possible for a user to add electronic records.
Reqt 105 – Provide one of the following responses (selectable at configuration time) whenever a user requests access to, or searches for, a record, volume or aggregation that they do not have the right to access: display title and records management metadata; display the existence of an aggregation or record (that is, display its file or record number) but not its title or other records management metadata; or not display any record information or indicate its existence in any way. [M]
Options – SharePoint provides fewer options. If a record is found, and the user has permission to see it, it will display the title and any metadata with a hyperlink to the record. If the user does not have permission, nothing will be displayed. In other words, SharePoint cannot show the existence of a document without also providing a link to it.
Reqt 125 – Be able to export metadata for specified records and selected groups of records without affecting the metadata stored by the electronic records management system. [M]
Options – Metadata (columns) can be exported directly from a Library to an Excel spreadsheet, without affecting the original metadata stored on the site. Metadata can also be move to a List.
Reqt 127 – Be able, at a minimum, to provide reports for actions on records and aggregations organised: by record or aggregation; by user; and in chronological sequence. [M]
Options – SharePoint is able to report in a number of ways on information contained in the database. This can be by exporting the data to an Excel spreadsheet, using some of the pre-defined (Excel) reports, or using Business Intelligence tools to analyse the data in the database.
Reqt 171 – Be able to specify the frequency of a disposal authority report, the information reported and highlight exceptions such as overdue disposal. [M]
Options – SharePoint includes disposal reports in reporting options for site collections.
Reqt 172 – Alert the administrator if an electronic aggregation that is due for destruction is referred to in a link from another aggregation and pause the destruction process to allow the following remedial action to be taken: confirmation by the administrator to proceed with or cancel the process; and generation of a report detailing the aggregation or record(s) concerned and all references or links for which it is a destination. [M]
Options – Disposal processes in SharePoint may be subject to a disposition review workflow, allowing an administrator to review the proposed disposal. A review of metadata for the records should identify hyperlinks to other records.
Reqt 173 – Support reporting and analysis tools for the management of retention and disposal authorities by the administrator, including the ability to: list all disposal authorities; list all electronic aggregations to which a specified disposal authority is assigned; list the disposal authority(s) applied to all aggregations below a specified point in the hierarchy of the classification scheme; identify, compare and review disposal authorities (including their contents) across the classification scheme; and identify formal contradictions in disposal authorities across the classification scheme. [M]
Options – SharePoint provides basic reporting functionality on retention and disposal, but not to the same degree as stated in this requirement. Additional reporting tools may be required to achieve this level of functionality.
Reqt 179 – Be able to include a copy of the entire metadata set associated with the records and aggregations that are transferred or exported from an electronic records management system. [M]
Options – Records in SharePoint are stored entirely in a SQL database, unlike traditional EDRMS systems that store metadata in the database and binary objects in a file store. Therefore, when the data is exported from SharePoint, the metadata that is associated with the records is also exported. The process of doing this is possibly not as simple as other EDRMS systems.
Reqt 180 – Produce a report detailing any failure during a transfer, export or destruction. The report must identify any records destined for transfer that have generated processing errors, and any aggregations or records that are not successfully transferred, exported or destroyed. [M]
Options – SharePoint provides limited capability to report on such failures.
Reqt 186 – Provide a utility or conversion tool to support the conversion of records marked for transfer or export into a specified file transfer or export format. [S]
Options – Limited capability to do this in SharePoint, except through scripts.
Reqt 188 – Provide the ability to sort electronic aggregations selected for transfer into ordered lists according to user-selected records management metadata elements. [S]
Options – Document libraries can be sorted by metadata columns, allowing them to be grouped for export.
Reqt 211 – Allow users to retrieve aggregations and records directly through the use of a unique identifier. [M]
Options – Records have unique Document IDs and these are searchable. Document Sets also have Document IDs and these are also searchable. Aggregations in form of document Libraries or folders do not have unique IDs.
Reqt 234 – Allow the administrator to specify that all printouts of records have selected records management metadata elements appended to them, for example, title, registration number, date and security category. [M]
Options – Exports (e.g., to Excel), or print outs of records metadata from SharePoint can be configured in a number of ways, including by the options listed.
Reqt 255 – Support the movement of users between organisational units. [M]
Options – There are several ways to address this requirement. At its simplest, a person can move from one Active Directory to another. When a person has been granted permission to something in SharePoint, that person can be moved to a different group to grant or deny access to records.
Reqt 275 – Be able to notify users whose updates may have been incompletely recovered, when they next use the system, that a potentially incomplete recovery has been executed. [M]
Options – This requirement is in the context of back up and recovery. Users can be advised of problems with back ups in a number of ways.
One thought on “Does SharePoint 2010 do Records Management? The ‘12% (ICA) gap’ explained.”
Sharepoint can do records management with a plug-in addition, there is one here in the UK called Automated Intelligence. This manages lifecycle and disposition of records via a workflow (this is anecdotal, I haven’t seen it in action). Job done. Well no, not really, because up to Sharepoint 2010 you work on shared drives and then upload into Sharepoint, something that we know most folks simply aren’t gonna do. Sharepoint 2013 apparently lets you work directly in the Sharepoint environment, but you still need to declare your records ie tell the system when to set the lifecycle clock running – again most folks are going to ignore this so the retention functionality won’t trigger.
The conversation therefore needs to be about organisational culture change; we can get records management implemented but need users to do as they are told. Users have day to day control over their electronic records and must be made to manage them. We can only really advise.
I think the trick is to somehow persuade CEOs, COOs, CFOs etc to follow threads like this one and spread the word from on high.
Good luck with that…