Audit Logs for Compliance: SOC 2, GDPR, and HIPAA Explained

Why compliance teams care so much about audit logs

Regulators and auditors share a common problem: they can't watch everything that happens inside your system in real time. Audit logs are the evidence trail that lets them reconstruct what happened after the fact. Without them, you can't prove your controls worked — even if they did.

For SaaS founders, this means one thing: audit logs are a checkbox on every enterprise security review, compliance questionnaire, and vendor assessment you'll ever fill out.

This guide covers the three frameworks you're most likely to encounter: SOC 2, GDPR, and HIPAA.

SOC 2: The SaaS standard

SOC 2 (Service Organization Control 2) is the de facto compliance standard for SaaS companies selling to US enterprises. It's not a regulation — it's an attestation framework developed by the AICPA.

What SOC 2 requires for audit logging

SOC 2 is organised around Trust Service Criteria (TSCs). Audit logs touch several of them:

CC6.1 — Logical access security You must restrict logical access to the system and monitor access. Audit logs are your evidence that you know who has access and that you're watching what they do with it.

CC6.6 — Restriction of access to sensitive information Implementing logical access security measures to protect against threats from sources outside system boundaries. Logging external access attempts (including failed logins and API key usage) satisfies this.

CC6.8 — Prevention and detection of unauthorized software Logging configuration changes and deployments demonstrates that you control what runs in your environment.

CC7.2 — Monitoring of system components You must implement procedures to detect anomalies and incidents. An audit log is the data source that makes anomaly detection possible.

What a SOC 2 auditor will actually look for

When a SOC 2 auditor reviews your logging controls, they want to see:

Completeness — are all privileged actions logged? User creation, role changes, data deletion, config changes.
Integrity — can logs be tampered with? They'll ask whether any user (including admins) can delete or modify log entries.
Retention — how long are logs kept? 12 months is the common minimum for Type II.
Review procedures — does someone actually look at the logs? Automated alerting on suspicious patterns counts.
Access to logs — who can query the audit log? This access itself should be logged.

The SOC 2 audit log minimum

- actor_id, actor_name, actor_email
- action (what happened)
- resource_type, resource_id (what it happened to)
- timestamp (UTC)
- source IP address
- outcome (success / failure)

Twelve months of retention, append-only storage, and a query interface that lets you pull logs by user, date range, and action type will get you through a SOC 2 Type II engagement.

GDPR: Accountability by design

The General Data Protection Regulation applies to any company that processes personal data of EU residents — regardless of where your company is located.

Article 5(2): The accountability principle

GDPR's accountability principle requires that you can demonstrate compliance, not just claim it. Audit logs are your demonstration. Without them, you're asking regulators to take your word for it.

Article 30: Records of processing activities

Controllers must maintain a record of processing activities. While this is a register of what you process rather than a log of every action, your audit log is evidence that the processing you've documented is the processing that actually occurs.

Article 32: Security of processing

GDPR requires "appropriate technical and organisational measures" to protect personal data. Logging access to personal data is specifically called out as a measure for ensuring confidentiality and integrity.

Responding to Subject Access Requests (SARs)

Under Article 15, data subjects can request a copy of all personal data you hold about them, including records of who accessed their data and when. Without an audit log, answering a SAR accurately is nearly impossible.

A compliant response might need to show:

Every time an employee viewed the subject's records
Every system-to-system transfer involving their data
Any time their data was exported or downloaded

What GDPR logging looks like in practice

Focus on logging access to personal data:

{
  "actor": {"id": "emp_042", "name": "Support Agent"},
  "action": "customer_record.viewed",
  "resource": {"type": "customer", "id": "cust_789"},
  "organization_id": "org_your_company",
  "metadata": {
    "reason": "support_ticket_ref: TKT-1234",
    "ip": "10.0.0.5"
  }
}

Adding a reason or ticket_reference field to access events is worth doing — it demonstrates that access was purposeful and authorized, which is exactly what DPAs want to see.

HIPAA: Healthcare's non-negotiable

The Health Insurance Portability and Accountability Act applies to covered entities (healthcare providers, health plans) and their business associates — any vendor that handles electronic protected health information (ePHI).

If your SaaS processes health data, HIPAA's Security Rule applies to you.

§164.312(b) — Audit Controls

The Security Rule's Technical Safeguards require:

"Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information."

This is not optional. Unlike some HIPAA standards that are "addressable" (meaning you can document why you're not doing them), the audit control standard is required.

What HIPAA auditors look for

Completeness of coverage — logging must cover all systems that touch ePHI, not just the front end
User-level attribution — every access must be tied to a specific user account, not a shared credential or system account
Tamper-evidence — can log entries be altered? Access to log data should itself be logged
Alerting — passive logging isn't enough; there should be procedures to review logs and respond to anomalies

Audit log retention under HIPAA

HIPAA requires retaining documentation for 6 years from creation or last effective date. Most covered entities treat this as the minimum for audit log retention as well, though the Security Rule doesn't specify a duration for logs explicitly.

In practice: 6 years is the safe answer for any healthcare-adjacent SaaS.

HIPAA-specific fields worth capturing

{
  "actor": {"id": "provider_123", "name": "Dr. Smith", "role": "physician"},
  "action": "patient_record.accessed",
  "resource": {"type": "patient_record", "id": "pat_456"},
  "metadata": {
    "access_type": "read",
    "patient_mrn": "MRN-789",
    "workstation_id": "WS-CLINIC-3",
    "ip": "192.168.1.50"
  }
}

The workstation_id is worth capturing in clinical environments — it's often a control requirement when devices are shared.

Practical checklist

Use this as a starting point regardless of which framework applies:

[ ] All privileged actions are logged (user management, config changes, data deletion)
[ ] Every log entry includes actor ID, name, action, resource, and timestamp
[ ] Log storage is append-only — no user can modify or delete entries
[ ] Retention period matches your framework requirements (12 months for SOC 2, 6 years for HIPAA)
[ ] Logs include source IP address
[ ] Failed actions are logged alongside successful ones
[ ] Access to the audit log itself is logged
[ ] You have a process to review logs periodically (automated alerts count)
[ ] You can export logs in a format auditors can read (CSV or JSON)

One more thing: make logs customer-facing

Compliance is one audience for your audit log. Your customers are another. Enterprise buyers want to give their compliance teams access to audit data — not just trust that your team is watching.

Building a customer-facing audit log UI is the difference between "we log everything internally" and "your admins can see everything, right now, filtered by user and date range."

That's the feature that closes enterprise deals.