Skip to content
Rooche
Platform Products FAQ Talk to us

Legal

Security

Last updated: September 1, 2026 ← Back to home

This page describes, in plain terms, how the Rooche platform is secured — the architecture decisions and operating practices behind the promises in our Privacy Policy. We would rather tell you exactly what we do (and don’t) than hide behind badges: we do not currently hold third-party certifications such as SOC 2 or ISO 27001, and we won’t claim one until we do.

Sections

  1. Isolation by architecture
  2. Identity & sessions
  3. Encryption in transit
  4. Server-enforced roles
  5. Operational practices
  6. Data protection
  7. Incidents & breaches
  8. Reporting a vulnerability

§1Isolation by architecture

The strongest control on the platform is structural: each customer organization gets its own deployment at its own address (yourcompany.rooche.biz) — its own application containers, its own database, and its own identity store. Customers’ data is not pooled in a shared multi-tenant database, so the classic multi-tenant failure — one customer’s query leaking another customer’s rows — is prevented by architecture, not just by code.

Consumer (personal) accounts live in their own dedicated deployment, separate from every organization workspace, with per-user data isolation enforced on the server.

§2Identity and sessions (CEM)

All sign-in flows go through CEM, our central identity service — one implementation to harden, not one per product.

  • Passwords are stored only as salted hashes, never in plain text, and are never included in support tooling or logs.
  • Third-party sign-in (Google, Facebook, Apple) uses the provider’s OAuth flow — we never see or store your password for those services, only the profile fields listed in the Privacy Policy.
  • Phone sign-in uses short-lived one-time SMS codes.
  • Sessions are tokenized and tied to your account; signing out of a device revokes that device’s session. Email verification and password-reset links are single-purpose and expire.

§3Encryption in transit

Every public surface of the platform — company deployments, product sites, the consumer apps, and our own operator console — is served exclusively over HTTPS/TLS, with certificates provisioned and renewed automatically. There are no plain-HTTP application endpoints.

§4Authorization is enforced on the server

What a signed-in user can see and do is governed by their role, and every check runs on the server — hiding a button is never the security boundary. Administrators manage their own workspace; members see what their role grants; personal accounts see only their own data. The platform’s authorization rules are covered by a standing automated test suite that runs endpoint-level allow/deny cases, so a regression in who-can-do-what fails a build rather than reaching production.

§5Operational practices

  • One audited build for everyone. Every customer runs the same code, differing only by configuration — so a security fix ships to all customers at once, and no customer is stranded on an unpatched fork.
  • Least-access operations. Access to production systems is limited to the personnel who operate and support the service.
  • Secrets are managed as secrets. Credentials and tokens live in the deployment environment, not in source code or client apps.
  • Monitoring. The platform's infrastructure and services are continuously monitored so failures and anomalies surface to the operator quickly.
  • Crash reports carry no personal content. They contain technical diagnostics only (stack traces, app/OS version, device model) — never your data.

§6Data protection and durability

  • Soft deletion first. Deleted records are tombstoned before they are purged, protecting customers against accidental destruction of their own data.
  • Suspension never deletes. A workspace suspended for non-payment keeps its data intact until the balance is settled.
  • Export on the way out. On termination of a paid subscription, we make your data available for export for a reasonable period on request (see the Terms).

§7Incidents and breach notification

No system is perfectly secure, and we won’t pretend otherwise. If a personal data breach occurs that requires notification, we will notify the National Privacy Commission and affected data subjects in accordance with RA 10173 and NPC rules, tell you plainly what happened and what we’re doing about it, and publish a post-incident summary when the facts are established.

§8Reporting a vulnerability

If you believe you’ve found a security issue anywhere on the platform — *.rooche.biz, the mobile or desktop apps — please tell us at hello@rooche.net with “Security” in the subject line. Include what you found, where, and how to reproduce it.

  • We will acknowledge your report and keep you informed as we investigate and fix.
  • Please practice responsible disclosure: give us a reasonable window to fix before publishing, do not access other people’s data beyond what proves the issue, and do not degrade the service.
  • We do not currently run a paid bug-bounty program.

See also our Privacy Policy and Terms of Service. Questions about anything on this page: hello@rooche.net.

© 2026 Rooche Digital IT Solutions, Inc. Privacy · Terms · Security