How to use this SIEM log retention requirements checklist
A regulated organization building a self-hosted SIEM on Wazuh, Graylog or OpenSearch has to answer two questions before anything else: how long must we keep logs, and how fast must they be searchable? The short answer is that the frameworks set a minimum retention period and a minimum period of immediate search access, and the design must meet both. PCI DSS Requirement 10.5.1 sets 12 months of audit log history with the most recent three months immediately available for analysis, while CIS Safeguard 8.10 sets at least 90 days, and NIST AU-11 leaves the period to the organization.
This checklist separates three things that teams often blend together. The retention rule is the length of time a framework or regulator requires you to keep a log. The search-speed rule is how quickly a log must be queryable during an investigation or assessment. The storage tier is the technical arrangement that implements both, such as hot indices on fast storage, cold or archived data on cheaper media, and index lifecycle policies that move data between them. Keeping these apart lets you see which requirement drives which sizing decision.
Read the sections that follow in that order. Each one names the framework, the control or article, the rule it sets and the design decision it forces. Where a figure appears, it comes from the cited framework or from the platform documentation linked in the text. Where a framework leaves the period to your own risk assessment, the page says so and lists what to confirm with your assessor, your regulator or your own policy owner before you size storage.
Functional retention requirements and how to verify them
This table compares the retention period, immediate searchability, sources in scope and verification method for each framework that touches SIEM logs. Read it by finding the strictest applicable row for each log source, since that row sets the hot tier size and index lifecycle policy. Confirm the NIST AU-11 period with your assessor before sizing storage.
| Requirement | Retention and searchability | Sources in scope | How to verify |
|---|---|---|---|
| PCI DSS 10.5.1 | At least 12 months of audit log history, with the most recent 3 months immediately available for analysis | Audit logs from systems in the cardholder data environment and connected systems, including anti-malware logs tied to Requirement 5.3.4 | Examine the written retention policy, the audit log history configuration, and the logs themselves; run a search against a month that is three months old without restoring from archive |
| CIS Safeguard 8.10 | At least 90 days of retained audit logs across enterprise assets (IG2 and IG3) | Audit logs from enterprise assets in scope for the organization's implementation group | Confirm the implementation group, check retention settings on each log store, and sample logs dated near the 90-day boundary |
| NIST SP 800-53 AU-11 | Organization-defined period sufficient for after-the-fact incident investigations and regulatory retention needs | Audit records from systems in the authorization boundary, as defined in the system security plan | Compare the documented period in the system security plan against index lifecycle settings; ask the assessor to confirm the value for each baseline |
| DORA Article 10 and delegated Article 12 logging | No fixed period in the supplied sources; the retention period must follow the entity's own policy and the regulator's expectations | Access control, identity management, capacity, change, ICT operations and network traffic logs | Confirm the retention period with the competent authority or compliance lead, then test that logs are protected from deletion and that clock sources are documented |
| Hot tier searchability | Logs needed for routine analysis stay in indices that answer queries without restoring from archive | All indexed security events, alerts and audit trails | Run timed searches on the oldest hot index and record results; check that the index lifecycle policy moves data to cold storage only after the hot period ends |
| Index lifecycle policy | Rollover, move and delete actions set per index pattern so retention matches the strictest rule | Each index pattern, including alert, event and audit indices | Export the lifecycle policy configuration and confirm each index pattern is attached to it and that delete actions are not earlier than the required period |
| Storage sizing | Plan capacity from daily ingest multiplied by retention days, with headroom for growth and replicas | Ingest volume measured per source over a representative period | Graylog guidance uses daily ingest times retention days times 120 percent; confirm the headroom and replica factor with the platform vendor and test with real ingest |
What PCI DSS, NIST, CIS and DORA each ask the log store to do
PCI DSS asks for a fixed retention floor and fast access to the newest logs. Requirement 10.5.1 requires audit log history to be retained for at least 12 months, with at least the most recent three months immediately available for analysis. In practice, the log store needs two tiers: a hot tier that answers queries against the last three months without a restore step, and a colder tier that holds the remaining nine months. Requirement 5.3.4 links anti-malware audit logs to the same 10.5.1 retention period, so your endpoint protection logs cannot sit on a shorter schedule than the rest of the estate. Ask your assessor which systems fall in scope, then confirm in your SIEM that the retention policy applies to each of those log sources, not only to the default index.
NIST SP 800-53 control AU-11 (Audit record retention) asks you to define a retention period and keep audit records long enough to support after-the-fact incident investigations and to meet regulatory and organizational requirements. Unlike PCI DSS, the number is yours to set, so the decision is documented in your own policy and mapped to the baseline you are assessed against. SP 800-53B selects AU-11 for the low, moderate and high baselines and the privacy baseline, so the same control applies to most federal and contractor systems. Record the chosen period per log category, because an investigation often reaches back further for authentication and privileged activity than for routine application events.
CIS Safeguard 8.10 (Retain audit logs) asks for audit logs across enterprise assets to be retained for at least 90 days. It applies to Implementation Groups 2 and 3 but not to Implementation Group 1, so an IG1 organization can treat it as a recommendation rather than a requirement for its own program. Treat 90 days as a floor that the hot tier can meet on its own. DORA Article 10 and Delegated Regulation (EU) 2024/1774 Article 12 ask for something different: the store must protect logs and show that they are reliable. Article 12 expects logging of access control, identity management, change management, ICT operations and network traffic, protection of logs against tampering and deletion, detection of logging failures, and clock synchronization to a documented reliable time source. Confirm that your platform signs or restricts log deletion, alerts on dropped or stalled ingest, and syncs every node to one time source. None of these frameworks replaces your own policy or legal duties, which may require longer retention than any of them.
How retention rules become hot, warm and cold storage tiers
The simplest pattern keeps every retained log on one OpenSearch-based cluster and uses index lifecycle policies to delete indices once they pass the retention window. Under PCI DSS Requirement 10.5.1, audit log history must be kept for at least 12 months, and at least the most recent three months must be immediately available for analysis. On a single tier, the three-month rule is met automatically because all twelve months sit in searchable indices, but the cost of that choice grows with every month of retention.
- Index rotation: Roll indices by size or age so that each daily or weekly index can be deleted as a unit rather than trimmed record by record.
- Lifecycle deletion: Configure the delete action in the index lifecycle policy to match the twelve-month period set by your assessor scope, not the shortest rule that might apply.
- Storage sizing: Estimate daily ingest times retention days, then add headroom and replica copies. Graylog's sizing guidance uses daily ingest times retention days times 120 percent as a starting baseline.
- Replica and snapshot cost: Replicas double disk use on a hot tier unless you accept reduced redundancy, so price them explicitly.
- Access control: Apply OpenSearch Security roles so that analysts see only the indices their role needs.
Confirm with your QSA which retention period and access expectations apply to your in-scope systems, and confirm the lifecycle behavior in the OpenSearch version you intend to run.
A two-part design keeps the most recent three months in hot indices on fast local storage and moves older logs to a cheaper repository through snapshots. The hot tier answers daily review and incident queries, while the archive satisfies the remaining months of the twelve-month requirement. This split is usually where storage cost falls most, but it adds a restore step that analysts must be able to perform quickly during an investigation.
- Hot window: Set the rollover and migration rules so that indices older than roughly three months leave the hot tier, keeping the immediate-access rule satisfied with margin.
- Snapshot repository: Register a snapshot repository on lower-cost storage, and schedule snapshots of closed indices before they leave the hot tier.
- Restore path: Test restoring a month of logs into a searchable index, and record how long the restore takes on your hardware.
- Integrity of archived logs: Protect the repository against deletion and tampering by limiting who can delete snapshots, and keep a record of snapshot hashes.
- Cost drivers: Archive storage, snapshot frequency and restore compute are the recurring items, while the initial build is largely one-time labor.
Ask your implementation partner to show a documented restore test and to confirm that archived indices remain searchable by the same detection rules and dashboards.
Graylog separates the log processing layer from its search backend. Graylog recommends Data Node as the search backend, and Graylog Open manages storage through index sets that rotate by message count, size or time and delete the oldest indices under a retention policy. Graylog Enterprise adds data lake with archive restore and data tiering, and Graylog Security adds SIEM features, so tiering is not part of the free tier. Confirm tiering behavior on the exact Graylog version you plan to run, because the documentation for index sets and tiering may differ between releases.
- Index sets: Create index sets with a rotation strategy and a retention strategy that match the required hot window and total retention period.
- Free tier limits: With Graylog Open, plan the cold period as deletion or an external archive you manage, since native archive restore is an Enterprise feature.
- Data Node sizing: Use the daily ingest times retention days times 120 percent guidance as a baseline, and size the message journal at 3 to 5 times daily ingest on SSDs.
- Compatibility: Check the compatibility matrix for the MongoDB and search backend versions your Graylog release supports, because OpenSearch 1.x use is deprecated from Graylog 7.0.
- Licensing: Graylog Open is licensed under SSPL-1.0, so review that license with counsel before embedding it in a product.
Request a written tiering and retention test plan from any partner, and confirm whether the chosen edition supplies the tiering and restore features your retention design requires.
Setting index lifecycle policies on OpenSearch-based platforms
This sequence turns the retention periods your frameworks set into index lifecycle rules that keep recent logs searchable, move older data to cheaper storage and delete it on schedule, with evidence that each step worked.
Map retention periods to each log class
Before touching the cluster, list every log class the SIEM receives, such as authentication events, endpoint alerts, network sensor data and application audit trails, and assign each one a retention period taken from the governing requirement. The compliance owner signs off on the table, and the platform engineer confirms each class has a named index pattern or stream. The step is complete when every class has a retention value, a hot search window and an owner, with no class left on a default setting.
Define hot, warm and cold tiers
Decide which portion of each retention period must be immediately searchable for analysts and which portion can sit on slower or cheaper storage. Requirements such as PCI DSS 10.5.1 separate a 12-month total from a most-recent-three-months immediately available window, so use that split as the test for the hot tier, and confirm any longer archive expectations with your assessor. The output is a tier definition per log class that states where data lives at each age.
Configure rollover by size or age
Set the conditions under which an active index is closed and a new one starts, using size, document count or age, so that no single index grows beyond what your nodes handle well. In Graylog, this is configured as index rotation by message count, size or time, and the platform's index model documentation describes the options. In Wazuh, the indexer holds the alert data that the Wazuh server writes, so confirm with the Wazuh documentation for your release how rollover and index templates are managed. The check is a test index that rolls over under the chosen condition.
Move aging indices to read-only or cold state
Create transition rules that move indices past the hot window into a read-only or cold state, reducing write activity and, where the storage design allows, moving them to lower-cost nodes or storage. The SIEM administrator applies these rules and records which indices changed state and when. Confirm the exact policy syntax, the state names and any node-attribute requirements with the OpenSearch or Graylog documentation for your version, since these details differ between releases. The step closes when a sample index shows the expected state at its target age.
Delete indices at expiry
Configure deletion for each class once the retention period ends, so that indices are removed automatically and consistently. Graylog's retention setting removes the oldest indices, which fits this model when the rotation strategy is aligned to the retention target. Document the deletion behavior, including how long it takes to process and whether any legal hold or investigation exception must pause it. The output is a retention report showing the oldest remaining index per class falls inside its policy window.
Protect lifecycle settings from change
Restrict who can edit lifecycle policies, index templates and retention settings, and log every change to those settings. Auditors examine whether retention can be shortened quietly, so the platform's security and audit logging should record policy edits, and access should follow the role model in the OpenSearch Security plugin or the equivalent Graylog and Wazuh roles. The check is a change record that shows who edited a policy, when and under which approval.
Test restore from cold storage
Restore a sample of archived or cold indices into a search-ready state and run the queries an investigator or assessor would run, confirming that results return and timestamps are intact. Record the time taken and any manual steps, then compare them with the recovery expectations in your incident response plan. Repeat the test after each platform upgrade, since restore behavior can change across releases. The step is complete when a documented restore succeeds and the result is filed with the retention evidence.
How to size storage for the retention period
Start with the sizing approach in the Graylog system architecture guidance: daily ingest multiplied by retention days, multiplied by 120 percent gives the log storage the search backend needs, and the message journal needs a further 3 to 5 times daily ingest on SSDs. For a 12-month PCI DSS 10.5.1 retention period, the retention figure is 365 days, but the 120 percent factor is the guidance's own allowance for overhead, so treat it as a floor for planning rather than a final answer. Run the formula separately for each retention tier you define, because the hot tier that holds the most recent three months and the colder tier that holds the rest will have different retention days and possibly different hardware.
The formula covers only primary storage. Replicas, snapshots, index overhead and growth from new sources are separate line items that the formula does not include, and each one can push the total well past the first estimate. Replica count multiplies the stored data on OpenSearch, snapshot repositories need their own capacity and retention, and every new log source adds daily ingest that the original figure never saw. Ask your implementation partner to show each of these as a named line in the sizing sheet, with its assumption written next to it.
The most important input is the daily ingest figure, and it must be measured from real sources rather than assumed. Turn on collection from a representative set of endpoints, firewalls, identity systems and cloud or application logs for a full business cycle, then read the daily volume per source from the indexer or Graylog metrics. Illustrative example: if a pilot measures 50 GB per day, 365 retention days and the 120 percent factor give about 21.9 TB of log storage before replicas and snapshots, and the journal would add 150 to 250 GB on SSD. Confirm each figure with your own measurements before you buy hardware.
Security requirements for the logs themselves
A retention schedule is only useful if the logs survive, stay accurate and remain readable to people who should see them and no one else. The controls below protect the log store from change and deletion, restrict who can query it, encrypt traffic to it, record administrator activity, keep timestamps trustworthy and govern logs that carry personal or patient data.
Protecting logs from change and deletion
Retention periods mean little if an administrator or attacker can edit or purge events before an auditor samples them. Decide how archived logs become immutable, for example with write-once object storage, snapshot repositories with restricted delete rights, or signed exports to a separate system. Confirm each immutability control with the chosen platform's documentation and test it by attempting a deletion from an ordinary administrator account.
Role and field-level access to the log store
Most people who need SIEM data need only a subset of it, and some fields, such as user identifiers or payment data in event bodies, need masking. The OpenSearch Security plugin provides role-based access control, document-level and field-level security and field masking. Map roles to SOC tiers and auditors, then test that a restricted role cannot see masked fields in dashboards, saved searches or exported reports.
TLS for node and client traffic
Agents, log shippers, cluster nodes and dashboard users all move security events across the network, and interception of those events can hide an intrusion. Require TLS for node-to-node and client traffic and for every input, including syslog over TLS where the source supports it. Confirm the certificate lifecycle, including renewal and the procedure for rotating a compromised key, because an expired certificate can silently stop ingestion.
Audit trail for administrator actions
Changes to retention policies, index lifecycle rules, role mappings and input configurations are the changes an assessor will ask about first. Enable audit logging for the security plugin and the SIEM application, send those records to a location administrators cannot edit, and review them on a set schedule. Ask the implementation partner which administrator actions are captured by default and which need explicit configuration.
Clock synchronization to a documented source
Event correlation, incident timelines and evidence of retention all depend on timestamps that agree across every source. Synchronize every log source, the SIEM servers and the indexers to one documented reliable time source, and record which source and tool, such as chrony, each system uses. Monitor drift and alert when a host stops synchronizing, because a silent clock fault can break a retention or investigation claim later.
Retaining logs with personal or patient data
Security logs often contain names, IP addresses, account identifiers and, in clinical systems, patient record references. Keeping them for the full retention period extends the privacy and access obligations that apply to that data. Decide which fields are pseudonymized or dropped before indexing, set separate access and deletion rules for personal data, and confirm with legal counsel how retention periods interact with erasure requests and sector rules such as the HIPAA audit controls standard at 45 CFR 164.312.
Operational requirements and how to prove retention works
This table compares the recurring operational duties that keep log retention compliant after go-live, with the evidence an examiner typically samples for each. Read each row as a control to run continuously, not a one-time build task. The main takeaway is that retention is only as defensible as the dated records showing that the policy was configured, monitored and tested over time.
| Requirement area | What must happen in operation | Verification evidence an examiner samples |
|---|---|---|
| Recent log review | Review recent audit logs daily or through automated alerting, with the most recent three months immediately searchable for analysis under PCI DSS Requirement 10.5.1 | Dated alert review records, saved searches showing hot-tier query results, and reviewer sign-off history |
| Logging failure and ingest gap monitoring | Alert when agents stop reporting, syslog sources go silent, or the indexer rejects events, and track the duration of each gap | Health monitoring alert history, agent last-seen reports, and tickets showing gap investigation and backfill |
| Storage capacity alerts | Set thresholds on hot and cold tier disk use so retention cannot silently shorten when storage fills | Capacity alert configuration exports, threshold change records, and disk utilization trend reports |
| Retention configuration control | Keep index lifecycle or Graylog index rotation and retention settings under change control with version history | Exported lifecycle policy files, change tickets, and the configuration history showing who altered retention and when |
| OpenSearch maintenance cadence | Plan upgrades within the maintenance window of each OpenSearch version, since maintenance releases carry security patches but no new features | Upgrade records mapped to OpenSearch release dates, version inventory, and vulnerability scan results per node |
| Wazuh patch currency | Apply 4.14 patch releases on a scheduled cadence, testing indexer and dashboard compatibility before rollout | Change records for each 4.14.x patch, pre-production test results, and agent version reports |
| Restore testing | Restore archived or snapshotted indices to a test cluster on a documented schedule and confirm searchable results | Restore test records with dates, index names, record counts compared with source, and remediation notes for failures |
| Documented retention decisions | Record the chosen retention period per log source and the rule that sets it, and review it when obligations change | Signed retention decision register, mapping to the controls cited, and dated review minutes |
How much does a SIEM retention build cost, and what can the team do itself?
What drives SIEM log storage cost, and how does retention multiply it?
Storage cost scales with daily ingest, the number of days you keep data searchable and the overhead the search engine adds on top of raw logs. Retention multiplies the first two: doubling the retention period doubles the stored volume at the same ingest rate. Graylog's architecture guidance suggests sizing log storage as daily ingest multiplied by retention days and then by 120 percent, and it advises setting aside 3 to 5 times daily ingest on SSDs for the message journal. The usual cost levers are the hot tier (fast, searchable, usually SSD-backed), the cold or archive tier (cheaper, slower to query) and how much noise you drop or filter before indexing. Ask any partner to show the per-source volume figures behind its sizing, not a single blended number.
How long does a retention design and sizing exercise take?
The duration depends on how many log sources you have, how well documented they are and how many compliance frameworks set the retention rules. A design covering a few well-understood sources is far shorter than one that must reconcile PCI DSS, NIST SP 800-53 and DORA requirements across dozens of systems. Your written scope should state the source count, the frameworks in scope, the storage platform (Wazuh indexer, OpenSearch or Graylog with Data Node) and whether a restore test is included. DeployOpen agrees scope, deliverables and timelines in writing before work starts, so ask for the timeline as part of that scope rather than relying on a general estimate.
What must our team provide before a retention sizing engagement starts?
Four inputs make the difference between a credible sizing and a guess. First, a source inventory listing every system that sends logs, its log type and its owner. Second, daily ingest measurements per source, taken over a representative period, not a vendor estimate. Third, the framework scope: which requirements apply to which systems, such as PCI DSS Requirement 10.5.1 or AU-11 in your chosen baseline. Fourth, named policy owners who can approve the retention periods and the rules for the hot tier, since the auditor will ask who set them. Missing any of these usually extends the work, so confirm each one in the written scope.
Can an in-house team run OpenSearch index lifecycle policies by itself?
Yes, a team with solid OpenSearch operations skills can write, apply and tune index lifecycle policies that move data from hot to cold storage and delete it on schedule. The configuration is the easier part. The harder work is proving it: you need regular restore tests that show archived logs can be brought back and searched within your stated window, and you need retained evidence of each policy change, each deletion and each test. OpenSearch's maintenance model also means you must plan regular upgrades, since versions receive only bug and security fixes during maintenance. Assess whether your engineers have that discipline before deciding who owns the policies day to day.
What changes between Graylog Open and Graylog Enterprise for tiering?
Graylog Open is free with no volume limits and community support. Graylog Enterprise, which Graylog's pricing page lists from 15,000 US dollars per year, adds a data lake with archive restore and data tiering, plus a correlation engine and 24/7 support. Enterprise licensing starts at a minimum of 10 GB per day or 100 Graylog Compute Units, and it is licensed on processed data with no per-user or per-device fees. Graylog Open still rotates and deletes indices by message count, size or time, so you can build a retention model without paying for tiering, but you will manage archive and restore steps yourself. Confirm current pricing and terms directly with Graylog before you decide.
What does a partner charge for compared with the work a team keeps?
A partner's cost covers the work you choose to hand over, typically the sizing model, the policy configuration, the restore test design and the evidence pack. Your team keeps the recurring work of operating retention: watching storage growth, handling new log sources and running restore tests on schedule. Ask any provider to split the quote into one-time items (design, configuration, initial testing) and recurring items (support, upgrades, periodic restore tests). DeployOpen does not publish a price list, and a quote follows from the written scope, so compare proposals on that split rather than on headline totals.
Which retention figures should we verify with our auditor before paying for sizing?
Before you size storage, confirm the retention period and the searchable window your assessor expects. Written requirements such as the PCI DSS retention requirement and the CIS audit log safeguard set minimum periods, but your organization may choose longer ones under NIST AU-11 or your DORA obligations. Ask your auditor or compliance lead which period applies to each log type, because that single decision sets the hot and cold tier sizes. Put the answer in the scope so the sizing model reflects it, and avoid paying for a sizing built on assumed numbers.
How DeployOpen scopes and delivers retention design
DeployOpen turns the retention rules in your frameworks into a written scope, a tested OpenSearch-based tier design and a handover your auditors can follow. We plan, implement, harden, document and support self-hosted platforms inside your own infrastructure, so the logs stay where your policy requires them.
How we scope
- We list every log source and its regulatory owner, such as PCI DSS 10.5.1, CIS Safeguard 8.10 or DORA Article 12 logging.
- We record the hot search window, total retention period and archive location for each source in the written scope.
- We agree in writing which platform, version and deployment model is in scope before any work starts, with fixed deliverables and timelines.
How we build
- We configure index lifecycle policies or Graylog index rotation and retention that move logs from hot to cold storage on the agreed schedule.
- We size storage from daily ingest, retention days and overhead, and test that the cluster holds the agreed retention under realistic load.
- We test that retained logs can be searched within the required window and that deletion happens only when the policy says so.
How we hand over
- We document the retention policy, tier design, lifecycle settings and sizing assumptions so an assessor can trace each rule to a configuration.
- We provide evidence packs showing configuration exports, test results and retention settings for the auditors your organization names.
- We train your operators to run restore, search and retention checks, and we record the runbook for upgrades and capacity changes.
How we support
- Ongoing support, upgrades and capacity reviews are available as a retainer, scoped separately from the initial build.
- We review retention settings after each platform upgrade, such as OpenSearch or Wazuh releases, and re-test the tier design.
- Your compliance team confirms the final retention periods with its assessor, since DeployOpen prepares evidence but does not issue audit opinions.
