SharePoint 2010: Recordkeeping Considerations

Contents

Purpose
Scope
Records management in SharePoint 2010
Designing a SharePoint implementation
Creating and capturing records in SharePoint 2010
Managing authentic and reliable records in SharePoint 2010
Managing physical records in SharePoint 2010
Disseminating records in SharePoint 2010
SharePoint 2010 implementation case studies
SharePoint 2010 glossary
Assessment of SharePoint 2010 against the Standard on Records Management
References and further reading
Acknowledgments

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.

Recordkeeping features and functionality should ideally be considered when a public office is planning and designing its SharePoint implementation. It is far easier to incorporate the necessary features and functionality into a new implementation than add them to an existing implementation.

Trying to retrospectively add recordkeeping features and functionality to an existing implementation may meet with resistance from users if the changes impact on the ways in which they use SharePoint. In addition, some features (such as metadata and changes to metadata) can be difficult to add retrospectively.

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.

Good governance and careful planning are essential to an effective SharePoint implementation. Microsoft has published a range of articles and resources to assist in planning, designing and implementing a SharePoint implementation in the SharePoint 2010 section of the Microsoft TechNet Library.

Documenting roles and responsibilities is critical to governance. In regard to records management, it is important to document at the outset of a SharePoint implementation which role/s within an organisation will be responsible for configuring and maintaining the features and functionality that support and facilitate recordkeeping (e.g. who will be responsible for managing the Term Store, who will be responsible for setting up user profiles, allocating users to groups and setting security attributes for users and groups, who will be responsible for creating and managing Content Types etc.)

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.

This guidance assumes a degree of familiarity with SharePoint terminology. Definitions for relevant SharePoint terms are included in the Glossary.

This guidance also assumes a degree of familiarity with SharePoint server and site architecture (i.e. Farms, Servers, Content Databases, Site Collections, Sites, Lists etc.) For a visual representation of the SharePoint object model hierarchy see Microsoft’s Server and site architecture: object model overview.

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.

Public offices should note that while each option consists of certain recordkeeping features and functionality, additional configuration is required to ensure that records, either in collaboration sites or in a Records Centre, can function as authentic evidence of business. This configuration is outlined in further sections of this guidance.

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.

When a Site Collection Administrator activates the In Place Records Management feature he or she specifies whether declared records can be edited or deleted by users. Depending on how In Place Records Management is set up, declaring a record may not automatically protect it from being further edited or deleted by users. This may compromise a record's integrity and accessibility: records must be protected from unauthorised alteration and deletion, and remain accessible for as long as they are required.

The Site Collection Administrator also specifies the types of users who will be able to declare and un-declare records (e.g. In Place Records Management might be configured so that all users can declare records but only users with a certain permission level can un-declare records). Public offices should consider whether it is feasible to restrict the ability to un-declare records to records management staff to protect the integrity and accessibility of records.

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.

Wiki pages and blog posts can be declared as records in SharePoint.

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 possible to manage records in place without using the 'Declare Record' option. Options for protecting records within collaboration sites from unauthorised alteration and deletion include:

making Libraries read only
removing the 'Delete Items' permission from the Contribute permission level (for more information about permission levels, see Access and security).

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.

The Records Centre site template is not included in SharePoint Online, but it is possible to manually configure a site to act as a records repository within a SharePoint Online implementation. It is important to note, however, that the Records Centre site template includes specific features that are missing from other types of sites. One of the most important of these is the ability to contain a higher volume of content.

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.

When a record is sent to a Records Centre, the SharePoint metadata recording its creator and date of creation is overwritten by default with metadata recording the user who sent the record to the Records Centre and the date this occurred. However, metadata recording the record’s true creator and date of creation is maintained in the record’s properties (e.g. for a Microsoft Word document, the underlying properties for Date Created and Author remain unchanged and can be accessed by navigating to the document’s properties).

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]

SharePoint should be configured to prevent users from copying a record and maintaining two versions, one in a Records Centre and one in a collaboration site (the first option above). Maintaining two versions of a record means that there is no 'single source of truth'. It also presents a risk that two very different records will evolve, making it difficult to trace accountabilities and determine what information was used as the basis for decision making.

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.

Record versions

SharePoint includes versioning functionality that can be configured to track versions of a record. Further information about enabling and configuring versioning is available in the Microsoft article Enable and configure versioning for a list or library.

When a record is sent to the Content Organiser (which occurs when a record is sent to a Records Centre) its version history is erased. In some cases it may be appropriate to erase a previous version of a record (e.g. if the version represents a minor change and there is no identified recordkeeping requirement to retain it). In other cases, previous versions of a record may document significant decisions, reasons and actions, or contain substantial information that is not contained in the final version – in these cases, previous versions should be retained as records.

The Content Organiser settings can be configured to preserve a record's audit logs and properties after it is routed to a Records Centre. Alternatively, previous versions of a record could be captured as individual records.

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.

For some organisations it may be appropriate to use different approaches for different business units or functions, depending on the likely needs and behaviours of different users. However, managing multiple, tailored approaches can become complex and difficult to maintain.

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]

When configuring either In Place Records Management or a Records Centre, it is important to consider whether users can be depended upon to make decisions about when a record should be declared or sent to a Records Centre:

If users will be required to manually declare records or send them to a Records Centre, they will need to receive appropriate training and their compliance should be monitored.
If users cannot be depended upon to make these decisions, SharePoint should be configured so that records are declared or moved automatically.

All configuration decisions should be documented.

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.

My Sites

A My Site is a 'personal' location within a SharePoint implementation for users to manage and store content, links and contacts (e.g. as an alternative to 'personal' space on a shared or network drive). A My Site is a Site Collection in its own right, and each user has administration rights over their own My Site. Users can add new pages, or new sub-sites, and can give particular colleagues permissions to view and/or contribute to content within their My Site.

My Sites present a risk to public offices in terms of control over corporate records (similar to the risk presented by users creating and keeping corporate records on personal drives). If users create and store records within their My Site, only the user and those colleagues granted the necessary permissions by the user will be able to access the records.

My Sites can be used to give users some freedom to create personal information (e.g. in lieu of a personal folder on a shared or network drive). However, the creation of corporate records within My Sites should be discouraged. The use of My Sites should therefore be accompanied by appropriate governance to prevent the accumulation of records within My Sites.

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.

While licence costs for SharePoint may be relatively inexpensive, the costs of configuration could be substantial. As a SharePoint implementation often consists of a series of collaboration sites, any estimation of costs should consider that each site may need to be specifically configured to meet the particular recordkeeping requirements of the relevant business area.

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.

Legal Aid NSW has integrated SharePoint with its EDRMS (TRIM). Further details about this integration are provided in a case study [COMING SOON].

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.

Making decisions about shared or network drives

SharePoint is often implemented as a replacement for the use of shared or network drives. Following an implementation, a public office might choose to:

bulk migrate all records to SharePoint and then delete them from the drives
migrate records to SharePoint as needed and then delete them from the drives
make the drives read only
allow users to continue to keep and edit working documents on the drives
remove all user access to the drives.

Decisions about shared or network drives should be accompanied with the necessary change management.

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.

SharePoint can import records from commonly used sources, such as shared or network drives. Add-on software is required to import records from other, less commonly used sources, e.g. Lotus Notes.

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.

If email messages are saved as .msg files, the complete message (message header, message body, sender, recipients, HTML-body and attachments) is stored in one file.

When a user opens a message saved as a .msg file in SharePoint it opens as it would in Microsoft Outlook. The user can then view the message's transmission data by navigating to the message's properties. This transmission data and the content and appearance of the message cannot be edited by users.

Users can amend the name or title of an email record by editing its SharePoint metadata (e.g. to give a message a more useful name, such as Approval to attend Records Managers Forum instead of RE: your request). Such changes to a record's metadata are recorded in the audit log of the Content Type (if enabled).

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.

An alternative to capturing email records in SharePoint is to manage them in a separate repository. If a public office decides to store email records in a separate repository, there must be a means of linking them to related records in other formats stored in SharePoint.

Note: Microsoft Exchange Server 2010 includes Messaging Records Management (MRM) technology for managing the retention and disposal of email messages. Although MRM can be used to assign retention periods to email messages, it fails to manage messages in context with other, related records. Further information about MRM is available in the Microsoft article Choose an e-mail and messaging records management strategy (SharePoint Server 2010).

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.

Creating aggregations using Document Libraries or Document Sets

Aggregations of records might include groups of records that, when created in paper form, would have been managed in a file or series (e.g. records about a specific project or case). Within SharePoint, such aggregations can be managed in their own Document Library or using Document Sets (which have a unique identifier and can have their own metadata properties).

Document Sets can also be used to manage compound documents.

Note: Document Sets are not available in SharePoint Foundation, only in SharePoint Server and SharePoint Online.

Folders versus metadata

In environments such as shared or network drives and email inboxes users often employ folders to contain related records. It is important to note that folders in a SharePoint Library do not function in the same way as folders in drives and inboxes (e.g. SharePoint does not display a hierarchical representation of a folder structure by default, making it difficult to navigate).

Hierarchical metadata sets in the Term Store provide an alternative way of creating aggregations. In some cases, the names given to folders on a shared or network drive can provide the basis for metadata terms which, when applied to records, can be used to achieve the same form of aggregation provided by the folders.

Note: Folders based on an organisation's Business Classification Scheme with Information Management (IM) Policies applied to them can be used effectively in a Records Centre (see Structuring a Records Centre according to a classification scheme). Folders also provide a means for controlling Permissions (see Access and security).

For details of the benefits and disadvantages of using folders rather than metadata, see:

'Folders in SharePoint are not evil!' on Glyn Clough’s blog – all about Microsoft SharePoint
‘“Folders are bad” and other urban legends…’ on the Clever workarounds blog
‘SharePoint folders vs. metadata’ on the Things that should be easy blog
‘Alternatives to folders in SharePoint 2010’ on the Records about the world: thoughts and comments about managing information and other things blog

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.

The taxonomy tools in SharePoint can be used to enforce reliable metadata value selection.

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

Retaining point of capture metadata

The General retention and disposal authority: administrative records requires certain key metadata to be retained for a minimum of 20 years after the record to which it relates is disposed of. Public offices must plan for how they will maintain this metadata for records captured in SharePoint for this period.

Any decision to maintain this metadata in another system will require further development work to enable SharePoint to export metadata for records. It is possible to export metadata about records to Microsoft Excel and then save it as a CSV or XML file for importing into another system.

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.

Metadata for imported records

If records are imported to a SharePoint implementation from other systems, certain point of capture metadata may be overwritten. For example, if records are imported from shared or network drives, the date the record was created will be replaced with the date the record was imported to SharePoint, and the name of the record’s creator will be replaced with the name of the person who imported the record. Other information captured within the record’s properties, such as date last modified, may also be lost.

The loss of this metadata reduces the authenticity of the records: they can no longer be proven to have been created or sent by the person that created or sent them, or to have been created or sent at the time they were created or sent.

To mitigate the loss of this metadata, point of capture metadata can be bulk imported separately from records and then re-linked to each record. Alternatively, add-on software can be implemented to manage imports so that the point of capture metadata for each record is retained.

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 have the format prefix – site number – number (e.g. PROP-23-1234). Add-on software can be implemented to manipulate the format of unique identifiers in SharePoint. For example, unique identifiers could be manipulated to follow the format 'year/number', e.g. 2012/0128.

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.

A hierarchy of terms can be a maximum of seven levels deep.

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.

Example:

Classification metadata on a Content Type can be used to create a rule in the Content Organiser to move a record to the relevant part of the classification scheme in the folder structure of a Records Centre Library.

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.

Example:

An organisation creates a Site Collection for Fleet Management. This Site Collection includes a site for Maintenance Records. This site has a number of sub-sites for each vehicle, or a Document Library for each vehicle. Content Types with appropriate metadata and Information Management (IM) Policies are available in each Document Library.

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

With this approach, a record's business context will be ascertained from its location within the Site Collection structure. Any changes to the structure must therefore be prevented in order to maintain this context. If a record is moved to another location, information about its original business context will be lost.

This approach would preclude the creation of sites and sub-sites by users, as users must not be able to create and capture records in any site other than the site representing the lowest level of the classification scheme. The creation of sites and sub-sites would need to be strictly controlled.

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.

Ideally, records management staff should manage the Term Store that contains all managed metadata terms. This will enable records management staff to monitor the Enterprise Keywords that are created and, where necessary, either add these terms to existing Term Sets, create new Term Sets or include the new terms as synonyms for existing terms.

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.

Permissions are, by default, inherited from the parent object (so a library inherits its permissions from the site, a folder in a library inherits its permissions from the library etc.) It is possible for a Site Collection Administrator (or other user with the necessary permissions) to break this inheritance and assign unique permissions at the list or library, folder or item level. However, the more broken inheritance a Site Collection accumulates, the more administration is required of those disconnected areas.

Broken inheritance created in an ad hoc manner can also result in users being unable to access the records they require to work and undertake business.

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:

Example of changes to access group following movement of records

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

If changes are made to permissions for a site or library they can be cascaded to all records within the site or library, irrespective of any specific access restrictions the records may already have. It is therefore very important that the ability to change permission settings is restricted to relevant staff (e.g. records management staff).

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.

Auditing events and operations performed on records

Information Management (IM) Policies include an Auditing feature that can be configured to log events and operations performed on records. The following events can be logged:

opening or downloading a record
viewing a record
viewing a record’s properties (e.g. metadata)
editing a record
checking a record in or out (if this functionality is available for records)
moving or copying a record to another location
deleting or restoring a record.

Other actions that are audited and produce reports include:

modifications to Content Types and Lists
expiration and disposition of content
creation and use of IM Policies
changes to auditing settings
changes to the security configuration.

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.

Retaining records management process metadata

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.

By default, Site Collection Administrators have full rights to all sites within a Site Collection. They can add or delete sites, or change the settings for any site. They can also view, add, delete or change all content within those sites.

If a Site Collection Administrator deletes a site that contains records that are being managed in place, the records will also be deleted. If this occurs, it may not be possible to determine what records have been lost as no audit trail will be available for the deleted content (other than a record of the action to delete the site).

The ability to delete sites must be restricted and controlled with a clear policy and firm administrative controls. In addition, organisations should consider whether the role of Site Collection Administrator should only be given to relevant records management staff.

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).

The ability to define IM Policies should be restricted to relevant records management staff. This will give records management staff control over the Policies and ensure that the Policies are authoritative and reliable.

Restricting the ability to define IM Policies will also ensure that changes to an IM Policy for a location do not override relevant IM Policies applying to records contained in that location.

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.

The more Content Types available for users to choose from when creating and saving records, the less chance there is of a user choosing the appropriate Content Type.

The number of Content Types available can be restricted by only adding relevant Content Types to a particular list or library. The number of Content Types available for use in a particular Site can also be restricted.

The application of metadata on each Content Type can help restrict the number of Content Types required (e.g. an organisation may have a Content Type named ‘Fleet Management’ with a metadata field that defines the various activities that might occur, such as acquisition, accidents, maintenance, disposal, policy etc.)

If Content Types are used to facilitate the disposal of records, the ability to create and manage Content Types should be restricted to relevant records management staff.

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.

Using location-based IM Policies to dispose of aggregations

The Content Organiser can be configured to route different Content Types to a single location in a Records Centre. As location-based IM Policies (i.e. Policies on Libraries or folders) override IM Policies defined for Content Types, this functionality can be utilised to facilitate the concurrent disposal of aggregated records comprising different Content Types. It is vital to document any such configuration. See Documenting design and configuration decisions.

Location-based IM Policies can also be used in collaboration sites to facilitate the concurrent disposal of records that are managed as a 'case'.

Note: IM Policies defined for folders in collaboration sites can be difficult to manage as they are decentralised and hard to oversee. IM Policies applied to folders are inherited by any sub-folders.

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.

As far as possible the destruction of records should be irreversible with no reasonable risk of the information being recovered again. SharePoint must be configured to enable the total destruction of records so that they cannot be restored.

The disposal options available in SharePoint are:

move to recycle bin
permanently delete
transfer to another location
start a workflow
skip to next stage
declare record
delete previous drafts
delete all previous versions.

Choosing the 'Delete' option will usually transfer a record to the Site's recycle bin for a period of three months, after which it will be transferred to the Site Collection's recycle bin for a further three months, after which it will be permanently deleted. Choosing 'Permanently Delete' will make it difficult to recover a record.

Note: The periods of time for which a record is kept in each recycle bin can be changed.

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.

When a record is permanently deleted from SharePoint its metadata is also permanently deleted. SharePoint must be configured or enhanced with add-on software to retain metadata for deleted records.

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.

Add-on software can be implemented to enable the export of contextual metadata.

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.

Physical records will typically be registered in a list while digital records will be registered in a Document Library. A Document Set could potentially operate as a hybrid aggregation in a small SharePoint implementation.

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.

The provision of these features and functionality must be subject to any relevant access restrictions on the records.

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

Case study: Why Cobbora Holding Company chose SharePoint 2010 as its digital recordkeeping system

This case study examines the motivations of Cobbora Holding Company in choosing to implement SharePoint 2010 as its digital recordkeeping system.

Case study: SharePoint 2010 pilot project at Bankstown City Council

This case study describes a pilot project to determine whether SharePoint 2010 could meet Council’s document and records management needs as well as introduce improvements to Council’s information management practices.

Case study: SharePoint 2010 implementation at the Police Integrity Commission

This case study describes a project to implement SharePoint 2010 as the Police Integrity Commission’s document management system.

Content Organiser	A feature that enables the routing of content to defined destinations such as libraries, folders or other Content Organiser managed sites. Content Organiser analyses an item’s Content Type and/or metadata information and then matches the results with a set of rules. If there is a matching rule, the item will be moved to the defined destination. ^[7]
Content Type	A named and uniquely identifiable collection of settings and fields that store metadata for individual items in a List
Document Library	A type of List that is a container for documents and folders
Document Set	A folder-based Content Type that organises multiple related documents into a single view where they can be worked on and managed as a single entity
Farm	The highest object within the SharePoint object model hierarchy A collection of one or more SharePoint servers and one or more SQL servers that come together to provide a set of basic SharePoint services bound together by a single configuration database in SQL ^[8]
Information Management Policy	Functionality that enables Site Collection Administrators to specify a collection of rules that dictate how documents should be treated within a SharePoint implementation. Policies can be created to specify how long documents should be retained by SharePoint and what auditing information should be captured regarding document usage. Policies can also be used to dictate that barcodes be added to documents or that labels be automatically injected into documents prior to being printed. ^[9]
List	A container within a Site that stores List Items
Managed Keyword	A word or phrase that is added to an Item, either as a value in the Managed Keyword column or as a social tag
Managed Metadata	A hierarchical collection of centrally managed terms that can be defined and then used as attributes for Items
Managed Metadata Service	A shared service that publishes a Term Store and, optionally, a set of Content Types
Managed Term	A word or phrase that can be associated with an Item. Usually predefined, can only be created by users with the appropriate permissions, and often organised into a hierarchy.
My Site	A Site that is personalised for an individual user
Permission	A rule that is associated with an object to regulate which users can gain access to the object and in what manner
Permission Level	A set of Permissions that can be granted to principals or SharePoint groups on an entity such as a Site, List, Folder, Item or Document
Records Centre	A Site that is designed for records management. Records management staff can configure the routing table to direct incoming files to specific locations. Contains specialised records management features.
Site	One or more related web pages and other items (such as Lists, Libraries and Documents) that are hosted inside a Site Collection
Site Collection	A set of Sites that are in the same content database, have the same owner, and share administration settings Each Site Collection contains a top-level Site, can contain one or more sub-Sites, and can have a shared navigation structure
Site Collection Administrator	A user who has administrative permissions for a Site Collection
Team Site	A Site on which a team can organise, author, and share information. It provides a document library, and lists for managing announcements, calendar items, tasks and discussions.
Term Set	A collection of related Managed Terms
Term Store	A database that stores Managed Metadata, including Term Sets, Managed Terms and Managed Keywords
Timer Job	A built-in object that can perform various tasks within the environment on a scheduled or one-time event basis.

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.

Compliance requirement	SharePoint functionality
3.1 Records and information are routinely created and managed as part of normal business practice	SharePoint can be configured to automate the capture of records (to be managed in place or in a separate Records Centre). See Managing records in place and Managing records in a Records Centre for more information.
3.2 Records and information are reliable and trustworthy	SharePoint captures a range of point of capture and recordkeeping process metadata by default, but must be configured to capture certain metadata. See Point of capture metadata, Records management process metadata and Classification for more information. SharePoint can be configured to persistently link metadata with digital records and aggregations of digital records maintained within a SharePoint implementation. See Point of capture metadata and Records management process metadata for more information. 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 reporting functionality provided in SharePoint allows selected users 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. See Records management administration for more information.
3.3 Records and information are identifiable, retrievable and accessible for as long as they are required	SharePoint captures a range of point of capture and recordkeeping process metadata by default, but must be configured to capture certain metadata. See Point of capture metadata, Records management process metadata and Classification for more information. SharePoint can be configured to persistently link metadata with digital records and aggregations of digital records maintained within a SharePoint implementation. See Point of capture metadata and Records management process metadata for more information. Records exported from SharePoint lose certain contextual metadata, only retaining any metadata embedded in each record. Add-on software can be implemented to enable the export of contextual metadata. See Exporting records for more information. The Document ID feature in SharePoint can be activated so that identifiers are assigned to documents when they are created. However, Document IDs can only be generated for documents and Document Sets (not records in other formats, e.g. list items, wiki pages and blog posts). Additional configuration is required to generate identifiers that are unique across a SharePoint Farm. See Unique identifiers for more information. SharePoint must be configured to prevent the premature deletion of records. See Retaining records for more information. 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). See Exporting records for more information.
3.4 Records and information are protected from unauthorised or unlawful access, destruction, loss, deletion or alteration	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. See Access and security for more information. SharePoint can be configured to make records read only. See Records management in SharePoint 2010 for more information. SharePoint must be configured to prevent the premature deletion of records. See Retaining records for more information.
3.5 Access to records and information is managed appropriately in accordance with legal and business requirements	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. See Access and security for more information.
3.6 Records and information are kept for as long as they are needed for business, legal and accountability requirements	Information Management (IM) Policies can be configured to facilitate the routine and regular disposal of records in SharePoint. See Disposing of records for more information. Records identified as State archives can be exported from SharePoint as a digital transfer. However: records exported from SharePoint lose certain contextual metadata; add-on software can be implemented to enable the export of contextual metadata with records SharePoint must be configured to easily transfer aggregations of records SharePoint must be configured to report on any failure during an export SharePoint must be configured to retain copies of all exported aggregations and records until the export has been confirmed as successful SharePoint must 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). See Exporting records for more information.
3.7 Records and information are systematically and accountably destroyed when legally appropriate to do so	Information Management (IM) Policies can be configured to facilitate the routine and regular disposal of records in SharePoint. See Disposing of records for more information. SharePoint must be configured to automatically record and report on all disposal actions. See Documenting disposal for more information.

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

Automated Intelligence, Automated Intelligence presents a response to The National Archives review of SharePoint 2010, September 2011, <http://www.automated-intelligence.com/wp-content/uploads/2012/06/Automated-Intelligence-TNA-Response-White-Paper-Screen-Optimised.pdf> (viewed 23 April 2012)

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

Kitta, T, B Grego, C Caplinger and R Houberg, SharePoint Server 2010: enterprise content management, Wrox, 2011
Note: ‘Chapter 8: Records management’ is available via <http://www.knowledgelake.com/resources/Pages/whitepapers-microsoft-sharepoint-ecm.aspx> (viewed 21 June 2012)

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)

Microsoft TechNet Library: SharePoint 2010 products, <http://technet.microsoft.com/en-us/library/ee428287.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/review-of-records-management-in-sharepoint-2010.pdf>, 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-content-organizer-part-1-a-cool-new-feature-for-managing-your-content.aspx> (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)

[9] T Kitta, B Grego, C Caplinger and R Houberg, SharePoint Server 2010: enterprise content management, Wrox, 2011, p. 263

Published 2012 / Revised February 2015

Shopping cart

Purpose

Scope

Records management in SharePoint 2010

Managing records in place

Managing records in a Records Centre

Choosing an approach

Records management administration

Designing a SharePoint implementation

Configuration versus customisation

Add-on software

Integration with a separate EDRMS

Documenting design and configuration decisions

Creating and capturing records in SharePoint 2010

Email

Aggregations

Point of capture metadata

Unique identifiers

Classification

Using managed terms to represent a classification scheme

Structuring a Records Centre according to a classification scheme

Structuring Site Collections according to a classification scheme

Folksonomies

Managing authentic and reliable records in SharePoint 2010

Access and security

Security categories

Records management process metadata

Retention and disposal

Retaining records

Disposing of records

Defining IM Policies for Content Types

Defining IM Policies for locations

Triggers for disposal

Reviewing disposal

Deleting records

Documenting disposal

Exporting records

Managing physical records in SharePoint 2010

Disseminating records in SharePoint 2010

Searching for and retrieving records

Printing records

Redacting records

SharePoint 2010 implementation case studies

SharePoint 2010 glossary

Assessment of SharePoint 2010 against the Standard on Records Management

References and further reading

Acknowledgments

Footnotes

GRK footer