Security & privacy at Hober
How we protect the data our customers trust us with. Every commitment below maps to a specific, shipped control in the platform — not an aspiration. Where a capability isn't yet in place, we say so plainly further down.
Tenant isolation
Every tenant's data is isolated at the database layer with PostgreSQL Row-Level Security (RLS), and the tables holding sensitive data run in FORCE mode — meaning even the application's own database role cannot read across tenants. Access is scoped per request to a single tenant via a database session variable set inside each transaction; a tenant's API key can never reach another tenant's subscribers, channels, or credentials.
Encryption
Data is encrypted in transit (TLS) and at rest. Secrets and credentials are protected with envelope encryption backed by Google Cloud KMS: each credential is sealed with its own AES‑256‑GCM data key, which is itself wrapped by a KMS key and never stored in plaintext. Distinct keys separate channel credentials, multi‑factor secrets, and OAuth tokens. A database dump on its own yields no usable secret — an attacker would also need live KMS access.
Your data rights (GDPR / CCPA / LGPD)
- Access & portability — a self‑service data‑request portal lets a subscriber (or a customer acting on their behalf) request a copy of their data. Tenant-level portability — full export and shutdown off-ramp — is a written commitment: see our Data Portability & Off-Ramp Policy.
- Right to erasure — erasure requests cascade across a subscriber's records and anonymize historical delivery logs; deletions are irreversible and audited.
- Consent, enforced at send time — every message is checked against the recipient's consent before delivery; withdrawn consent suppresses delivery automatically, not just eventually.
- Immutable consent ledger — every consent change (who, which channel, old and new state, source, time) is recorded in an append‑only ledger.
See our Data Processing Addendum, sub‑processor list, and the preference center.
Data retention
Delivery logs are retained for 90 days, then anonymized. Deletion‑audit records are retained for 7 years as compliance evidence. Personal data is kept until erasure is requested.
Authentication & account protection
- Multi‑factor authentication (TOTP) for both customer users and our own staff/operator console.
- RS256 (RSA) signed sessions with short‑lived tokens.
- Account lockout after repeated failed sign‑in or MFA attempts.
- Password reset and OAuth 2.0 sign‑in.
Least‑privilege access
- Per‑binary database roles: each service runs under its own narrowly‑scoped database role, with no ability to alter schema at runtime.
- Role‑based access control scopes what a user can do within their tenant.
- Our internal operator plane is separated from customer data access, requires MFA, and writes to its own audit log.
Testing & vulnerability management
- An automated security suite runs against staging before any release is promoted to production — verifying at‑rest encryption round‑trips, access boundaries, and that no secret leaks into logs or queues.
- Container image scanning on every build (a critical vulnerability fails the build) plus automated dependency updates.
- Static analysis and linting gate every change.
- A dedicated penetration-test suite exercises authentication, session, and tenant-isolation attack paths pre-release, and a standing least-privilege test role supports external security engagements.
Infrastructure & sub‑processors
Hober runs on Google Cloud (Cloud Run, Cloud SQL, Cloud KMS, Pub/Sub), with
data stored in the United States (region us‑central1). We use a small,
disclosed set of sub‑processors — see the
sub‑processor list and its change log.
Breach notification
We commit to notifying affected controllers of a personal‑data breach within 72 hours (GDPR) / 2 business days for high‑risk breaches (LGPD).
Certifications & roadmap
We believe in being candid about where we are. Hober is not currently SOC 2, ISO 27001, or HIPAA certified. A SOC 2 Type I audit and EU (europe‑west1) data residency are on our roadmap, and we'll update this page as those land — we won't claim them before they're real.
Control mapping
| Commitment | Backing control |
|---|---|
| Tenant isolation | PostgreSQL Row‑Level Security (FORCE mode) |
| Encryption at rest | Cloud KMS envelope encryption (AES‑256‑GCM data keys) |
| Encryption in transit | TLS |
| Right to erasure | subscriber‑erasure cascade + delivery‑log anonymization |
| Consent & opt‑out honored | immutable consent ledger, enforced at send time |
| Data‑subject requests | self‑service data‑request portal |
| Retention limits | 90‑day delivery logs · 7‑year deletion audit |
| Authentication | user + staff TOTP MFA · account lockout · RS256 sessions |
| Least privilege | per‑binary database roles · tenant‑scoped RBAC |
| Vulnerability management | pre‑release security suite · image + dependency scanning |
Report a vulnerability
Found a security issue? We want to hear from you. Email security@hober.io with details and steps to reproduce. We'll acknowledge your report and keep you updated on the fix. Please give us a reasonable window to remediate before any public disclosure.
Our machine-readable security.txt lives at
/.well-known/security.txt.
In scope: the Hober web properties (hober.io and its subdomains), the dashboard, the public API, and the published SDKs.
Out of scope: denial-of-service or volumetric testing, social engineering or phishing of Hober staff or customers, physical attacks, and findings that require an already-compromised device or stolen credentials.
Safe harbor: we will not pursue or support legal action against good-faith security research that stays within scope, avoids privacy violations and service disruption, and allows a reasonable remediation window before public disclosure. We do not currently run a paid bounty program — we say that plainly rather than imply one.