How to Design Smart Retention Policies in OpenCTI

Retention policies in OpenCTI are not just about saving disk space. They are a core part of keeping your threat intelligence knowledge base efficient and relevant. Without them, analysts drown in outdated indicators, irrelevant reports, and test data that create noise and disrupt the analysis.

In this article, we’ll walk through practical ideas for designing retention policies in OpenCTI, explain when to safely delete data, and highlight what should almost always be preserved, especially incident-related knowledge and PIR (Priority Intelligence Requirements).

TL;DR

• Retention policies keep your threat intelligence platform fast and relevant – without them, analysts drown in outdated indicators, stale reports, and test data that slow down search, correlation, and decision-making.
• Six ready-to-use policy templates cover the most common cleanup needs: low-confidence indicators, temporary observables, outdated public threat intel, import files, abandoned workbenches, and closed non-PIR reports.
• Always exclude incident-related and PIR-linked data – this knowledge carries legal, regulatory, and forensic weight and should be preserved regardless of age or source.
• Start conservatively and use the “Verify” button before activating any policy to preview impact and align with CTI, SOC, IR, and Legal teams before any data is deleted.
• OpenCTI is not your archive – for long-term or compliance-driven storage, offload older data to a data lake and keep only operationally relevant knowledge inside the platform.

Why Retention Policies Matter in Threat Intelligence

Threat intelligence platforms tend to grow fast. New connectors, feeds, and internal reports constantly add millions of observables and indicators, along with possibly overlapping threat actor profiles, intrusion sets, and campaigns. If nothing is ever removed, the consequences compound quickly: search and correlation slow down, analysts spend more time filtering noise than finding actionable signals, and storage costs climb, particularly for large on-premises deployments.

A well-structured retention strategy addresses all of this at once. It preserves what matters most (incident-related and high-value intelligence), removes what is temporary, low-confidence, or no longer relevant, and keeps the platform responsive and usable for both analysts and leadership.

What to Consider When Defining Retention Policies

Before jumping into technical rules, align on what is truly valuable for your organization. The most common candidates for cleanup are observables or indicators with low confidence or no meaningful labels, indicators that carry low risk or have been revoked through decay rules, reports not linked to Priority Intelligence Requirements or top threat actors, and intrusion sets or threat actors irrelevant to your sector, clients, or region.

From there, you can implement concrete retention policies in OpenCTI.

Below are six examples you can adapt:

1. Low-Confidence Indicator Cleanup

Scope: Knowledge | Retention: 365 days | Filters: Entity type: Indicator – Confidence level: less than 50 – Score: less than 20

Not all indicators carry the same value. Low-confidence, low-score indicators are often noisy and short-lived. If they are not updated or reinforced by new evidence, they quickly become clutter. A 365-day window gives you enough time to observe their usefulness; after that, if they haven’t been enriched or referenced, they can be safely removed. This policy helps ensure analysts stay focused on higher-quality, better-validated signals.

Note: The number of retention days in all the examples can vary according to your organization’s regulations and internal processes.

2. Temporary Observables Cleanup

Scope: Knowledge | Retention: 90 days | Filters: Entity type: Observable (IPv4, Domain, URL) – Labels: temporary or test (example)

During investigations, testing, or POC activities, teams often create observables that serve triage or validation purposes but were never meant to become part of the long-term knowledge base. By labeling them consistently (for example as temporary or test) and applying a 90-day retention rule, you give analysts enough time to complete their work while preventing disposable data from polluting the platform. It’s a simple habit that pays off quickly, as long as label usage is enforced from the start.

3. Outdated Threat Intelligence (Non-PIR/Incident Related)

Scope: Knowledge | Retention: 365 days (extendable to 3–5 years depending on compliance needs) | Filters: Entity type: Intrusion Set, Threat Actor, Campaign, Malware – Marking: TLP:WHITEor TLP:CLEAR – Exclude: anything related to Incidents or PIRs

Publicly sourced intelligence about campaigns or malware families is useful for trend analysis but becomes less operational over time. For many organizations, keeping this type of high-level information beyond compliance requirements offers limited value when it isn’t tied to an active incident or PIR. The critical element of this policy is the exclusion: any entity linked to an incident or PIR should never be touched, since that data typically carries legal, regulatory, and forensic weight and may be needed years down the line. For everything else, a one-year default strikes a reasonable balance between historical context, regulatory compliance, and avoiding the endless accumulation of generic public intelligence no one is actively using.

4. Import Files Cleanup

Scope: File | Retention: 365 days (OpenCTI default) or shorter (7–30 days, based on your needs)

Import files are valuable during ingestion, troubleshooting, or audits — but once successfully imported and validated, organizations rarely need to retain them long-term inside OpenCTI. A time-bound cleanup frees storage space, reduces clutter in the file management section, and limits the risk of keeping sensitive raw files longer than necessary. If you operate under strict audit requirements, align this period with those expectations or export files to a controlled archive before deletion.

5. Workbench Cleanup

Scope: Workbench | Retention: 60 days

Workbenches are powerful collaborative spaces, but many are created for short-lived tasks, validating newly imported data, triaging a lead, and then simply abandoned. A 60-day retention window for untouched workbenches keeps the interface clean and focused on active work, encourages analysts to properly incorporate objects into cases, incidents, or reports rather than leaving them in limbo, and reduces confusion in shared environments where multiple analysts are working in parallel.

6. Reports Not Related to Incidents/PIRs

Scope: Knowledge | Retention: 2–3 years | Filters: Entity type: Report – Report type: News – Status: Closed – Exclude: reports related to Incidents, Cases, or PIRs

News-type reports are snapshots of a moment in time. They support situational awareness and communication, but their operational relevance fades as the threat landscape evolves. Keeping closed, non-incident news reports for two to three years strikes a reasonable balance: long enough to support trend analysis and historical reference, short enough to prevent stale content from accumulating indefinitely. As with other policies, incident-related reports should be preserved beyond this window whenever internal policies or legal obligations require it.

Critical Steps When Implementing Retention Policies

Start Conservatively and Use “Verify”

When defining retention policies in OpenCTI, always begin with conservative periods. Use the “Verify” button before activation to see exactly which data would be affected. This gives you the opportunity to validate your assumptions with CTI, SOC, IR, and Legal teams, catch accidental deletions of valuable or regulated data before they happen, and fine-tune filters and retention periods in a safe, reversible way.

Offload to a Data Lake for Long-Term Storage

Retention in OpenCTI should favor operational relevance and performance, it does not need to be your eternal archive. For long-term or regulatory storage, consider exporting older data to a data lake or separate archival system, keeping only essential and active knowledge inside OpenCTI, and ensuring that compliance and audit teams know exactly where full historical data lives. This approach lets you satisfy strict retention requirements without degrading platform usability.

Preserve Incident-Related and High-Value Knowledge

One principle should guide every policy you design: protect incident-related data and high-value intelligence. When building filters, always account for incidents and all entities linked to them, PIR-related intelligence, and data held for legal, regulatory, or contractual obligations. Your retention strategy should be aggressive about cleaning up noise while remaining very cautious about anything tied to real compromises, active investigations, PIRs, or business-critical decisions.

Conclusion and Next Steps

Well-designed retention policies in OpenCTI help you keep your environment clean, performant, and focused on what really matters: high-quality, actionable threat intelligence that supports your operations and compliance needs. In this article, we covered how to clean up low-confidence indicators and temporary observables, manage outdated public threat intelligence, handle import files and stale workbenches, and control the lifetime of non-incident, non-PIR reports.

I hope this helps you structure or refine your own retention strategy. If you want to go further, join our community Slack to exchange with other OpenCTI users on how they handle retention and data lifecycle, and explore our documentation and related blog posts on OpenCTI data modeling, incident management, and connector strategies to build an end-to-end, sustainable CTI practice.

Enjoy and feel free to ask any questions about it on our Slack community channel !