DeveloperOffice SSO
Privacy
How we handle personal data in DeveloperOffice SSO — what we collect, why, who else touches it, and how long we keep it.
1. Who controls the data
The service handles two kinds of personal data, and our role differs for each.
For the accounts of your users — the people who sign in through your tenant — you, the tenant, are the controller and DeveloperOffice is your processor. You decide who has an account and why; we process that data on your instructions to run the service.
For the details of your tenant administrators and billing contacts — the people we deal with to run your account and invoice you — DeveloperOffice is the controller, because we decide how to use them to manage the business relationship.
2. What we collect
For your users: name, email address, a salted password hash (never the password itself), multi-factor authentication credentials, sessions, and an audit log of authentication and administrative events. For your administrators and billing contacts: name, email, and the invoicing and payment records needed to bill you. We also record operational logs needed to run and secure the service.
3. Why we use it
We use user data only to provide the sign-on service on your behalf: to authenticate people, enforce MFA, keep sessions, maintain the audit ledger, and send transactional email such as invitations and security alerts. We use administrator and billing data to manage your account, send invoices, and provide support. We do not sell personal data and we do not use it for advertising.
4. Subprocessors
We use a small number of infrastructure providers to run the service. Each is bound to protect the data they process for us.
| Provider | What they do | Location |
|---|---|---|
| Cloudflare | Edge hosting, application runtime, and network security | Global edge |
| Hetzner | Managed servers hosting the Postgres database | Germany |
Transactional email is sent through Postal, which we run ourselves on our own infrastructure — it is not a third-party subprocessor. We give tenants advance notice before adding or changing a subprocessor.
5. How long we keep it
Retention is set per tenant, with defaults by tier. Audit logs are kept for the retention window configured on your tenant. When a tenant closes, its data is retained for the tenant's retention period so it can be reinstated, then exported and deleted. Sessions and one-time codes expire quickly and are purged automatically.
6. How we protect it
Our security measures include:
- Per-tenant isolation enforced in the database with row-level security keyed to each organization, underneath application-level scoping.
- Passwords stored only as salted PBKDF2 hashes with a server-side pepper, never in plain text; secrets such as client credentials are stored encrypted.
- Multi-factor authentication and passkey support for sign-in.
- An append-only audit log of authentication and administrative actions.
- Encryption in transit (TLS); tenant-isolated storage on a dedicated database accessed through a least-privilege database role. Encrypted off-site backups and network-level database isolation are part of our operational roadmap and are being independently verified.
7. Data subject requests
If one of your users asks to access, correct, or delete their data, that request goes to you as the controller. As your processor we act on your instructions to help you answer it. If you are a tenant administrator or billing contact and want to exercise your own rights over the data we control, contact us directly.
8. Contact
For any privacy question, reach us at sam@developeroffice.com.
Draft — under legal review. Last updated 23 July 2026.
DeveloperOffice · Colombo, Sri Lanka · sam@developeroffice.com