WikiArtifactsDatabase Audit Logs

Database Audit Logs

Log
Updated: 2026-02-13

Database Audit Logs record security-relevant activity within critical data repositories. They help organizations understand who accessed a database, when access occurred, and what actions were performed (e.g., authentication events, privilege changes, schema changes, and access to sensitive tables). Audit logs are commonly used to support security monitoring, investigations, and audit readiness by providing an evidence trail of administrative and data access activity. Effective database log management includes enabling appropriate audit events, securely centralizing and protecting logs, defining retention aligned to policy and regulatory needs, and routinely reviewing or analyzing logs to detect unusual behavior.

Standardized Database Audit Log Schema

A JSON structure for a database audit event, ensuring consistency across different database engines.

{
  "event_id": "evt-db-99283",
  "timestamp": "2026-02-13T15:45:00Z",
  "db_instance": "prod-finance-db-01",
  "db_user": "app_service_acct",
  "os_user": "system",
  "source_ip": "10.0.5.23",
  "event_type": "DML_SELECT",
  "object_accessed": "public.payment_cards",
  "query_text": "SELECT customer_id, card_brand, last4, token_id FROM payment_cards WHERE customer_id = ?",
  "status": "SUCCESS",
  "sensitivity_level": "HIGH",
  "session_id": "sess_8821_xp"
}

Database Audit Logging Pipeline

Workflow showing the flow of audit data from the database engine to long-term retention and analysis.

Rendering diagram...

Command Line Examples

logging_collector = on
log_statement = 'ddl, mod'
pgaudit.log = 'write, ddl'
pgaudit.log_catalog = 'on'

Organizations commonly audit: privileged user activity, authentication events (success/failure), changes to roles/permissions, schema changes (DDL), changes to audit configuration, and access to high-sensitivity tables. The exact scope should balance risk, performance, and data minimization.

Configuration involves enabling native audit features (like pgAudit or SQL Server Audit), defining granular policies to capture specific events without overwhelming system performance, and ensuring that database logging captures the user identity, timestamp, source IP, and the exact SQL query executed.

Retention depends on regulatory expectations, business needs, and investigation requirements. Many organizations align retention to their log retention policy and risk profile, keeping security-relevant audit logs long enough to support audits and forensic investigations.

Analysis involves ingesting logs into a SIEM (Security Information and Event Management) system to correlate database activity monitoring data with other security events, establishing baselines for normal behavior, and setting up alerts for anomalies like mass deletions or access during unusual hours.

Compliance requirements typically mandate that organizations implement database security audit controls to track access to personal or sensitive data, protect the integrity of the logs themselves, and demonstrate accountability for all data processing activities.

To support integrity, logs are typically centralized to a secure location with restricted access, strong access controls, and tamper-evident protections (e.g., append-only controls, immutability options, or integrity checks). Separation of duties helps reduce the risk of administrators altering audit records.

Automated monitoring should include real-time alerts for critical security events such as multiple failed authentication attempts, changes to database audit procedures, creation of new superuser accounts, and unauthorized exports of large datasets.

In an investigation, database audit logs allow forensic teams to reconstruct the timeline of an attack, identify the specific records compromised or exfiltrated, determine the method of intrusion (e.g., SQL injection), and attribute actions to specific user accounts or IP addresses.

VersionDateAuthorDescription
1.0.02026-02-13WatchDog Security GRC Wiki TeamInitial publication