How to Set Up Audit Logging for Compliance Requirements

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

Browse more articles in Compliance & Industry-Specific Hosting.

מאגר מידע

קטגוריות

קטגוריות