Edit #2: Laserfiche Cloud retains Audit Trail logs indefinitely at this time, though only the last 18 months are immediately available for reporting. On the backend, similar to self-hosted, there are both the raw audit logs and an audit reporting index. I believe you can open a support request to load older audit data for reporting. We're having internal discussions on how to make this process something you can do yourself.

You can assure your customers that the audit logs are retained and accessible for reporting if necessary. While I can't personally provide a binding guarantee that Laserfiche Cloud will always have indefinite Audit Trail log retention, we know that many of our customers have legally binding log retention requirements of significant length (e.g., HIPAA requires a minimum of six years). I don't foresee us making changes that would compromise the compliance positions of sizable portions of our customer base.

----------------------------------------------------------------------------------------------------------------------

Important Edit: The response below is accurate for self-hosted Laserfiche systems, not Laserfiche Cloud, which works a bit differently. I somehow missed the "Cloud" part of the question. We'll work on getting you a Cloud-specific answer since I don't know that offhand. 

----------------------------------------------------------------------------------------------------------------------

Hi Dylan,

There are two separate components to Laserfiche Audit Trail. Understanding their roles is critical to understanding audit retention in Laserfiche. The components are:

1. Laserfiche Server's auditing functionality, which captures events in-scope for auditing and writes them to binary audit log files that are stored on disk in each repository's /AUDIT directory. These audit logs are the Source of Truth. They are not in a human readable format. 
2. Audit Trail Reporting, which ingests a subset of audit data and writes it to a reporting database (LF10)/catalog (LF11) in an easily searchable format. Audit Trail Reports run against the events in this reporting database/catalog.

The audit log files that Laserfiche Server writes to disk are retained indefinitely. Laserfiche does not even have a configuration option to set any kind of retention rule on the audit log files. If you want to delete older audit logs, you have to do it yourself. Some of our customers configure time-based audit log rollover and then write PowerShell scripts to run as scheduled tasks that copy audit log files older than X years to long-term archival storage and then delete the originals to save disk space.

In Audit Trail Reporting, in order to generally keep the reporting databases a more manageable size, you configure what subset of events are kept loaded. I recall there are three options:

1. A rolling time range (e.g., last 180 days) where Audit Trail Reporting will constantly be ingesting new events and dropping the oldest ones. Expanding the time range will cause Audit Trail Reporting to request the older events now in-scope from Laserfiche Server to load them into the reporting database.
2. A specific date range (e.g., 2020-01-01 to 2021-06-30) where Audit Trail Reporting will keep audit events from that date range in the reporting database. Expanding the date range will cause Audit Trail Reporting to fetch any audit events from the newly added dates from Laserfiche Server.
3. The audit events in the specified audit log files. You can upload one or more of the binary audit log files directly to Audit Trail Reporting to run audit reports on their contents.

Audit Trail Reporting cannot modify the source-of-truth audit log files that Laserfiche Server produces, only read them. People often mistake option #1 above, the Audit Trail rolling reporting time range, as how long the actual audit logs are retained. This is a difference that matters for compliance purposes.

The extreme case illustrates this: uninstalling Audit Trail Reporting and deleting its audit reporting database does not affect the audit log files. As long as the audit log files exist, you can reinstall Audit Trail Reporting, create a new, empty audit reporting database, populate it with any desired time/date range/set of audit files, and then run reports against the audit events in that data set.

I hope that helps add clarity. If this response answered your question, please select the "Mark as Answer" button. If it didn't, let us know what else you'd like to know.

Cheers,
Sam