Data retention & privacy
Oho holds some of the most sensitive data an organisation collects about its people: dates of birth, police check outcomes, Working With Children clearances, visa and passport details. This page sets out where that data lives, what happens to it when you remove a record, and what Oho does and doesn't do with it.
It describes how Oho is built. Your own obligations — how long you must keep a police check outcome, what your privacy policy promises your workers — come from your regulator and your legal advice. Retention periods that bind Oho contractually are in your agreement, not in this page.
Where your data lives
| Region | AWS Asia Pacific (Sydney), ap-southeast-2 |
| Data residency | Your records — workers, credentials, check results, attachments — stay in Australia |
| Certification | Oho is ISO 27001 certified |
Uploaded documents are held in a dedicated store. Every object is encrypted at rest with a customer-managed AWS KMS key — the bucket applies it regardless of what the uploading client asks for — and access over anything but TLS is refused. Integration credentials, the secrets that let connectors reach your HR system, are encrypted per tenant rather than stored in the clear.
Where document recognition is enabled, uploaded documents are analysed by an AI model running in Amazon Bedrock, in the same Sydney region. The document is analysed to identify its type; it is not used to train any model.
What removing a record actually does
Oho's default is soft delete: the record is hidden, not destroyed. This is deliberate, and it's the tension at the heart of a compliance platform — the audit trail only means something if it can't be quietly edited, which means deletion can't simply erase.
| Action | What happens |
|---|---|
| Delete a worker | Hidden from every list and search. Credentials, verification history and review items are retained for audit. Open fetch request links stop working immediately and can't be reopened. |
| Delete a credential, exemption, set | Soft-deleted — hidden from listings, retained underneath, marked as removed |
| Restore a deleted worker | Not self-serve — contact support@weareoho.com |
| Permanent erasure | Not available in the app. See Erasure requests below |
Over the API the same rule holds: DELETE marks the record removed and preserves it. Deleted
records can be listed back with includeDeleted=true and carry "deleted": true. The one
documented exception is attachment deletion, which is permanent — see
API Basics.
How long data is kept
Records and their history are kept for the life of the tenant. Oho does not automatically age out worker records, credential history, or Activity Log entries after a set period, and there is no self-serve retention policy to configure.
The practical implication for a buyer: Oho retains by default and removes on request. If your policy requires data to be destroyed after a defined period, that needs to be a term of your agreement and an operational process — it will not happen on its own.
Erasure requests
Where you need data genuinely destroyed rather than hidden — a privacy request from a worker, or the end of a retention period — that's a support-assisted process, not a button in the app. Contact support@weareoho.com with the records concerned.
Two things worth thinking through before you ask:
- Erasure is not reversible, and it removes the evidence too. Destroying a worker's record destroys your ability to show what you checked and when. Where you're under a duty to retain screening evidence, that duty may outlast the erasure request — take your own advice on which wins.
- Soft delete may already be enough. If the requirement is that the person no longer appears in the system and is no longer processed — no longer monitored, no longer in dashboards, no longer contactable — deleting the worker achieves that while keeping the audit trail.
Who can see what
Access is role-based, and scoped by organisation: an administrator over one part of the business doesn't see workers in another. Sensitive detail is not visible to everyone with a login. See Roles and access for the model.
Two access paths deserve particular care:
- API tokens inherit the privileges of whoever created them. A token issued by a Super Admin can read everything that Super Admin can.
- OAuth2 clients act as a shared Super Admin service account. Every OAuth2 client in a tenant has full access, and actions through them are attributed to the service account rather than to the client. See Authenticate with OAuth2 before you use one for anything narrow.
What Oho does with the data
- Verification. Identifiers are sent to the issuing register or authority to confirm a credential — that's the product working as intended. Which authority, per credential type, is set out under Verification sources.
- Delivery back to your systems. Where you've configured a connector or webhooks, outcomes are sent to the systems you nominated.
- Document recognition, where you've enabled it — see above.
Oho does not sell your data, and does not use worker data to train models.
Related
- Audit trail — what history is recorded, and how far back
- Offboard a worker — deactivating versus deleting
- Roles and access — who can see what
- Verification sources — which authority each check reaches