Security
Last updated: October 2026
StreamSource is built on one principle: your data should stay in your own cloud. Our platform runs inside your AWS, GCP or Azure account, so your events are produced, stored, processed and delivered behind your network, your keys and your policies. This page describes how we protect the parts we are responsible for, and where our compliance work stands today.
Compliance
We would rather give an accurate status than display badges we have not earned. Audit reports will be shared with customers under NDA once each audit is complete.
| Data residency | Choose any region your cloud provider supports. Data stays there unless you send it elsewhere. | Available |
| ISO/IEC 27001 | Information security management system certification. | In progress |
| SOC 2 Type II | Independent audit of our security controls over time. | In progress |
Product security
Your data stays in your account
Kafka brokers, connectors, transforms and sinks all run in a Kubernetes cluster inside your cloud account. Our control tower, which hosts the dashboard and release manager, only sends deployment instructions and receives health metrics such as throughput, consumer lag and error counts.
The control tower never receives message payloads, keys or headers, connector credentials, or any data stored in your databases, buckets or warehouses.
Access to your cloud
- One scoped role. The role you grant is limited to resources tagged
streamsource:managed. It has no permission to read your other databases, storage buckets or secrets. Deleting the role ends our access. - Outbound-only connection. The agent in your cluster opens a mutually authenticated TLS connection to us. You do not open any inbound port for management.
- Short-lived credentials. The agent enrolls once with a single-use token, then uses certificates that rotate automatically.
- Approved workloads only. The agent can only deploy components from an approved list of signed images.
Encryption
All traffic between components, Kafka and your sinks is encrypted with TLS. Broker disks are encrypted at rest. Connector passwords and tokens are stored in your cloud provider's secret manager and are read only by components running in your cluster. Enterprise customers can encrypt disks with keys from their own KMS.
Isolation and access control
Each workspace has its own Kafka users and topic permissions, so components in one workspace cannot read another's topics. Users sign in with Google, Microsoft or email, and receive one of four roles per workspace: Admin, Maintainer, Developer or Viewer. Every change made by a user or by the platform is written to an audit log that customers can export.
Secure development
Every change to StreamSource goes through a pull request and must be reviewed and approved by another engineer before it can be merged. Our build pipeline runs automated tests, dependency vulnerability scans and static analysis on every change.
Released container images are signed, and new versions roll out in stages: first to our own environments, then to customers who have approved the upgrade. Every release can be rolled back.
Organizational security
Information security policies
We maintain written policies that every employee reads and accepts when they join. They cover:
- Access control: how access to systems is requested, approved, reviewed and removed.
- Change management: how changes to code and infrastructure are reviewed and recorded.
- Data classification: how information is labelled and handled by sensitivity.
- Incident response: how security incidents are detected, handled and communicated.
- Encryption and key management: how keys are created, stored and rotated.
- Vendor management: how third-party providers are assessed before and during use.
- Business continuity: how we keep the service running and recover from disruption.
Security training
All employees complete security awareness training when they join and every year after. Engineers receive additional training on secure coding and threat modelling.
Access to customer environments
Support engineers can only access a customer environment to deploy or troubleshoot the platform, and only with an approved, time-limited request. That access never includes your topics or data stores, and every session is logged in the customer's audit log.
Operational security
Monitoring and logging
Our control tower and internal systems are monitored for unusual activity, and security-relevant logs are kept for review. In customer environments, platform health is monitored through the metrics the agent reports.
Incident response
We have a documented incident response process with named owners. If an incident affects your environment or account, we will notify you without undue delay and share what happened, what we have done and what you should do.
Resilience
Because data moves entirely inside your account, your pipelines keep running even if our control tower is unavailable. During such an outage you cannot deploy changes from the dashboard, but the ssctl CLI continues to work against your cluster.
Risk assessment
We review security risks regularly, and whenever our architecture changes significantly, so that our controls keep pace with the product.
Vulnerability disclosure
Found a security issue in StreamSource? Please report it to our security team with a description of the problem, the steps to reproduce it and its possible impact. We will reply within 2 business days and keep your report confidential while we fix it.
Please do not access or change data that does not belong to you, and give us reasonable time to fix the issue before sharing it publicly. Thank you for helping keep StreamSource and our customers safe.