Skip to content
  • About Andrew Warland

Records about the world

All about managing records and information and some of my photos

Month: February 2013

Posted in Compliance, Electronic records, Products and applications, Records management, Retention and disposal, Sharepoint 2010

Document Audit Trails in SharePoint 2010

Posted on February 14, 2013 by Andrew Warland

Part 2 of ISO 16175 (‘Principles and functional requirements for records in electronic office environments’) includes a section (5.4.7) on records management process metadata. This section contains 13 mandatory requirements including:

  • To create unalterable metadata of records management actions on records, aggregations of records, or the classification scheme.
  • To track events without manual intervention.
  • To maintain that metadata ‘for as long as required’.
  • Provide metadata of all changes.
  • Document all changes made to administrative parameters.
  • Ensure that the metadata is available for inspection on request.
  • Allow the metadata to be exported.
  • Record any violations, or attempted violations (e.g., access attempts).
  • Provide reporting.
  • Allow configuration.
  • Allow an administrator to make authorised changes, which are also recorded.

SharePoint 2010 provides audit trails on all sites but, unlike some other systems, audit trail information is not included in the metadata about the document itself. That is, records management process metadata is not included with other metadata about the record, but must be accessed separately, and only by a Site Owner or someone with higher privileges.

Records management process metadata is captured in two ways in SharePoint:

  • By enabling it in a Content Type that is enabled in a Site Library.
  • By enabling it in the Site Collection settings.

Audit trails may be deleted regularly as a default setting

Process metadata (‘audit trails’, or ‘audit logs’) are not kept permanently by default but are ‘trimmed’ according to a schedule for audit logs that is configured by the SharePoint (or server) Administrator in Central Administration.

The reason for not keeping the logs is to do with performance. According to Microsoft’s online help ‘… auditing can potentially generate a large number of audit events, creating a large audit logs. This could fill the hard drive, affecting performance and other aspects of a site collection’.

The default trim schedule is ‘end of the month’, which means that all previous metadata is deleted and a new log is started. Alternative options include a given period, for example 30 days or 7 days.

This means that audit trails for documents will not exist beyond the configured time period.

Turning off the default schedule

To disable the default schedule, the Site Collection Administrator must change the configuration settings of the ‘Audit Log Trimming’ section of the ‘Configure Audit Settings’ option under ‘Site Collection Administration’.

The Site Administrator may also opt to store the audit reports in a site collection library before they are trimmed. The three options are:

  • Automatically trim the audit log for this site? This is set to ‘Yes’ by default, which means it will trim the logs in accordance with the Farm default setting.
  • Specify the number of days of audit log data to retain. The Site Administrator may set the days when the audit log will be trimmed, regardless of the Farm default setting.
  • Specify a location to store audit reports before trimming the audit log. This option allows the Site Administrator to automatically save audit logs to the location identified so the logs are not lost.

Other configuration options in the ‘Configure Audit Settings’ section are:

  • Documents and Items. There are five events that can be audited: (a) opening or downloading documents, viewing items in lists, or viewing item properties; (b) editing items; (c) checking out or checking in items; (d) moving or copying items to another location in the site; and (e) deleting or restoring items.
  • Lists, Libraries, and Sites. There are three events that can be audited: (a) editing content types and columns; (b) searching site content; and (c) editing users and permissions.

Audit Log Reports

Once auditing is enabled, the audit logs are available via Site Settings – Site Collection Administration – Audit Log Reports.

There are usually four options available:

  • Content Activity Reports. This includes: (a) content modifications (‘all events that modified content’ – this includes editing, checking out/in, moving/copying); (b) content type and list modifications; (c) content viewing (‘all events where a user viewed content in this site’); and (d) deletion (‘all events that caused content in this site to be deleted or restored’).
  • Custom Reports. This allows the Administrator to manually specify filters for a report.

  • Information Management Policy Reports. This includes reports on: (a) expiration and disposition and (b) policy modifications.

  • S

    ecurity and Site Settings Reports

    .

    This includes: (a) auditing settings (‘all events that change the auditing settings’) and (b) security settings (‘all events that change the security configuration of SharePoint’).

Audit trail report content

Audit trails in SharePoint are exported to Excel and include two worksheets, a summary and the detail.

The summary worksheet shows the number of actions (e.g., view, edit) on a document. The detailed worksheet includes a row of information similar to the following:

Site Id: {fffaf4fd-b5d0-4940-a615-06e0026a855d}
Item Id: {373b3b5e-43a7-46d8-8d44-9a36fad6a4da}
Item Type: Document
User Id: John Smith <DOMAIN\jsmith>
Document Location: _catalogs/masterpage/v4.master
Occurred (GMT): 2013-02-13T04:02:45
Event: View
Custom Event Name: (may be blank)
Event Source: SharePoint
Source Name: (may be blank)
Event Data: <Version><Major>1</Major><Minor>0</Minor></Version>

Compliance with ISO 16175

While SharePoint 2010 does create audit trails for records management actions, it does not store these audit trails in an end-user visible form with the record itself; that is, when an end user views the metadata describing the record, he/she cannot view the audit trail history of the record. Only a Site Administrator can access and/or view the audit trails.

The other main weakness, in terms of compliance with ISO 16175, is that the audit trails could be deleted according to the default schedule set by the farm administrator. To get around this, a choice needs to be made whether to override the default trimming, or (to reduce storage requirements) to export the audit logs regularly and store them on the same site.

Andrew Warland

Recent Posts

  • Classifying records in Microsoft 365
  • The complicated world of Tasks and To Do
  • SharePoint is not an EDRMS
  • The challenge of identifying born-digital records
  • Can Microsoft technology classify records better than a human?
  • Understanding permission groups in Teams and SharePoint
  • Different ways to access content stored in SharePoint
  • A brief history of electronic document and records management systems and related standards
  • Classifying records in Microsoft 365
  • Managing the retention of records in Microsoft 365 with an E3 licence

Follow me on Twitter

My Tweets

Categories

Site tag cloud

admissibility Audit audit events audit logs audit trails authenticity Content Types Digital Disposal evidence Exchange folders google HTML inferences information integrity language Legal linguistics Logs metadata Microsoft Outlook Preservation probabilities records records management reliability Retention Semantic Office semantics Semantic Web SharePoint Sharepoint 2010 SharePoint 2013 SharePoint SharePoin software technology Trails wave XML

Enter your email address to follow this blog and receive notifications of new posts by email.

Archives

  • April 2021 (3)
  • March 2021 (3)
  • February 2021 (2)
  • January 2021 (2)
  • December 2020 (2)
  • November 2020 (2)
  • October 2020 (2)
  • September 2020 (3)
  • August 2020 (1)
  • July 2020 (3)
  • June 2020 (2)
  • May 2020 (5)
  • April 2020 (5)
  • March 2020 (3)
  • February 2020 (7)
  • January 2020 (4)
  • December 2019 (1)
  • November 2019 (2)
  • October 2019 (5)
  • September 2019 (3)
  • August 2019 (7)
  • July 2019 (2)
  • May 2019 (2)
  • March 2019 (2)
  • February 2019 (1)
  • December 2018 (1)
  • August 2018 (1)
  • May 2018 (1)
  • March 2018 (2)
  • October 2017 (2)
  • September 2017 (1)
  • August 2017 (1)
  • July 2017 (3)
  • April 2017 (1)
  • March 2017 (2)
  • December 2016 (1)
  • September 2016 (1)
  • May 2016 (1)
  • December 2015 (1)
  • November 2015 (1)
  • September 2015 (1)
  • May 2015 (1)
  • August 2014 (1)
  • June 2014 (3)
  • October 2013 (1)
  • September 2013 (1)
  • May 2013 (3)
  • March 2013 (2)
  • February 2013 (1)
  • November 2012 (1)
  • October 2012 (1)
  • September 2012 (1)
  • July 2012 (1)
  • June 2012 (3)
  • May 2012 (2)
  • April 2012 (1)
  • March 2012 (1)
  • February 2012 (1)
  • September 2011 (2)
  • November 2010 (1)
  • June 2010 (1)
  • May 2010 (1)
  • January 2010 (2)
  • November 2009 (12)
Create a free website or blog at WordPress.com.
Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here: Cookie Policy