Deployment is a responsibility model.
Compare where employee and campaign evidence lives, who patches and monitors the application, how outbound simulation traffic leaves the environment, which internal systems must connect, how backups and retention work, and who responds when the service fails.
“On-premise” and “cloud” are not feature names. They describe a division of operational responsibility. A self-hosted license can improve control while increasing the customer’s security burden. A managed service can reduce maintenance while introducing vendor and data-location review. The right answer follows the organization’s threat model and operating capacity.
Use a boundary-first decision matrix.
| Question | Managed SaaS | Self-hosted |
|---|---|---|
| Time to start | Usually faster once contracting and tenant setup are complete. | Depends on infrastructure, networking, and internal approval. |
| Application operation | Vendor operates the service and product updates. | Customer operates the host, database, network, logs, and backups. |
| Data boundary | Defined by the service region, contract, and vendor controls. | Defined by the customer’s environment and chosen dependencies. |
| Internal integration | Requires approved connectivity to the managed service. | Can stay closer to internal systems, subject to customer design. |
| Isolation | Logical tenant separation within the managed platform. | Customer can design dedicated or isolated infrastructure. |
| Total operating cost | Subscription plus internal program operation. | License plus infrastructure, maintenance, monitoring, and staff time. |
Self-hosted means owning the hard parts.
A customer-controlled deployment can keep data and credentials within a defined network boundary. It can also simplify some internal connections and suit environments that restrict externally hosted security tooling. But the customer must make real engineering decisions:
- host hardening, administrator access, secrets, TLS, and exposure;
- database durability, backups, tested restore, and retention;
- mail, SMS, or supported IM provider credentials and egress;
- monitoring, alerting, capacity, updates, and vulnerability response;
- application audit review and separation of operator duties;
- the process for renewing or transferring any machine-bound license.
The current private single-host path uses SQLite by default. The SaaS runtime requires MySQL. Kubernetes and Helm packaging are not currently supported. Confirm topology, database, identity, and licensed modules against the support matrix before procurement.
SaaS still requires customer governance.
Managed infrastructure does not make the customer’s exercise automatically safe. The customer still owns written authorization, target selection, campaign content, internal communications, provider configuration, appropriate use, employee privacy, and what happens after an exercise. The vendor and customer should also agree on support, retention, deletion, incident handling, and export requirements.
Ask whether tenant boundaries cover every resource, which functions are licensed, how administrative actions are reviewed, and whether the deployment meets the organization’s geographic and contractual requirements.
Evaluate one representative workflow.
- Write the security and data boundary before choosing a SKU.
- Choose one realistic, authorized workflow—campaign design through reporting and follow-up.
- List required providers, directory sources, APIs, webhooks, exports, and identity requirements.
- Map each requirement to Core, Licensed, Integration-only, Unsupported, or external dependency.
- Test operational failure: expired credentials, blocked egress, restore, update, and administrator turnover.
- Compare three-year operating responsibility, not only the first invoice.
A short, honest pilot will reveal more than a long feature checklist. It shows whether the product fits the security program and whether the team can operate the chosen deployment responsibly.