Running a threat intelligence platform for air-gapped networks
A SOC or CERT inside an enclave with no route to public feeds can still run a threat intelligence platform, but the boundary changes what the platform is for. Nothing arrives on its own schedule, so every feed, taxonomy, galaxy and software update is a deliberate transfer that someone must approve, scan and record. In short, MISP fits most offline deployments because its taxonomies and galaxies ship as portable data, its export formats cover the sensors analysts already run, and its sharing model works between instances that never touch the internet. OpenCTI can work offline too, but it needs more infrastructure (Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage), more connectors to keep in step, and a licensing decision because LTS releases require a specific license key and some features sit in the Enterprise Edition.
The boundary also changes the design around the platform. Connectors that call external services, such as enrichment lookups to hosted reputation services, have to be removed or replaced with local data, and the reader should confirm which modules in their chosen platform make outbound calls before go-live. Transfer media becomes a control point, so the team needs a documented process for importing feeds and taxonomies, verifying hashes and signatures where the source provides them, and recording who approved each import. Sharing with partner communities happens through sync or file exchange across a controlled path, which means distribution levels and sharing groups must match the enclave's rules before any event leaves it.
Indicators only help if they reach the sensors inside the enclave. MISP exports Suricata and Zeek formats, so the team can generate rules locally and deploy them to sensors through its own change process, which should be confirmed against the sensor versions in use. Update cadence is the operational question that remains. With every update manual, the team should set a fixed import schedule, test each package on a staging copy, and plan for the gap between a transfer and the next one. Ask any implementation partner how they will handle an emergency import outside that schedule and how they will prove each transferred package was the one that was approved.
Which requirements shape an air-gapped deployment
This table maps the regulatory requirements supplied for this topic to what each one means for feed transfer, offline updates, logging and access in an isolated MISP or OpenCTI deployment. Read each row only if your sector or contract is subject to that rule, since HIPAA, FTC Safeguards, NERC CIP and other frameworks apply to different organizations. The main takeaway is that every package and feed crossing the boundary becomes an auditable event.
| Requirement | What it means for the enclave | Evidence an assessor will ask for | Where it usually fails |
|---|---|---|---|
| HIPAA 45 CFR 164.312 unique user identification and audit controls (applies to covered entities and business associates handling ePHI) | Each analyst and service account gets its own MISP or OpenCTI login, and audit logs must record activity in the platform. Only apply this row if threat intelligence stores or touches systems holding ePHI. | User account list tied to named individuals, audit log samples, log retention settings and review records | Shared analyst accounts for feed imports, or audit logging left at defaults with no review |
| FTC Safeguards 16 CFR 314.4 monitoring and logging of authorized users (applies to covered financial institutions) | Logins, imports, sharing actions and configuration changes must be logged and reviewed. Logs for the intelligence platform should feed the enclave SIEM, which may itself be offline. | Log sources inventory, sample events for imports and exports, alert or review procedure | Logs written only to the platform host, with no review and no copy kept outside the instance |
| FTC Safeguards 16 CFR 314.4 multi-factor authentication for individuals accessing information systems (applies to covered financial institutions) | Offline does not remove the need for MFA. Plan a local identity provider or an MFA method that works without internet access for analysts and administrators. | MFA configuration for each access path, list of exceptions and their approvals | Break-glass accounts without MFA, or an identity provider that depends on a public service |
| NERC CIP-013-2 software integrity and authenticity for vendor software and patches (applies to bulk electric system operators and vendors in scope) | Every package, container image, feed bundle, taxonomy and galaxy file carried across the boundary needs a documented verification step (checksums, signatures, provenance) before import. | Procurement records, hash or signature verification logs, transfer chain-of-custody forms | Feed bundles copied by hand with no hash record, or updates imported straight from a laptop |
| NERC CIP-005-7 Interactive Remote Access and Intermediate System (applies to high and medium impact BES Cyber Systems) | Vendor or support access into the enclave for updates or troubleshooting must pass through an Intermediate System with encryption and MFA, and active vendor sessions must be detectable and disableable. | Network diagrams of access paths, Intermediate System configuration, session detection and disablement records | Vendor remote tools installed on the platform host, or sessions that cannot be ended quickly |
| Transfer media and cross-domain movement of feeds and taxonomies | Controlled transfer is the only update path, so define who may stage media, how it is scanned, and where it is logged before import. | Transfer procedure, media register, scan results, import records | Ad hoc USB use with no register, or staging on hosts outside the enclave |
| Offline update cadence and enrichment modules | Enrichment connectors that call public services must be disabled or pointed at internal copies. Record each update as a dated release bundle that has been tested in a staging copy first. | Connector configuration export, update change records, staging test results | Connectors left enabled and failing silently, or updates applied to production without a tested copy |
| Sensor rule export to Suricata and Zeek inside the enclave | Indicator exports to Suricata and Zeek rules are generated inside the enclave, and each rule set needs a version and an approval record before deployment to sensors. | Rule set version history, approval records, sensor deployment logs | Rules pushed to sensors without version tags, making rollback and review hard |
Which platforms fit an isolated threat intelligence stack
An isolated threat intelligence stack needs a sharing platform, a data store, a sensor side that consumes rules, and an update path that carries everything across the boundary. The cards below cover the components most often evaluated for that role and the licensing and packaging checks that decide whether each one fits.
MISP as the sharing core
MISP is licensed under AGPL-3.0 and runs on PHP with CakePHP, MySQL or MariaDB and Redis. Its installer, Docker images, Ansible roles and RPM packages let teams build the instance from artifacts staged in the enclave. Confirm which database you will run, since PostgreSQL support arrived with the 2.5.47 migration system. Use MISP 2.5 for new deployments, because 2.4 is end of life.
OpenCTI as the graph-based option
The OpenCTI Community Edition is licensed under Apache-2.0 and models data on STIX2 with a GraphQL API. A full deployment also needs Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage such as MinIO, so the offline bundle grows with each component. Its LTS releases require a specific license key, so confirm how that key is issued and renewed when no internet route exists.
Exports to Suricata, Snort and Zeek
MISP can export indicators in Suricata, Snort, Zeek and RPZ formats, which is how sensors inside the enclave receive new intelligence without a live feed. Export jobs should run on a fixed schedule, and each generated rule file should be checked against the sensor version in use before it is deployed. Confirm the rule syntax each sensor accepts, because export coverage is not the same as a tested import on every engine version.
Security Onion as the sensor side
Security Onion is licensed under the Elastic License 2.0 and bundles Suricata, Zeek, osquery and the Elastic stack. Its airgap documentation covers full installs from an ISO that carries packages and NIDS, YARA and Sigma rules. Updates arrive as newer ISO media applied with the soup tool in airgap mode, so the rule refresh cycle is set by how often new media is carried in. Confirm the license terms for your use case before you plan a commercial deployment.
Paid editions and air-gapped licensing
Air-gapped support is often tied to a paid edition, so a free license does not guarantee an offline install path. Vendors tie offline packaging, enterprise connectors and some update channels to commercial tiers. Ask each vendor in writing which features, update methods and key types apply to a disconnected deployment, and get the answer in the quote before you choose the stack.
Offline update and transfer controls
Every component, rule set, taxonomy and galaxy package crosses the boundary by controlled transfer, so each package needs a checksum or signature check before import. MISP taxonomies and galaxies carry CC0 1.0 or BSD-2-Clause licenses, separate from the AGPL software. Record which artifact came from which transfer, so an auditor can trace each rule and feed back to its source.
How the rollout moves from transfer design to a repeatable update cycle
The sequence turns a one-time offline build into a documented transfer path, a verified intelligence base and a scheduled update routine that analysts can run without internet access. Each phase closes with a named output that the security owner can review before the next phase starts.
Define the transfer procedure and approvals
The security owner, the platform team and the analysts agree how every file enters the enclave: which media or diode path is used, who prepares each transfer, who approves it, and where the transfer log is kept. The same discussion sets the rule that every package, feed and rule set is checked against a recorded hash before it is loaded. This maps to the software integrity and authenticity expectations in NERC CIP-013-2 where that standard applies. The step is complete when a written transfer procedure is signed off and a sample transfer has been walked through end to end on paper.
Build the offline platform from carried media
The platform team builds MISP or OpenCTI using installers, packages or container images that were prepared outside the enclave and carried in through the approved path. Dependencies such as the database, Redis, and for OpenCTI Elasticsearch or OpenSearch, RabbitMQ and S3-compatible storage must be resolved from the carried set, with no pull from public registries at install time. Confirm the exact installer method and version for your chosen release with the vendor documentation before you build. The step closes when a clean install boots inside the enclave and a dependency check shows no outbound calls.
Load taxonomies, galaxies and feeds by controlled import
Analysts import taxonomies, galaxies, warning lists and any approved feed bundles from the transfer media, one batch at a time, recording the source, date and hash of each file in a load register. Taxonomy and galaxy data carry their own licenses, separate from the software license, so the register should note them as well. Enrichment modules that call public services are disabled or pointed at internal copies, so that nothing attempts an external lookup. The step is complete when every loaded item appears in the register with a matching hash and a test event shows the expected tags.
Configure sharing groups and distribution levels for restricted content
The platform owner creates sharing groups and assigns distribution levels so that restricted indicators stay within the enclave or within named partners, and confirms that synchronization is switched off for any content that must not leave. Access roles are mapped to the analyst groups from the identity platform. Test events are created at each distribution level and checked from accounts with and without the right group membership. The step closes with a short test record showing that restricted events are not visible or synchronized to unauthorized users.
Export rules to Suricata and Zeek and validate on sensors
MISP can export indicators in Suricata, Snort, Zeek and RPZ formats, and the network team loads the generated rules into sensors inside the enclave through the same controlled transfer path. Rules are tested in a lab or on a mirror sensor first, checking for syntax errors, false positives against known-good traffic and the expected alert output. Confirm the export formats and rule set details for your versions with the vendor documentation. The step is complete when each sensor loads the rule set, the alerts fire on the test traffic, and the rule set version is recorded against the import register.
Run a tabletop update drill and set the cadence
The team walks through a full update cycle on paper: a new bundle is requested, approved, carried in, hash-checked, imported, tested on sensors and rolled back if a test fails. The drill exposes gaps in roles, timing and evidence before a real update is needed. The output is a written update cadence agreed with the security owner, a named owner for each update type, and a rollback procedure. Ask the vendor to confirm the upgrade path for offline installs and how long the platform's supported release line remains available before any version change is planned.
How offline enrichment and rule export change the workflow
In an enclave, every enrichment lookup that depends on an external service has to be replaced with local data or switched off, and that decision changes what analysts can conclude from an indicator. Before go-live, list each enrichment module and external lookup enabled in the MISP or OpenCTI instance, then mark each one as replaced by a local dataset, disabled, or accepted as an internal-only service. Analysts should know which enrichment answers they no longer get, because a missing reputation or passive DNS result can look like a clean indicator when it is simply unanswered. Correlation coverage shrinks in the same way: the engine can only match against what has been imported, so the import cadence becomes the limit of what the platform can see. Confirm with the vendor and your own testing which modules still function without outbound connections, since module behavior varies and should not be assumed from the product name.
Rule export turns indicators into detection content that runs inside the enclave. MISP can export to Suricata and Zeek formats, and the resulting signatures should be reviewed by a detection engineer before they reach the sensors, since an indicator that is valid in a public feed may be noisy on internal traffic. Set the false-positive process locally: who can suppress a rule, how suppressions are logged, and how long an indicator stays active before it expires without fresh sightings. Those ageing rules belong in the platform configuration and in a written procedure, not in the head of one analyst. Test each exported rule against recorded enclave traffic in a staging sensor before promoting it, and keep the previous rule set so a bad push can be rolled back.
Because the feed is manual, every rule change inherits the transfer and review delay, so plan the cadence around the review capacity of your team rather than the arrival of new intelligence. Keep a short list of indicator classes that must reach sensors within a fixed window, and treat the rest as batch content. Ask any implementation partner how they will validate exported Suricata and Zeek content against your sensor versions, and how they will record each import and export as evidence for later review.
What a deployment inside the enclave includes
What does the threat intelligence platform host and database need inside the enclave?
The TIP host runs the MISP or OpenCTI application, and its database is the system of record for events, attributes, sharing groups and audit history. For MISP, the stack is PHP with CakePHP, MySQL or MariaDB and Redis, and the project's download page recommends Ubuntu 24.04 with its provided installer for MISP 2.5, which is the recommended version for new deployments. Confirm with your platform team which operating system images the enclave accepts, how the database is sized and patched, and whether MISP 2.5 with PostgreSQL support (introduced in 2.5.47) fits your database standards.
Why does Redis matter in an offline MISP or OpenCTI deployment?
Redis holds cache and queue state that the TIP application depends on during ingestion and background work. MISP lists Redis in its core stack, and OpenCTI requires Redis 7.1 or later. Because the enclave cannot pull packages from public repositories, Redis must come from an internally approved package set or image, with its version recorded in the change record. Confirm the approved Redis version, its persistence settings and how it is restarted safely after a host reboot.
What dependency set does OpenCTI add inside an air-gapped enclave?
If you choose OpenCTI, the deployment adds Elasticsearch 8.0 or OpenSearch 2.9 or later, Redis 7.1 or later, RabbitMQ 3.11 or later, and S3-compatible object storage such as MinIO. Python workers consume RabbitMQ messages for asynchronous writes, and connectors handle import, enrichment, export and stream consumption. Each of these components needs an offline install path and a container or package source inside the enclave. Confirm the sizing the documentation gives (at least 2 cores and 8 GB RAM for the platform, and 2 cores, 8 GB RAM and 16 GB SSD for Elasticsearch or OpenSearch), and confirm whether any feature you need requires the OpenCTI Enterprise Edition license.
How does a transfer gateway move feeds and updates across the air gap?
A transfer gateway is the controlled point where approved media or a one-way transfer path brings feeds, taxonomies, galaxies and software packages into the enclave. Every inbound package should be logged, scanned and hashed before it reaches the TIP host, and the gateway should refuse anything outside an approved manifest. Confirm the transfer method your security policy allows, who signs off each import, how media is sanitized and tracked, and whether the gateway keeps an audit trail that an assessor can review. MISP taxonomies and galaxy data are licensed under CC0 1.0 or the 2-clause BSD license, which makes them straightforward to carry, but the feed licenses you import still need review.
How do indicators reach Suricata and Zeek sensors without a live connection?
MISP exports indicators in Suricata, Snort, Zeek and RPZ formats, so the TIP can generate rule files that are then copied through the same controlled path to the sensors. Suricata 8.0.7 and Zeek 9.0.0 are the versions published in the supplied facts, and Security Onion ships its own NIDS, YARA and Sigma rules in its airgap ISO. Confirm which rule formats each sensor will load, how rule files are tested in a staging sensor before production, and who approves changes that could block legitimate traffic in an operational network.
How do SIEM and SOAR connect to the TIP when nothing leaves the enclave?
The SIEM and SOAR platforms query the TIP over internal network paths only, so their integrations must point at enclave addresses and use internal certificates. Wazuh and Security Onion can run offline and can use locally maintained vulnerability and rule content, and Shuffle is a SOAR option licensed under AGPL-3.0. Confirm that each enrichment or lookup step in a playbook has an internal data source, because any step that calls a public service will fail or leak metadata. Also confirm the API key handling and the rotation schedule for those integrations.
What backup and restore storage does an offline TIP need?
Backups in an enclave must be written to storage inside the same controlled boundary, and they must include the database, configuration, sharing group definitions, imported feed archives and, for OpenCTI, object storage contents. Restore must be tested on a separate host, because an untested backup is not evidence of recovery. Confirm backup frequency, retention period, encryption at rest, the location of the offline copy, and the restore time your operations team has tested. Ask your partner to document the restore procedure in the same change system used for software packages.
How do patches and software integrity checks work when every update is carried in by hand?
Each update is a package that must be verified before installation, which means checking its checksums or signatures against values obtained through a trusted channel, reviewing release notes, and recording the approval. NERC CIP-013-2 requires supply chain procurement processes to address verification of software integrity and authenticity for vendor software and patches, which is the control behind checking every package crossing an isolated boundary. For MISP, the release history includes MISP 2.5.50 on 9 October 2026, and the end of life for MISP 2.4 means older instances need an upgrade path. Confirm your update cadence, the test environment that receives each release first, and who owns rollback.
Evidence assessors ask for from an offline platform
This table maps the evidence items an assessor usually requests from an air-gapped MISP or OpenCTI deployment to the component or process that produces each item. Read it as a checklist for what to design into the enclave from day one, since evidence that is not generated at transfer or change time is hard to reconstruct later. DeployOpen prepares this evidence, but auditors and certification bodies draw the conclusions.
| Evidence item | Produced by | What to retain or confirm |
|---|---|---|
| Feed and taxonomy import logs | MISP import tasks and OpenCTI connector logs on the enclave host | Confirm logs are shipped to a store inside the enclave and retained for the period your policy sets |
| Transfer records and hash checks | Controlled transfer procedure with checksums recorded at the boundary | Record who carried media, when, and the hash of each package before and after import |
| Package validation records | Your transfer workstation and signature or hash verification step | Keep the verification output with the transfer ticket so each import links back to an approved package |
| User access and audit logs | MISP audit log and OpenCTI platform logs, forwarded to a local log store | Confirm which events are logged, who can read them, and whether they cover administrator changes |
| Authentication configuration | MISP and OpenCTI user and role settings, plus any local identity provider | Export role and account lists regularly and compare them with the approved access roster |
| Sharing group and distribution configuration | MISP sharing groups and distribution levels, OpenCTI marking definitions | Keep dated exports of sharing group settings so you can show who could see which indicators at any point |
| Rule export history | MISP Suricata and Zeek exports, and the rule files deployed to sensors | Record each export, its version, the sensor it was loaded on, and the date it went live |
| Update and patch records | Platform release notes, package hashes and the manual upgrade runbook | Keep the version of every component, the offline package used, and the test result before production |
| Backup and restore test results | Backup jobs for the MISP database and OpenCTI Elasticsearch, Redis, RabbitMQ and object storage | Confirm restores were tested inside the enclave, not only that backup jobs completed |
What to ask an implementation partner before an air-gapped build
Start by asking how the partner packages and verifies everything that crosses the boundary. Ask for the written transfer procedure covering MISP or OpenCTI container images, MISP taxonomies and galaxy data, feed snapshots, Suricata and Zeek rule sets and operating system packages. Each item should arrive with a checksum or signature list, a manifest of exactly what changed since the last transfer, and a record of who scanned it on the approved side. Ask how they keep the offline copy of MISP's bundled feeds and taxonomies current, since those data sets are licensed separately from the AGPL-3.0 software under CC0 1.0 or BSD-2-Clause, and your legal team will want that split documented. Ask which package sources they mirror and how they confirm the mirror matches upstream before transfer.
Next, settle licensing before the design is fixed. OpenCTI Community Edition is Apache-2.0, but OpenCTI LTS releases require a specific LTS license key, so ask the partner to confirm in writing whether the key works on an isolated network, how it is delivered and renewed, and what happens when a key lapses during a long freeze. Ask which features they assume need the OpenCTI Enterprise Edition, and which MISP or Suricata capabilities depend on plugins or connectors with their own terms. Confirm whether any proposed component is available only in a paid air-gapped tier, and get that cost in the quote rather than discovering it later. Ask who holds the license records for your audit file.
Finally, ask who runs the manual update cycle after handover, and how rule changes are proven on sensors before they go live. The partner should describe a named role for each step (curator, transfer operator, sensor engineer, approver) and a rollback path if a Suricata or Zeek rule set causes alert floods or packet loss. Ask for a test sensor that mirrors production, a validation log for each rule release, and a documented retention period for prior versions. For evidence, ask which artifacts they will hand over for your sector, such as transfer logs, sharing group configurations and change tickets, and whether they have mapped those to the control IDs your assessor will test. Ask them to explain what they will not certify: independent auditors issue the assessment, and the partner prepares the evidence.
How much effort does an air-gapped threat intelligence platform take?
What drives the cost of running MISP or OpenCTI on an air-gapped network?
The software is not the main line item. MISP is licensed under AGPL-3.0 and OpenCTI has a Community Edition under Apache License 2.0, so cost sits in infrastructure, transfer tooling, integration work, curation time and any OpenCTI Enterprise subscription. For OpenCTI, the dependencies are Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage such as MinIO, each of which must be hosted, patched and backed up inside the enclave. The documented sizing starts at 2 cores and 8 GB RAM for the platform, with a recommendation of at least one platform node for every 3 workers. Confirm with your architect which of these components must be highly available and what the storage growth looks like for your feeds. Ask for a quote that separates one-time build work from recurring operations.
Can an internal team run an air-gapped threat intelligence platform without outside help?
A team with Linux, database and container skills can run it, but the work is more than installation. The team must handle the controlled import path for feeds, taxonomies and software packages, keep enrichment modules offline, tune the Suricata and Zeek rule exports, and maintain the update cycle without a live connection to upstream sources. Many organizations split the work: internal staff own curation and analysis, while a partner builds the offline package pipeline, hardens the stack and writes the runbooks. Check whether your analysts have time for curation alongside the platform itself, because an unmaintained feed is a common failure. DeployOpen implements, hardens, backs up and documents self-hosted platforms inside the client's own networks, so the split of work can be defined in the written scope.
How long does a rollout take on an air-gapped network?
Duration depends on scope, the number of feeds and sharing communities, the number of integrations, and how long change approvals take on your side. A single MISP instance with a defined feed set and one export to a sensor will take far less time than an OpenCTI deployment with connectors, a search cluster and integrations into a SIEM or SOAR. Approvals for media transfer, package review and firewall exceptions often set the pace more than the build itself. No duration is set here because none is supplied for this topic. Ask any partner for a phased plan with named approval gates, and ask which steps depend on the client's network, security and change teams. The fixed-scope agreement is where those dates should be written down.
What does the client need to provide for the project?
Three groups of people are needed from the client: network owners, change approvers and analysts. Network owners define the transfer points, the enclave boundary and the rules for moving files across it. Change approvers sign off on each package, configuration change and firewall or sensor update, which is where audit evidence comes from. Analysts define the intelligence requirements, which feeds matter, how indicators are classified under the Traffic Light Protocol and who approves what is shared. For sectors such as energy, NERC CIP-013-2 requires procurement processes that address verification of software integrity and authenticity, which is the control behind checking every package carried across an isolated boundary. Confirm with your compliance lead which of these controls apply to your environment.
How are feed and software updates handled after go-live?
Every update is manual, so the operating model needs a fixed cadence and a defined transfer process. The cycle typically covers new MISP or OpenCTI releases, feed and taxonomy refreshes, and operating system and container images. MISP's download page recommends MISP 2.5 for new deployments, and MISP 2.4 is end of life with security fixes only. OpenCTI LTS releases are distributed as container images but need an LTS license key, and after a one-month stabilization they receive only critical bug and security fixes. For Security Onion, the soup tool can update from newer ISO media in airgap mode. Each package should be verified before it crosses the boundary and recorded for audit. Ask any partner how often they will run the cycle, who approves it and how rollback is tested.
Which costs recur after the platform goes live?
Recurring costs come from operations, not from licenses for the open-source core. They include staff time for the update cycle, curation of indicators, aging out false positives, backups and restore tests, and patching the database, search and messaging layers. Any paid feed or OpenCTI Enterprise subscription also recurs. Air-gapped support is often a paid-edition feature in other products: Mattermost places it in Enterprise Advanced, and Metabase offers it only on its Enterprise plan, so confirm that every component in your chosen stack is licensed for offline use. Ask for a quote that lists each recurring item, its owner and its frequency, and whether ongoing support is a separate retainer.
What evidence will the platform produce for an audit?
The platform itself produces logs of imports, exports, sharing decisions and user activity, and those records help meet audit expectations. The HIPAA Security Rule at 45 CFR 164.312 calls for audit controls that record and examine activity in systems with ePHI, and the FTC Safeguards Rule at 16 CFR 314.4 calls for monitoring and logging of authorized user activity. DeployOpen prepares systems, controls and evidence for assessments but does not issue audit reports or certifications; independent auditors do that. Confirm with your assessor which records they need, such as package verification logs, change approvals and sharing group decisions, and set retention periods that match your policy.
How DeployOpen scopes and builds an air-gapped threat intelligence platform
DeployOpen scopes every air-gapped threat intelligence engagement as a fixed-scope project with written deliverables agreed before work starts. In practice, the written scope should name each component to be installed inside the enclave, such as the MISP or OpenCTI application stack, the import path for feeds and taxonomies, the Suricata and Zeek rule export jobs, and the update procedure. It should also name who receives each deliverable, including architecture records, hardening baselines, runbooks and the evidence set. DeployOpen plans, implements, hardens, documents and supports self-hosted platforms inside the client's own networks, including air-gapped ones, so the work happens in the client's accounts, data centers or isolated networks. Before scoping, confirm with your team which platform you intend to run, which accounts will hold administrative access, and which network segment the analysts and sensors occupy, because these decisions change the statement of work.
Ongoing work after go-live can be covered by a retainer, which is useful because the manual update cycle, package verification and version upgrades continue long after the first build. A retainer scope should state how often new media is brought across the boundary, who reviews each transfer, how security patches are tested before release, and what response time applies to a broken sync or a failed rule export. Ask for these terms in writing and compare them against your own change control process. DeployOpen does not issue audit reports or certifications, so any compliance evidence it prepares should be reviewed by your independent assessor and internal governance team.
