I love this question! Almost everybody accepts it must be done, but almost no-one asks how to actually do it. The answer to this question is largely dependent on what the system is used for, how it stores data, and how detailed the audit trail is.
In our viewLinc system, no user can actually make a record involving raw data or even change it. So in some sense, we don't even need an audit trail… But, since it is a hard argument to have, we put an audit trail in anyway. The viewLinc audit trail tracks events and configuration changes.
Since a monitoring system's secondary function, after collecting raw data, is sending alarms for any out-of-spec conditions or data, the configuration of the alarms is probably the most sensitive data that can be changed by a user. Therefore, in a review of a monitoring system audit trail, I would be looking for administrative events that involved configuration changes. I would be looking at the comments tied to the events to see that the changes were part of legitimate change controls. Here's what the "Events" view panel looks like in viewLinc... However, if I was dealing with a more complex system, such as a HPLC tied to a LIMS system I would see it differently. In this type of setup, the raw data files are often created by users and often need analysis and adjustment to make the data into actual and meaningful test results. Such as system would likely be equipped with security roles to prevent people with review responsibilities from being able to change data, but if it wasn't (which would be a Part 11 compliance violation) I would look for change events by users known to have review roles.
Otherwise, I would check the dates associated with the given projects and files. If a HPLC analysis and review of the file is typically completed and reviewed within 3 working days, I would look for instances where the changes to the data were made outside that 3-day window. This might be indicative of people making changes after the fact. So we see that our audit trail review strategy is tied very much to the type of system we are using. We consider the system's existing data protections, and the way the it is used to process and store data. To really understand how to review the audit trail, you must imagine the ways a person could "cheat" the data, and then design your review strategies to detect these activities.