
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.


