What it means
Database audit logging records security-relevant access, administrative changes, authentication events, and sensitive data operations with enough context for investigation and assurance.
Why it matters
Application logs alone may not show direct database access, privileged changes, or destructive queries, leaving a critical evidence gap.
Practical focus
- Define the scope, owners, acceptable risk, and required outcome for database audit logging before choosing a tool or platform feature
- Implement event selection, protected destinations, synchronized time, privileged-user visibility, and retention controls through documented, reviewable configuration and change control
- Collect successful and failed authentication, role changes, schema changes, sensitive-query events, and log-integrity checks and compare the results with approved baselines, service objectives, and policy requirements
- Exercise audit collection stopping, being bypassed by a privileged user, or producing too much noise to investigate as a planned test case, including detection, containment, rollback, escalation, and evidence retention
Common mistakes
- Treating database audit logging as a one-time technical setting instead of an operating control with owners and review cycles
- Using default thresholds or broad exceptions without connecting them to business, privacy, security, and availability requirements
- Keeping evidence in disconnected tools so reviewers cannot reconstruct who changed what, why it changed, or whether it worked
- Testing only the normal path and discovering during an incident that audit collection stopping, being bypassed by a privileged user, or producing too much noise to investigate was never rehearsed
Certification relevance
This subject appears in or supports the following certification bodies of knowledge: