Linux

Audit Logging for Compliance on Linux and Cloud: What to Log and How Long to Keep It

What to log on Linux servers and in AWS, Google Cloud and Azure for SOC 2, PCI DSS and GDPR,…

1 November 2026  ·  4 min read  ·  Anand

Audit Logging for Compliance on Linux and Cloud: What to Log and How Long to Keep It

Almost every security framework asks the same question in different words: can you show who did what, when, on which system? SOC 2 auditors test it, PCI DSS sets explicit rules for it, and GDPR breach notification depends on it. Yet audit logging is often the weakest part of an otherwise secure setup: logs stay on the server an attacker controls, clocks drift, and retention is whatever the disk allows. This guide covers what to log, how to protect it and how long to keep it.

What to log

Event Why it matters
Logins and failed logins (SSH, consoles, VPN, applications) Shows who had access and reveals brute-force attempts
Privilege use (sudo, root commands, role changes) The actions with the biggest impact
Changes to users, groups, keys and permissions Attackers create accounts and add keys to keep access
Configuration changes to security-relevant files and cloud resources Firewalls, SSH, IAM policies and audit settings themselves
Access to sensitive data stores Needed to judge the scope of a breach
Starting, stopping or changing the logging itself A silenced log is one of the first signs of an intrusion

Linux: auditd

The Linux audit system records security events from the kernel. A small rule set covers most of the table above. Put rules in a file under /etc/audit/rules.d/, for example:

-w /etc/passwd -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/group -p wa -k identity
-w /etc/sudoers -p wa -k privilege
-w /etc/sudoers.d/ -p wa -k privilege
-w /etc/ssh/sshd_config -p wa -k sshd
-w /etc/audit/ -p wa -k audit_config
-a always,exit -F arch=b64 -S execve -F euid=0 -F auid>=1000 -F auid!=unset -k root_commands

Load them with sudo augenrules --load and search by key, for example sudo ausearch -k privilege -i. The last rule records every command a logged-in user runs as root. On older audit versions, use auid!=4294967295 instead of auid!=unset. Start small: rules that log every file read on a busy server produce more data than anyone will review.

Cloud accounts

  • AWS: an organisation-wide CloudTrail trail for all regions, with log file validation enabled and delivery to a dedicated, locked-down S3 bucket.
  • Google Cloud: Admin Activity audit logs are always on; Data Access audit logs are mostly off by default, so enable them for services that hold sensitive data, and route logs to a separate project with a log sink.
  • Azure: the Activity Log covers control-plane changes; use diagnostic settings to keep it, and resource logs, beyond the default retention.

Get logs off the server

A log that lives only on the server it describes can be deleted by anyone who compromises that server. Forward logs in near real time with rsyslog, journald forwarding or a log agent to a central store or SIEM. Make the central store hard to tamper with: separate credentials, write-only access for the senders, and immutable storage such as S3 Object Lock for the archive.

Synchronise clocks

Logs from different systems are only useful together if their timestamps agree. Run chrony or another NTP client on every server, point it at trusted time sources, and alert when a clock drifts. PCI DSS makes time synchronisation an explicit requirement.

How long to keep logs

Framework Retention guidance
PCI DSS v4.0 At least 12 months, with the most recent 3 months immediately available for analysis
SOC 2 No fixed period; logs must cover the audit period and match your own retention policy
GDPR No fixed period; keep logs long enough to detect and investigate breaches, but not longer than needed, and minimise personal data in them

Write your retention period into a policy, configure storage lifecycle rules to enforce it, and make sure deletion actually happens.

Logs nobody reads do not count

Auditors and attackers both know the difference between collecting logs and using them. Alert on high-value events: root logins, new administrator accounts, changes to audit settings, and cloud actions such as disabling a trail. Review alerts and keep a record of the review.

Keep personal data out of logs

Application and web server logs often capture email addresses, IP addresses, tokens or form data. Mask or drop what you do not need, restrict who can read logs, and apply your retention policy to them like any other personal data.

Get help

TechProvidence engineers set up audit logging, central log storage and alerting on Linux servers, AWS, Google Cloud and Azure as part of our cybersecurity and risk management services. For the wider picture, see our checklists for GDPR server security and SOC 2 technical controls, or contact us.

Running into something similar?

We look after Linux servers, control panels and virtualization for businesses every day. If an update, vulnerability or outage here affects you, we can help.