Which is the right fit for a CTI team or a DFIR team
Choose OpenCTI when the work is shared threat intelligence. If your team needs to model adversary activity as STIX-based entities and relationships, keep that knowledge current across analysts, and pull in feeds through a connector ecosystem that includes MISP, MITRE and CVE connectors, OpenCTI is built for that workload. Its Apache-2.0 Community Edition covers the core data model and GraphQL API, but the controls a multi-team CTI function often asks for first (SSO through OpenID, LDAP or SAML, audit logs, playbooks and automation, and organization segregation) require an Enterprise Edition license. Confirm those gates with Filigran before you assume the Community Edition meets your access or audit requirements.
Choose Yeti when the work is forensic investigation. If your analysts start from a host, an artifact or an alert and need to bulk search observables, map a threat to its TTPs, malware and forensic artifacts, or store DFIQ objects, Sigma and YARA rules alongside indicators, Yeti is aimed at that workflow, with Timesketch and MITRE ATT&CK integration. It is also Apache-2.0 and is built on Python, FastAPI and ArangoDB. Yeti is not designed as a community sharing hub between organizations, so if you need to exchange indicators with partners, that requirement points back toward MISP. Ask the Yeti maintainers to confirm which features you would need beyond the open-source release before you plan around them.
Three questions usually decide it. First, who are the users: if most of them write reports and track actors, OpenCTI's model fits; if they investigate incidents and hunt on endpoints, Yeti's artifact and rule handling fits. Second, how much infrastructure will you run: OpenCTI depends on Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage, plus workers and connectors, so size that stack against your platform team's capacity before committing. Third, do you need SSO, audit logs or playbooks from day one: if yes, price the Enterprise Edition into the decision now, and if a Yeti-based stack covers your DFIR needs, confirm its authentication options in the release you deploy, since the 2.12.0 release added an access token exchange endpoint that is disabled by default.
Which platform fits which team scenario
This table maps common team scenarios to the platform that usually fits better, with the reason and the condition that would reverse the choice. Read each row against your own team's mandate, staffing and compliance obligations, because the better fit depends on whether the work centers on strategic intelligence or case-level forensics.
| Scenario | Better fit and reason | When the other platform is the better choice |
|---|---|---|
| A CTI team consolidating many feeds into one graph | OpenCTI. It organizes intelligence as STIX-based entities and relationships and imports feeds through a connector ecosystem that includes MISP, MITRE and CVE connectors. | Yeti if the feeds mainly serve DFIR hunts on specific observables and the team does not need a shared STIX graph across analysts. |
| A DFIR team enriching case observables | Yeti. Analysts can bulk search observables and pivot from a threat to its TTPs, malware and forensic artifacts, with Timesketch and MITRE ATT&CK integration. | OpenCTI if the enrichment work must feed a broader STIX knowledge graph shared with CTI analysts and other tools. |
| A team that needs SSO and audit logs from day one | OpenCTI, but only with an Enterprise Edition license. OpenID, LDAP or SAML SSO and audit logs are gated behind that license. | Yeti if your SSO requirement can be met through its Google token exchange endpoint, which is disabled by default and must be reviewed before use. Confirm the audit and access control model with the vendor before relying on it. |
| A team that must share indicators with other organizations | Neither is the primary choice. Yeti is aimed at DFIR and analyst work rather than community sharing between organizations, so a sharing platform such as MISP is the more natural fit. | OpenCTI if sharing means structured exchange through its connectors and you accept the Enterprise Edition license needs for organization segregation. |
| A small team with limited platform operations capacity | Yeti for a narrow DFIR scope, because it is a single Python and FastAPI application backed by ArangoDB. Confirm its operational footprint with the maintainers for your expected volume. | OpenCTI only if the team can run its dependencies, which include Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage, plus the sizing the documentation recommends. |
| A team running a formal CTI program with governed workflows | OpenCTI, because playbooks, automation and organization segregation are Enterprise Edition features that support governed, multi-team workflows. | Yeti if the program is primarily hunting and case work and an Enterprise Edition subscription would not be justified by the workflow needs. |
| A team that needs machine-readable exports for SIEM and DFIR tools | Yeti, which supports custom export formats for third-party tools so analysts do not hand-write exports for each target. | OpenCTI if exports are mostly STIX-based and your downstream tools consume STIX natively. Confirm the export connectors you need. |
How OpenCTI and Yeti are built and what that means for operations
OpenCTI is a multi-service platform whose health depends on several external data and messaging components. Yeti is a smaller Python stack built on FastAPI and ArangoDB. The cards below set out what each design asks of the team that upgrades, monitors and keeps it running.
Stateless platform with GraphQL API
OpenCTI's platform serves the web application and a GraphQL API, and it keeps no state of its own; the data lives in the search and storage layers around it. That makes the platform tier easier to scale and restart, but it also means that a healthy-looking platform can still be failing if its backing services are not. Monitor the platform's API and UI response separately from the health of Elasticsearch or OpenSearch, Redis, RabbitMQ and storage, and confirm with Filigran how the platform nodes should be sized for your expected load.
Python workers and connectors
Writes in OpenCTI are asynchronous: Python workers consume messages from RabbitMQ, and connectors handle import, enrichment, file extraction, export and stream consumption. Each connector is a separate process you may need to configure, upgrade and watch. For a team that plans to pull in MISP, MITRE and CVE feeds, the number of connectors becomes the main operational variable, and each one needs its own health check and log review.
Search, cache, queue and object storage
OpenCTI depends on Elasticsearch 8.0 or later or OpenSearch 2.9 or later, Redis 7.1 or later, RabbitMQ 3.11 or later and S3-compatible storage such as MinIO. Each dependency has its own version support, backup routine, patch cycle and capacity planning. Before committing, check which of these your platform team already operates, since running four additional stateful services is often the largest effort in the deployment.
Upgrade cadence and LTS licensing
OpenCTI ships non-LTS releases from daily to weekly, while LTS builds arrive every six months and are supported for one year. LTS builds require a specific LTS license key and receive only critical and security fixes after stabilization. Plan upgrades against the release line you choose, and test the dependency versions each release requires before you apply it to production.
Python, FastAPI and ArangoDB base
Yeti is built in Python with FastAPI and stores its data in ArangoDB, so the team needs skills in Python service operations and in running an ArangoDB instance. Its footprint is a smaller set of components than OpenCTI's, but ArangoDB is a less common database in many operations teams, so its backup, upgrade and monitoring practices should be confirmed before adoption. Ask the vendor for Yeti's supported deployment topology, resource sizing and high availability options, because these are not covered in the sources used here.
Capabilities side by side: data model, extensibility, identity and licensing
This table compares OpenCTI and Yeti on license, data model, integrations, APIs, single sign-on and release cadence. Read each row as a question about your own requirements, and treat any cell that says to confirm as an open item for your evaluation.
| Capability | OpenCTI | Yeti |
|---|---|---|
| License | Community Edition under Apache-2.0. Enterprise Edition files fall under a separate proprietary license and need a paid subscription. | Apache-2.0 for the platform. No separate paid edition was identified in the supplied material, so confirm current edition terms with the maintainers. |
| Data model | STIX2-based knowledge schema of entities and relationships, suited to structured intelligence sharing and graph analysis. | Observables, entities such as threat actors and campaigns, indicators, DFIQ objects, forensic artifact definitions, Sigma and YARA rules, and reusable queries. |
| Threat intelligence integrations | Connectors for import, enrichment, export and stream consumption, including MISP, MITRE and CVE connectors and a MITRE ATT&CK connector. | Timesketch and MITRE ATT&CK integration, plus pluggable data sources and analytics. |
| Export and downstream tools | Export through connectors. Confirm which formats and SIEM targets your connector set supports. | Custom export formats for third-party SIEM and DFIR tools, so analysts avoid hand-writing machine-readable exports. |
| API | Web application with a GraphQL API. | Web API for automating queries and enrichment. |
| Single sign-on | OpenID, LDAP and SAML configuration require Enterprise Edition. Community Edition does not include these. | Google access token exchange endpoint added in 2.12.0, disabled by default, trading OAuth access tokens for Yeti API tokens. Confirm other identity options. |
| Release cadence | Regular releases ship from daily to weekly, with LTS builds every 6 months, each supported for 1 year. LTS use requires a specific license key. | Versioned releases; 2.12.0 is the current release, following 2.11.0 and 2.10.0 on September 1, 2026. Confirm support windows with the maintainers. |
What OpenCTI Enterprise Edition gates and what Yeti's license covers
The Community Edition of OpenCTI is licensed under Apache-2.0, and the OpenCTI LICENSE file in the main repository sets that terms for the open-source code. A team can use it to build a STIX-based knowledge base, run connectors for imports such as MISP and MITRE, and query data through the GraphQL API. The license is permissive, so the decision point is not the code itself but the features that sit behind the Enterprise Edition gate.
- Core data model: STIX-based entities and relationships are available in the Community Edition.
- Connector ecosystem: Import, enrichment and export connectors, including MISP, MITRE and CVE connectors, are part of the platform's documented design.
- Local accounts: Confirm with Filigran which login methods are available without an Enterprise license before you assume SSO is absent.
- Operating cost: Your infrastructure, dependencies and staff time are your own costs, separate from any license.
Before you commit, check the feature list for the exact release you plan to run, since gate placement is set by Filigran and can change between versions.
The Enterprise Edition is governed by the proprietary OpenCTI Enterprise Edition License and requires a paid subscription. According to the OpenCTI documentation, audit logs, playbooks and automation, organization segregation and SSO configuration through OpenID, LDAP or SAML all require this edition. For a regulated team, these gates usually decide whether the platform is usable for the access and traceability controls the organization must show.
- SSO: OpenID, LDAP or SAML configuration sits behind the paid license, so identity integration with your corporate directory depends on the subscription.
- Audit logs: Records of who changed what are an Enterprise feature, which matters if you must show an access trail to an auditor.
- Playbooks and automation: Automated workflows inside OpenCTI are gated, so plan any automation on the Community side separately.
- Organization segregation: Separating data between internal groups or customers requires the Enterprise Edition.
Ask Filigran for a written quote that names each gated feature you need, and confirm how the license is activated in your environment.
OpenCTI publishes long-term support builds alongside regular releases, identified by an lts suffix such as 7.260309.0-lts.8 from the OpenCTI GitHub releases page. According to the product life cycle documentation, LTS releases occur every six months, each is supported for one year, and they are distributed as container images. Using an LTS build requires a specific LTS license key, so the release track is also a licensing decision.
- License key: An LTS build needs its own LTS license key before it runs.
- Stabilization period: After roughly one month of stabilization, the LTS line receives only critical bug and security fixes.
- Overlap: Consecutive LTS versions overlap by about six months, which gives time to plan upgrades.
- Non-LTS releases: Regular releases ship daily to weekly and receive new features at a faster pace.
Confirm with Filigran whether your subscription includes LTS key access and how long each key is valid for your environment.
Yeti is licensed under Apache-2.0, according to the yeti-platform/yeti GitHub repository, and is built in Python with FastAPI and ArangoDB. The supplied facts do not describe a paid Yeti edition, so this page does not claim that SSO, audit logging or other administrative features are gated or free. Teams should treat Yeti's licensing as open source at the code level and confirm every administrative feature directly with the vendor.
- License terms: Apache-2.0 applies to the repository code, as stated in the GitHub repository.
- Authentication: Yeti 2.12.0 added a Google access token exchange endpoint, disabled by default, according to its release notes. Enabling it is a configuration decision you should test.
- Paid editions: No paid Yeti edition is described in the supplied facts, so confirm with the vendor whether one exists.
- Audit and SSO features: Confirm whether any administrative controls you need are included in the open-source release.
Ask the Yeti maintainers in writing which features are provided under the Apache-2.0 license and which, if any, depend on commercial support.
What drives the running cost of OpenCTI and Yeti
The running cost of OpenCTI is mostly the stack around it, not the license line. A self-hosted OpenCTI deployment needs the platform, Python workers, connectors, Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage, and each of those is hardware or cloud capacity you pay for every month. Yeti has a much shorter dependency list built on Python, FastAPI and ArangoDB, so its infrastructure line is usually smaller, though you still need to size and back up the database. Separately, OpenCTI's Enterprise Edition needs a paid subscription if you want SSO, audit logs, playbooks or organization segregation, and that fee recurs. Yeti is Apache-2.0 with no edition gate in the supplied facts, so its recurring cost is infrastructure and people. Confirm with Filigran and your own environment what an EE subscription covers for your node count before you budget it.
Split the costs into one-time setup and recurring operations. One-time work includes sizing, provisioning, integrating SSO or LDAP, mapping your data sources to connectors, and writing the runbooks for backups and restores. Recurring work includes staff time for upgrades, monitoring queues and dependency health, and reviewing connector output. OpenCTI adds a recurring cadence to plan for: non-LTS releases ship from daily to weekly, while LTS builds need a specific LTS license key and receive only critical bug and security fixes after stabilization. Worker count, the number of connectors you enable, and the dependency services you run all push infrastructure and upgrade effort up. Trimming unused connectors, sharing one platform node across a sensible worker count, and choosing a tested LTS line reduce both. Filigran's sizing guidance for platform and worker nodes is the starting point for estimating the first set of nodes.
When you request a quote from DeployOpen or any implementation partner, ask for each cost line to be written separately: the scope of setup work, the handover documentation, the support or retainer model for upgrades and monitoring, and the assumptions about your infrastructure and licensing. Ask which items are fixed-scope and which recur, and who holds the EE or LTS license relationship. Ask whether the quote includes a named upgrade window for each OpenCTI LTS cycle and what happens if you move between Yeti releases. This page does not give DeployOpen prices, fees or effort estimates; a quote follows from the written scope.
Moving intelligence from one platform to the other
This sequence moves observables, entities, indicators and access rules between Yeti and OpenCTI without losing track of what was imported, what was rebuilt and what still needs vendor confirmation. It ends with a verified cutover, not an assumed one.
Confirm version and edition scope with both vendors
Before any data moves, the migration lead records the exact Yeti and OpenCTI versions in use and the edition each side needs. Yeti's current release is 2.12.0, and OpenCTI's regular and LTS lines differ in how they are licensed and supported, so confirm which OpenCTI build and license type your team will run. Ask Filigran which Enterprise Edition features (SSO, audit logs, organization segregation) your target design depends on. Done when the version, edition and license decisions are written into the migration plan and signed off by the platform owner.
Inventory objects, observables and access rules
The migration lead, with a Yeti administrator and a DFIR analyst, exports a complete list of what lives in Yeti: observables, entities such as threat actors and campaigns, indicators, DFIQ objects, forensic artifact definitions, Sigma and YARA rules, saved queries, Timesketch links and ACL assignments. Each category is tagged as transfers cleanly, needs transformation or must be rebuilt. Done when every category has an owner and a disposition, and the list is reviewed by both CTI and DFIR leads.
Map Yeti types to STIX entities and relationships
A CTI engineer builds a mapping table that pairs each Yeti object type with its nearest STIX 2 entity or relationship in OpenCTI, because OpenCTI organizes intelligence as STIX-based entities and relationships. Yeti's DFIR-specific objects, such as DFIQ objects and forensic artifact definitions, often have no direct STIX equivalent and need a documented decision: store as external references, notes or custom fields, or leave in Yeti. Run the mapping against a sample export and check each record survives the round trip. Done when the mapping is reviewed and every unmapped type has a recorded decision.
Rebuild connectors, enrichment and exports
The integration owner recreates the feeds and outputs that used Yeti's web API, custom export formats and pluggable data sources. In OpenCTI, imports and enrichment run through connectors, and MISP, MITRE and CVE connectors are documented options, so each Yeti feed must be matched to a connector or a custom build. Downstream SIEM and DFIR consumers that read Yeti's exports need new export paths and format checks. Done when each consumer has a tested input from OpenCTI and the owner signs off on the format.
Re-create access controls and SSO
The identity administrator rebuilds Yeti's ACL model as OpenCTI roles and groups. OpenCTI's SSO through OpenID, LDAP or SAML and its organization segregation require the Enterprise Edition, so confirm licensing before designing the access model. Yeti's Google access token exchange, disabled by default, does not carry over, so plan the authentication path separately and verify it with your identity team. Test that a sample of analysts sees only the data they should. Done when access tests pass for each role and the SSO flow is confirmed in a non-production environment.
Import data and run both platforms in parallel
The team imports the mapped dataset into OpenCTI in a staging environment and keeps Yeti live for DFIR work. Both platforms receive the same new intelligence for a defined observation period agreed in writing, and analysts compare query results, enrichment output and export files. Discrepancies are logged with the mapping rule that caused them. Done when the discrepancy log has no open high-impact items and the owners accept the parity results.
Cut over and retain a Yeti fallback
The team switches its authoritative intelligence store to OpenCTI, redirects consumers to the new exports and connectors, and sets Yeti to read-only. The Yeti data, exports and configuration are backed up and retained under the agreed retention policy so analysts can still answer historical questions. Done when all consumers are confirmed on OpenCTI, the backup restore has been tested, and the cutover decision is recorded.
Verify open questions with each vendor
Before work begins, ask Filigran and the Yeti maintainers to confirm the items the public sources do not settle: whether Yeti data can be bulk exported in a form OpenCTI accepts, how Yeti's DFIR objects should be represented in STIX, and what OpenCTI license type your use requires. Record each answer with the date and the person who gave it. Done when every open question has a written answer that the migration plan references.
Where OpenCTI and Yeti implementation projects usually run long
The longest part of an OpenCTI project is usually the infrastructure you must stand up before any intelligence is loaded. OpenCTI is a stateless platform with a GraphQL API, Python workers and connectors, and it depends on Elasticsearch 8.0 or later or OpenSearch 2.9 or later, Redis 7.1 or later, RabbitMQ 3.11 or later and S3-compatible storage. Each of those is a component your team must size, back up, patch and monitor. Confirm the sizing guidance in the OpenCTI deployment overview against your expected data volume and worker count, and ask whether the connector set you need runs at your target schedule. Connector tuning is where many teams lose time: MISP, MITRE and CVE connectors each have their own import behavior, and noisy feeds can flood the knowledge graph. Plan a data mapping review early, because deciding how STIX entities and relationships represent your sources is hard to undo once analysts rely on them.
Yeti's infrastructure is narrower but still needs a deliberate plan. The platform is built in Python with FastAPI and ArangoDB, so your team must own an ArangoDB deployment and its backups alongside the application. The schedule risk for Yeti is usually analyst workflow rather than hosting: the platform stores DFIQ objects, artifact definitions, Sigma and YARA rules and reusable queries next to threat intelligence, and each DFIR team will want its own query patterns and export targets for SIEM and DFIR tools. Agree on those exports, the Timesketch integration and the MITRE ATT&CK mapping with the analysts who will use them before configuring anything. Identity is a shared risk on both platforms. OpenCTI's SSO through OpenID, LDAP or SAML sits in the Enterprise Edition, and Yeti 2.12.0 added a Google access token exchange endpoint that is disabled by default, so confirm which sign-in method your identity provider supports and whether your license covers it before design starts.
A fixed-scope written agreement should name the components in scope, the dependency versions and deployment target, the connectors and Yeti export formats to be configured, the SSO method and the identity provider involved, the data mapping decisions and who signs them off, and the acceptance tests that show analysts can complete their core tasks. It should also state what is excluded, such as ongoing feed curation or analyst training, and how changes after sign-off are priced. Ask for a quote that separates one-time build work from recurring upgrades and support, and check whether it covers the lts track if you choose OpenCTI LTS builds, which require a specific license key. Written scope is what keeps these projects from drifting, because data model and workflow disagreements are the usual causes of delay.
Questions buyers ask before choosing OpenCTI or Yeti
Can a small team run OpenCTI itself?
Yes, it is possible, but the team should expect to operate more than one application. An OpenCTI deployment is the platform with its UI and GraphQL API, Python workers that consume RabbitMQ messages, and connectors for import and enrichment. It also depends on Elasticsearch 8.0 or later or OpenSearch 2.9 or later, Redis 7.1 or later, RabbitMQ 3.11 or later and S3-compatible storage. The OpenCTI deployment overview lists sizing that includes at least one platform node for every 3 workers. A small team should count those services as ongoing operations work, including upgrades, backups and monitoring. Yeti has a lighter footprint, built on Python, FastAPI and ArangoDB, so the operating surface is smaller. Confirm the sizing for your own data volume before committing.
What cost drivers should we ask for in a quote?
Ask for a fixed scope that lists each component, who does the work and what is handed over. Cost moves with the number of platforms and dependencies to deploy, the connectors and integrations to build, the number of users and organizations that need segregation, and the hardening and backup work your policies require. For OpenCTI, add any Enterprise Edition subscription, since the Enterprise Edition License requires a paid subscription, and any LTS license if you choose that release line. Yeti is Apache-2.0, so the software itself carries no license fee, but the implementation and integration work still do. Separate one-time work (deployment, integration, migration) from recurring work (upgrades, retainers, subscriptions). DeployOpen does not publish a price list, and a quote follows from the written scope.
Does OpenCTI SSO require the Enterprise Edition?
Yes. The OpenCTI documentation states that SSO configuration through OpenID, LDAP or SAML requires OpenCTI Enterprise Edition, alongside audit logs, playbooks and automation, and organization segregation. The Community Edition is Apache-2.0 and covers the core knowledge graph and connectors, but identity integration is gated. Check the OpenCTI Enterprise Edition documentation before design work starts, and confirm with Filigran which license tier covers your identity provider and how it is activated. If your identity policy requires SSO for every analyst, budget for the Enterprise Edition in the quote. Yeti's 2.12.0 release added a Google access token exchange endpoint, disabled by default, which is a different mechanism and should be reviewed against your own access control policy.
Can Yeti serve a CTI team that shares indicators with partners?
Probably not as the primary sharing hub. Yeti describes itself as a forensics intelligence platform for DFIR teams, and it is aimed at analysts rather than at community indicator sharing between organizations. That sharing role is the focus of MISP, which synchronizes events between instances using distribution levels and sharing groups. OpenCTI sits between the two, with a STIX knowledge graph and connectors that can import from MISP. If your team needs to exchange indicators with partners, plan for a sharing platform alongside the analysis tool. If your main need is internal analysis, Yeti may be enough. Confirm with your partners which formats and sharing controls they expect before you choose.
How long does a migration take and what does it need from our team?
No migration duration is fixed in this comparison, and the answer depends on the size and shape of your existing data. The work usually falls into four areas: mapping your current objects to the target data model, building or reusing connectors, validating that analysts can find what they found before, and retiring the old system. OpenCTI's knowledge schema is based on STIX2, so STIX-compatible data is easier to map, while Yeti's model centers on observables, entities, indicators, DFIQ objects and forensic artifact definitions. Your team needs a named data owner, analysts who will test queries and workflows, and someone who can run the infrastructure. Ask any implementation partner for a written migration plan with the acceptance criteria stated before work starts.
Do we need an outside partner to deploy either platform?
Not always. Teams with experienced platform engineers and a clear CTI or DFIR requirement can deploy either platform in-house, using the official documentation and release notes. An outside partner adds value when the work is large, when dependencies must be hardened to your policies, or when you need documented evidence for a compliance assessment. DeployOpen plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted open-source platforms inside your own infrastructure, typically under a fixed-scope agreement with scope and timelines agreed in writing. DeployOpen does not issue audit reports or certifications, so independent assessors remain necessary for formal compliance. Ask any partner, including DeployOpen, to show how they will hand over runbooks and knowledge so your team can run the platform afterward.
Which platform is better for a DFIR team with limited CTI resources?
Yeti is the better starting point when the main work is forensic analysis, because it stores DFIQ objects, forensic artifact definitions, Sigma and YARA rules and reusable queries alongside threat intelligence. It also integrates with Timesketch and MITRE ATT&CK. OpenCTI is the stronger choice when you need a STIX knowledge graph, many connectors and an ecosystem that covers enrichment and export. The operating cost is also different, since OpenCTI's dependency set is larger. Test both against a real case from your own environment, using the query patterns your analysts already use, before deciding.
How DeployOpen helps choose, implement or migrate between them
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For OpenCTI vs Yeti, we start by mapping which team will own the platform, which data it must hold and which edition or license gates your requirements, then build only what the written scope covers.
How we scope
- Map whether your primary users are CTI analysts, DFIR responders or both before choosing a platform
- Confirm which OpenCTI Enterprise Edition features, such as SSO and audit logs, your requirements need
- Agree the written scope, deliverables and timeline in writing before any work starts, with no quote until then
How we build
- Deploy the chosen platform with its dependencies in your cloud account, data center or air-gapped network
- Configure connectors or integrations, such as MISP feeds for OpenCTI or Timesketch and MITRE ATT&CK links for Yeti
- Run security testing on the deployed APIs and access paths before the platform receives production data
How we hand over
- Document architecture, dependency versions, sizing decisions and the upgrade path for your operations team
- Deliver backup and restore procedures and evidence that your compliance assessor can review
- Walk your analysts and administrators through daily use, access control and the edition license in place
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover
- Plan upgrades around the release cadence and long-term support lines of the platform you choose
- Keep a written record of changes so a later move to another platform starts from documented data
