How rivonOS protects your data.

Five things to know first. Everything here is live in production today.

• Each customer's data is kept separate in five layers, and automated tests check that separation on every release.
• People see only what their role and scope allow. Floor prices, costs, internal notes and bank details are hidden from roles without permission.
• Price activation, approval policies, invoice issue and agreement approval need a second person. The same person cannot be maker and checker.
• Every change is written to an audit log with who made it, when, from where, and what it looked like before and after.
• Customer data is hosted in AWS Mumbai (ap-south-1), encrypted at rest and in transit, with 7 days of point-in-time database recovery.

rivonOS does not hold SOC 2 or ISO 27001 certification today and does not offer an uptime SLA. We will say so here when that changes.

All customers share one rivonOS application. Five layers keep each customer's data apart:

1. The customer (tenant) is taken only from the verified login session, never from anything the browser sends.
2. Business code reaches the database through a scoped client that adds the tenant to every query. If the tenant is missing, the query fails instead of returning data.
3. A code check stops business code from using an unscoped database client, so the first two layers cannot be skipped by mistake.
4. Database keys include the tenant, so a record in one customer's data cannot point to a record in another's.
5. Each customer's data lives in its own database schema, and the application connects to that schema only.

Automated isolation tests cover every kind of customer-owned record and run on every release. They try to read another customer's records and expect “not found”, so even the existence of a record is not revealed.

rivonOS comes with ten default roles, including a community manager role scoped to the centres a person runs. Each person's access is also limited by scope: their own records, their team, a centre, a city, a region, or the whole company.

Sensitive fields are hidden from roles that do not need them: floor prices, costs, internal notes and bank details.

Four actions need a second person: activating a price, activating an approval policy, issuing an invoice and approving an agreement. The rule is enforced in the application and again by the database, which rejects a record where the checker is the same person as the maker.

Discount approvals follow your policy by level. Nobody can approve their own deal, and the same person cannot approve two levels of one request.

Every change is written to the audit log in the same database transaction as the change itself, so a change cannot be saved without its log entry. Each entry records the person, the time, the IP address, the request and the record before and after.

The log is append-only: the application adds entries and does not change them. That rule is enforced by the application, not yet by the database itself.

• Passwords are hashed with Argon2id and must be 12 to 128 characters long.
• An account locks for 15 minutes after 5 failed sign-in attempts, and requests are rate-limited.
• Access tokens last 15 minutes and are kept in memory, not in browser storage.
• Refresh tokens rotate on every use and are held in an HttpOnly, Secure, SameSite=strict cookie. If an old refresh token is reused, the session is ended.
• Sessions end after 7 days without activity, and after 30 days in any case.

rivonOS runs in Amazon Web Services in Mumbai (region ap-south-1): application servers on EC2, the database on Amazon RDS for PostgreSQL 16, files on Amazon S3 and email on Amazon SES.

The database sits in private subnets with no public access. The application servers have no SSH access; administration goes through AWS Systems Manager.

Customer data is stored in India. The one exception is the AI assistant: if a customer chooses to turn it on, the records needed for a request are sent to OpenAI outside India. See AI and your data.

• In transit: TLS 1.2 or 1.3 between browsers and rivonOS, with HSTS.
• At rest: encrypted database storage, encrypted server volumes, and files in S3 encrypted with a rivonOS key in AWS KMS.
• Sensitive fields, such as people's email addresses and phone numbers, notes and comments, are encrypted inside the application with a key for each customer, itself protected by AWS KMS.
• The application verifies the database's certificate on every connection.
• The file bucket is versioned and accepts only TLS connections.
• Application secrets are kept in AWS Systems Manager Parameter Store, not in code.

The database is backed up automatically, with point-in-time recovery for the last 7 days. Earlier versions of stored files are kept for 90 days.

When a customer needs help, a rivonOS staff member can be given support access to that customer's workspace. That access is:

• read-only,
• limited in time,
• granted only with a stated reason,
• shown to the customer's users as a banner while it is active, and
• written to the customer's own audit log.

The AI assistant in rivonOS is off by default. It runs only for a customer that opts in.

If a customer opts in, the records relevant to a request, such as an account's history or an agreement's text, are sent to OpenAI to produce an answer. OpenAI processes them outside India. If you do not opt in, nothing is sent to OpenAI.

We build our practices against India's Digital Personal Data Protection Act, 2023 and the DPDP Rules, 2025. For your company's data in rivonOS, your company decides what is collected and why, and rivonOS processes it on your behalf.

• Privacy questions and requests: privacy@rivonos.com
• Grievance officer: how to reach them
• How this website uses personal data: privacy notice

If you think you have found a security problem in rivonOS or this website, email security@rivonos.com with the steps to reproduce it. Please do not access or change other people's data, and give us reasonable time to fix the problem before you share it. We will confirm we have received your report.