There are several more things you might want to audit, such as table/column names, computer/application from which an update was made, and more.
Now, this depends on how detailed auditing you really need and at what level.
We started building our own trigger-based auditing solution, and we wanted to audit everything and also have a recovery option at hand. This turned out to be too complex, so we ended up reverse engineering the trigger-based, third-party tool ApexSQL Audit to create our own custom solution.
Tips:
Include before/after values
Include 3-4 columns for storing the primary key (in case it’s a composite key)
Store data outside the main database as already suggested by Robert
Spend a decent amount of time on preparing reports – especially those you might need for recovery
Plan for storing host/application name – this might come very useful for tracking suspicious activities
