SIEM requirements checklist

Retention period, not the license, usually decides how much hardware you need. Hot storage is the tier your analysts search interactively during an investigation. Archive storage holds older logs that you must keep for audit or legal reasons but rarely query. Open-source SIEM software is free to run in both tiers, so the real cost is disks, compute and the staff time to manage them. Before you compare platforms, decide how many days each log family must stay searchable (hot) and how many more days it must exist somewhere (archive). Those two numbers multiply directly into terabytes.

Graylog's system architecture guidance gives a usable starting method: multiply daily ingest by retention days and by 120 percent, then size the message journal at 3 to 5 times daily ingest on SSDs. The figures below are illustrative only, not a sizing recommendation. Suppose 50 GB per day of ingest is kept hot for 30 days. That gives 50 x 30 x 1.2 = 1,800 GB of log storage, and a journal of 150 to 250 GB on SSD. Doubling the retention doubles the storage figure, while the journal does not grow with retention. Your own numbers will differ, so measure them. Pull real ingest per source from a week or more of traffic, including peaks such as month-end batch jobs, and record it per log source, not as one total.

Then decide the tier for each source. Firewall and authentication logs may justify long hot retention, while verbose endpoint telemetry may only need a short hot window before archiving. Ask every vendor or partner how archive restore works: whether archived data can be brought back into the search tier, how long a restore takes at your volume, whether restored data is still subject to retention deletion, and who performs the restore during an incident. Graylog's Enterprise and Security editions list an archive restore capability in their product descriptions, and the Graylog pricing page is the place to confirm what your chosen edition includes. Get those answers in writing before you commit to a retention design.

Start by mapping each compliance obligation to the logs, alerts and review records the SIEM must produce, because a platform choice cannot satisfy a requirement that nobody has named. The HIPAA Security Rule at 45 CFR 164.312 asks for unique user identification, audit controls that record and examine activity in systems holding ePHI, person or entity authentication, and transmission security. The FTC Safeguards Rule at 16 CFR 314.4 asks covered financial institutions to require multi-factor authentication for anyone accessing an information system, encrypt customer information in transit and at rest, and monitor and log the activity of authorized users. For each clause, write down the source system, the event fields that prove it (for example, a successful login with a unique account name and source address), the alert that fires on failure, and the person who reviews it.

The SIEM produces the evidence, but it does not decide whether that evidence is adequate. Regulators, assessors and the organization's own counsel judge whether logging and review were sufficient for the risk, so the SIEM design should be defended in terms of what it records and how review is documented. Practical checks include whether authentication logs from the identity provider reach the SIEM with the user identifier intact, whether MFA events are captured separately from password events, whether administrator and database activity on ePHI or customer systems is logged, and whether review tickets or dashboard exports are kept with dates and reviewer names. Ask each candidate platform to show these records from a test source, not a demo dataset.

Treat this mapping as a gate in the selection process. Build a table with one row per requirement, one column for the named log source, one for the parsing or decoder that normalizes it, one for the alert or threshold, and one for the review record and retention period. Compliance views in platforms such as Wazuh, which include prebuilt dashboards for HIPAA and PCI DSS among other frameworks, help readers navigate the data but do not replace this mapping. Confirm with your assessor or regulator which evidence they expect, and confirm with each vendor which fields and retention settings are available in the edition you plan to run.

Vague answers to a few specific questions predict cost and delay better than any feature list. Before comparing platforms, ask every vendor and implementation partner how they measure ingest, how they enforce and restore hot and archive retention, how they prove access control on the logs themselves, how offline updates arrive, how upgrades are handled, and who writes and tunes detection rules. Ask for the answers in writing, tied to the platform you are considering, because a SIEM with the same feature list can behave very differently on these points.

Start with ingest. Ask whether licensing or sizing counts raw events, processed data or compute units, and whether the count is per source, per agent or per day. Graylog's published model licenses processed data with no per-user or per-device fees, while a Wazuh deployment is sized around agents, indexer storage and server nodes. For retention, ask how the platform separates hot and archive data, which component deletes old data, and how a restore is performed and timed. In Graylog, index rotation and retention delete the oldest indices, and the Graylog system architecture guidance sizes storage as daily ingest times retention days times 120 percent. Ask the partner to show that calculation against your numbers, and confirm whether an archive tier is included in the edition you are quoting.

For access control, ask for a demonstration rather than a checkbox. Confirm that role-based access, document-level and field-level security, and field masking are configured on the log store itself, not only in the dashboard, and that administrator actions on the SIEM are written to an audit log that is stored separately. Ask how the platform authenticates users through SAML, OpenID Connect, LDAP or Active Directory, and who holds the keys to the logs. For offline operation, ask how signatures, rule packs and vulnerability data reach a disconnected network, and what the update cycle looks like. Wazuh documents an offline installation guide and an offline vulnerability repository; Security Onion's airgap updates are covered separately. Finally, ask who writes detection content, who tunes it after go-live, and whether that work is in the quote.