Security

This is the control that matters most, so it comes first. Every Workspace lives under its own identifier inside one of four top-level stores — individuals, businesses, enterprises, and visitors for trials — and every read and write is scoped to the identifier carried in your signed session token.

The scoping is enforced on the server and again by database rules, not by hiding things in the interface. A request for another organisation's record fails at the source regardless of what the client asks for, so a modified client, a replayed request or a guessed identifier gains nothing.

Within your Workspace, role permissions are enforced the same way. An assignment is private to the people on it; what a role cannot see, it cannot request — and that includes through VO, which never exceeds the permissions of the person asking.

• Passwords are hashed with bcrypt at 12 rounds. They are never stored, logged or transmitted in readable form, and we cannot recover one for you — only reset it.
• Sessions use signed JWTs with a 7-day expiry. Where a server session cookie is used it is marked httpOnly, secure and sameSite, so page scripts cannot read it and it is not sent on cross-site requests.
• Google OAuth is available for sign-in.
• Two-factor authentication (2FA / MFA) is mandatory on every account and cannot be turned off. Since September 2026 every sign-in — password or Google — is completed with a one-time code. A password on its own does not open an account, for anyone, on any plan, including the free one.
• An authenticator app, per person. Anyone can enrol Google Authenticator (or any TOTP app) from their own settings and take their codes off the phone instead of the inbox. Enrolment is proven with a live code before it is accepted, one code cannot be replayed inside its thirty seconds, and the shared secret is sealed with AES-256-GCM under a key that never leaves the server — a copy of the user records is not a set of working authenticators.
• Email is never removed. There is deliberately no authenticator-only mode: both options sit on the sign-in page every time, so a lost phone is a nuisance rather than a lock-out.
• Enterprise SSO — SAML 2.0, OAuth 2.0 and OpenID Connect, tested against Okta, Microsoft Entra ID, Google Workspace, OneLogin, Auth0 and custom SAML identity providers. Available on Enterprise agreements.
• reCAPTCHA protects sign-up and sign-in against automated abuse.

The platform runs on Google Cloud Platform (Firebase) in the us-central1 region, on managed, auto-scaling infrastructure. Google's own compliance certifications for that infrastructure — including SOC 1, 2 and 3 and ISO 27001 — cover the layer we build on. They are Google's certifications, not ours; we do not currently hold an independent SOC 2 or ISO 27001 audit of our own, and we will say so on this page when that changes.

Data is encrypted in transit with TLS and at rest with AES-256, including uploaded files. All traffic is HTTPS; certificates are managed automatically.

Standard hardening headers are applied to responses: Strict-Transport-Security, X-Content-Type-Options: nosniff, X-Frame-Options: DENY and a Content Security Policy.

Limits protect availability for everyone and blunt credential-stuffing and scraping. Ordinary use will not reach them.

VO additionally meters a daily token budget per account, set by the VO your Workspace has, and reset each day at midnight Pakistan Standard Time.

Roles decide what a person may open. A lock decides whether they may open it today, and the two are deliberately separate.

The Workspace owner can lock any dashboard from Access & Security. A person who holds the role still holds it — the menu, the permissions, the entitlement — and still cannot open the room until the owner generates a code and hands it over. It is the control for the rooms where the role is not the whole question: payroll, the ledger, partner-level figures.

The same separation is what makes an exported seat safe to grant quickly: give somebody the role they need to work, and keep the room that holds the money shut until you decide otherwise.

Uploads are stored in Google Cloud Storage, encrypted at rest, and served only to authenticated members of the owning Workspace — downloads are authorised per request, not exposed as public links. Maximum upload size and total storage depend on your plan and are shown on the pricing page.

Actions inside a Workspace are written to an immutable audit trail recording who acted, what they acted on, when, and what changed. It cannot be edited or deleted from the application — including by an administrator — because a log an administrator can rewrite is not evidence of anything.

Backups. The production database is backed up every night and kept for 30 days, with point-in-time recovery over the last 7 days and delete protection on the database itself. A restore from a real nightly backup was last tested on 9 September 2026 and is re-tested quarterly; the date is published on the trust page.

The recycle bin. Almost everything anyone deletes inside a Workspace — a project, a task, a client, a file, a record, and everything inside it — is placed in a recycle bin for 30 days. The principal can bring it back with one press, through the same plan limits a new record goes through, or let it go early. After 30 days it is purged for good. Not covered: a handful of records removed inside a database transaction, and a full Workspace wipe, which keeps its own archive.

Your data, in one file. From Settings → Data & Recovery the principal can download the whole Workspace as a single ZIP — every record and every file, drawings and photographs included — at any time, on any plan. The archive is signed when it is made; the download link lives for one hour; each download is written to the audit trail. It contains your staff's and clients' personal data, and once it is on your computer it is yours to protect.

Restoring it. The same ZIP restores into the same Workspace or a brand-new one. Records already present are never overwritten. An archive that was altered, or was not made by Ofivio, is refused before anything is written. What does not travel between Workspaces is a person's login: restored users arrive inactive and the principal re-invites them.

Deleting a Workspace. A principal can delete the Workspace. Everyone else is signed out at once, but nothing is removed for 30 days, during which one press undoes it. After 30 days it is archived and purged. A lapsed subscription is different and gentler: the Workspace is suspended and kept for 90 days.

Half of any organisation's security is on the organisation's side, and we would rather say so than imply otherwise:

• Use a strong, unique password. Do not reuse one from another service — and enrol an authenticator app from your settings.
• Remove seats when people leave. A departed employee's account is the most common way an organisation's data walks out.
• Grant the narrowest role that lets someone do their job, and review it periodically.
• Treat exports as you would any other copy of your data — once downloaded, it is outside our controls entirely.
• Tell us immediately at contact@ofivio.com if you suspect an account is compromised.

Two-factor authentication is on by default and an authenticator app is available to every person — see section 2. What is not offered is a hardware security key or a passkey (WebAuthn/FIDO2). That is on the roadmap and this page will say so when it ships. We would rather tell you that than let you assume a protection you do not have.

If we become aware of a breach affecting your data we will notify you and the relevant authority without undue delay, telling you what we know, what is affected, and what we are doing. We will not wait until we have a complete picture to tell you that something happened.

If you have found something, we want to hear about it. Write to contact@ofivio.com with the subject line Security, describing what you found and how to reproduce it.

• We aim to acknowledge within two business days and to keep you updated until it is resolved.
• Please give us a reasonable opportunity to fix it before disclosing it publicly.
• Please do not access, modify or exfiltrate data belonging to anyone else while investigating, and do not run tests that degrade the service for other customers.
• We will not pursue a researcher who reports in good faith and stays within those bounds.

We do not currently run a paid bug bounty. We do credit reporters who would like to be credited.