
One boundary, enforced thrice.
Riopex holds your contract pricing across borders. Your security review is the real gate, so the design is here before you ask.
Request a pilot
- What it does
- Isolates data at the operating company and only there, enforced in the route, in the server action and again in the database as a row policy.
- What it reads
- Membership rows, never a token claim. A stale session cannot widen access, because the boundary is evaluated against the current membership on every query.
- What stays yours
- Your credentials and your row boundary. The application runs without a service-role client, monitoring and carrier secrets live in a secrets manager, and the monitoring key we ask for is read level.
Also inside this capability
Each row opens to what it does and where it stands.
Identity
Who can see what, and the record of what they did.
- Sign-in
- SSO over OIDC and SAML, with MFA.
- Provisioning
- SCIM, so joiners and leavers follow your own directory.
- Grants
- Scoped to a country, so a reader sees the operating companies their role covers.
- Audit trail
- Append-only, so a recorded entry stays as it was written.
- Status
- Built. Every certification is named the day an audit backs it.
Who uses it
- The reader
- Your security team, your data protection officer, and the procurement lead who signs the pilot agreement.
- The question
- Where does our data sit, who can reach it, and what does the read-level key actually allow?
- What they get
- An access model stated in full before the review starts, a subprocessor register, a DPA on request, and a penetration test report that goes to your team once the first pilot runs it.
- Where it starts
- Send your security questionnaire. The answers on this page are the ones you will get back, and anything it lacks becomes a specific answer rather than a generic one.
Control areas
Isolation at the entity
The tenant key is the operating company, carried on every table so that every policy is a single-column comparison. Parent and child rows are joined by keys that include the tenant, which makes attaching a row to another entity impossible by construction rather than by review.
Group reporting by design
A group administrator sees every operating company through one audited database function, and that function is the only path across the entity boundary. It is defined once, reviewed once and covered by its own isolation tests.
Read-only keys, held elsewhere
Monitoring and carrier credentials are opaque references resolved at job time from a secrets manager. They never enter the database, the repository or an environment file, and the monitoring key we ask for is read level only.
Evidence and privacy
Sensitive actions are appended to an audit trail, because service activation drives billing and has to be defensible. Mobile numbers are stored hashed with only the last digits in the clear. Error reporting scrubs personal data, and invoice bodies stay out of it entirely.
Certifications
SOC 2 is planned with the first pilot. We name a control the day an audit backs it, and until then this page is the evidence.
What you get
A boundary you can test
Cross-entity isolation is covered by its own tests: one entity's context returns one entity's rows, and an unauthenticated context returns an empty set. The tests run with every build.
Secrets that stay in the vault
Monitoring and carrier credentials are references into a secrets manager, resolved at job time. They are absent from the database, the repository and every environment file.
Evidence for the auditor
Sensitive actions are appended to an audit trail, mobile numbers are stored hashed, and error reporting scrubs personal data. What the auditor asks to see exists as a record rather than a recollection.

The controls we are building to
- AccessFive roles with an explicit permission set, membership held as data and revoked rather than deleted, invitations as hashed single-use tokens with a short expiry, and rate limiting on the paths that accept credentials.
- DataRaw artifacts in one private bucket, addressed by content hash under the owning entity, with a storage policy matching the same boundary. Encryption at rest is verified as part of the security gate before a pilot begins.
- ResidencyResidency is a real question for a group whose entities span jurisdictions, and it deserves a specific answer rather than a generic one. Ask, and we will tell you exactly where a pilot's data would sit.
- TestingCross-entity isolation is tested rather than asserted: one entity's context returns one entity's rows, and an unauthenticated context returns an empty set. Penetration testing is scheduled with the first pilot, and the report goes to your security team.
One request, end to end
A group administrator opens the group view while a regional IT lead opens their own operating company's inventory, at the same moment.
- The session
- Each request carries a session. Membership is read from its own rows on every query, so a role changed a minute ago applies to the very next request.
- The route
- The route checks the membership first. The regional lead's request names one operating company; the administrator's names the group.
- The action
- The server action checks again, with the same rule, before any query runs. Two checks that agree are cheap, and one check that is missing is how a boundary leaks.
- The policy
- The database applies its row policy: every table carries the operating company key, and the regional lead's query can only return rows that carry theirs.
- The group path
- The administrator's query goes through the one audited function that crosses entities. It is defined once, reviewed once, and covered by the isolation tests.
- The trail
- Both reads complete. The sensitive ones are appended to the audit trail with the actor, the time and the scope, and the raw invoice bodies stay out of every error report.
Questions about security
Where is our data hosted?
Residency is a specific question for a group whose entities span jurisdictions, and it gets a specific answer. Ask, and we will say exactly where a pilot's data would sit and which subprocessors would touch it.
Are you SOC 2 certified?
SOC 2 is planned with the first pilot, and this page is the evidence until an audit backs the claim. We name a control the day an audit backs it.
Can our own team review the access model?
Yes, and we would rather they did before the pilot than after. The five roles, the permission set, the invitation flow and the rate limiting on credential paths are set out above, and the isolation tests are shown on request.
What does the read-level key let you do?
Read interface inventory and historic utilisation series from your monitoring system's own API, and nothing that writes. It is held as a reference into a secrets manager and resolved only when a read runs.
Related capabilities
