Most servers and applications write logs by default and quietly delete them after a few days to save disk space. That is fine until you need to know who logged in last month, which request caused an outage, or how an attacker got in.
What to collect
- Authentication events: logins, failures, password resets, MFA changes, privilege changes.
- Administrative actions in control panels, cloud consoles and applications.
- Web server access and error logs.
- Firewall, VPN and network device logs.
- Application logs for business-critical events, such as payments and data exports.
- Changes to backups, users and security settings.
How long to keep them
There is no single answer; it depends on your industry, contracts and the regulations that apply to you. Practical guidance:
- Keep recent logs, for example the last 90 days, quickly searchable for troubleshooting and investigations.
- Keep older logs in cheaper storage for as long as your obligations require. Standards such as PCI DSS require at least a year of audit logs, with recent months readily available.
- Delete logs that contain personal data once you no longer need them; keeping everything forever is a privacy risk too.
Where to store them
- Off the server that produced them, so an attacker cannot delete their own traces.
- In storage with access separate from production administrators.
- Protected against changes, ideally with immutable retention.
- With accurate timestamps from synchronised clocks, so events from different systems line up.
Make them useful
Logs nobody reads detect nothing. Centralise them, set alerts for the events that matter most, and review regularly. Even a short weekly look at failed logins and admin changes catches problems early.
How IDX helps
IDX Object Storage is a cost-effective home for long-term logs, with S3-compatible access for log shipping tools. Our SOC service collects and analyses security logs, and our team can help design retention that meets your obligations.
IDX on digital infrastructure
Back to blog →