Security

Scope of this page

This document covers the Ownstack platform posture reflected in production today: the control plane (launch, billing, entitlements, admin tools, and marketing intake) and the per-brand runtime environments where client apps, booking, and payments operate. It applies to ownstack.co and the shared platform services that power live tenant brands unless a signed agreement states otherwise.

Architecture principles

• Role-based access control (RBAC) for owner and admin surfaces
• Tenant isolation and entitlement boundaries between brands
• Audit trails for lifecycle-changing and operator-sensitive actions
• Server-owned writes for public intake, billing mutations, and Demo Studio changes
• Fail-closed feature gating when entitlements or runtime posture are unavailable

These principles guide how we design new features: privileged behavior runs on the server, client apps request capabilities rather than granting them, and cross-brand data paths are treated as exceptional rather than default.

Data separation model

Ownstack separates the control plane from each brand’s runtime environment. The control plane holds launch workflows, commercial posture, owner tooling, and marketing lead intake. Each runtime holds that brand’s client accounts, appointments, service catalog, and payment activity for end customers.

How separation works in practice

• Each live brand runs against its own Firebase project and runtime boundary — not a shared “one database for all tenants” model.
• Control-plane records (inquiries, demo requests, billing views, entitlements) live in the Ownstack control-plane project and are accessed only through authenticated operator flows or server functions.
• End-customer and day-to-day operational data for a brand stays in that brand’s runtime unless an integration explicitly copies a subset elsewhere (for example CRM sync of lead contact details).
• Entitlements and commercial posture are authored in the control plane and mirrored into runtime so client-facing capabilities reflect what the brand is allowed to use.
• Demo, sales-preview, and public marketing routes are isolated from production tenant runtime data and are excluded from public search indexing where appropriate.

Data categories

• Marketing lead data — contact details and context submitted through ownstack.co forms (demo, inquiry, investor, newsletter).
• Tenant operational data — bookings, client profiles, service history, and staff workflows inside a brand’s live app.
• Payment metadata — Stripe references, charge status, and reconciliation fields; not raw card numbers (see Payment data handling).
• Operator audit data — records of who changed launch, billing, or demo state and when.

Data processing terms for marketing-site submissions are summarized on our Data Processing page. Customer and end-user data in live tenant apps is governed by tenant agreements and applicable privacy terms.

Payment data handling

Ownstack does not store raw payment card numbers (PAN), CVV, or magnetic-stripe data in tenant runtime or control-plane databases.

Stripe as the cardholder data environment

• Stripe handles card capture, tokenization, and payment processing for tenant client payments and for Ownstack platform billing where Stripe is enabled.
• Card entry surfaces use Stripe-hosted or Stripe-tokenized flows so sensitive card data stays within Stripe’s PCI-scoped environment.
• Ownstack stores payment-related metadata needed to operate the product — Stripe customer IDs, payment-intent references, charge status, receipt links, and reconciliation fields — not cardholder data itself.

Server-side payment integrity

• Stripe webhooks and server-side verification drive payment state changes rather than trusting client-reported outcomes alone.
• Platform billing credentials and webhook secrets are held in managed secret storage, not committed to source control or public site builds.
• Separate Stripe accounts or credential scopes may apply between tenant client payments and Ownstack platform billing.

Merchants remain responsible for their Stripe account configuration, payout settings, dispute handling, and compliance with Stripe’s terms and applicable payment rules for their business. Ownstack does not claim PCI DSS certification as a service provider; card data is handled by Stripe as the payment processor.

Access control model

Access is layered: identity first, then role, then entitlement, then document-level rules. The goal is that a user, operator, or automated job can only reach the data and actions required for their function — and nothing else by default.

Identity and sessions

• Firebase Authentication secures user sign-in for owner and client surfaces.
• Privileged Cloud Functions and callable endpoints validate auth context before executing sensitive logic.
• Public marketing forms do not grant authenticated access; they write through dedicated server endpoints with abuse controls.

Operator RBAC

• Admin and control-plane actions are scoped by role (for example super-admin, support, and tenant-scoped operator permissions).
• Sensitive functions refuse execution outside the intended control-plane Firebase project.
• Demo Studio, billing, and launch tooling require authenticated operator context; there is no anonymous path to mutate tenant commercial posture.

Entitlements and fail-closed gating

• Feature access is driven by mirrored entitlement state from the control plane into each brand runtime.
• When entitlement or runtime posture cannot be verified, gated capabilities fail closed rather than silently widening access.
• Add-on modules (analytics, specialty workflows, commerce growth, and similar) are enforced as entitlement-governed capabilities, not always-on defaults.

Firestore security rules and secrets

• Client reads and writes are constrained by Firestore security rules aligned to tenant membership, role, and document ownership.
• Third-party API keys, webhook secrets, and integration credentials are injected at runtime from secret management — not baked into public site builds or mobile bundles beyond public keys where required (for example reCAPTCHA site keys).

Audit log policy

Ownstack favors append-style operational records for actions that change lifecycle, ownership, billing posture, or operator-visible state — rather than silent overwrites with no trace.

What we record

• Demo Studio and operator workflows record actor, action, target path, and status transitions for key mutations.
• Public lead intake (inquiries, demos, investor requests, newsletter signups) is written through server endpoints with timestamps, source context, and consent flags where applicable.
• CRM sync and automation events produce traceable downstream activity in logs and synced records when HubSpot or email integrations are enabled.
• Cloud Function and platform logs support investigation of failed submissions, payment webhook handling, and integration errors.

What audit data is — and is not

• Audit data supports operator review, support investigation, and post-incident reconstruction.
• It is not marketed as an immutable legal archive, WORM storage, or standalone compliance attestation.
• Retention follows operational needs and provider defaults unless a contract specifies otherwise.

Public marketing intake

Forms on ownstack.co (demo booking, business inquiry, investor inquiry, newsletter signup) use layered abuse prevention before records reach operator workflows:

• Rate limiting on submission endpoints keyed by IP and contact identifiers
• Consent checks where required (for example follow-up and contact permission)
• Honeypot fields on applicable flows to discard automated spam without persistence
• Google reCAPTCHA v3 when configured, validated server-side with secret management
• Server-owned writes only — forms do not write directly to Firestore from the browser

Subprocessors

Ownstack uses vetted infrastructure and service providers to operate the platform. The list below reflects common subprocessors in current production workflows. A specific tenant, integration, or contract may reference additional providers during onboarding.

• Google Cloud / Firebase — hosting (ownstack.co), authentication, Firestore database, Cloud Functions, Secret Manager, and related Google Cloud infrastructure. Underlying provider controls apply to encryption in transit and at rest within Google’s environment.
• Stripe — payment processing for tenant client transactions and Ownstack platform billing; cardholder data environment for tokenized card flows.
• HubSpot — CRM sync for qualified leads, inquiries, and demo requests when enabled for Ownstack team follow-up.
• SendGrid / email delivery vendors — transactional email, automation sequences, and operator notifications.
• Google Calendar / scheduling integrations — demo and operator scheduling where configured.
• Slack — internal operator notifications for new demo requests when configured.
• Google reCAPTCHA — abuse prevention and bot scoring on public forms.

See also our Privacy Policy and Data Processing pages for marketing-site data handling and subprocessors referenced there.

What Ownstack does not claim (today)

We believe in being direct about scope. Unless explicitly stated in a signed agreement, Ownstack does not represent or warrant that it holds:

• SOC 2 Type I or Type II certification
• HIPAA compliance or a Business Associate Agreement (BAA) by default
• PCI DSS certification as a service provider (card data is handled by Stripe)
• ISO 27001, FedRAMP, or other formal security attestations
• A published uptime SLA or formal disaster-recovery certification on this page
• Penetration-test or vulnerability-assessment reports as a public deliverable

If your organization requires a formal security questionnaire, custom DPA, BAA evaluation, or specific compliance review, contact us during sales or onboarding so we can scope what is available today versus on a roadmap.

Incident reporting and security contact

To report a suspected vulnerability, unauthorized access, data exposure, or other security concern related to Ownstack infrastructure or ownstack.co:

How to report

• Email support@ownstack.co with subject line Security Report
• Include affected URLs, tenant or brand context if known, steps to reproduce, and a brief impact assessment
• Do not include live secrets, credentials, full payment details, or unrelated customer personal data in initial reports

What happens next

• We review good-faith reports and acknowledge receipt when valid contact details are provided.
• We triage severity, reproduce where possible, and remediate confirmed issues on a reasonable operational timeline.
• We may request additional detail under confidentiality expectations; we do not publish a formal bug-bounty program or guaranteed remediation SLA on this page.

Customer and merchant responsibilities

Security is shared. Business owners using Ownstack are responsible for:

• Protecting staff account credentials and removing access for departed team members
• Configuring Stripe, payout, and tax settings appropriate to their business
• Using strong device and account hygiene on devices that access admin tools
• Informing Ownstack promptly if they suspect unauthorized access to their brand or data
• Complying with applicable laws for their clients (privacy notices, consent, record retention)