How OpenCTI case management fits incident response
Yes, OpenCTI can serve as the place where a threat intelligence team tracks investigations, requests for information and takedown requests, as long as the case types and templates in your chosen release match the workflow your team already runs. The main value is linkage. A case tied to the indicators, malware, reports and threat actors already stored in the platform keeps the analyst's context in one place instead of splitting it between a spreadsheet, a ticket queue and a shared drive. OpenCTI structures its data with a knowledge schema based on the STIX2 standards, so those objects are first-class records that work can reference directly.
In general terms, cases group related work, tasks assign individual steps to people, and templates standardize work that repeats, such as a takedown request sent to a hosting provider. Together they let teams attach work to intelligence objects so that anyone opening the object can see which cases touch it. Before you commit to a design, confirm the exact case types, task fields, template contents and whether templates can be edited, against the release you plan to deploy. OpenCTI uses date-based version numbers and ships non-LTS releases often, so these details should be verified in your own pilot rather than taken from a summary. Decide early who owns each case type and who may close it.
OpenCTI is best understood as the intelligence context layer. Containment, forensic evidence handling, chain of custody and response actions usually belong in a dedicated incident response platform or ticketing system. OpenCTI documents integrations with TheHive and MISP, and the MITRE ATT&CK framework can be loaded through a dedicated connector. Confirm the current versions of any connector you plan to use and the exact data each direction carries, including whether case references, observables and status changes move in both directions. Then record which system is the system of record for each artifact, so that analysts do not update the same fact in two places.
Plan a pilot that tests the workflow before rollout. Map each case type to the intelligence objects it needs, confirm through the GraphQL API that your reporting or downstream tools can read case links, and test permissions for any external party, such as a takedown provider, who should see only part of a case. Check which features you need are available in the Community Edition and which fall under the Enterprise Edition license, because the Enterprise Edition adds capabilities such as organization-based data segregation and priority intelligence requirements. Ask Filigran or check the Enterprise Edition documentation to confirm the case capabilities you depend on, and write those answers into your design record.
Which OpenCTI case management options fit your team
This table compares the case choices a team makes before running incident response, RFI and takedown work in OpenCTI: case types, task templates, who may open or close cases, and where case records live. Read each row by checking whether the option fits your team size and sharing model, then check the admin effort and whether it depends on Enterprise Edition features. Items marked as questions for Filigran need confirmation against your installed version before you commit.
| Decision | Option | When it fits | Admin effort and license dependency |
|---|---|---|---|
| Case type for incident response | Incident response cases in OpenCTI | Teams that want intelligence linked directly to each incident and its related objects | Moderate: define stages and fields once. Ask Filigran which case types your version provides. |
| Case type for RFI and takedown work | Separate case types for RFIs and takedowns | Teams handling external requests or takedowns with different owners, deadlines and close criteria | Low to moderate: one template per type. Confirm whether these types are available in Community Edition. |
| Task and template standardization | Shared templates with fixed task lists | Recurring case types where steps must follow the same order every time | Moderate upfront, low later. Review templates after each upgrade, since task behavior can change between releases. |
| Who may open or close cases | Open access for all platform users | Small teams with high trust and few users who touch cases | Low setup effort, but no per-case control. Confirm the default permissions in your version. |
| Who may open or close cases | Authorized members per case | Shared or regulated deployments where case access must be limited to named people | Requires Enterprise Edition. Plan membership rules and schedule regular access reviews. |
| Separation between teams or customers | Organization-based data segregation | Several business units, clients or partners sharing one OpenCTI instance | Requires Enterprise Edition. Design the organization model before cases and intelligence are imported. |
| Where case records live | Keep cases inside OpenCTI | Teams that want intelligence and case history in one place with fewer tools to run | Low ongoing effort. Confirm that approval, reporting and SLA needs are met by case features alone. |
| Where case records live | Export cases to a dedicated incident response platform | Teams with an established IR platform for ticketing, approvals and formal reporting | Ongoing effort to maintain field mapping, sync rules and duplicate handling. Ask Filigran which export formats are supported. |
Where OpenCTI cases end and a dedicated incident response platform begins
OpenCTI cases are best understood as a way to organize intelligence-led work: incident response, request for information and takedown cases that link back to threat actors, campaigns, indicators and reports already in the knowledge graph. A dedicated incident response platform takes on a different job. It pages responders, records who handled each piece of evidence and when, drives containment actions against endpoints or accounts, and produces the post-incident report. The boundary matters because the two tools carry different obligations. Before you standardize on one, decide which of those obligations your team must meet inside the case record itself, and which can be handled by another system.
In the OpenCTI deployment you plan, check what a case object actually gives you: its tasks, its linked entities, its templates and who can see or edit it under your access model. Confirm whether the case workflow covers the operational detail your responders need, such as timeline entries from forensic work, approval steps before containment, or a retained audit trail for each change. OpenCTI's native audit logging and organization-based segregation are Enterprise Edition features (OpenCTI Enterprise Edition docs), so confirm with Filigran and your own requirements whether those controls are in scope for your license tier before assuming they cover incident handling.
OpenCTI integrates with tools such as MISP and TheHive (OpenCTI GitHub README). Treat any such link as a design decision to confirm, not a default you inherit. Ask which connector or integration you would run, which direction data flows, whether observables and indicators are synchronized or only referenced, which system is authoritative for case status, and who maintains the connector when versions change. Each synchronization path adds a failure mode, such as duplicate records, stale status or a case closed in one tool and open in the other, so the design should name an owner for every field that appears in both places.
Use these questions to choose between three options. Keep cases in OpenCTI if incidents are mostly intelligence-led, the team is small, and your regulators or customers do not require separate evidence custody or containment logs. Link to a separate incident response tool if you need paging, formal chain of custody for evidence, containment actions with approval gates, or structured post-incident reporting that your process owners already use. Run both if intelligence analysts work in OpenCTI while responders work in another platform, but only after you have defined the handoff point and the fields that must match. Ask: Who is paged, and from which system? Where is the evidence stored, and who can prove what was touched? Which system records containment? Who writes the final report, and where is it retained? Which team owns each integration after go-live?
Scope the decision before you build anything. An illustrative example: a team that receives takedown requests and writes threat briefings may keep those cases in OpenCTI with tasks and templates, while a separate platform handles live intrusions. Document that split in a short runbook, test the handoff with a tabletop exercise, and confirm with your own compliance owner which records must be retained and for how long. The most common gap is not a missing feature but an unnamed owner for the boundary.
Setting up OpenCTI case management with checks
This sequence takes a self-hosted OpenCTI instance from an agreed release and license decision to a case workflow the team has tested end to end. Each step closes with a check against the documented minimums or the designed behavior. The platform, data and access decisions stay in your infrastructure and with your team.
Confirm the release line and license needs
The platform owner and the security lead agree on the release line before anything is installed. Compare a regular release with an LTS release: LTS builds require a specific LTS license key and receive only critical bug and security fixes after a one-month stabilization. List each feature the case workflow depends on, such as SSO, organization segregation, audit logs and playbooks, and check each one against the Enterprise Edition documentation. Confirm license terms directly with Filigran. Done when a signed decision record lists the version, the license type and any Enterprise features in scope.
Size the platform and its dependencies
The infrastructure owner sizes each component against the documented minimums before ordering hardware or cloud capacity. The platform needs at least 2 cores and 8 GB of RAM, and Elasticsearch or OpenSearch needs at least 2 cores, 8 GB of RAM and 16 GB of SSD storage. Plan at least one platform node for every 3 workers. Confirm the search engine is Elasticsearch 8.0 or later or OpenSearch 2.9 or later, Redis 7.1 or later, RabbitMQ 3.11 or later, and an S3-compatible store such as MinIO. These figures are starting points, so confirm capacity against your expected case and indicator volume. Done when the sizing sheet cites these minimums and each target version is checked against the vendor documentation.
Deploy the dependencies and platform
The platform engineer deploys the search engine, Redis, RabbitMQ and object storage, then deploys OpenCTI, all inside your infrastructure. Workers consume RabbitMQ messages for asynchronous writes, so confirm that the workers can reach both RabbitMQ and the platform before any testing. Set connection settings to the versions validated in the previous step. Done when every service reports healthy, the web application loads, the GraphQL API answers requests, and a test write passes through the queue and appears in the platform.
Configure authentication and a break-glass account
The identity team configures the sign-in method before case work begins. Since OpenCTI 7.260224.0, defining and using authentication strategies, including SSO, requires the Enterprise Edition, so confirm which strategies your version allows under your license. Create one local administrator account for recovery, store its credentials in your secrets vault, and record who may use it. Done when a test account signs in through each intended method, a disabled user is refused access, and the break-glass account works while SSO is unavailable.
Define case types and templates
The incident response lead and a CTI analyst define one case type for each workflow the team runs, such as incident response, request for information and takedown. For each type, set the fields that must be completed, the default tasks, the owner of each task, and the kinds of objects expected to link to the case, such as indicators or observables. Keep templates short so analysts complete them. Done when a case created from each template shows the expected fields and default tasks, and the owners match the design.
Set roles, access and segregation
The security lead maps each team to a role that controls who can create, edit, assign and close cases, and who can see their contents. Where teams or customers must not see each other's cases, confirm that organization-based data segregation is available in your edition, because it is an Enterprise Edition feature. Document the mapping so reviewers can trace each permission to a team decision. Done when test accounts for each role attempt create, edit, assign and close actions, unauthorized actions are refused, and cases outside a team's scope do not appear in its lists.
Connect the connectors that feed cases
The CTI engineer lists the sources that should reach cases, such as the MITRE ATT&CK connector for technique data or feeds shared with MISP or TheHive. Check each connector's documentation for supported versions and required settings. Enable one connector at a time, set its scope so it imports only the objects the cases need, and confirm that its import completes. Done when each connector reports a running state, the expected objects appear, and repeat runs do not create duplicate objects.
Run a test case through its full life
The incident response lead runs a test case in a non-production instance using illustrative data only. Create the case from its template, add tasks, link indicators and observables, assign an owner, move the case through its statuses, and then close it. Check that task status updates as designed, that each linked indicator shows the link back to the case, and that the history records each change. Repeat the run for the request for information and takedown types. Done when every behavior matches the design and any defect is logged with a named fix owner before production use.
Security and operational considerations for OpenCTI cases
Case data in OpenCTI carries the same sensitivity as the intelligence and correspondence it references, so controls need to be planned before a team works live cases. The cards cover access, identity, auditing, files, recovery and separation. Several depend on whether your deployment uses the Enterprise Edition, so confirm licensing alongside each control.
Access control on case data
Case visibility can interact with the visibility of the reports, indicators and observables linked to it, so a case may expose more intelligence than its title suggests. Decide which teams may read, edit, close and export incident response, RFI and takedown cases before loading live data. Map those rights to groups from your identity provider, and test them with a non-privileged account. Confirm exactly how case permissions and linked-object permissions combine in your version.
Local, LDAP and SSO authentication
OpenCTI supports local users and LDAP, along with SAML, OpenID Connect and other strategies. Since OpenCTI 7.260224.0, defining and using authentication strategies, including SSO, is an Enterprise Edition feature, so an SSO requirement for case handlers affects the license decision. Local accounts remain a fallback to plan for, including how they are created, disabled and reviewed when a responder leaves. Confirm which strategy your identity provider supports before the pilot.
Audit trail and activity monitoring
Case work produces evidence of who viewed, changed or closed a takedown or RFI case, and an internal or external review may ask for it. Enterprise Edition adds activity monitoring and audit logs, so a regulated team should decide whether that license is required or whether logging from the platform, reverse proxy and identity provider meets the review need. Confirm log retention, who may read the logs, and how they reach your SIEM.
Attached files and object storage
OpenCTI depends on S3-compatible object storage, such as MinIO, so attached files need a storage plan of their own. Attachments such as phishing samples, screenshots and vendor correspondence may contain malicious content or personal data. Restrict bucket access to the platform service account, enable encryption at rest in your storage layer, and review who can download files directly. Confirm which case attachments are stored there and whether any file-extraction connector processes them.
Backups of database and object storage
Case records reference attached files, so restoring the database without the matching object storage leaves broken references, and the reverse leaves orphaned files. Back up the database and object storage on one schedule or at a documented consistency point, then test a full restore into a separate environment. Confirm which components must be backed up and which can be rebuilt, including the search index and the queues used for asynchronous writes. Agree recovery objectives for case data with the business owners.
Separating takedown and RFI material
Takedown requests and requests for information often contain partner data, legal correspondence and personal data that most analysts should not see. Decide whether these cases live in a separate instance, a separate organization or a restricted group, and document who may export them. Confirm whether your license includes organization-based data segregation. Avoid copying sensitive material into general reports, shared templates or broadly visible tasks.
Running RFI and takedown cases day to day
The day-to-day question is who opens a case, who works it, and who decides when it closes. Before go-live, name these roles in a short runbook. A requester raises a request for information (RFI) or a takedown request, usually with the indicators, the business reason and the urgency. A case owner triages it, sets the priority and assigns it. Analysts carry out the work, and a reviewer approves any outbound message to an external party before it leaves. Agree who can change a case's status, since an unclear owner is the most common reason cases stall without anyone noticing.
Analysts break each case into tasks, such as confirming indicators, collecting screenshots and passive DNS records, requesting data from a partner, and drafting the external message. Keep one task per action so progress is visible to the owner. Attach evidence to the case itself, not to personal folders, and write notes as dated, factual statements that another analyst could follow. If your version offers case templates, use them for recurring RFI and takedown types so the standard tasks appear automatically. Confirm in your version how templates, task assignment and evidence attachments behave before you rely on them.
Takedown requests depend on an external party, so track each one as its own thread. Record the hosting provider, registrar or platform contact, the date the request was sent, the reference number returned and the expected response time. Create a follow-up task for each external party instead of relying on memory. Move the request through clear states such as requested, acknowledged, actioned and verified. Verification means your analyst re-checks the artifact and saves the result as evidence. Where legal or policy sign-off is required, make it a task with a named approver so it cannot be skipped silently.
Review open cases on a fixed cadence, such as a standing weekly meeting or a daily queue check, depending on your volume. The owner checks overdue tasks, missing evidence and external responses that have not arrived. Closure should follow written criteria: all tasks complete, outcome recorded, external confirmation attached, and indicators updated with the labels your team uses. Confirm whether closing a case keeps its linked objects and what audit trail remains afterwards. Activity monitoring, audit logs and organization-based segregation are Enterprise Edition features, so check your license if you need them for a regulated or shared deployment.
Upgrades can change how in-flight cases behave, so inventory open cases and pending takedowns before any upgrade and take a verified backup. OpenCTI regular releases use date-based version numbers in the form x.YYMMDD.z, for example 7.261016.0. LTS releases use the form x.YYMMDD.z-lts.n, require a specific LTS license key, and after a one-month stabilization period receive only critical bug and security fixes. Plan LTS adoption with that in mind, and confirm your license entitlement with Filigran before you start. Test the upgrade in a staging copy of your data, and check that open cases, templates and tasks render and transition correctly before you upgrade production.
Limits to confirm before you rely on OpenCTI cases
OpenCTI case management depends on features that vary by edition, version and deployment size. Each card names one limit to confirm with Filigran or in a test environment before incident response, RFI and takedown runbooks depend on it.
Case types and task features by edition
Case, task and template features differ between the Community Edition and the Enterprise Edition, and the Enterprise license covers several governance capabilities. Ask Filigran for a written feature list covering case types, task options and template functions in both editions at the exact version you plan to deploy. Then confirm each item in a test environment before you design runbooks around it.
Template sharing across organizations
Incident response, RFI and takedown templates may need to serve several teams or partner organizations. Sharing across organizations depends on how the platform segregates data, and organization-based segregation is listed as an Enterprise Edition capability. Ask Filigran whether a template can be shared, copied or scoped to one organization, then test a handover between two organizations using a user from each side.
Audit retention for case history
Regulated teams often need to show who changed a case or task, what changed and when. OpenCTI Enterprise Edition lists activity monitoring and audit logs, so confirm what the Community Edition records for cases at all. Ask Filigran which case and task events are logged, how long records are kept, whether they can be exported to your log platform, and whether deleted content remains traceable.
Case volume on the chosen sizing
OpenCTI's documented sizing starts the platform at 2 cores and at least 8 GB RAM, with Elasticsearch or OpenSearch at 2 cores, 8 GB RAM and 16 GB SSD, plus at least one platform node for every 3 workers. These minimums do not show how many open cases, tasks and attachments a team can handle. Load test with volumes drawn from your own incident history, and measure search and case page response times before go-live.
Takedown workflows and external tools
Takedown work often involves hosting providers, registrars and platforms outside your organization, with requests tracked to closure. Confirm whether OpenCTI can record takedown status, contacts and evidence natively, or whether you need an external ticketing or notification tool. If playbooks will open cases or notify teams, confirm the Enterprise Edition license requirement, then test a full takedown lifecycle end to end.
Login methods and case access
Case access depends on how users sign in and which organization they belong to. Authentication strategies, including SSO, became an Enterprise Edition feature in OpenCTI 7.260224.0, so confirm which login methods your edition supports for case handlers. Also ask Filigran whether case visibility can be limited to named teams and how access is removed when someone leaves. Test with two accounts from different teams.
What OpenCTI case management costs and who does the work
What drives the cost of OpenCTI case management?
The main cost drivers are the edition license, the infrastructure the platform runs on, the integration scope, and the number of workflows and templates you need. Community Edition is licensed under the Apache License 2.0, while Enterprise Edition uses a proprietary license from Filigran, so confirm with Filigran which features your case processes depend on before you choose an edition. Infrastructure is the next driver: OpenCTI depends on Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage, all of which run in your environment. Each connector to a ticketing, mail or SOAR tool adds build and test effort, and each additional workflow or template adds design and review time. Ask for a quote that prices each of these separately.
Which OpenCTI costs are one-time and which recur?
Platform setup, case templates, integrations and acceptance testing are one-time work, usually delivered as a fixed-scope engagement agreed in writing before work starts. Recurring costs include Enterprise Edition license fees if your case processes need them, which Filigran quotes directly, plus hosting and storage in your cloud account or data center. Upgrades across releases and any support retainer also recur. The Community Edition is licensed under the Apache License 2.0, so its recurring costs are infrastructure, staff time and any services you buy. LTS releases require a specific LTS license key, so confirm whether your chosen line needs one and when renewal falls. Ask the quote to show one-time work and each recurring line separately so you can compare the second and third years, not only the first invoice.
How long does OpenCTI case management setup take?
Duration depends on scope, and no single timeline applies to every deployment, so ask for one in the written scope. One team using a single case type with few integrations is a much smaller job than several case types, multiple connectors and SSO that must be planned with your identity team. The work typically runs in sequence: infrastructure readiness, platform and dependency deployment, case design and templates, integration and testing, then handover. Infrastructure access and approvals often set the pace more than build work does. Ask the proposal to show each phase, the client dependencies inside each phase, and the acceptance tests that close it.
What must our team provide before OpenCTI setup starts?
Your team provides four main inputs. Infrastructure access: cloud accounts, data center or air-gapped network access, and hosting for the platform and its dependencies. Defined case processes: the incident response, RFI and takedown steps, with stages, roles and handoffs written down. Named approvers: people who sign off the design, access model and go-live. Test data: sample cases that reflect your real case shapes without exposing sensitive material. If you plan to use SSO, add a contact from your identity team who can confirm the protocol, claims and group mapping. Missing any of these usually moves the schedule, so confirm owners and dates before the build phase begins.
Can an internal team set up OpenCTI case management alone?
Yes, if your team has the skills and time, though few teams hold all of them at once. The work spans Linux and container operations, Elasticsearch or OpenSearch administration, message queue operations, identity integration, STIX2 data modeling and incident response process design. Check these against your team. Someone must own platform upgrades, including LTS license keys and database migrations, and someone must run backup and restore tests. A partner adds the most value where capacity is short or where no one owns design decisions. In either case, settle who owns the case processes first, because tooling cannot decide who approves a takedown.
How do I get a quote for OpenCTI case management?
DeployOpen does not publish a price list, and a quote follows from a written scope. Most engagements are fixed-scope, so the scope, deliverables and timeline are agreed in writing before work starts. A useful scope lists the target environment, the Community or Enterprise edition decision, the number of case types and templates, each connector and integration, the SSO approach, testing and handover, and any ongoing retainer. Ask the quote to state its assumptions and exclusions, along with the client inputs it depends on. Filigran license quotes are separate from DeployOpen's quote, so request both before comparing options.
Does the Enterprise Edition license change the project cost?
It can, and the answer depends on which features your case workflow uses. Filigran documents Enterprise Edition features that include playbooks, activity monitoring and audit logs, organization-based data segregation, and SSO configuration. Since OpenCTI 7.260224.0, defining and using authentication strategies, including SSO, is an Enterprise Edition feature. Confirm with Filigran which capabilities your case design requires, and record that dependency in the written scope. Filigran offers trial licenses and free licenses for development, research and non-governmental organizations, which may help during evaluation, but confirm eligibility directly with Filigran.
How DeployOpen scopes and supports OpenCTI case management
DeployOpen plans and deploys OpenCTI in infrastructure you control, then configures case workflows for incident response, RFI and takedown work around your team's roles and handoffs. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing support, upgrades and testing are available as retainers.
How we scope
- The written scope names which case types, such as incident response, RFI and takedown, are in use.
- Scope also covers case templates, task lists, roles and the teams that open and close cases.
- Edition choices are confirmed up front, because some features you need may require the Enterprise Edition license.
How we build
- Deploy the platform with its dependencies: Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage.
- Configure case templates, task workflows and access groups, then test them with sample cases before go-live.
- Connect the workers and connectors your intake sources need, and verify each data path end to end.
How we hand over
- Written runbooks covering case templates, role assignments, connector configuration and day-to-day operations.
- A verification record showing test cases run, results and any open issues at handover.
- Administrator training for the team that will maintain templates, users and integrations after go-live.
How we support
- Upgrade planning that follows OpenCTI's regular and LTS release lines, including the LTS license key requirement.
- Retainers for ongoing maintenance, upgrades and continuous testing, if your team wants them.
- Confirm with your incident response platform owner which workflows stay there and which stay in OpenCTI.
