The "proper" way to make triggers really depends on your database schema, your application, your need to audit etc etc .... for example *we* currently audit approximately 150 "sensitive" items across 20 tables ... we don't "care" about the rest.
This link has discussions about several potential solutions http://stackoverflow.com/questions/1962398/creating-audit-triggers-in-sql-server
When you say you need to track "everything" do you mean update, deletions, insertions ... (answer should probably be yes to the last two)... when you "audit" an update ... do you actually need to know what
was updated or just the fact that the record was updated.
When you have defined clearly what your requirements are only then can you really determine the "proper" way.
An alternative that has been used by certain solution providers is to have columns on each table that show when they were created (and who by) and when they were last updated (and who by) ... this is very simply implemented using table triggers without having to purchase 3rd party tools ... and also simplifies the subsequent detailed audit requirements