Security

The job of this page is to pre-answer the standard vendor security questionnaire. If you can tick every row below without emailing us, it has worked.

Every SorviAI customer is provisioned with a dedicated PostgreSQL schema. Customer records are held in separate database schemas, not in shared tables partitioned by an identifier column.

The ordinary approach to multi-tenancy is a single shared table with a tenant_id column and a WHERE clause on every query. That works until one query is written without the filter, and then one customer can read another’s ledgers. It is a control that depends on every developer getting every query right, forever, including the ones written at speed on a Friday.

Schema separation removes that entire class of bug structurally rather than by discipline. There is no shared table to forget to filter. Sitting on top of that database boundary are three further controls, each of which would independently have to fail before a cross-tenant read became possible.

Public storefronts

Businesses can publish a catalogue to a public web address through SorviAI. That read path resolves the tenant from the Host header through the same middleware used everywhere else, and serves published content only. No authenticated session is involved on the public side.

This is worth stating explicitly because a public surface on a multi-tenant platform is exactly where a reviewer will look for a leak, and rightly so. The answer is that the public path shares the tenant resolution used by the authenticated application and reads only records a tenant has marked published.

Reviewers look for isolation and encryption first, in that order. The first half of this section is straightforward. The second half is not finished, and we are not going to write it as though it is.

Sessions are carried by signed tokens rather than server-side session state, and every token is bound to exactly one workspace.

• Access tokens expire after 60 minutes. A refresh flow renews them silently while you are active, so the expiry is short without being disruptive.
• Tokens carry the tenant schema and are validated against it on every request. This is the same control described under Tenant isolation, and it is worth counting twice: it is both an authentication and an isolation control.
• Portal users authenticate on a separate path. Customers and suppliers signing in to a Portal do not use the platform authentication route, so a portal credential is not a staff credential that happens to have fewer permissions.
• Password policy: [MINIMUM LENGTH, COMPLEXITY, BREACH-LIST CHECKING]
• Failed attempts: [RATE LIMITING AND LOCKOUT BEHAVIOUR]
• Single sign-on: [SAML / OIDC AVAILABILITY, OR STATE PLAINLY THAT IT IS NOT AVAILABLE]

Access inside a workspace is governed by role-based permissions scoped to each application. A role granted in Finance conveys no access to Inventory, or to any other module, unless it is granted there too.

Roles carry an application code, so the unit of a grant is an application plus a permission rather than a job title that quietly widens as the platform grows. Permission checks are resolved against a central registry rather than being scattered through individual views, which means there is one place a permission is defined and one place it is enforced.

Administrative tiers

Administrative rights are tiered rather than binary, so granting someone the ability to manage one application does not hand them the workspace.

Administrative status is cached for performance, and the cache is tenant-scoped, so a cached administrative decision cannot leak across the workspace boundary.

An audit log is written into the tenant’s own schema, which means audit records are isolated on exactly the same boundary as the data they describe. Your audit trail is not co-mingled with anyone else’s, and it cannot be read from another workspace.

How code reaches production, and what stands between a newly written line and your ledgers.

• Code review before merge: [REQUIRED? BY WHOM? ENFORCED HOW?]
• Dependency management: [SCANNING TOOL AND PATCH CADENCE FOR CRITICAL ADVISORIES]
• Static analysis and secret scanning: [WHAT RUNS IN CI]
• Environment separation: [CONFIRM PRODUCTION IS SEPARATE FROM DEVELOPMENT, AND WHETHER PRODUCTION DATA IS EVER COPIED INTO NON-PRODUCTION]
• External penetration testing: Not yet carried out. No independent test has been performed. One is planned as part of certification readiness, and when a report exists a summary will be available under NDA. See the Compliance page for that timetable.

SorviAI runs on [HOSTING PROVIDER], in [REGION]. We operate no data centre of our own, so physical security, power, and hardware disposal are our provider’s responsibility and are described in their documentation rather than invented here.

• Network segmentation and firewall posture: [DESCRIBE]
• Denial-of-service protection: [PROVIDER-LEVEL OR APPLICATION-LEVEL - DESCRIBE]
• Database reachability: [CONFIRM THE DATABASE IS NOT REACHABLE FROM THE PUBLIC INTERNET]
• Production access: [WHO HAS IT, HOW IT IS GRANTED, HOW OFTEN IT IS REVIEWED, WHETHER IT IS LOGGED]
• Sub-processors: every third party that can reach customer data is listed on the Compliance page, with advance notice before a new one is added.

This section is incomplete. Every row below is a question a reviewer will ask, and none of them yet has an answer we can evidence.

A note on what a backup does not solve: a backup protects against loss, not against an unwanted change being made correctly by someone with valid credentials. For that, the relevant controls are Authorisation and Audit logging.

If something goes wrong with your data, the question that matters is when you hear about it and what you are told. Commitment not yet published

• Runbook: [WRITTEN RUNBOOK REQUIRED - WHO DECLARES AN INCIDENT, WHO LEADS, HOW IT IS RECORDED]
• Notification commitment: [E.G. WITHOUT UNDUE DELAY AND IN ANY CASE WITHIN N HOURS OF CONFIRMING AN INCIDENT AFFECTING YOUR DATA]
• What you would be told: what happened, which categories of your data were involved, when it occurred and when we detected it, what we have done, and what you need to do.
• Who we would tell: the workspace administrators on record, and any additional contact you have given us for this purpose.

If you have found a security problem in SorviAI, we want to hear about it, and we would rather hear about it from you than from someone else.

What we ask of you

• Test only against a workspace you own. Do not access, modify or retain another customer’s data.
• Do not run denial-of-service tests, or automated scanning heavy enough to degrade the service for other customers.
• Give us reasonable time to fix the issue before disclosing it publicly.

What we commit to in return

[SAFE HARBOUR WORDING - CONFIRM WITH COUNSEL] We will not pursue legal action against a researcher who reports in good faith and stays within the boundaries above, we will keep you informed as we work on the issue, and we will credit you if you would like to be credited.

We run no bug bounty programme at present and offer no payment for reports. We would rather say that plainly than leave it ambiguous.

The controls above describe the platform. This section describes the people who can reach it, which is the part questionnaires ask about and vendor pages routinely skip.

• Background checks: [WHAT IS CARRIED OUT, FOR WHICH ROLES]
• Security training: [AT ONBOARDING AND HOW OFTEN THEREAFTER]
• Staff devices: [DISK ENCRYPTION, SCREEN LOCK, MANAGED UPDATES, WHETHER PERSONAL DEVICES MAY ACCESS SYSTEMS]
• Production access: [NAMED ROLES ONLY, HOW APPROVED, HOW REVIEWED, WHETHER SESSIONS ARE LOGGED]
• Access to customer data for support: [WHETHER STAFF CAN VIEW TENANT DATA, UNDER WHAT CONDITIONS, AND WHETHER IT IS RECORDED]
• Offboarding: [ACCESS REVOKED WITHIN N, AND WHO IS ACCOUNTABLE]
• Physical: we run no data centre. [DESCRIBE OFFICE ACCESS CONTROL, OR STATE THAT THE TEAM WORKS REMOTELY]

Three different things, three different routes, so an urgent one does not sit in a queue behind a questionnaire.

The words on this page that carry a specific technical meaning, in plain language.