Audit trail integrity
By auditing the actions that users perform on a record and the changes that users make to its data, it is possible to have a detailed and accurate audit trail with which you can determine exactly how the record came to have its current data and state.
- Make changes to an application only when users are not using it.
-
It is a good idea to keep users from using an application while it is being changed, just to be sure of getting consistent results. Another reason to keep users from using an application while it is being changed has to do with accurately interpreting audit trails.
It is important to know whether the consequences of clicking a sub action happened before or after a change to the way an application works. If users are using an application at the same time it is being changed, it may become difficult to know if an action and its consequences happened before or after a change. If the change affected which workflows are started by the action, it may not be possible to know which workflows were started by an action.
- Restrict access to the Data Modeler.
-
Even if you are only auditing data changes, it is still important to restrict access to the Data Modeler.
Through the Data Modeler, it is possible to turn off generation of audit records for all records that are created from a business object and then later turn the generation of audit records back on. While the generation of audit records is turned off, a user can change data in records without the change being recorded in an audit trail. Also, there is no record in the audit trail that generation of audit records was turned off or on.
- Security settings should prevent users from deleting records for which you are keeping an audit trail.
-
When a record is deleted, the audit records associated with the record are also deleted.
Instead of designing audited records to be deleted, design them to have a retired state that keeps them from being seen or used in most contexts.
- Avoid designing records that are likely to accumulate many audit records.
-
There is no way for workflows to access audit records. They must be interpreted manually. If a record accumulates a large number of audit records, it may not be practical to interpret the audit trail.
To avoid this problem, try to design records so that they do not accumulate a large number of audit records.
- Changes to records that have an audit trail should only be initiated from a form.
-
Data audit records are only created by changes that are made to a record through a form.
Audit records are not created when records are created or modified by the Data Integrator or by other means.
If you cannot follow these rules, and you must have a secure audit trail, you can use your database manager to keep an audit trail. The platform creates a database table for each business object. Records that are created from a business object are stored in the database table that corresponds to the business object used to create the record. The details of auditing database tables vary with the database software used. Consult your database administrator or database documentation for the specifics.