Cloud Log Retention Renewal: Price the Data You Can Actually Investigate
Your SIEM proposal may price log volume by the gigabyte. Your security team does not investigate incidents by the gigabyte.
They investigate a disabled MFA method, a new administrator, an unusual mailbox rule, or traffic that crossed the wrong boundary. If those records are gone, trapped in an unusable archive, or stripped of the fields needed to connect the activity, the retention line on the proposal is mostly decoration.
Before you renew a cloud logging or SIEM agreement, stop asking only how many days of retention you have. Decide which data must remain searchable, what can move to a lower-cost tier, how fast archived data can return, and which sources no longer earn their full ingestion cost.
Retention should follow investigations. The price should follow the retention design.
Start with the questions your team has to answer
A blanket rule such as “keep everything for one year” sounds safe. It can also be expensive and lazy.
Different records support different decisions. Identity events may help reconstruct an account takeover. Endpoint telemetry can connect a process to a user and device. Firewall events may show where traffic went. Debug logs from a low-risk application may produce huge volume without answering a useful security question.
CISA and its international partners say event logging improves network visibility and the resilience of critical systems. Their guidance also accounts for resource constraints. That combination matters. Buyers need enough evidence to investigate, but more collection is not automatically better security.
List the investigation questions that matter to your company:
- Can we reconstruct a privileged account compromise?
- Can we see who changed an identity, email, cloud, or security policy?
- Can we connect an endpoint alert to identity and network activity?
- Can we prove whether sensitive data was accessed or exported?
- Can we trace activity performed through a vendor or service account?
- Can we explain the first failure in a material outage?
For each question, identify the sources, fields, time range, and search speed the analyst needs. That is the beginning of a retention policy you can defend.
Build a source-level retention map
Do not accept one retention number for the whole environment. Build a row for every material source.
| Log source | Decision it supports | Current daily volume | Searchable period | Archive period | Retrieval test | Monthly cost |
|---|---|---|---|---|---|---|
| Identity provider | Account compromise and privilege changes | Export actual volume | Record current tier | Record archive | Search a known old event | Record full cost |
| Email platform | Forwarding, mailbox rules, admin actions | Export actual volume | Record current tier | Record archive | Rebuild a sample timeline | Record full cost |
| Endpoint security | Process, alert, user, and device activity | Export actual volume | Record current tier | Record archive | Find a closed incident event | Record full cost |
| Firewall or SASE | Connection, policy, and routing evidence | Export actual volume | Record current tier | Record archive | Trace a controlled event | Record full cost |
| Cloud control plane | Administrative and configuration changes | Export actual volume | Record current tier | Record archive | Find a known change | Record full cost |
| Business application | Access, export, and admin activity | Export actual volume | Record current tier | Record archive | Prove user and action context | Record full cost |
Pull the numbers from the platform, cloud bill, storage, and managed service invoice. A proposal estimate is not usage.
Include sources that bypass the main SIEM. Some logs remain in a SaaS portal, cloud account, endpoint console, storage bucket, or provider platform. Show where the evidence lives, not where the architecture diagram says it should live.
Separate searchable retention from stored retention
“We keep the logs” can mean several different things.
The data may be immediately searchable. It may sit in a lower-cost tier with limited queries. It may need a restoration job, new index, parser, or separate tool. It may technically exist while the security team cannot use it.
Microsoft’s current Sentinel cost guidance makes this distinction explicit. Microsoft says its analytics tier is intended for continuous, real-time threat detection, while its data lake can hold secondary security data that does not need real-time detection. The same guidance says data that ages out of analytics retention can remain available at lower cost through the data lake. That is one vendor’s design, not a universal recommendation. It shows why “retained” and “ready for investigation” are different promises.
For every tier in your environment, document:
- How long data remains immediately searchable
- Which query functions and fields remain available
- How archived data is requested or restored
- Expected retrieval time and any service commitment
- Retrieval, rehydration, transfer, or query charges
- Who can approve and perform the recovery
- Whether detections can run against that tier
- What happens to parsers, enrichment, timestamps, and source identity
- How the organization handles a legal hold or active incident
- What survives contract termination
If the answer is “we would call the vendor,” put a time and cost around that dependency.
Run an old-event retrieval test before renewal
A storage policy is not evidence. Run the process.
Choose a closed incident, approved change, or controlled event old enough to sit in the tier you plan to rely on. Do not create a production security event just to make the test interesting. Use something safe and known.
Ask an analyst who would handle a real investigation to retrieve the records. Start the clock when the request begins. Confirm the data range, event count, timestamps, source, user or device identity, important fields, and any enrichment the original investigation would require.
Test whether the data connects across sources. An identity event without the related endpoint, email, or network record may not answer the question. A year of one log does not fix 30 days of another.
Record the work involved:
- Who approved access or restoration?
- Which tool, query, ticket, or vendor request was required?
- How long did usable data take to arrive?
- Which fields or records were missing?
- Did the team need to rebuild an index or parser?
- What did storage, retrieval, transfer, and labor cost?
- Could a second person repeat the process from the documentation?
If nobody can retrieve an old event during a planned test, do not assume the process will improve during an incident.
Price the full data path
The renewal price may show ingestion and platform licensing while leaving half the cost elsewhere.
Build the cost model across collection, processing, searchable storage, archive storage, retrieval, data transfer, managed monitoring, and internal labor. Include duplicate destinations. The same event may land in a vendor portal, SIEM, cloud storage account, and data warehouse.
Look at each source in plain terms:
Keep it searchable when analysts use it for detection, triage, frequent investigations, or a requirement that needs fast access.
Move older data to archive when the source supports longer lookback but rarely needs immediate queries, and the retrieval test proves it can return in time.
Filter or transform it when a noisy source contains useful records mixed with low-value events. Preserve the fields and event types tied to a defined use case. Test the filter before removing volume.
Keep it outside the SIEM when the source platform provides adequate retention and access for the use case, the team can correlate it when needed, and the commercial tradeoff is clear.
Stop collecting it when nobody can name the decision it supports, the data has not been used, and no legal, contractual, insurance, or operational requirement applies.
Be careful with that last decision. “We did not use it last year” is not enough by itself. Rare incidents can still justify retention. The decision needs a named owner who understands the risk.
For a broader source and ownership review, use the logging and monitoring guide. If you are deciding whether the platform and staffing model still fit, revisit the SIEM evaluation guide. DNS evidence has its own path and attribution issues, covered in the DNS log export renewal test.
Ask vendors to price your design, not their default
Bring the source-level map to the renewal conversation. Ask the incumbent and any alternative provider to price the same design.
Your request should specify current volume by source, expected growth, filtering assumptions, searchable days, archive days, retrieval frequency, managed service scope, support, and termination rights. Otherwise, each vendor will optimize a different architecture and the quotes will not be comparable.
Ask these questions in writing:
- What event, data, asset, or capacity measure drives the bill?
- Which commitments, minimums, or volume bands apply?
- What happens when daily volume spikes or grows?
- Which retention tier is included in the quoted rate?
- What query, restore, transfer, or rehydration charges sit outside it?
- Can retention differ by source or table?
- Can the customer filter data before paid ingestion?
- Who monitors dropped events, connector failures, and archive jobs?
- What data and configuration can the customer export at termination?
- How long does post-termination access last?
Microsoft advises Sentinel customers to monitor ingestion volume and match commitment tiers to actual volume patterns. That is good buying discipline for any consumption-shaped proposal. Commitments can lower the unit price while making bad collection choices harder to unwind.
Do not negotiate the per-gigabyte rate before you decide which gigabytes deserve premium treatment.
Make one renewal decision per source
The final output should not be one yes or no decision for the SIEM. Give every source and tier a treatment.
Renew the current design where investigation value, access speed, coverage, and cost hold up.
Correct the configuration where a useful source is missing fields, sending noise, dropping events, or sitting in the wrong tier.
Resize the commitment where measured volume no longer matches the commercial band.
Archive older data where the retrieval test works and immediate search does not justify the premium.
Compare another platform, storage design, or managed service when the current provider cannot supply usable evidence at a defensible cost.
Use a short bridge instead of a long renewal when material source, retention, retrieval, ownership, or exit questions remain open near the notice deadline.
Write accepted changes into the agreement, order form, service description, responsibility matrix, and retention schedule. The security architecture and the commercial terms need to describe the same service.
A large retention number can look responsible while hiding weak coverage and expensive retrieval. Price the data your team can use. Prove the old records come back. Then sign the term.
If your SIEM, cloud logging, MDR, or managed security agreement is approaching renewal, request a Contract and Spend Risk Review. Bring the proposal, invoices, source inventory, volume exports, retention policy, archive design, investigation history, and one retrieval test. Catch Advisors will help you decide what stays searchable, what moves, what gets filtered, and what should be compared before the contract renews.