Compliance

This is the distinction that almost everybody collapses, and the whole page depends on it, so it is worth stating flatly.

• Security is our own account of what we do. Self-reported. It lives on our Security page.
• Compliance is somebody else’s verification that we do it. Externally attested. That is this page.

“We encrypt customer data at rest” is a statement for the Security page. “An accredited auditor tested our encryption controls across a twelve-month window and issued an unqualified opinion” is a statement for this one. The first is a description. The second is evidence produced by someone with no commercial interest in the answer.

So this page answers one question, in as few words as it can: who checked, and can we see the report?

The table below is the complete list of the standards a reviewer is likely to ask us about, grouped the way procurement teams usually group them. Every one carries the same status today. It is a long table for a short answer, and it is here because the more useful thing than a single “no” is knowing that we understand which of these apply to us, which do not, and why.

A certificate is a way of answering a reviewer’s questions without their having to ask. Where we cannot hand over the certificate, we can still answer the questions. This is everything available right now.

Two frameworks are worth pursuing and one of them is worth pursuing first. Which one is a commercial question rather than a technical one, and the honest deciding factor is where the revenue is, not which sounds more impressive.

• Selling primarily to United States buyers, the answer is SOC 2 Type II.
• Selling primarily to European, UK, Indian and government buyers, the answer is ISO 27001.
• Both are six to twelve month projects with real external cost and meaningful internal time. Neither is a document exercise that compresses into a sprint, and we are not going to pretend otherwise on a roadmap.

Our current position, and the date it was set: [CHOSEN FRAMEWORK], decided [DECISION DATE].

The stages, and where we are

Written for the reviewer who has been handed a policy naming a framework and now has to work out what it would actually tell them about us. This section holds no claims about SorviAI at all; every status is in Certification status.

ISO/IEC 27001

Certifies that an organisation operates an information security management system: documented policies, a risk assessment method, a defined set of controls, internal audits and management review. It certifies that security is run as a system. It does not certify that any individual control is strong.

Issued by an accredited certification body after a two-stage audit, then maintained through annual surveillance audits with full recertification every three years. Preparation typically runs six to twelve months and is more a documentation and process undertaking than an engineering one.

Its extensions. ISO 27017 adds cloud-specific controls, ISO 27018 adds protection of personal data in a public cloud, and ISO 27701 adds a privacy management system. All three ride on a live 27001 certificate. A vendor citing 27018 without 27001 is describing something that cannot exist.

SOC 2

Not a certification but an attestation: a report produced by a CPA firm on controls measured against five trust services criteria. Security is mandatory; availability, processing integrity, confidentiality and privacy are optional scope. Two reports naming the same framework can therefore cover very different ground, which is why scope is worth asking about.

Type II is substantially harder, substantially more expensive, and the one enterprise buyers mean when they say “SOC 2”. A vendor writing “SOC 2” without the type reads as evasion, and a reviewer will ask.

A SOC 2 report is not a public document. What a vendor publishes is that they hold one; the report itself is released under NDA. A bridge letter covers the gap between the end of the last window and today.

SOC 1, and why it appears here at all

SOC 1 reports on controls relevant to a customer’s own financial reporting, rather than on security generally. It is unusual on a SaaS compliance page and it is on ours because SorviAI holds general ledgers, journals and invoices. If a customer’s external auditor eventually places reliance on our system, SOC 1 is the report they will ask for. It is not in our current scope, and we would rather say that in advance than be surprised by the question.

CSA STAR

A registry run by the Cloud Security Alliance, at three levels: Level 1 is a published self-assessment, Level 2 is a third-party audit built on ISO 27001 or SOC 2, Level 3 is continuous monitoring. Level 1 entries are free and self-published, so appearing in the registry is not itself a certification, and any vendor presenting it as one is overstating it.

Cyber Essentials and Cyber Essentials Plus

A UK government-backed scheme covering a baseline of five technical control areas. The base level is a verified self-assessment; “Plus” adds hands-on technical testing by an assessor. Both are far cheaper and faster than ISO 27001, and some UK public-sector contracts require one, so it can be the right first step for reasons that have nothing to do with which framework is more rigorous.

PCI DSS

Applies only to organisations that store, process or transmit cardholder data. It is a scope question before it is a compliance question, and Payments and PCI DSS sets out our scope.

HIPAA

Worth stating plainly because the claim is so common: there is no such thing as HIPAA certification. No body issues one. What exists is a Business Associate Agreement between a covered entity and its vendor, and, optionally, an independent examination against the Security and Privacy Rules, usually delivered as a SOC 2 report with HIPAA criteria added. A vendor describing itself as “HIPAA certified” is describing something that does not exist, which is a useful thing to know about how they write the rest of their claims.

These are laws we are subject to, not audits we have passed. No certificate exists for most of them, and no auditor issues one, so this section is a statement of practice that links to the documents carrying the substance.

Card data does not enter SorviAI systems. That single fact settles most of what a reviewer needs to know here, but it is worth setting out how, because the difference between “we are compliant” and “we are out of scope” matters and is frequently blurred.

Payments are handled by [PAYMENT PROVIDERS], who are assessed as PCI DSS compliant service providers. Card details are entered into fields hosted by the provider and exchanged for a token. What SorviAI stores is that token and [CONFIRM: LAST FOUR DIGITS, CARD BRAND, EXPIRY]. The primary account number never reaches our servers, our logs or our backups.

The practical consequence is that our own PCI scope is minimal, in the territory a self-assessment questionnaire covers rather than a full assessment. We state that as a scope position and nothing more.

Storefronts run by our customers

Businesses using SorviAI to sell through a storefront take payment through the same provider integration, on the same basis. A customer who connects their own payment processor instead takes on whatever scope that processor’s arrangement carries. That scope is theirs, not ours, and it is worth their asking the question before they connect it.

Every third party with access to customer personal data is listed publicly, with what they do, where they are and what safeguard is in place. The list is versioned, and we give notice before adding to it.

The maintained list lives at [SUB-PROCESSOR LIST URL]. We give [NOTICE PERIOD] days’ notice before a new sub-processor begins handling customer data, and you can subscribe to those notices at [SUBSCRIBE URL]. The list is referenced by URL from our Data Processing Addendum rather than reproduced inside it, so it can change without either party re-executing an agreement.

Customer data is stored in [PRIMARY REGION], with backups held in [BACKUP REGION]. Where that involves moving personal data out of the EEA or the UK, the transfer needs a lawful basis, and the basis we rely on is set out below.

EU data residency is [EU RESIDENCY POSITION]. It is worth being clear that this is an infrastructure commitment rather than a legal one: it is not a clause we can write, it is a region we have to run in. For some buyers it is decisive, and if it is decisive for you, tell us early rather than late.

Full detail is on the Security page. The summary here exists because a reviewer arriving at a compliance page holding no certificates deserves to know, in one screen, what is actually running.

Tenant isolation. Every SorviAI customer is provisioned with a dedicated PostgreSQL schema. Customer records are held in separate database schemas rather than in shared tables partitioned by an identifier column, which removes an entire class of cross-tenant query error rather than relying on every query being written correctly. Requests are resolved to a tenant before reaching application code, authentication tokens are scoped to a single tenant and validated on every request, and the data access layer applies schema-aware filtering automatically. A token issued for one workspace cannot read another.

Authentication and authorisation. Access tokens expire after 60 minutes and are renewed through a refresh flow while you are active. Within a workspace, access is governed by role-based permissions scoped to each application, so a role granted in Finance conveys no access to Inventory. Administrative rights are tiered rather than binary: workspace administrators manage the whole workspace, application administrators manage only their own application, and everything else is granted per permission against a central registry.

Audit logging. Audit records are written to the tenant’s own schema, so the audit trail is isolated on the same boundary as the data it describes.

Everything marked public in What we provide instead needs no request at all. For the rest, one address reaches us and we answer in English.

• Tell us three things. Your organisation, the framework or control set your policy actually names, and your deadline. The third one matters more than people expect: it changes what we prioritise, and we would rather tell you early that we cannot meet it.
• We answer your questionnaire, on your form. We have no policy of responding only to a form of our own, and we do not charge for completing one. If your form asks about a control we do not have, the answer will say so.
• Anything under NDA needs a mutual NDA in place first. Today that applies to nothing, because the documents it would cover do not yet exist. Once a SOC 2 report or a penetration test summary exists, this is the route to it.

Requests reach [COMPLIANCE CONTACT EMAIL], and we aim to respond within [N] business days.

One address for security questionnaires, document requests, and anything on this page you think is wrong. We would rather hear about it than not.

Data protection contacts

Some of the regimes in Regulations we comply with require a named contact inside the region. Where one is required of us, it is listed here.

The regulators

If you are not satisfied with our answer on a data protection matter, you can go to the supervisory authority for your region. We would rather you came to us first, but nothing here requires you to.

The words on this page that carry a specific meaning, in plain language. Several of them are used loosely in vendor marketing, which is the reason they are here.