Access & identity
Every request to SERVORA is authenticated and then checked against what the signed-in person is allowed to do.
- Password storage. Passwords are hashed with Argon2id, a modern algorithm designed to resist brute-force attacks. We never store passwords in readable form.
- Sessions. Access tokens are short-lived. Refresh tokens rotate on use, and reuse of an old refresh token is detected so the session can be revoked.
- Role-based access control. Permissions are expressed as resource.action rules (for example, approving a document). The platform includes system roles for Owner, Admin, Consultant, QA and Client.
- Client portal users are always scoped to their own client. They cannot see other clients, other projects or your internal work.
Tenant isolation
SERVORA is a multi-tenant platform: many organizations use the same infrastructure, and each organization’s data is kept separate.
- The organization a request operates in is derived from the authenticated membership, never from ids or parameters supplied in the request.
- Asking for a record that belongs to another organization returns “not found”, so the platform does not even confirm that the record exists.
- A person can belong to more than one organization, and each membership carries its own role and permissions.
Data & documents
Documents are often the most sensitive part of a service. They are handled differently from ordinary records.
- Files are kept in private storage. There are no public object URLs.
- Each file is stored with a checksum, so its integrity can be verified, and with version history, so earlier versions are not silently overwritten.
- Downloads are served through signed links that expire after a short time and are issued only to people with permission to view the document.
- Write operations in the API are idempotent, so a retried request does not create duplicate records or documents.
Auditability
When something important happens, you should be able to see who did it and when.
- Significant actions, such as approvals, status changes and permission updates, are written to an append-only audit trail.
- Each project and client has an activity timeline that shows its history in context.
- Published workflow versions are immutable, so you can always tell which rules a project followed.
Reliability & observability
- Reliable notifications. Notifications and events are written to a transactional outbox together with the change that caused them, so a message is not lost if a downstream service is briefly unavailable.
- Observability. The platform exposes health checks, metrics and tracing so issues can be detected and investigated quickly.
- Documented API. The REST API is described with OpenAPI, which keeps integrations explicit and reviewable.
Responsible disclosure
If you believe you have found a security vulnerability in SERVORA or this website, we would like to hear from you.
- Please report it through our contact form, starting your message with “Security report”. Include enough detail for us to reproduce the issue.
- Give us reasonable time to investigate and fix the issue before sharing it publicly.
- Do not access, change or delete data that does not belong to you, and do not degrade the service for others while testing.
We will acknowledge reports we receive and keep you informed of progress. A dedicated security contact channel will be published here when it is available.
What we don’t claim
This overview describes how the platform is designed. Specific commitments for customers are set out in the agreements we sign with them.