Data Handling Statement

This page describes, concretely, what data Talon Studio touches and where it goes — for both the self-hosted appliance and Talon Cloud. It is written to be read by a security team doing vendor due diligence, not as marketing copy.

Talon Studio does not ingest your logs

Talon Studio is metadata-only by design. It reads index names, sourcetype/field schemas, and small samples of events (for detection testing) from a SIEM connection you configure — it does not copy or store your organization's raw log volume. Detections are authored as Sigma/native-query YAML and stored in a git repository, not as a copy of your event data.

Self-hosted deployment

Everything runs inside your own infrastructure. Specifically:

• The application, its embedded Postgres database, and the detection git repositories all live inside your own Docker volume.
• SIEM connection credentials are encrypted at rest using a key you control (TALON_ENCRYPTION_KEY) and are never logged or returned unmasked by the API.
• The only default outbound network calls are: (a) pulling public detection-content updates (SigmaHQ, Atomic Red Team, and similar open sources) over HTTPS, and (b) validating your offline license signature. Both can be disabled for air-gapped installs.
• If you configure an AI provider (including a local Ollama instance), prompts go directly from your server to that provider — never through Talon Labs' infrastructure.
• Talon Labs has no access to a self-hosted instance, its data, or its credentials, unless you explicitly grant remote access for a support session.

Talon Cloud

Talon Cloud runs the same appliance, operated by us, on a silo model: each customer gets their own isolated namespace, database, and git storage — tenants are never pooled onto shared application processes or shared database rows. Specifically:

• Isolation: one Kubernetes namespace and one dedicated Postgres database per tenant; network policy prevents cross-tenant traffic.
• Encryption: credentials encrypted at rest per tenant; TLS in transit for all traffic.
• Backups: automated backups per tenant, with restore drills — see the Support Policy for what's covered.
• Region: tenants are provisioned in a specific AWS region at signup (currently UK/EU); cross-region replication is snapshot-based, not live.
• Access: Talon Labs operations staff can access tenant infrastructure for operational purposes (upgrades, incident response) under logged, audited access — not for browsing customer detection content.

Sub-processors

Talon Cloud's infrastructure runs on Amazon Web Services. Billing is processed by Stripe. We do not use additional data sub-processors beyond what's needed to operate the infrastructure you're provisioned on.

Deletion

On self-hosted, deleting a workspace removes its database rows and git repository from your volume. On Talon Cloud, closing an account triggers deletion of the tenant's namespace, database, and backups per the retention window in your order form.

Questions

Security or data-handling due diligence questions: security@talonlabs.dev.