Technical and Organizational Measures (TOMs)
Last updated: July 16, 2026
This document describes the technical and organizational measures Rivo applies to provide a level of security appropriate to the risks of processing personal data, candidate profiles, and financial or billing records.
1. Confidentiality
1.1 Physical-access controls
Rivo uses serverless hosting and managed cloud environments. Cloudflare Pages hosts the application on a global CDN, while Supabase stores the database and files on EU-based AWS infrastructure. AWS and Cloudflare manage data-center physical security—including biometric access controls, 24/7 video monitoring, and physical barriers—under standards such as ISO 27001 and SOC 2 Type II.
1.2 Logical-access controls
Role-based access control (RBAC) is enforced. Before private pages are served, server-side hooks validate cryptographic user sessions. Administrator routes require an administrator account and least-privilege role; employer routes require an employer account; job-seeker routes require a job-seeker account.
Database credentials, payment codes, and webhook secrets are supplied at runtime as environment variables and are never committed to source code or version control.
1.3 Data-access controls
Row-Level Security is enabled on database tables so users can read or change only their permitted data. Organization access to vacancies and candidates follows database roles such as owner, administrator, recruiter, and member. Privileged database functions use a fixed, secure search path to prevent schema manipulation and unauthorized privilege use.
1.4 Transfer controls
HTTPS is mandatory for public endpoints. Cross-origin POST requests are blocked, and every payment webhook is verified with a cryptographic signature.
2. Data integrity
2.1 Payment and transaction integrity
- Signature verification: payment webhooks are checked by a secure validation algorithm using the payment module’s secret key.
- Replay prevention: the system rejects a transaction when the related payment is already complete.
- Atomic operations: database updates prevent duplicate credit awards and race conditions between concurrent webhooks.
2.2 Hardening and manipulation prevention
- Profile-takeover prevention: database rules block unauthorized changes to user roles and identifiers.
- Strict validation: the database validates credit amounts, operation types, and organization-plan limits before changing a balance.
3. Availability and resilience
3.1 Infrastructure resilience
The web application runs on a global CDN, providing resilience against DDoS attacks, traffic spikes, and local outages. A managed database provider supplies monitored high availability under its service commitments.
3.2 Backups and recovery
The database provider creates daily backups automatically. Point-in-time recovery (PITR) is enabled for production and can restore data to a point within the available interval. Recovery follows documented procedures, and simulations run only in isolated test environments.
4. Candidate personal-data protection and consent
4.1 File storage and access auditing
Candidate CVs are stored in a private bucket. An employer receives file access only after the required credits are paid. An audit log records each CV opening, including the organization, time, and related transaction.
4.2 Retention and deletion
Database cascade rules remove all candidate records, uploaded files, and applications when a user or profile is deleted. Periodic purge jobs delete inactive candidate accounts and files based on the last activity date. A clear consent acknowledgement is collected when a CV is submitted.
CV uploads are limited to 5 MB and to PDF or DOCX formats, reducing the risk of executable malicious uploads.
5. Organizational and development security
5.1 Workstation security
Developers and administrators with access to database credentials or dashboards must use full-disk encryption; unique, strong passwords and multi-factor authentication for GitHub, database, and hosting accounts; and automatic screen locking after no more than five minutes of inactivity.
5.2 Staging gate
Every change must be deployed and verified in staging before production. Developers may not use production access keys for testing.
5.3 Code quality
Automated static analysis validates code and types locally and in CI. Production deployment occurs only after review, approval, and security checks.