What Should You Log to a SIEM and How Long Should You Keep It?

A security information and event management (SIEM) system should receive logs that let you answer who did what, to which system, when, from where and with what result. Start with identity, endpoint, network edge and cloud audit logs. Then decide retention by what your investigations and regulators need, not by what is cheap.

What does the standard ask for?

NIST SP 800-53 control AU-2 Event Logging asks you to identify the event types the system can log, specify which ones you will log, and give a rationale for why they are adequate to support after-the-fact investigation of incidents, then review the list periodically. AU-3 says each record should establish what type of event occurred, when, where, the source, the outcome and the identity of individuals or objects involved. AU-12 asks that components generate those records, and AU-11 asks you to retain audit records long enough to support investigations and meet legal and organizational retention requirements.

AU-6 covers review: analyze audit records for signs of inappropriate or unusual activity, report findings to defined roles, and adjust the review level when risk changes. Its first enhancement asks you to integrate review and analysis processes using automated mechanisms, which is where a SIEM comes in.

NIST SP 800-92 on log management gives practical guidance on developing, implementing and maintaining effective log management across an enterprise. CISA, together with the Australian Signals Directorate and other partners, published best practices for event logging and threat detection that describe a baseline for event logging to mitigate cyber threats.

What should you send first?

Rank sources by the questions they answer:

1. Identity provider: sign-ins, failures, multi-factor outcomes, role and group changes.
2. Endpoints and servers: process creation, authentication, service installs, security tool alerts.
3. Cloud audit trails: every API call that changes configuration or access.
4. Network edge: firewall, proxy and DNS logs, which show outbound behavior.
5. Key applications: admin actions, access to sensitive records, errors and exports.

Skip the temptation to ingest everything on day one. Unreviewed volume costs money and hides signals.

How do you decide what matters?

Work backward from the incidents you fear. A constructed example: a company worries about stolen credentials leading to data theft from file storage. The questions would be: did a sign-in come from an unusual place, were sessions created without multi-factor authentication, were large downloads made, was anything shared externally?

Each question maps to a log: identity sign-ins, session details, storage access logs, sharing events. The team confirms each source has the fields AU-3 lists, such as the user, source address and result, and writes one alert per question. Sources that answer none of their questions wait.

How long should you keep logs?

AU-11 gives no number; it ties retention to investigations and requirements. Practical reasoning: attackers are sometimes in an environment for a long time before discovery, so retention shorter than your typical detection delay leaves you blind. Some regulations and contracts set minimums, so check yours. Keep recent data searchable and older data in cheaper storage that you can still restore.

Protect the logs as evidence. Send them off the source system, limit who can delete them and alert if logging stops. Silence is a signal.

What goes wrong with SIEM projects?

• Sources that stop sending and nobody notices.
• Inconsistent timestamps and time zones across systems.
• Missing fields, such as no username on a record.
• Hundreds of default rules, nobody owning tuning.
• No test that detections still fire after a log format changes.

How to check or apply this

1. List your top five incident scenarios and the questions you would need answered.
2. Map each question to a log source and verify the fields exist.
3. Onboard sources in priority order, and measure missing or delayed data per source.
4. Alert if any source goes quiet for longer than a set period.
5. Synchronize clocks across systems and store timestamps in one standard time zone.
6. Set retention by source, with a written reason, and test restoring old data.
7. Restrict deletion rights and keep a copy outside the systems being logged.
8. Test each detection quarterly with a harmless simulated event.

Quick check

Sources

• NIST SP 800-53 Rev. 5 control catalog, OSCAL JSON from NIST (AU-2, AU-3, AU-6, AU-11, AU-12)
• NIST SP 800-92, Guide to Computer Security Log Management
• CISA, Best Practices for Event Logging and Threat Detection

Last reviewed: 18 October 2026.