HR audit logs are the primary forensic evidence in a data breach investigation — they establish what data was accessed, by whom, from where, and when — and the organizations that cannot answer these four questions within 72 hours of a breach discovery fail GDPR notification requirements and face regulatory enforcement, not because the breach was large but because the evidence was inadequate. Here is how to build audit logs that function as forensic-grade evidence. See the Make.com HR Data Security guide for the log storage architecture this framework requires.

What Fields Must Every HR Audit Log Entry Contain for Forensic Use?

Each audit log entry requires eight fields for forensic adequacy: (1) timestamp with timezone (ISO 8601 format, UTC); (2) actor identity (user ID, not just username — usernames change, IDs do not); (3) actor IP address and geolocation; (4) action type (read, create, update, delete, export); (5) resource type (employee record, compensation data, health data, ATS application); (6) resource identifier (employee ID, application ID); (7) before-value and after-value for update/delete actions; and (8) session ID linking the action to the authentication event. Missing any of these fields limits the forensic reconstruction you can perform after a breach.

How Do You Investigate an HR Data Breach Using Audit Log Evidence?

The investigation sequence: (1) Identify the breach window — when was the first anomalous event and when was the last? Use log timestamps to bound the window. (2) Identify affected records — query the log for all records accessed during the breach window. (3) Identify the actor — correlate the actor ID and IP address from the log with your identity management system and network logs. (4) Reconstruct the access pattern — was this a bulk export, targeted record access, or systematic enumeration? The pattern indicates intent and helps determine whether the access constitutes a reportable breach. (5) Assess data sensitivity — categorize affected records by data type (personal, sensitive, financial) to determine GDPR notification thresholds.

How Do You Maintain Forensic Chain of Custody for Audit Log Evidence?

Chain of custody for digital evidence requires: storing audit logs in write-once storage (AWS S3 with Object Lock, or equivalent) so logs cannot be altered after the fact; generating a hash of the log file at each export interval and storing the hash separately from the log; documenting every person who accessed the audit logs during the investigation with timestamps; and retaining all forensic evidence in its original format — do not convert log formats during an investigation, as conversion introduces chain of custody questions. Legal counsel will ask for chain of custody documentation if the breach results in litigation or regulatory enforcement.

How Do You Build Forensic-Grade Audit Logging in Make.com HR Workflows?

Every Make.com™ scenario processing HR data writes an audit entry on each execution: scenario ID, execution timestamp, actor identity (the triggering user or system), data accessed (field names and record IDs), and action performed. In Make.com™, implement this as a dedicated logging module appended to each scenario: after the core workflow action, a Google Sheets “append row” module writes the audit entry to your centralized log. For high-sensitivity data (health information, compensation, termination records), also write the log entry to AWS S3 via the HTTP module for write-once archival. Sarah’s healthcare HR team discovered a former contractor’s credentials were used to access 340 employee health records — the Make.com™ audit log identified the exact access pattern within 4 hours of breach discovery.

Expert Take — Jeff Arnold, 4Spot Consulting™

The question is never “do we have audit logs?” The question is “can we answer a regulator’s forensic questions from our audit logs within 72 hours?” I have worked with HR teams whose logs contained all the right data but were stored in a format that took 3 days to query. Log structure and queryability are as important as log completeness. Design logs to be investigated, not just collected.

Key Takeaways

• Eight required audit log fields: timestamp (UTC), actor ID, actor IP, action type, resource type, resource ID, before/after values, session ID.
• Investigation sequence: bound the breach window, identify affected records, identify the actor, reconstruct the access pattern, assess data sensitivity.
• Chain of custody: write-once storage, file hashing, documented investigator access, original format retention.
• Make.com™ logging: append audit entry to Google Sheets + S3 write-once archival on every scenario execution touching HR data.
• Design logs to be investigated: queryability within 72 hours is as important as completeness.

Frequently Asked Questions

How long must HR audit logs be retained for forensic purposes?

GDPR does not specify a log retention period but requires retention “no longer than necessary.” Regulatory guidance and breach investigation timelines support a minimum 2-year retention for access logs covering personal data. SOX-relevant HR system logs: 7 years. HIPAA-covered entities: 6 years. Set your default retention at the longest applicable requirement — data minimization at the category level is more practical than maintaining different retention schedules for different log types.

What constitutes a reportable breach under GDPR for HR data?

A reportable breach under GDPR Article 33 is any personal data breach that is “likely to result in a risk to the rights and freedoms of natural persons.” For HR data, this includes: unauthorized access to employee health data, salary or compensation data, immigration status, disciplinary records, or any combination that enables identity theft or discrimination. Breaches affecting only low-sensitivity contact data with no downstream risk do not require DPA notification — but document the risk assessment that led to this conclusion.

Can Make.com execution history serve as an audit log for regulatory purposes?

No. Make.com™ execution history has a default retention period of 30 days and is not write-once — it is a debugging tool, not a compliance record. All compliance-grade audit logging must export from Make.com™ to external write-once storage during execution, not be retrieved from Make.com™ execution history after the fact.