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, which is also the source of the security measures in our Data Processing Agreement.
• 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. Nothing in it is held. It is a long table for a short answer, and it is here because knowing which of these apply to us, which do not, and why is more useful than a single “no”.

What “not held” does and does not mean

It does not mean the controls do not exist. Tenant isolation, tenant-scoped authentication, role-based access control, per-user multi-factor authentication and audit logging are all built and running, and Our security architecture links to where they are described in detail.

It means no independent party has tested them and issued a report. Those are two different claims and we are not going to blur them, because blurring them is precisely what a certification exists to prevent.

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 now, and what is not yet ready, so you can see both at once.

Several 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 UK buyers, including the public sector, the first step is Cyber Essentials, then Cyber Essentials Plus, then ISO 27001. Cyber Essentials is cheap and fast, some government contracts require it, and it is the floor UK buyers most often ask for.
• Selling to larger enterprise buyers, including in India, the usual answer is ISO 27001, the standard rule 8 of the SPDI Rules 2011 names for reasonable security practices.
• The Software Security Code of Practice self-assessment costs little and UK public buyers are starting to ask for it, so it runs alongside Cyber Essentials rather than after it.
• ISO 27001 and SOC 2 are each 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 position: Cyber Essentials first, then Cyber Essentials Plus, then ISO 27001, with the Software Security Code of Practice self-assessment alongside Cyber Essentials; SOC 2 Type II only if our buyers require it. Decided on 28 September 2026.

The stages

No stage has a target date yet. Each date will be added here when it is set, and not before: a roadmap with invented dates is worse than one that admits it has none.

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.

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. Certificates last twelve months.

Software Security Code of Practice

Published in May 2025 by the Department for Science, Innovation and Technology and the NCSC. It sets out, in 14 principles, what software vendors should do across secure design and development, build environment security, secure deployment and maintenance, and communication with customers. It is voluntary, and conformance is declared by the vendor itself. Treat a declaration as a statement of intent backed by whatever evidence the vendor offers, not as an audit.

CERT-In empanelled audits and MeitY empanelment

CERT-In keeps a list of empanelled information security auditing organisations, and Indian government and regulated buyers often ask for an audit by one of them. Such an audit is a point-in-time test, not a certification of a management system. MeitY empanelment is how a cloud service becomes available to Indian government bodies: a route to market, which expects the service to be hosted in India, not a security attestation.

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. Look for a certificate from an accredited certification body. Rule 8 of the SPDI Rules 2011 names ISO/IEC 27001 as one way for a business to show reasonable security practices under section 43A of the Information Technology Act 2000.

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, and 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.

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.

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 our position and of what is still missing, with a link to the document carrying the substance. SORVI AI LTD is a UK company with no Indian entity or office; Indian law reaches us because we offer the service to businesses in India, host content they publish, and employ a team that works from India.

SorviAI does not currently use an AI provider, and India has no AI-specific statute that places a duty on us today; if we add one, we will say so here first.

Why none of these rows says “compliant”

“DPDP compliant” as a standalone claim carries almost no information. Nobody certifies it, and most of the Act’s duties do not start until 13 May 2027. A reviewer asking about it needs concrete things: a contract that makes us your processor, the security safeguards we keep, how fast we tell you about a breach, and where the data is. The first is the Data Processing Agreement; the rest are on the Security page and below.

So each row points at the document rather than asserting a state. If you find yourself unable to get from a row to the thing it names, that is a fault worth reporting to us, and our contact details are below.

Company, tax and employment law reach into how a product behaves, not only into what its policies say. This section sets out what SorviAI does and does not do for the records Indian law requires, so that you and your chartered accountant can decide how to use the product before you rely on it. It is not tax or legal advice.

Your books of account, and where they are kept

An Indian company must keep books of account (Companies Act 2013, section 128), and the Companies (Accounts) Rules 2014 (rule 3(5)) require a company that keeps them in electronic form to keep a backup of them, every day, on servers physically located in India. SorviAI does not do that for you today. All customer data is held in London; our database backups are held by our hosting provider off-site, at a location it does not publish; and a backup in India is planned but not in place, with no date. If your company keeps its books in SorviAI Finance, keep your own daily export or backup on servers in India until that changes.

Audit trail

The same rules (rule 3(1)) require accounting software used by an Indian company to record an audit trail of every transaction, with an edit log of each change and the date it was made, and the audit trail must not be capable of being disabled. SorviAI Finance does not meet that standard today: its audit log covers some actions but not all, it is not tamper-evident, an audit entry is not written in the same transaction as the change it records, and a sent or partly paid invoice can still be edited in place. Our Security page lists what is and is not recorded. Your auditor reports on this rule, so tell them how you use SorviAI.

GST invoicing and returns

SorviAI Finance produces PDF invoices. It is not an e-invoicing system: it does not report invoices to an Invoice Registration Portal or obtain an IRN, it does not generate e-way bills, and it files no GST return (no GSTR-1, GSTR-3B or any other). It files nothing with the GST portal, the income tax department or the Registrar of Companies. You will need separate software or your accountant for those, and filing on time remains your responsibility. Check that every invoice you issue from SorviAI carries the particulars the CGST Rules 2017 require for a tax invoice before you rely on it.

An invoice that has been sent, or partly paid, can still be edited in place in SorviAI Finance, lines and totals included. GST law corrects an issued tax invoice by a credit or debit note (CGST Act 2017, section 34), not by editing it. If you need the invoice as issued, keep the PDF you sent or export it at the time.

Record retention is separate from our backups

Indian law sets how long you keep your records: books of account and vouchers for eight financial years (Companies Act 2013, section 128(5)), and GST accounts and records for 72 months from the due date of the annual return for the year they relate to (CGST Act 2017, section 36). Those duties are yours, and they continue after you stop using SorviAI. Our database backups are kept for seven days to recover the service after a failure; they are not an archive and do not meet any retention duty. Exports today run per screen or per report, and list exports are capped at 20,000 rows; Nest downloads one file at a time; TeamEmail, Storefront, POS and Escalate have no export; there is no whole-workspace export, so our team does a full export for you on request, as our Terms of Service set out. Keep your own copies for the statutory period.

Point of sale

SorviAI POS is not certified under any cash-register or fiscal-device scheme. A receipt you give a customer has to meet GST invoicing rules, as a tax invoice or bill of supply, and SorviAI POS has not been checked against them. It can show a Daily Summary (Z-report) computed from the day’s sales, but it does not store or seal that report, writes no audit records today and produces no tamper-evident log.

Worklink and employment records

Worklink records employee attendance: check-in and check-out times, the IP address each came from, breaks, hours, overtime, a reason for arriving late, and leave. Working from home is recorded as an approved request rather than on the daily record. Check-in is by kiosk code or by signing in. Worklink also marks employees absent automatically each day when no attendance is recorded; this is an automated step that people review, not a decision made solely by software. Worklink uses no biometrics: no fingerprint, face or other biometric recognition, only an optional profile picture.

• Aadhaar numbers. Do not enter them in Worklink. The Aadhaar Act 2016 (section 29) limits how an Aadhaar number may be kept, displayed and shared, and Worklink has no masked or restricted field for one: anything typed into the national ID field is stored in plaintext and shown in full on the edit form.
• PAN and bank details. A PAN goes into the free-text tax ID field, and an employee’s bank name, account number and routing code have their own fields. All are stored in plaintext and visible to anyone with access to employee records; they are not restricted to payroll roles. Financial details are sensitive personal data under the SPDI Rules 2011, so grant that access with that in mind.
• Sickness absence. Every workspace that uses Worklink comes with a “Sick Leave” type, and each leave request needs a free-text reason, so illness details can end up in that field. Leave requests can also carry supporting documents such as a doctor’s note. Medical records are sensitive personal data under the SPDI Rules 2011; ask employees to give no more than you need.
• Labour law. The labour codes and state rules require employers to keep registers of attendance, working hours and wages. Worklink’s attendance records, and the attendance export (CSV or Excel), can help, but Worklink does not produce any statutory register format, and keeping the registers the law requires is the employer’s duty.
• Who decides. The employer is the Data Fiduciary for Worklink data and decides what is recorded and for how long; SorviAI processes it on the employer’s instructions.

Storefronts and portals

Storefronts built on SorviAI show the business’s own catalogue and take enquiries, which go only to that business. There is no checkout, no payment and no public user content. Three storefront pages show a file field that sends nothing, although the page tells the visitor the upload worked. Customer and Vendor Portals show each portal user the documents on their own customer or supplier record, including files uploaded by other logins of the same customer and by the business’s staff; portal users can upload documents, and the portals have no ticket view. A business that uses its storefront to sell to consumers carries the duties of the Consumer Protection Act 2019 and its e-commerce rules, such as showing its own details and grievance contact, and every storefront needs its own privacy notice; the storefront themes have no dedicated place for them today.

Accessibility

Our storefront templates and admin application have not been audited against WCAG 2.2 AA, and no audit is scheduled yet. A customer whose storefront must meet an accessibility standard, for example a body covered by the Rights of Persons with Disabilities Act 2016, carries that duty for its storefront. We make reasonable adjustments for disabled users of our service on request.

Card numbers never reach SorviAI’s servers. 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.

Your SorviAI subscription is paid through Stripe, which is certified as a PCI DSS Level 1 service provider. You enter card details on pages and fields hosted by Stripe, not by us. What SorviAI stores is Stripe’s reference for your customer account and your subscription. When we show your card on the billing page, the brand, last four digits and expiry date are fetched from Stripe for display and are not stored by us. The full card 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.

Payments taken by our customers

Storefronts built on SorviAI take enquiries and have no checkout, so no card data passes through them at all. Separately, a customer can connect its own Stripe account so that its customers can pay its invoices online. That payment happens on Stripe’s own pages, under the customer’s agreement with Stripe, and the money goes to the customer’s own connected account; SorviAI creates that connected account and the charge using its own Stripe platform key, and sends the payer’s email address and the invoice number to Stripe. Card numbers do not reach SorviAI there either, and any PCI scope that arrangement carries is the customer’s, not ours. It is worth asking the question before connecting it.

The third parties with access to customer personal data are listed here, with what they do, where they are and their own certifications, followed by the services your browser loads from third parties while you use SorviAI. This list is the maintained version.

We separate our own sub-processors from integrations you choose to switch on, because the second group works on your instructions under your own agreement with that provider. We announce any change on this page and by email to workspace account owners at least 30 days before a new sub-processor begins handling customer data. Nothing in the product sends that notice automatically, and there is no separate subscription to sign up for. The certifications below are the suppliers’ own, as their sites stated them on 28 September 2026; they are not ours.

SorviAI’s sub-processors

SorviAI does not currently use an AI provider, and no AI provider receives customer data; if one is added it will be listed here with where it processes data.

Integrations you choose to switch on

These are not our sub-processors. When you connect one, data goes to that provider on your instruction, and your own agreement with that provider governs it.

The application, the database and uploaded files are all in DigitalOcean’s London region, for every workspace wherever the customer is. Nothing is kept in India today. Data still leaves London in a few ways, set out below.

When Indian rules want data in India

Some Indian rules ask for data or a copy of it to be kept in India, and SorviAI does not meet them today. A backup in India is planned, but it is not in place and has no date.

• Books of account. The daily backup on servers in India that the Companies (Accounts) Rules 2014 ask of an Indian company keeping its books electronically; see Records and obligations in India.
• Regulated customers. Banks, NBFCs, brokers and insurers whose regulator requires their data to be kept in India cannot meet that with SorviAI while it is hosted in London.
• CERT-In logs. These do not need to be in India: CERT-In’s FAQs (question 35) allow logs to be stored outside India as long as they are produced to CERT-In within a reasonable time. Ours stay in London.

The Data Processing Agreement records where data goes: we make no transfer beyond those listed without your authorisation, so moving hosting would need your agreement first. We offer no data residency in India today.

Why this section carries dates and the others do not

Transfer rules can change without anything at SorviAI changing: India’s restrictions under section 16 of the DPDP Act take effect only when the Government names a country, and sector regulators change their own rules. It is the one part of this page that can become wrong without anybody here noticing.

So the rows carry the date they were last confirmed, rather than an implied “as at publication”. If a date above is more than a year old, treat it as a question to ask us rather than an answer.

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, and authentication tokens are scoped to a single tenant and validated on every request. A token issued for one workspace cannot read another. User accounts, their two-factor secrets and invitations sit in a shared platform schema, because one person can belong to several workspaces.

Authentication and authorisation. Access tokens expire after 60 minutes and are renewed through a refresh flow while you are active. Multi-factor authentication is available to every staff account at the main sign-in, as a time-based code with recovery codes; administrators cannot yet make it mandatory, the two Django administration sign-ins take a password only, and single sign-on is not supported. 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, and kept for the life of the workspace. It cannot be altered through any interface, but it is not tamper-evident against someone with direct database access.

The gaps are on the Security page too

Administrator-enforced multi-factor authentication, the password-only Django administration sign-ins, single sign-on, internal connections that use TLS without certificate verification, the missing Content Security Policy, audit log coverage and tamper-evidence, backup restore testing, recovery targets, dependency and secret scanning and external penetration testing are all stated there as open, rather than left out.

This is not modesty. A reviewer assumes the worst about an omission and then asks anyway, so the round trip happens either way and the only variable is whether it costs you a week. You will find our gaps faster on our own page than in a questionnaire exchange.

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 [email protected], and we respond within 10 working 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.

Our full company details are in our Legal Notice and Grievance Officer page.

Data protection and regulatory contacts

The regulators

Start with our Grievance Officer. If you are not satisfied with the decision on a complaint about content, you can appeal to the Grievance Appellate Committee within 30 days at gac.gov.in. From 13 May 2027, once you have used our grievance route, you can complain about our handling of your personal data to the Data Protection Board of India (DPDP Act, section 13(3)). To report a cyber crime, use cybercrime.gov.in, or call 1930 for financial fraud. You can go to the courts at any time.

Version 1.1 describes the consent banner, affiliate tracking through Tradedoubler, and Session Replay running only with consent. It replaces version 1.0, effective 1 October 2026. Every later version will be published here with its date, and earlier versions will be kept at this address.

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.