Security
How we protect what you put here.
Serene Studio is a privacy-first productivity platform for small and midsize businesses — branded email, files, contacts, calendar, chat, newsletters, and a company website, under one login and one bill. This page explains, plainly, how we protect the data you trust to it.
Where something is designed but not yet shipped, it appears under a calm “On our roadmap” marker. We would rather tell you plainly what is built and what is coming than blur the two. Last reviewed 11-Nov-2026.
Our commitments, in plain terms
Your data is yours
We do not sell it, share it with advertisers, or feed it to third-party analytics. There are no trackers, ad SDKs, or session-replay tools anywhere in the product — enforced by written repository policy, not just good intentions.
Passwordless-first identity
The platform is its own identity authority. Sign-in is built around passkeys and authenticator-app MFA, with external providers and email links as a first step only — and full session revocation.
Tenant isolation by design
Every business on the platform is scoped at a server-side authorization checkpoint. Data rows carry tenant identity; cross-tenant access is refused at the database query layer, not filtered in the UI.
A small, auditable surface
The platform runs on Cloudflare's edge with TLS on every connection, encryption at rest, daily automated database backups, and an audit log of identity and administrative events.
Disciplined engineering
Every change reaches production through a pull request with required automated checks: type checking, tests, and secret scanning. Static analysis also runs on every pull request. Known vulnerabilities are fixed on a written schedule, set out below.
A small company, on purpose
We treat our size as a security feature: the people who write this platform are the people who answer for it. Where we have not yet earned a claim, we say so below rather than implying otherwise.
Identity and authentication
Serene Studio maintains its own user records. External identity providers — Microsoft, Google, LinkedIn, GitHub — act as authenticators only: they can prove you control an account, but they are never the source of truth for who you are on the platform. Sign-in and the platform itself run on studio.onserene.io, so tenant-branded domains never handle raw credentials themselves.
Passwordless-first sign-in
- Passkeys (WebAuthn). Phishing-resistant credentials — the strongest option we offer, and the one we encourage. Use the passkey built into your phone or computer, a synced passkey from your password manager, or a hardware security key such as a YubiKey. Every passkey sign-in requires user verification (your PIN, fingerprint or face), so a key on its own is never enough.
- Magic links. Single-use, expiring sign-in links. Redemption happens on an explicit user action, not on the link being fetched — so corporate mail scanners that pre-open links cannot consume them on your behalf.
- External providers. Microsoft, Google, LinkedIn, and GitHub — under the explicit-linking rule below.
Explicit linking, never email matching
Many platforms silently attach a new “Sign in with X” identity to an existing account because the email addresses match — a known account-takeover vector. We deliberately do not. An external identity is bound to a Serene Studio user only when an already-authenticated user explicitly links it from their own settings. This is enforced in the identity-linking code path itself, not by convention.
Multi-factor authentication
Every account signs in with a passkey or an authenticator app. A passkey sign-in already requires your PIN, fingerprint or face. Signing in through an external provider or an emailed sign-in link counts as a first step only: the platform then asks for your passkey or your authenticator app's six-digit code before it opens your workspace. Backup codes are for recovering an account, not for everyday sign-in, and a code sent to your email is never accepted as a second factor. Authentication surfaces are rate-limited against guessing.
Sessions you can actually revoke
Sessions are first-party, host-only cookies (HttpOnly, Secure, and bound to the exact hostname that issued them), backed by a server-side session store. Revoking a session — or all of a user's sessions after a suspected compromise — deletes the server-side record, and the platform refuses the stale cookie from then on. Identity-significant events are written to an audit log.
Tenant isolation and encryption
Every business on Serene Studio is a tenant, and isolation is enforced server-side, in code paths every request must pass through. Requests resolve to exactly one tenant context before any module logic runs. Authorization decisions go through a single capability resolver — one checkpoint, not per-page ad hoc checks — and core data tables carry a tenant identifier, so queries are scoped to the caller's tenant at the database layer.
Sharing outside a tenant happens only through explicit, revocable mechanisms — for example, guest file links, which can be revoked at any time — never through implicit visibility. Per-tenant resource controls, including storage quotas, apply on top.
Encryption
- In transit: TLS on every connection, everywhere, always.
- At rest: all platform data stores are encrypted at rest by Cloudflare as the infrastructure provider.
- Secrets and connector credentials a tenant supplies are held in dedicated encrypted vault modules, never as plaintext rows.
- Files: the files you upload are also encrypted with a key specific to your tenant, on top of the provider-level encryption above.
Data protection and privacy
These commitments are structural — several are enforced by written repository policy that blocks the relevant software from ever being added.
- No third-party trackers. No analytics SDKs, no ad SDKs, no session-replay tools, no third-party beacons — anywhere in the product, including admin surfaces.
- Self-hosted fonts. Font CDNs are a tracking vector, so fonts ship with the application.
- No selling or sharing of data. We do not sell customer data, share it with data brokers, or use it for advertising. Full stop.
- Data-footprint minimization. By standing engineering rule, logs reference entities by internal ID, not personal information; identifiers are hashed where a hash suffices; personal data is rendered only in the authenticated view that needs it; features collect only what they actually need.
- Sanitized rendering. Inbound email HTML is sanitized and displayed inside sandboxed per-message frames, limiting what hostile mail content can do in your browser.
- Short lifetimes. Sessions have a fixed maximum lifetime. Sign-in links expire within minutes and can be used only once.
- An encrypted offline cache you can clear. To open pages quickly, your browser keeps an encrypted copy of recent chats and notifications. It is removed when you sign out or switch workspaces, and you can clear it yourself in Settings.
- Children. Serene Studio and our websites are not directed at children under 13, and we do not knowingly collect personal data from children under 13. Where we learn we hold such data, we delete it.
Our Terms of Service andContent Policy cover the Serene Studio platform. Our Privacy Policy is published here as well. Questions about how the platform handles personal data go to the address at the foot of this page.
Platform and pipeline
Serene Studio is built natively on Cloudflare's developer platform: Workers for compute, D1 for structured data, R2 for files, KV for short-lived operational state. Cloudflare operates and patches the runtime that runs our code, so we have no long-lived application servers to patch, no SSH ports to expose, and no shared virtual machines holding customer data. A dedicated backup process is scheduled to export the primary database to durable object storage every day — automated, not operator-remembered.
Security in the pipeline, not just in the product
- PR-only production. The production branch cannot be pushed to directly; every change arrives via a pull request with required automated checks — type checking, tests, and secret scanning. Static analysis also runs on every pull request, and dependencies are monitored across repositories.
- A written patching schedule. For every known vulnerability in software we run, the clock starts when the advisory is published or we raise our own alert, and stops when the fix is live in production, not when it is merged. If a vulnerability is known to be exploited and can be reached in our deployment, we reduce the risk within 48 hours (for example with a configuration change or a feature flag) and fix it within 7 days. Other critical or high-severity issues that affect us are fixed within 7 days, and everything else that affects us within 30 days. If a vulnerability cannot be reached in anything we run, we record why and close it. The schedule covers our code dependencies, the operating-system packages on the Linux servers we run, and the containers we run, such as the document-editing engine. Cloudflare patches its own platform. We adopted this schedule in October 2026; alerts raised before then are still being worked down against it.
- Approval-gated deploys. Merging to production is gated: an operator must explicitly authorize each item before automation will merge it.
- Integrity-verified migrations. Database migrations are applied through a controlled pipeline that verifies a cryptographic hash of the SQL — a mismatch is refused, never applied — and records each migration atomically in an applied-migrations ledger.
- Drift detection. A scheduled check verifies that what is deployed matches the repository, catching silent drift between what is reviewed and what is running.
Disaster recovery is a redeploy-plus-restore exercise, not a rebuild-from-memory exercise: infrastructure is declared in version-controlled configuration, the database is restorable from its exported backups, and application code redeploys from the repository. The platform inherits Cloudflare's global global network, DDoS absorption, and edge redundancy.
Where we stand on compliance
We will be straightforward here, because trust pages that imply certifications a company does not hold are exactly the pattern we built this platform against.
What is true today: we are a U.S. limited liability company; our privacy, terms, and content policies are published; our terms and content policy cover the platform; and the controls described on this page — tenant isolation, encryption in transit and at rest, audit logging, backup automation, CI security gates — are operating controls, verifiable in our engineering practice, not aspirations.
What we do not have yet: we have not undergone a SOC 2 examination, and we do not claim ISO 27001, HIPAA, or PCI DSS. The platform does not process payment card data directly — payments are handled by a dedicated payment processor — and is not offered as a HIPAA-covered service. We apply data-minimization and deletion principles globally because they are good practice, but we have not yet completed a formal GDPR readiness program.
If a certification or attestation matters to your evaluation, ask us — we would rather discuss our actual controls with your team than hide behind a badge.
Reporting a vulnerability
Email privacy@serenecreations.iowith “SECURITY” in the subject line, and include enough detail to reproduce the issue. We commit to acknowledging good-faith reports promptly, keeping you informed of remediation, and not pursuing legal action against good-faith research that respects user data and avoids service disruption.
Privacy questions and data requests go to the same address. This page is reviewed and updated as the platform evolves.