1. Non mi farei troppi problemi. A meno che tu non voglia utilizzare quel log per ripristinare la situazione puntuale di un entità in maniera automatica, un log è un dato in read-only.
Anzi, prevedere un tool/mappe per leggere quella tabella è già un iniziativa "lussuosa". In genere un HelpDesk di secondo o terzo livello accede direttamente al DB.

2. Questo tipo di Audit Control secondo me dovrebbe avere le seguenti caratteristiche:
a) essere attivabile/disattivabile per entità
b) essere attivabile/disattivabile in maniera applicativa
c) eventuali errori non dovrebbero compromettere il normale utilizzo dell'applicazione

In progetti medio-ampi l'amministrazione del DB è gestita da un team (DBA administrators) differente da chi sviluppa e gestisce il business (e/o da chi ne fa manutenzione).
Associare questo tipo di funzionalità (del tutto applicativa e non di gestione del DB) all'uso di trigger potrebbe renderti la vita non semplice per le caratteristiche a) e b).
Inoltre, nella mia esperienza, spesso DBA sconsigliano l'uso di trigger (che potrebbero creare lock o sospensione del servizio DB in caso di anomalie) per gestire funzionalità applicative. Quindi anche per la caratteristica c) potrebbe non essere buona idea passare per i trigger