Why auditing?

- auditing registers access to confidential or vital enterprise data
- in some countries there is a legal obligation to "log" all access to data of a personal nature (e.g. medical data)
- auditing allows administrative follow-up (e.g. all actions taken for a given customer number)
- auditing may be useful for database administration to find out how tables are accessed

Scope of auditing

- SQL/AF audits all accesses to designated DB2/VM tables that contain sensitive or confidential data.
- SQL/AF audits all DB2/VM clients, that is, all VM/ESA, VSE/ESA and CICS users, as well as users accessing the DB2/VM database via IBM's DRDA protocol.
- SQL/AF monitors all table access, both dynamic (QMF, ISQL etc.) and static (compiled).
- Depending on the audit rules defined for the table, both read (SQL SELECT) and write ( SQL DELETE, INSERT, UPDATE) access is audited.
- By default, auditing is performed at the table level and audit logging occurs whenever an SQL statement refers to the table.
- Alternatively, named table-columns can be defined as audit triggers. Audit logging then occurs whenever an SQL statement refers to these table-columns.