Choosing a Deployment Model for a Security Platform

Why this decision moved

For a decade the deployment question had a settled answer. SaaS was cheaper to run, faster to adopt and better maintained, and the objections to it were mostly organisational. Where a genuine residency requirement existed, a private or on-premises instance answered it, and the trade was a slower release cadence.

AI-native platforms reopened it, because they introduced a second place data can go. A platform can be hosted entirely in your tenancy and still send every alert, prompt and piece of evidence to a model API somewhere else in order to reason about it. Hosting and inference are separate questions now, and only one of them is usually on the datasheet.

So the first thing to establish is not which model you prefer. It is whether the vendor's deployment options constrain inference at all, or only storage.

The five models, and what each actually gives you

Spharaka Sphere™ runs in five configurations. The differences that matter are control, latency to value, and who carries the operational burden.

SaaS is cloud-native and managed by the vendor. It is the fastest route to value and the least operational work, and sovereignty controls are retained rather than surrendered. Private cloud is a dedicated, organisation-controlled environment, which suits multi-site organisations that want centralised visibility without shared infrastructure. Sovereign cloud is government-certified or regionally compliant hosting, aligned to regimes such as the DPDP Act and GDPR, and is the usual answer where residency is a legal requirement rather than a preference.

Hybrid places the central platform at headquarters with lightweight sensors at sites, federating intelligence back to the centre, which fits organisations whose sites have thin connectivity or thin staffing. On-premises puts the full platform in your own data centre, and in its air-gapped form it operates with no external connectivity at all and maximum data control.

• SaaS: fastest time to value, managed by the vendor, sovereignty controls retained
• Private cloud: dedicated and organisation-controlled, scales for multi-site with centralised visibility
• Sovereign cloud: government-certified or regionally compliant, aligned with DPDP, GDPR and equivalents
• Hybrid: central platform at headquarters, lightweight sensors at sites, federated intelligence
• On-premises: full platform in your own data centre, air-gapped operation available, maximum control

The questions that actually decide it

Most deployment debates stall because they are conducted as preferences. They resolve quickly when they are conducted as constraints, and there are only a handful that bind.

Does a regulation, a contract or a classification prohibit specific data leaving a boundary, and does that prohibition cover derived data such as embeddings and model prompts as well as raw logs. Can the environment reach the internet at all, and must it continue operating when it cannot. Who will run the platform, and does that team have the capacity to carry patching and availability. How quickly does the organisation need coverage, and what is the cost of the gap until then.

Answer those four honestly and the model is usually already chosen. What remains is checking that the platform genuinely supports it rather than supporting a version of it.

What air-gapped has to mean to be worth the cost

On-premises and air-gapped deployment costs more in operational effort than any cloud option, so it is worth being precise about what it has to deliver in exchange. The test is whether capability survives disconnection.

In a genuine implementation, ingestion, detection, investigation, decision and response all complete inside the customer controlled network, and model inference happens there too. Investigations, detections and response workflows continue while the environment is disconnected from the internet. What pauses is the arrival of new threat content, and that has a controlled path: offline packages, approved transfer media or private update channels.

In a weaker implementation, the console and the collectors run locally while the reasoning does not, so the platform quietly degrades to a log store when the link drops. Both are described as on-premises. Only one of them justifies the operational cost.

• Unplug the environment and confirm which functions continue and which stop
• Ask whether prompts, embeddings and evidence stay local, not only whether logs do
• Establish the update path, and who approves what crosses the boundary
• Check whether the deployed edition is the full capability set or a reduced one
• Confirm that multi-tenancy, if you need it, separates data structurally rather than by view

Mixing models without splitting the SOC

Large organisations rarely land on one model. A group may run SaaS for the corporate estate, a sovereign region for a regulated subsidiary, and an air-gapped instance for a classified or industrial site. That is a reasonable end state and a difficult one, because the failure mode is a SOC that has to work in three consoles.

The thing to protect is the investigation surface rather than the infrastructure. If each deployment produces the same investigation output, verdict, evidence trail, attack timeline, affected entities and recommended response, then analysts move between them without relearning the work, and the reporting consolidates.

Where operational technology is in scope, the same principle applies across the IT and OT boundary. Spharaka Signal™ covers industrial estates passively and feeds the same investigation surface, so an OT site does not become a fourth console.

What does not change with the model

It is worth stating what should be constant, because a vendor whose capability varies by deployment is telling you something about where their engineering effort goes.

The capability set should not be a reduced edition. Autonomous investigation, local reasoning, entity profiling, attack correlation, case summarisation, endpoint visibility and governed response should all be present regardless of where the platform runs. What changes is where each part executes and how content is delivered to it.

Governance should also be constant. Every investigation step, evidence query and response action should be traceable for audit and review, and the boundary between what runs autonomously and what requires approval should be your policy in every deployment, not a default that varies with the hosting choice.