You are viewing limited content. For full access, please sign in.



Audit Trail, recommended procedures?

asked on April 9, 2015

I have questions regarding what I should be doing in the Audit Trail component, any pro-active type procedures so the information will be there if we come across an unexpected problem.  Questions I can't find answers to after looking at the usual LF training resources:

  • Should I be setting up any additional audit reporting procedures besides what Audit Trail is already defaulted for?  Or does it track everything, and all I have to do is create a report to obtain the data when I want it (I have done some exploration and practicing with audit reports).
  • Should I be saving audit reports to another location every so often?  (I've seen some posts that some people are doing this.  Is this something every office should be doing?  Is there a particular type of data people feel they need to save elsewhere?)
  • How long does the Audit Trail component keep the data for?
  • If a doc is to be presented in court and we need to prove it wasn't altered during a period of time, how would I go about proving it using Audit Trail?


These are the settings for our repository.

Any tips on policy or procedure for pro-active auditing would be appreciated.

Connie P.,

0 0


replied on April 15, 2015

Hi Connie,


I followed up with our engineers and received some great responses to your questions, listed below in order of your bullet points:


  • A repository created with recent versions of Laserfiche will default to auditing a moderate selection of events. Use the Administration Console to check the settings for your repository and make sure they are covering everything you want. The events that you are going to choose to audit are up to you and your organization! You can refer to the administration guide event descriptions to figure out which events you will want to audit. If in doubt, auditing everything except for the Entry Listing category is a reasonable start. Entry Listing records an event every time an entry shows up in an entry listing, so this may add a lot of extra information into the audit log with marginal value. Though, please note that regardless of what you audit, you can filter any reports that you run to focus on specific sets of events.
  • Saving audit reports to another location depends on your particular needs and practices. In principle, any audit report can be re-run at a later date and retrieve the same information from the database. Printing or exporting a report is going to be useful in giving a particular set of information to a user who should not have access to the complete set of audit data. If you have built custom report definitions, you may consider backing those up somewhere.
  •  The audit log files that the server generates stay around forever, unless they are manually deleted. Typically, only a subset of the audit log is loaded into the audit database at one time, which can be configured on the Audit Trail configuration page. Note that the more data you have in the database, the longer it will take to run a report. If data gets unloaded from the database, it can be loaded again later if you need to report on it.
  • While I am not a lawyer, I have a few suggestions for how you could present this information in court. First, the Change Audit Configuration event is important, both to establish what audit settings were in place at the start of the time period in question and to ensure that the audit settings were not changed during the time period in question. You will want to ensure that ‘Entry’ events were audited for any user that could have logged in during this time period. Note if they were not, a user for whom the events were not audited could have made modifications to the document without being audited. Second, all of the audit data for the time period in question should be loaded into the database (confirm that there are no gaps in the log files’ coverage for that time period) and then you can run a report on the document in question by looking at all events related to that document’s Entry ID. With this, you can look to see whether pages were moved or copied into the document. Assuming that there is nothing in the audit log that suggests the document was modified, this is a great start. Note, Laserfiche is tracking changes to the document that are made within the Laserfiche system, you may also want to check for Import and Export events and you may consider taking additional precautions for events outside of Laserfiche. Again, this is probably something you will want to consult with your lawyer smiley


Here are a  few additional considerations and notes that you may find helpful:

  • Another way to demonstrate document integrity - you could consider using digital signatures as these provide a validated timestamp and allow for verification that some parts of the document are unchanged since the signature was applied.
  • In the screenshot you posted, you have “Compress rollover files” set to false. You should consider enabling this, the files compress very well and will take up less storage space.
  • Resources that you may also find helpful: help files and recent Empower Conference PowerPoint slides, including a course titled “Auditing Your Repository” (you can find these in the Education Resources from the Support Site)   




2 0


You are not allowed to reply in this post.
You are not allowed to follow up in this post.

Sign in to reply to this post.