In our small shop, I function in multiple roles, including database administrator. Occasionally, we have to make changes to production data due to problems that slipped by us in testing or scenarios that were never imagined. My favorite example is when Lotus Notes calculated a result of -0 (negative zero) but then was not able to store that result. These database changes are requested in writing, fully documented, and we review this documentation with our auditors. We need to take the same approach to SharePoint.
SharePoint includes a robust auditing capability, but audit trails only show that items are accessed or edited, when that occurred and by whom. Audit trails do not show why items were edited, and that might become important. We use a custom list in SharePoint to track our database changes. The list includes columns for the systems involved, the date and time of the change, etc. We also attach the written request, and before and after screen-shots, SQL queries or report pages to illustrate the changes required and the changes made. My database changes occur in DB2 or SQL Server, so I have to remember to update the documentation. It would be a simple thing to have a workflow create a documentation task when something changes in SharePoint.
On the other hand, we might be able to avoid creating and maintaining a separate list by using the features available in SharePoint. The first feature to consider is Versioning; if you want to document the changes made to document, version comments might be the way to go. In theory, each time the document is changed, the new author will be required to complete the version comments. The potential problem with this approach is the prior versions can be deleted, and the comments are going to go with them. This might not be a problem, but if you are trying to document and preserve a true audit trail, version comments will not work. You could end up with an audit trail that says there were five changes, but only have an explanation for the final edit.
The second way you can provide for documenting changes is by adding a column specifically for that purpose. We have a small group at work that use and maintain a set of documents. They are motivated to track the changes because the changes are important to their work. They track their changes in a custom column and updating that column is a business requirement. This approach works in this case, but I think it is due to the motivation of the people involved. In general, this seems like a much less reliable mechanism. If I wanted to track changes to information subject to an audit, I would do it like we do our database changes, by creating a task in a separate list. I also like the fact that someone without access to the library itself, could be granted access to the audit trail for review.
#SharePoint #sharepoint
#audit