Security at Kayden Connect

Security posture

Kayden Connect is a multi-tenant SaaS platform for internal communications. We designed it with three principles in mind: keep tenants strictly isolated, give administrators clear control over who can see what, and host data in the European Union by default. Our engineering practice follows the SOC 2 Common Criteria controls (we have not yet completed SOC 2 certification — see the compliance roadmap below).

This page describes the controls that are live in production today. Everything marked “in progress” or “on roadmap” has not yet been delivered.

Data residency

Customer data is stored in Google Cloud’s europe-west1 region (St. Ghislain, Belgium). This includes our PostgreSQL database (Cloud SQL), Firebase Authentication directory, Firebase Storage uploads, and Cloud Run compute. We do not replicate primary customer data to other regions.

A small number of operational sub-processors (transactional email, payments, video hosting, bot protection, marketing analytics) operate from the United States or globally. Where personal data is transferred outside the EEA or UK, we rely on the European Commission’s Standard Contractual Clauses and the UK International Data Transfer Addendum. The full list is on our Sub-processors page.

Encryption

• In transit: all traffic between your browser and Kayden Connect is encrypted with TLS 1.3 (TLS 1.2 fallback for older clients). HTTP Strict Transport Security is enforced on both app.kaydenconnect.com and www.kaydenconnect.com.
• At rest: all customer data is encrypted at rest with AES-256. This is the default for Google Cloud SQL, Firebase Storage, and Firestore — keys are managed by Google Cloud KMS.
• Backups: Cloud SQL automated backups inherit the same AES-256 encryption and are stored in europe-west1.

Access control

Every API call is authorised against the caller’s tenant and role. The tenant identifier is bound to the user’s session at sign-in and cannot be spoofed by the client.

Roles inside a tenant:

• SUPER_ADMIN: full administrative control over the tenant, including billing and member management
• COMMS_ADMIN: content, campaigns, and tenant-wide communications; cannot manage billing
• SPACE_ADMIN: moderates a single space (group); no tenant-wide permissions
• EMPLOYEE: standard member; can post and react within permitted spaces

Tenant isolation: data is partitioned by tenant on every query. Tenant-scoped policies run server-side; the client never supplies the tenant ID.

Session controls: administrators can revoke all active sessions for a user at any time. Sessions also expire automatically after a configurable idle period.

Internal access: Kayden Connect employees do not access tenant content as part of normal operations. Production access is gated, logged, and limited to engineers responding to a specific support request or incident.

Authentication

• Identity provider: Firebase Authentication. Supported sign-in methods are email + password, Google SSO, and Microsoft SSO.
• Multi-factor authentication: available today via your Google or Microsoft identity provider when SSO is used. Standalone TOTP MFA for email/password accounts is on the roadmap.
• Session cookies: the application uses HTTP-only, Secure, SameSite=Lax session cookies. Cookies are not readable by client-side JavaScript and are sent only over HTTPS.
• Password policy: enforced by Firebase Authentication (length and complexity minimums, breached-password protection where available).
• SCIM and SAML: on the roadmap for the HQ tier. Not available today.

Audit logging

We record an audit event for security-relevant actions taken inside a tenant. Events include: sign-in and sign-out, role changes, member invitations, content publication and deletion, billing changes, and administrative configuration changes. Each entry captures the actor, the affected resource, a timestamp, and source IP.

Retention by tier:

• Spark: 90 days
• Command: 90 days
• HQ: retained for the life of the subscription

Tamper-evident, append-only audit storage on the HQ tier is on the roadmap; today audit records are stored in the same Cloud SQL instance as application data, with application-level write protections.

Sub-processors

We engage a small number of third-party sub-processors to deliver the Service. The current list, including the data category and processing region for each sub-processor, is published at /legal/sub-processors. We notify customer administrators by email at least 30 days before adding a new sub-processor that handles customer content.

Vulnerability disclosure

If you believe you have found a security vulnerability in Kayden Connect, please report it to legal@kaydenconnect.com with the subject line “Security disclosure”. Please include:

• A description of the issue and the steps to reproduce it
• The URL, request, or component affected
• Any proof-of-concept material (screenshots, requests, scripts)
• Your name or handle if you want to be credited

Our commitment to you:

• We acknowledge every report within 3 business days.
• We will not pursue legal action against good-faith researchers who follow this policy, avoid privacy violations and service disruption, and give us a reasonable opportunity to remediate before public disclosure.
• We will keep you informed as we investigate, and credit you in our security acknowledgements unless you ask us not to.

Please do not run automated scanners, denial-of-service tests, social engineering attacks, or physical intrusion attempts. Test only against accounts you own.

Incident response

We maintain a written incident-response procedure that covers detection, triage, containment, eradication, recovery, and post-incident review. Our on-call engineer is alerted by Google Cloud Monitoring on availability and error-rate thresholds.

Customer notification: in the event of a personal-data breach affecting your tenant, we notify the affected customer’s administrators without undue delay and within 72 hours of becoming aware, consistent with our obligations under GDPR Article 33 and POPIA. Notifications include what we know about the affected data, the suspected cause, the steps we are taking, and any actions we recommend the customer take.

If you suspect an active incident affecting your tenant, contact legal@kaydenconnect.com or your primary support contact. The current operational state of every Kayden Connect subsystem is published on our Service status page.

Compliance roadmap

We believe in being honest about where we are. Below is the truth as of the date stamped at the bottom of this page.

If your procurement process requires evidence of a control we have not yet certified, please reach out — we are happy to share our internal control documentation and remediation plan under NDA.

Bug bounty

We currently operate a coordinated-disclosure program rather than a paid bug bounty. Researchers who follow the vulnerability disclosure policy above will be acknowledged publicly (with consent) and may receive Kayden Connect swag.

A monetary bounty program is on the roadmap for V1.5. We will publish the scope, excluded targets, and reward bands when it launches.