The ability to verify and follow through a series of events to prove compliance (or not!) is essential. Historical records detailing who, what and how an event occurred are required by most regulatory bodies. Although the word ‘Audit’ sometimes sends a shiver down many a hardened business professionals’ back, immense comfort can be gained when processes and systems are developed to be watertight. You can’t permanently escape from fraud, but if you have sufficient records to prove when, how, who and why something happened, you will have enough evidence to prove intent on behalf of the fraudster and also to prove that as a corporate entity you had enough controls in place to ensure the fraudster had to transact illegally to commit the fraud in the first place.

SharePoint enables auditing through the provision of administrator audit permissions. Administrators can interrogate site events through audit log databases and can view user or content changes. The audit log object model can be used by other applications to provide custom analysis and reporting.

SharePoint must be enabled at the site collection by a Site Collection Administrator. It is possible to audit events such as opening or downloading a document, deleting, editing, moving or copying documents. It is also possible to specify whether to trim the log after x days.

If you are wondering why auditing shouldn’t just be turned on, then the answer is capacity and performance. If you have a high volume collaboration site then this may impact performance and will also take up much needed disk space, so beware before turning all the switches on.