Many compliance frameworks require the ability to answer "who did what, and when" — audit logging provides this accountability trail. This guide covers implementing comprehensive audit logging on a VPS.
What Audit Logging Captures (Distinct from General Application Logs)
Audit logs specifically focus on security-relevant and accountability events — authentication attempts, data access, permission changes, configuration changes — as opposed to general operational/debugging logs, though there's some overlap.
What to Audit Log
- Authentication events (successful and failed login attempts)
- Authorization changes (permission/role grants and revocations)
- Access to sensitive data (especially for regulated data types)
- Administrative/configuration changes
- Data modification or deletion of sensitive records
Essential Fields for Each Audit Log Entry
{
"timestamp": "2026-08-26T14:30:00Z",
"actor": "user_id_12345",
"action": "data_access",
"resource": "patient_record_789",
"result": "success",
"source_ip": "203.0.113.10"
}See Structured Logging Best Practices for Easier Debugging for the general structured logging approach, applied specifically to audit-relevant events here.
Implementing Application-Level Audit Logging
function auditLog(actor, action, resource, result) {
logger.info({
audit: true,
timestamp: new Date().toISOString(),
actor,
action,
resource,
result,
source_ip: req.ip,
});
}
auditLog(user.id, 'record_viewed', `patient/${patientId}`, 'success');Database-Level Audit Logging
Most major databases support native audit logging plugins/features, capturing queries and access at the database layer independent of application code — a valuable additional layer, since it captures direct database access too, not just access mediated through your application.
Ensuring Audit Logs Are Tamper-Evident
Audit logs need protection from modification, including by administrators — consider writing audit logs to a separate, restricted-access system or centralized logging platform (see How to Set Up Centralized Logging with the ELK Stack) rather than only local files an administrator could edit.
Restricting Access to Audit Logs Themselves
Audit logs often contain sensitive information about who accessed what — restrict access to the logs themselves to only those with a genuine need (typically security/compliance personnel), following the same access control principles applied elsewhere.
Setting an Appropriate Retention Period
Compliance frameworks often specify minimum retention periods for audit logs (commonly measured in years, not months) — verify your specific framework's requirement rather than assuming a generic retention period is sufficient.
Making Audit Logs Genuinely Reviewable
Logs that are collected but never reviewed provide limited practical value — establish a periodic review process (even a lightweight one) for audit logs, particularly around sensitive data access and administrative changes.
Common Gaps
- Audit logging covers the application but misses direct database access
- Logs are collected but stored with the same access permissions as the data they're auditing, undermining tamper-evidence
- No defined retention policy, leading to either premature deletion or unbounded, unmanaged growth
Common Errors
Audit logs missing critical context (who, when, what specifically) — review your audit log schema against your specific compliance framework's actual requirements, not just general best practice assumptions.
Continue Reading
- Structured Logging Best Practices for Easier Debugging
- How to Implement Role-Based Access Control for Compliance
- Data Retention Policies: What to Keep and What to Delete
Browse more articles in Compliance & Industry-Specific Hosting.
