Should organisations optimise token cost before fixing log quality?

No. Token cost matters only after the data is trustworthy enough to support a correct decision. If raw logs still need heavy parsing and context reconstruction, cheaper prompts simply make the wrong answer cheaper to produce. Fix normalization, enrichment, and correlation first.

Why This Matters for Security Teams

Token spend is visible on a dashboard, so it is easy to treat it as the primary optimisation target. In practice, however, low-cost prompting over incomplete or inconsistent telemetry usually creates false confidence, not better operations. Security teams need logs that are normalised, enriched, and correlated before they can expect reliable triage, detection engineering, or AI-assisted analysis. That aligns with the broader control intent of the NIST Cybersecurity Framework 2.0, which prioritises governance, detection, and response outcomes over isolated efficiency metrics.

The practical risk is that a team may cut token usage while preserving ambiguity in the data path. That usually shifts effort downstream into manual investigation, duplicated queries, and repeated model calls that try to reconstruct missing context. For SOC operations, the real question is not whether an LLM can summarise logs cheaply, but whether the underlying events are trustworthy enough to support action. If the data model is weak, every “optimised” prompt becomes a form of hidden rework.

In practice, many security teams discover this only after the first major investigation has already required analysts to rebuild the timeline by hand, rather than through intentional data engineering.

How It Works in Practice

The better sequence is to improve log quality first, then tune token usage around a stable workflow. Start by making sure events are parsed into a consistent schema, key fields are mapped correctly, and high-value context such as user, host, asset, session, and identity information is attached before the data reaches an AI workflow. If a model is expected to identify suspicious behaviour, it should not have to infer basic structure from raw text that varies across sources.

That approach also improves reliability across incident response and detection use cases. The CISA resources and tools catalogue reflects the same operational reality: usable security data depends on collection quality, coverage, and consistent handling. For AI-assisted SOC workflows, the aim is to reduce unnecessary context reconstruction, not to strip away signal that the model still needs.

• Normalise fields before prompt construction so the model sees consistent event names and timestamps.
• Enrich logs with asset, identity, and threat context so correlation does not depend on inference alone.
• Deduplicate noisy events to cut repeated processing without removing evidence needed for investigation.
• Set output validation rules so summaries, detections, and recommendations can be checked against source data.
• Measure analyst time saved, alert precision, and investigation quality, not token cost in isolation.

This is especially important when logs come from cloud services, identity providers, endpoint tools, and application telemetry that each use different schemas and retention behaviours. Where AI is involved, the operational goal is to feed models a coherent evidence set rather than ask them to stitch together fragmented records. These controls tend to break down when telemetry is siloed across multiple platforms and event schemas cannot be mapped consistently because the model then spends its budget reconstructing context instead of analysing it.

Common Variations and Edge Cases

Tighter token control often reduces cloud spend, but it also increases the risk of losing investigative context, requiring organisations to balance cost savings against detection quality. In some mature environments, once data is already well-structured, token optimisation can be a sensible second-order improvement. Current guidance suggests that this is an operational tuning step, not a substitute for data engineering or log governance.

There are a few edge cases worth calling out. If logs are already high fidelity and the use case is limited to short classification tasks, token reduction may be low risk. If the workflow touches regulated records, identity events, or incident evidence, the cost of truncation can be much higher than the savings from smaller prompts. If teams use retrieval-based pipelines or agentic workflows, the more relevant question may be whether the retrieval layer is selecting the right evidence, not whether the model consumes fewer tokens.

For organisations building AI-assisted security operations, the main design choice is sequencing. Fixing log quality first creates reusable value across SIEM, SOAR, and detection engineering; optimising token cost first usually improves only the prompt bill. Best practice is still evolving for autonomous or semi-autonomous analyst agents, but the operational principle remains consistent: trustworthy inputs before cheap outputs. The same principle underpins the NIST Cybersecurity Framework 2.0, which ties value to outcome quality rather than standalone efficiency.

Related resources from NHI Mgmt Group

• Should organisations prioritise token controls before expanding SaaS access?
• Should organisations replace VPNs before fixing privileged access governance?
• Should organisations optimise authorization engines before changing policy design?
• What should organisations do before certifying a data product based on quality scores?