Security
The security model, described as it is built.
Operanto handles customer data on behalf of the organisations that trust it. This page describes the concrete controls in the system — not an abstraction of them, and not badges we have not earned.
Invitation-only access
There is no self-serve signup. An account exists because an administrator of an organisation invited that specific person. Access starts closed and is opened deliberately.
Organisation-scoped authorization, re-checked per request
Operanto is multi-tenant, and every request re-verifies that the signed-in user belongs to the organisation that owns the data being touched. Scoping is enforced on each request, not assumed from a session.
Role-based permissions
What a user can see and do is bound to their role within their organisation. Responsibility in the product maps to permission in the system.
Signed webhooks with replay protection
Inbound events must carry a valid HMAC-SHA256 signature over the payload, computed with a per-integration secret. Deliveries are timestamped; stale or replayed deliveries are rejected before any processing happens.
Idempotent event processing
Each event is processed exactly once. A network retry, a duplicate delivery, or a replay attempt cannot create duplicate customers, leads, or tasks.
Encrypted integration secrets
Secrets used to verify and connect integrations are stored encrypted with AES-256-GCM at the application layer, not kept in plaintext at rest.
Full audit trail
Actions are recorded with who performed them, when, and against which record — including AI-assisted actions, which are audited the same way as manual ones.
Session revocation
Sessions can be revoked server-side. When access is withdrawn, it ends — without waiting for a token to expire on its own.
What we do not claim
We do not display compliance logos or certifications here. If a specific certification or assessment matters to your organisation, ask us directly where we stand — we will give you a straight answer.