Microsoft SharePoint 2010 is a software product with a range of uses, including website development, content management and collaboration. SharePoint allows users to collaborate on the creation, review and approval of various types of content, including documents, lists, discussions, wiki pages, web pages and blog posts.

SharePoint is not a recordkeeping system (i.e. a system purposely designed to capture, maintain and provide access to records over time). When implemented ‘out of the box’, SharePoint has limited capacities for capturing and keeping records in a way that supports their ability to function as authentic evidence of business. See Assessment of SharePoint 2010 against the Standard on Records Management for more information about some of its limitations.

Purpose

This guidance describes recordkeeping features and functionality that can be enabled or configured in SharePoint, and identifies where additional configuration and/or add-on software are needed to meet particular recordkeeping requirements. NSW public offices should refer to this guidance when:

• planning and designing a new SharePoint implementation in which records will be created and kept
• assessing how recordkeeping features and functionality can be incorporated into an existing Sharepoint implementation in which records will be created and kept.

There is no single way to design and configure SharePoint so that it facilitates good recordkeeping. NSW public offices should consider the features and functionality described in this guidance and their own recordkeeping requirements when making decisions about how SharePoint will be set up and used within their organisation.

Although SharePoint is not an electronic document and records management system (EDRMS), many of the considerations that need to be factored into an EDRMS rollout should also be considered as part of any SharePoint implementation. Common considerations that cannot be neglected if an implementation is to be successful include:

• requirements gathering and analysis
• project planning
• factoring in the range of costs that are likely to be incurred
• gaining and maintaining management commitment and support
• pre-implementation design, configuration and testing
• post-implementation testing and monitoring
• user training and change management.

For more guidance on these and other considerations, see FAQs about EDRMS.

Scope

For convenience this guidance generally refers to 'SharePoint'. This encompasses the various SharePoint 2010 products, including SharePoint Foundation, SharePoint Server and SharePoint Online.

It is important to note that each product does not necessarily contain the same features and functionality. In particular, SharePoint Foundation and SharePoint Online have more limited features and functionality. Where these limitations may impact on records management, this is noted.

Earlier versions of SharePoint, including SharePoint 2003 and SharePoint 2007, do not manage records appropriately and are outside the scope of this guidance.

Records management in SharePoint 2010

SharePoint provides two options for managing records:

• records can be managed 'in place' (i.e. in the collaboration site in which they were created or captured)
• records can be sent to a separate site or sites set up as a records repository (including a specific type of site known as a 'Records Centre').

This section of the guidance briefly explains these two options and then identifies some of the factors to be considered when choosing an approach to records management in SharePoint.

Managing records in place

The In Place Records Management feature in SharePoint enables records to be stored in a collaboration site but managed differently to content that continues to be edited or worked on. This feature is enabled by the Site Collection Administrator, and is only available in SharePoint Server and SharePoint Online (not in SharePoint Foundation).

Once enabled, the In Place Records Management feature adds the 'Declare Record' option to a Document Library. ^[1] Once declared, a record can be managed and eventually disposed of without ever being sent to a separate records repository.

In Place Records Management can be configured so that records are declared manually or automatically:

• Users can manually declare content to be a record.
• Workflows can be set up to run after a specific event and declare the associated content to be a record.
• Information Management (IM) Policies can be defined to declare content to be a record on creation or after a certain period of time.
• Lists and Libraries can be configured so that any content created or saved within them is automatically declared as a record.

Further information about configuring In Place Records Management is available in the Microsoft articles Configuring in place records management and Designing for in-place records management (SharePoint Server 2010).

It is vital to document decisions regarding the way/s in which records will be declared or otherwise protected in a SharePoint implementation, including details of any workflows and IM Policy features. See Documenting design and configuration decisions.

Managing records in a Records Centre

A SharePoint implementation can be configured to have one Records Centre or multiple Records Centres. A Records Centre is a particular type of site with pre-configured features that support records management. Further information about the features included in the Records Centre site template is available in the Microsoft article Introduction to the Records Centre.

Because a SharePoint implementation can have multiple Records Centres, a Records Centre could be established for each team within a public office, for each function that a public office carries out or even for each project or case that a public office works on.

Alternatively, a single Records Centre can contain multiple Libraries to store records according to business functions. Libraries in a Records Centre can be configured with folders that 'map' to an organisation’s Business Classification Scheme.

Depending on how a SharePoint implementation is configured, records can be sent to a Records Centre manually or automatically:

• Users can manually send records from the collaboration site in which they were created or saved to a Records Centre.
• Information Management (IM) Policies can be defined and/or workflows created for specific Content Types to automate the sending of records to a Records Centre.

A connection to a Records Centre can be configured so that each record is:

• copied to the Records Centre with the original version remaining in the collaboration site
• moved to the Records Centre (i.e. removed from the collaboration site), or
• moved to the Records Centre with a shortcut link to the record maintained in the collaboration site. ^[2]

Further information about configuring a Records Centre is available in the Microsoft article Introduction to the Records Centre.

It is vital to document decisions about the way in which each Records Centre is configured. This documentation should describe the ways in which records will be sent to a Records Centre, including details of any workflows and IM Policy features, and whether a connection to a Records Centre is configured so that a link to the record is maintained in the collaboration site. See Documenting design and configuration decisions.

Choosing an approach

It is possible to exclusively manage records in place, exclusively manage records in one or more Records Centres, or manage records both in place and in one or more Records Centres. For example, records might be managed within a Team Site for the duration of a project, and then moved to a Records Centre when the project is complete.

Any decision about which approach to take should consider the following points:

• Can records management staff effectively manage records stored across a SharePoint implementation? If the In Place Records Management feature is activated, records will likely be scattered across disparate sites, libraries and lists. Will record audits, reporting and disposal be manageable?
• Are records management staff able to configure and manage the routing rules necessary to move records from collaboration sites to a Records Centre? Using a Records Centre brings records together into a site that records management staff can control, but also requires records management staff to configure and manage the routing rules (located in the Content Organiser in the Records Centre) – this can be complex.
• Which staff will have Full Control permission levels? Users with this level of permission are able to change In Place Records Management settings, so it is important to appropriately restrict the number of users with this power. If this is not possible, the risk that records managed in collaboration sites will be inappropriately edited or deleted is high, so sending records to a Records Centre may be more suitable.
• Do records require specific access controls to limit which users are able to find and view them? Managing permissions at item level is complex (see Access and security), so it may be more appropriate to send records with specific access restrictions to a Records Centre than manage them in a collaboration site to which a range of users have access.
• How long will a collaboration site be in use? If it is only intended to be used for a short period of time (after which it would be deleted) but contains records that have a lengthy retention period, the site must be maintained after it ceases to be in use unless the records are sent to a Records Centre.
• What is the likely total size of a collaboration site (i.e. the estimated total number of records, maximum file sizes and total file sizes)? Managing records in a Records Centre relieves database size pressure on collaboration sites (which can affect performance), while managing records in collaboration sites means that the limits to the size of a Site Collection will be reached sooner. ^[3]

Records management administration

Information Management (IM) Policies include an Auditing feature, which can be configured to log events and operations performed on records, e.g. when a record is edited, deleted or has its permissions changed. The audit information is stored in a single audit log on the server that can only be accessed by Site Collection Administrators.

The reporting functionality provided in SharePoint (e.g. Web Analytics) allows Site Collection Administrators, Site Owners and other users with the necessary permission to report on the number of aggregations and records within an implementation, transaction statistics and the activity of individual users.

SharePoint can be configured to provide more advanced reporting, such as reports on metadata, aggregations or a classification scheme. SharePoint can also be configured to enable records management staff to sort, select, total and summarise report information, and to restrict users' access to selected reports (if required).

It is vital to document any configuration undertaken in a SharePoint implementation to support records management administration activities. See Documenting design and configuration decisions.

Designing a SharePoint implementation

SharePoint must be configured or enhanced with add-on software to ensure that it can create, capture and keep records in a way that supports their ability to function as authentic evidence of business. This section of the guidance examines the different ways in which SharePoint's features and functionality may be extended to facilitate good recordkeeping.

Configuration versus customisation

SharePoint must be configured to provide or extend certain recordkeeping features and functionality. However, care should be taken to avoid customising a SharePoint implementation (e.g. by making direct changes to the database schema, modifying files on the file system or excessively modifying the out of the box templates).

If customised rather than configured, a SharePoint implementation may become unsupported. This will make it difficult, if not impossible, to update SharePoint or upgrade to a newer version, thereby risking the integrity and long-term management of the records managed in the SharePoint implementation.

Detailed and complex configuration is required to provide certain recordkeeping features and functionality. Records management staff should ensure that they have a thorough understanding of what SharePoint can and cannot do before undertaking or requesting any configuration. Public offices should only consider undertaking this type of configuration if their IT staff have the capacity to develop and maintain the configured features and functionality over time.

Detailed and complex configuration might also be undertaken if a public office wishes to significantly tailor its SharePoint implementation to meet its own particular organisational needs. Some examples of more complex configuration include the creation of application sites, which are 'stand alone' sites dedicated to managing a particular type of content, and project sites, which may incorporate a range of project management features.

Some configuration can be avoided by implementing add-on software or integrating SharePoint with a separate EDRMS.

Add-on software

There are numerous software products available that extend the features and functionality of SharePoint. Organisations may choose to implement one or more products to enhance SharePoint’s existing recordkeeping features and functionality or to provide specific additional records management capabilities (e.g. the ability to easily capture email records).

Add-on software ranges from web parts and 'apps' that provide one or two additional features or pieces of functionality to extensive software suites that aim to make a SharePoint implementation compliant with records management standards (e.g. ISO 16175 Information and documentation – Principles and functional requirements for records in electronic office environments and Modular requirements for records systems (Moreq2010)).

When assessing add-on software it is important to consider:

• how easy the software is to implement and how much it will cost to implement, including whether a consultant will be needed to implement the software
• the impact of the software, and whether it alters the underlying infrastructure of SharePoint (i.e. whether it customises, rather than configures, SharePoint)
• whether the software is scalable and is likely to be able to meet potential future demand
• the financial stability of the software company, and whether or not they are likely to continue to exist and be able to provide support over the life of the software
• the extent and degree to which the software company works with Microsoft, and whether they are likely to provide updated versions of their software promptly when SharePoint is upgraded.

Implementing add-on software may hinder future upgrades to newer versions of SharePoint. The more products implemented, the more complex an upgrade – each add-on product will need to be tested against the upgrade and perhaps upgraded itself.

Integration with a separate EDRMS

SharePoint can be integrated with an electronic document and records management system (EDRMS). This approach often appeals to organisations that are already using a particular EDRMS, especially if the EDRMS has previously been integrated with other business systems in use within the organisation.

While integrating SharePoint with an EDRMS might be perceived as a relatively straightforward way of ensuring that records in SharePoint are managed as authentic evidence of business, there are a number of points to consider:

• An integration will require ongoing synchronisation. If changes are made to the way in which either SharePoint or the EDRMS is configured, the integration may require additional testing and adjustment. Additional testing and adjustments will also be required if either SharePoint or the EDRMS is upgraded to a newer version.
• Providing two repositories of information may be confusing for users when searching for records. This confusion can be mitigated through training and other change management initiatives. Alternatively, an integration could be designed so that records are managed in the EDRMS but accessed, together with other content, through SharePoint (i.e. without having to use the EDRMS and possibly without users realising that the records are stored in a separate repository).
• Maintaining both SharePoint and an EDRMS will require an organisation to employ staff with skills in both products, or source advice and assistance on both products from external service providers.
• Maintaining two products instead of one can result in substantial additional costs for an organisation, including costs for licences, infrastructure, support and maintenance.

Documenting design and configuration decisions

It is possible to implement SharePoint so that particular features are enabled or disabled and configured in different ways. It is critical to make records of all design and configuration decisions to promote the longevity and sustainability of a SharePoint implementation, and to support future upgrades, enhancements and migrations. Functional and technical documentation should include details of the SharePoint features enabled and disabled, and how they were configured, as well as any rules embedded in the implementation.

It is also important to document any add-on software implemented, including the version implemented, where the software was applied, and how the software was configured.

Public offices should ideally document all such decisions before rolling out SharePoint to users.

Creating and capturing records in SharePoint 2010

SharePoint must be configured and/or enhanced with add-on software to enable users to capture, identify and classify records so that their content, structure and context of creation are fixed in time and space. This facilitates the making of complete, authentic and usable records.

This section of the guidance identifies ways of configuring or enhancing SharePoint to:

• capture email messages as records
• manage aggregations of records
• generate point of capture metadata and persistently link this metadata with records
• classify records.

Email

Users are unable to capture email messages and attachments directly from their email application to SharePoint. Messages must first be saved to a shared or network drive, and from there saved to SharePoint.

Add-on software must be implemented to enable users to capture email records easily to SharePoint. Alternatively, a library in a SharePoint implementation can be configured with an email address to receive email messages.

SharePoint must be configured or enhanced with add-on software to capture email transmission data as separate metadata. However, even when an email record’s transmission data is not captured as separate metadata the message itself is fully searchable.

SharePoint must be configured to capture a human-readable version of an email message address (where one exists).

It is vital to document the ways in which a SharePoint implementation is configured to capture and manage email messages. See Documenting design and configuration decisions.

Aggregations

Aggregations are accumulations of related records that, when combined, may exist at a level above that of a single record. Aggregations may reflect relationships between records, such as shared characteristics or attributes, or the existence of sequential relationships between related records. For example, an aggregation may collectively constitute a narrative of events (i.e. a series of connected business transactions) in which the records may have a sequential relationship. ^[4]

ISO 16175, Information and documentation – Principles and functional requirements for records in electronic office environments, sets out the necessary functionality for managing aggregations within an EDRMS. SharePoint must be configured to provide much of this functionality. Alternatively, add-on software can be implemented to facilitate the management of aggregations.

Public offices should assess the ways in which different types of records relate to each other, depending on their business context and use, prior to configuring a SharePoint implementation or implementing add-on software. Any decisions to configure a SharePoint implementation or implement add-on software to facilitate the management of aggregations should be documented. See Documenting design and configuration decisions.

Point of capture metadata

To be meaningful as evidence of a business process, records must be linked to the context of their creation and use. These links can be achieved by associating each record with metadata that documents the business context in which it was created and its point of capture into SharePoint (referred to here as ‘point of capture metadata’).

An organisation may choose to implement a range of point of capture metadata, depending on their own business needs, including:

• unique identifier
• title
• date of creation
• who/what created the record
• the business function/process it relates to
• the creating application
• record type.

SharePoint must be configured to create this metadata for each record created and captured.

Point of capture metadata should be persistently linked with the record to which it relates.

SharePoint must be configured to enable records management staff to restrict the viewing or modifying of metadata elements by group, functional role or user, and to document all metadata administration activities.

It is vital to document the ways in which a SharePoint implementation is configured to facilitate the capture and management of metadata. See Documenting design and configuration decisions.

Unique identifiers

Unique identifiers can be used to point or provide a link to records.

The Document ID feature in SharePoint can be activated so that identifiers are assigned to documents when they are created. However as unique identifiers for records, the Document IDs generated within SharePoint have a number of weaknesses:

• The Document ID feature only applies to Document Libraries. Document IDs can therefore only be generated for documents and Document Sets (not records in other formats, e.g. list items, wiki pages and blog posts).
• Document IDs are only unique to a Site Collection. If more than one Site Collection uses the same Document ID prefix, two or more different records within a SharePoint Farm may be assigned the same Document ID.
• SharePoint must be configured to:
  • assign record extracts (i.e. copies of records from which some material has been removed or permanently masked) with unique identifiers
  • assign record aggregations (other than Document Sets) with unique identifiers
  • generate unique identifiers within a classification structure (it is possible to add numbers manually to folders that are used to represent an organisation’s Business Classification Scheme in a Records Centre).

The Document ID feature settings can be configured so that the identifiers generated in each Site Collection use a unique prefix. This will prevent the creation of duplicate Document IDs. Alternatively, add-on software can be implemented to enable the generation of SharePoint Farm-wide unique identifiers.

Document IDs are persistent.

Any decisions to configure a SharePoint implementation or implement add-on software to facilitate the generation of unique identifiers should be documented. See Documenting design and configuration decisions.

Classification

Classification for recordkeeping purposes is used to ensure that the links between the business being performed and the resulting records are robust and maintained. The purpose of records classification is to place each record in the context of the business activity that created it. ^[5]

A classification scheme can be established in SharePoint in different ways. Public offices should choose the approach that best suits their recordkeeping environment as well as the anticipated needs and behaviours of users. Decisions about the way in which a classification scheme is established within a SharePoint implementation should be documented. See Documenting design and configuration decisions.

Using managed terms to represent a classification scheme

SharePoint includes a centralised 'managed' metadata feature known as the Term Store. The Term Store provides a central location for the management of hierarchical metadata terms (in Term Sets) that are made accessible to Site Collections via the Managed Metadata Service. Each metadata term in a Term Store can include synonyms. For information about configuring a Managed Metadata Service, see ‘Configuring managed metadata service in SharePoint 2010 – step by step guide’.

A classification scheme can be represented by a set of managed terms stored in the Term Store that represents the hierarchy of the scheme.

Users can be required to choose a term from a term set each time they create or capture a record in SharePoint. Alternatively, Content Types can be configured to automatically assign the relevant terms from the set to new records when they are created or captured in SharePoint. This means that users only need to choose a relevant Content Type when creating or saving a record, and the record will automatically inherit relevant values from the classification scheme.

Records tagged with a term from the classification scheme can be managed in either a collaboration site or a Records Centre.

Structuring a Records Centre according to a classification scheme

A classification scheme can be used as the basis for structuring one or more Records Centres:

• A Document Library can be created within a Records Centre for each top level term, with folders within the Library for each second level term. Sub-folders can be added within folders to represent further levels of hierarchy.

• Alternatively, a Document Library can be created within a Records Centre to represent a record series. Folders and sub-folders within the Library can be used to represent the top and subsequent levels of the classification scheme.

With this approach, Content Types (including Document Sets) must be configured so that records created or saved as a specific Content Type are automatically routed via the Content Organiser to the appropriate folder in the Records Centre, either on creation or after a specified time period.

Structuring Site Collections according to a classification scheme

A classification scheme can be used as the basis for structuring Site Collections. Each Site Collection can represent a top level term, with sites within those Site Collections representing a second level term. Sub-sites can be created at lower levels to represent further levels of hierarchy.

This approach requires users to create and capture records within the relevant lowest level sub-site. These records can then be managed in place.

Folksonomies

SharePoint can be configured to allow users to create their own keywords (known as Enterprise Keywords) when capturing records. Enterprise Keywords enable users to tag records with words or phrases that meaningfully describe the record to them.

After a user creates an Enterprise Keyword it appears in the Keywords Term Set as a simple flat list of terms. An Enterprise Keyword can also be moved to another Term Set. Other users will be able to use the keyword when they are tagging records within the SharePoint implementation if Enterprise Keywords have been enabled.

Managing authentic and reliable records in SharePoint 2010

Digital records must be actively maintained to ensure their continued accessibility. To have integrity, records must be protected against unauthorised access, alteration, deletion or loss. This helps to ensure that records can be relied upon as trustworthy evidence of business.

This section of the guidance identifies ways of configuring or enhancing SharePoint to:

• control access to records
• generate records management process metadata and persistently link this metadata with records
• facilitate the appropriate and authorised retention and disposal of records
• export records to other systems and/or custodians with all necessary contextual metadata.

Access and security

Access to sites and site content in SharePoint can be controlled by assigning permissions to users or groups at the level of a site, library or list, folder, or item.

Although SharePoint provides the capability to set permissions on individual items, these are difficult to manage manually. Access to records can instead be restricted by applying permissions at a higher level (e.g. to a library or folder) and storing records with specific access restrictions in specifically restricted libraries or folders. Alternatively, add-on software can be implemented to assist in managing and automating the review of permissions in a SharePoint implementation.

When records are imported from shared or network drives into a SharePoint implementation, any permissions restricting access to the records on the drive are replaced by the permissions applying to the relevant site or library. Care must be taken to ensure that access restrictions are maintained after records are imported into SharePoint (if the restrictions remain current).

If a record is moved within a SharePoint implementation, SharePoint must be configured to prevent the record from inappropriately inheriting the permissions of its new location. The following example demonstrates how moving a record to a Records Centre could automatically change its access group, thereby potentially compromising its security:

Figure 1: Example of changes to access group following movement of records ^[6]

SharePoint 2010 must be configured to:

• prevent users (other than records management staff) from setting up user profiles and allocating users to groups (by default, Site Owners can do this)
• prevent users (other than records management staff) from changing security attributes for groups or users (e.g. access rights, security levels, privileges etc.)
• enable records management staff to alter the security category of individual records
• enable records management staff to alter the security category of all records within an aggregation in a single operation
• log all unauthorised attempts to access records in the records' metadata.

If a user requests access to or searches for a record that they do not have the right to view, SharePoint will not display any record metadata or otherwise indicate its existence. SharePoint must be configured to enable specific records management staff (or other security cleared users) to search for and retrieve metadata about all records.

It is vital to document the ways in which a SharePoint implementation is configured to manage access and security. See Documenting design and configuration decisions.

Security categories

Security caveats and hierarchical security are not available in SharePoint. Add-on software can be implemented to provide this functionality.

SharePoint must be configured to:

• assign security classifications to records
• allow security classifications for records and records aggregations to be selected and assigned at system level
• assign security categories at any level of records aggregation and after a specified time or event
• provide routine, scheduled reviews of security classifications.

Detailed design, development and/or configuration is required to allow access-permission security categorisation to be assigned by organisational role and at user level.

SharePoint does not support security clearances for users. Add-on software can be implemented to restrict access to aggregations and records that have a security classification higher than a user’s security clearance.

Records management process metadata

Process metadata documents the recordkeeping processes performed on records and information, such as registration into a recordkeeping system, the application or change of security and access rules, transfer of control, and record destruction or migration. It also includes information about the ways in which records and information are used.

SharePoint captures a range of process metadata by default. For example, SharePoint automatically captures metadata showing when a record was created or saved in SharePoint, or when it was modified, and by whom. SharePoint retains the original created date for a document created outside SharePoint (e.g. a document originally created on a shared or network drive) in the document’s properties.

SharePoint must be configured to capture certain other process metadata (including metadata documenting a record’s disposal). SharePoint must also be configured to capture metadata of all changes made to aggregations of records.

Process metadata should be persistently linked with the record to which it relates, and maintained after the record to which it relates is destroyed for as long as required. SharePoint must be configured to maintain records management process metadata for records and aggregations that have been destroyed or transferred to other organisations.

SharePoint can be configured to allow records management staff to restrict the viewing or modifying of metadata elements by group, functional role or user, and to document all metadata administration activities.

It is vital to document the ways in which a SharePoint implementation is configured to facilitate the capture and management of metadata. See Documenting design and configuration decisions.

Retention and disposal

Part 3 of the State Records Act 1998 prohibits the disposal of records created and maintained by NSW public offices except where it is authorised. SharePoint must be configured to facilitate the appropriate and accountable disposal of records.

Retaining records

Records must not be deleted before the minimum retention periods set out in approved retention and disposal authorities have expired. SharePoint must be configured to prevent the premature deletion of records.

Disposing of records

Records must be disposed of in a managed, systematic and auditable way.

Records disposal can be achieved in SharePoint using Information Management (IM) Policies. IM Policies include a Retention feature which can be used to set a retention period, disposal trigger and disposal action. Multi-stage disposal actions can be defined (e.g. retain x years in collaboration site, then send to Records Centre, then retain x years in Records Centre, then destroy).

IM Policies can be defined either for Content Types (including wiki pages and blog posts) or for locations (i.e. Libraries and folders).

Defining IM Policies for Content Types

Records can be disposed of according to their Content Type. Using IM Policies, each Content Type can be mapped to a disposal class in an authorised retention and disposal authority or to Normal Administrative Practice (NAP). In theory this will result in the appropriate retention and disposal of any record saved as or created using a particular Content Type. In practice, the appropriate retention and disposal of records will depend on accurate use of Content Types – users will need to receive adequate training and the use and application of Content Types must be controlled and monitored.

Defining IM Policies for locations

Records can also be disposed of according to their location. Related records that have the same disposal outcomes can be saved in a Library or folder that has a specific IM Policy which defines a retention period, disposal trigger and disposal action for the contained records. The records in the Library or folder will be disposed of concurrently.

Triggers for disposal

In SharePoint the disposal of records can be triggered by an event that has occurred in relation to each individual record (e.g. date created or date last modified). SharePoint must be enhanced with add-on software to enable a business event to be used as a trigger (e.g. expiry of contract, termination of employment etc.) Any decisions to implement add-on software to support the use of business event-based disposal triggers should be documented. See Documenting design and configuration decisions.

Reviewing disposal

Disposal decisions should be confirmed as current and accurate before they are executed. SharePoint must be configured to facilitate this review of disposal decisions.

Timer jobs run continuously in SharePoint, acting upon IM Policies, and can automatically delete items when the rules specified by the Policies are met. SharePoint must be configured to prevent these timer jobs from automatically destroying records when their minimum retention period has been met.

To facilitate the review of disposal decisions, SharePoint can be configured with a Disposition Approval workflow (one of the predefined workflow templates included in SharePoint) to alert records management staff to records and aggregations due for disposal before they are disposed of and enable staff to decide whether to retain or delete the records. SharePoint can also be configured to produce reports that identify all records that are due for disposal during a specified time period.

SharePoint must also be configured to enable records management staff and other relevant staff to review proposed disposal actions and to:

• easily assess aggregations due for disposal with their records management metadata and disposal authority information
• mark an aggregation for destruction, transfer or indefinite hold or change the disposal authority for an aggregation, after they have assessed it
• store all review decisions and reasons for review decisions in the metadata.

Extensive development is required to enable SharePoint to alert records management staff if an aggregation due for destruction is linked to another aggregation. Development is also required to provide complex reporting and analysis tools for records management staff to use to manage disposal, such as the ability to identify formal contradictions in disposal authorities across the classification scheme.

It is vital to document the ways in which a SharePoint implementation is configured to facilitate the review of disposal decisions. See Documenting design and configuration decisions.

Deleting records

Deleting records in a system is often considered to constitute permanent destruction. However, because SharePoint stores content in a database, deleting records from a SharePoint implementation does not necessarily mean that they are no longer recoverable.

Alternatively, add-on software may be implemented to facilitate the complete, unrecoverable destruction of records in SharePoint. Any decisions to configure a SharePoint implementation or implement add-on software to facilitate permanent destruction should be documented. See Documenting design and configuration decisions.

Further information about destroying digital records, including assessing methods of destruction in conjunction with the sensitivity of the records to be destroyed, is available from Destruction of records.

Documenting disposal

The disposal of all records should be documented, including the nature and time of the disposal action, the identity of the person authorising the action and the disposal authority authorising the action. If records are to be deleted, public offices must be able to demonstrate that the records have been deleted from the system.

SharePoint must be configured to automatically record and report all disposal actions to records management staff. Such configuration should be documented. See Documenting design and configuration decisions.

Exporting records

Records will need to be exported from a SharePoint implementation:

• if they need to be retained longer than the likely lifespan of a SharePoint implementation, in which case they will need to be migrated to a new system
• in the event that a public office decides to change the system it is using to manage digital records, in which case they will need to be migrated to the new system
• as a result of administrative change or privatisation, in which case they will need to be migrated to the system/s in use within the other organisation
• if they are identified for retention as State archives in an approved retention and disposal authority, in which case they may need to be transferred to State Records.

Records exported from SharePoint lose certain contextual metadata, only retaining any metadata embedded in each record. This creates significant records management risks, including:

• difficulty in managing exported records without losing their context
• inability to transfer contextual metadata with records to another public office or private sector organisation following administrative change or privatisation
• inability to transfer contextual metadata with records to State Records as part of a digital transfer.

SharePoint must be configured to:

• easily transfer aggregations of records
• report on any failure during an export (e.g. any records that generated processing errors, any records or aggregations that were not successfully exported etc.)
• retain copies of all exported aggregations and records until the export is confirmed to have been successful.

SharePoint must also be configured or enhanced with add-on software to convert records other than those created with Microsoft Office products to long-term, open preservation formats (e.g. PDF/A).

It is vital to document the ways in which a SharePoint implementation is configured or enhanced with add-on software to facilitate the export of records and metadata. See Documenting design and configuration decisions.

Managing physical records in SharePoint 2010

SharePoint is focussed on digital records and is unable to manage paper and other physical format information as effectively as some electronic document and records management systems (EDRMS).

Physical records (including the physical part of hybrid records) can be recorded and tracked using the List functionality in SharePoint. Because physical records in SharePoint are only a placeholder for the actual record, process metadata must be updated when actions are taken on the actual record.

Add-on software is required to enable SharePoint to comprehensively manage physical and hybrid records. Decisions to implement add-on software for this purpose, including details of the additional features and functionality provided, should be documented. See Documenting design and configuration decisions.

Disseminating records in SharePoint 2010

For the records that it holds to be useable, SharePoint must be able to search for, retrieve and render records in different ways. When implemented out of the box, SharePoint provides basic search, retrieve and render functionality.

This section of the guidance identifies the types of advanced or complex search, retrieve and render functionality that can be configured in SharePoint.

Searching for and retrieving records

SharePoint must be configured to:

• allow free-text searching of combinations of records management metadata elements and record content, and Boolean searching of metadata elements
• display all the records management metadata relating to an aggregation as a single unit
• allow users to retrieve aggregations directly through the use of a unique identifier
• allow users to see a record they are working with within the classification or aggregation hierarchy easily and without leaving or closing the record
• relate an extract of a record (i.e. a copy of a record from which some material has been removed or permanently masked) to the original record so that searching for one retrieves both the extract and the original record
• provide concept searches through the use of an thesaurus incorporated as an online index.

If a SharePoint implementation is configured to provide this functionality, the configuration should be documented. See Documenting design and configuration decisions.

Printing records

SharePoint must be configured to allow users to:

• print records and their relevant records management metadata
• print records management metadata for an aggregation.

Additional configuration is required to allow records management staff to specify that all printouts of records must have selected records management metadata elements appended to them (e.g. that a printed report has its unique identifier printed on the cover page).

Tailored reports can be configured to allow records management staff to print the classification scheme, metadata schema and element sets.

Any configuration of a SharePoint implementation to facilitate the printing of records should be documented. See Documenting design and configuration decisions.

Redacting records

An extract is a copy of a record from which some content has been removed or permanently masked. Extracts are made when a full record cannot be released for access but parts of the record can.

SharePoint must be configured to:

• allow records management staff to copy a record for the purpose of redaction
• record the creation of extracts in a record’s metadata, including the date, time, reason for creation and creator.

If a SharePoint implementation is configured to provide this functionality, the configuration should be documented. See Documenting design and configuration decisions.

SharePoint 2010 implementation case studies

SharePoint 2010 glossary

Definitions sourced from Microsoft Developer Network Library (<http://msdn.microsoft.com/en-us/library/dd776256.aspx>), Microsoft SharePoint Server 2010 help and how-to and Microsoft TechNet Library (<http://technet.microsoft.com/en-us/library/ee428287.aspx>) (all viewed 21 June 2012), unless otherwise specified

Assessment of SharePoint 2010 against the Standard on Records Management

Principle 3 of the Standard on Records Management requires that records and information are well managed. This management extends to records and information in all formats, in all business environments and in all types of systems.

The following table identifies the compliance requirements in the standard that are relevant to the use of SharePoint 2010 by NSW public offices. Each relevant requirement identifies sections of this guidance that public offices may refer to for assistance in meeting the requirement.

NSW public offices may use this table to assess the records and information management capabilities of their own SharePoint implementation.

References and further reading

Armstrong, D, ‘SharePoint 2010: storing documents on the file system with remote blob storage’, Simple-Talk, 19 April 2011, <http://www.simple-talk.com/dotnet/.net-tools/sharepoint-2010-storing-documents-on-the-file-system-with-remote-blob-storage> (viewed 21 June 2012)

Australian Handbook HB 5031-2011 Records classification

International Standard ISO 16175-2:2011, Information and documentation - Principles and functional requirements for records in electronic office environments, Part 2: Guidelines and functional requirements for digital records management systems

Lappin, J, Thinking records: James Lappin’s records management blog, <http://thinkingrecords.co.uk> (viewed 21 June 2012)

Microsoft Developer Network Library: SharePoint 2010, <http://msdn.microsoft.com/en-us/library/dd776256.aspx> (viewed 21 June 2012)

Microsoft Enterprise Content Management (ECM) team blog, <http://blogs.msdn.com/b/ecm> (viewed 21 June 2012)

Microsoft SharePoint Developer Center, <http://msdn.microsoft.com/en-US/sharepoint/default.aspx> (viewed 21 June 2012)

Miller, B, Managing records in Microsoft SharePoint, RIMtech, Ottawa, available via <http://www.rimtech.ca/managing-records-in-sharepoint-2010.html> (viewed 21 March 2016)

State Records of South Australia, Microsoft SharePoint and EDRMS, Adelaide, 17 September 2014, available via <http://archives.sa.gov.au/content/digital-records-management#Advice%20Sheets> (viewed 21 March 2016)

Tasmanian Archive and Heritage Office, Information management advice: no 22 records management using SharePoint – considerations, Hobart, 23 April 2012, available via <http://www.informationstrategy.tas.gov.au/Records-Management-Principles/Pages/Numeric-List.aspx> (viewed 21 March 2016)

The National Archives (UK), Records management in SharePoint 2010: implications and issues, Kew, 2011, <http://www.nationalarchives.gov.uk/documents/information-management/review-of-records-management-in-sharepoint-2010.pdf> (viewed 21 June 2012)

Warland, A, Records about the world: thoughts and comments about managing information and other things, <http://andrewwarland.wordpress.com> (viewed 21 June 2012)

Wise, J and R Colley, Analysis of MOSS 2007 and SharePoint 2010 against ICA ERMS Requirements, Wise Technology Management, Noosa Heads, Version 2.0, 27 April 2010, <http://download.microsoft.com/documents/australia/government/20101230_Analysis_MOSS%202007_SP_2010_against_ICA_ERMS_Requirements.pdf> (viewed 21 June 2012)

Wise Technology Management, Implementing SharePoint 2010 as a compliant information management platform, Noosa Heads, 2010, <http://www.wisetechnology.com/pdf/Implementing-SP-2010-as-a-compliant-IM-Platform-ICA-evaluation-summary.pdf> (viewed 21 June 2012)

Acknowledgments

State Records would like to gratefully acknowledge a number of key contributors to this guidance.

In particular we would like to thank Andrew Warland for his kind assistance in the development of this guidance. We would also like to thank the following public offices for sharing their experiences in planning and rolling out a SharePoint 2010 implementation:

• Bankstown City Council
• Cobbora Holding Company
• Legal Aid NSW
• Police Integrity Commission
• TCorp
• Transgrid
• University of Sydney.

Footnotes

[1] The concept of 'declaring' records comes from recordkeeping practices in the United States where documents are not considered to be records until they go through the process of 'recordization'. The Australian recordkeeping and legal environments do not require a document to go through a particular process or be managed in a particular way to be considered a record. The State Records Act 1998 defines a record as 'any document or other source of information compiled, recorded or stored in written form or on film, or by electronic process, or in any other manner or by any other means'.

[2] If a record is moved to a Records Centre with a link maintained in the collaboration site, the record's Document ID will no longer be visible in the collaboration site. However, users will still be able to search for and access the record using its Document ID.

[3] Records management staff should be aware of the software boundaries and limits of SharePoint, both in terms of volume and size (e.g. Microsoft strongly recommends limiting the size of site collections to 100 GB; files in lists and libraries can be a maximum of 2 GB in size etc.) Further information about software boundaries and limits in SharePoint is available in the Microsoft article SharePoint Server 2010 capacity management: software boundaries and limits.

[4] ISO 16175-2:2011, Information and documentation – Principles and functional requirements for records in electronic office environments, Part 2: Guidelines and functional requirements for digital records management systems, p.15

[5] Australian Handbook HB 5031-2011, Records classification, p.4

[6] The National Archives (UK), Records management in SharePoint 2010: implications and issues, Kew, 2011, <http://www.nationalarchives.gov.uk/documents/information-management/revi..., pp.8-9

[7] S Peschka, ‘SharePoint 2010 Content Organizer Part 1 - a cool new feature for managing your content’, Share-n-dipity blog, 30 October 2009, <http://blogs.technet.com/b/speschka/archive/2009/10/30/sharepoint-2010-c... (viewed 21 June 2012)

[8] J Yasir, ‘What is a SharePoint Farm and questions about topologies’, Jerry Yasir: SharePoint MVP – adventures of SharePoint, 14 March 2008, <http://jerryyasir.wordpress.com/2008/03/14/what-is-a-sharepoint-farm-and-questions-about-topologies> (viewed 19 June 2012)