Security

The job of this page is to pre-answer the standard vendor security questionnaire, including the questions UK public-sector and larger UK buyers now add from the government’s Software Security Code of Practice and the NCSC Cloud Security Principles. If you can tick every row below without emailing us, it has worked.

UK GDPR article 32 asks for measures appropriate to the risk, and names some of them. The table maps each to the section of this page that describes it and gives its status today. Annex 2 of our Data Processing Agreement carries the same rows, with the same status.

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 further controls, and the table says exactly what each one covers.

One set of records sits outside the per-customer schemas: user accounts, their two-factor secrets and pending invitations are held in a shared platform schema, because one person can belong to several workspaces. Business data is always in the customer’s own schema.

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. A storefront shows the business’s own catalogue and takes enquiries, which go only to that business; there is no checkout, and no reviews, comments, ratings or uploads that other shoppers can see.

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 ours. The second half is our hosting provider’s, and it is described as theirs, from their own published documentation.

Sessions are carried by signed tokens held in cookies the page’s own scripts cannot read, and every token is bound to exactly one workspace. The cookies and their settings are listed in our Cookie Policy.

• Access tokens expire after 60 minutes. A refresh flow renews them silently while you are active, so the expiry is short without being disruptive. A session can never be renewed beyond 30 days from sign-in.
• 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. Their tokens are signed with a portal key, which by default is derived from the staff signing key, and for a transition period the portal also accepts tokens signed with the staff key itself. A portal refresh token lasts 7 days and is renewed on each refresh, with no overall limit on how long a portal session can run.
• Moving between the public sign-in page and a workspace uses a single-use bridge token that expires after 15 minutes (30 minutes during sign-up). Refresh tokens rotate on use, and reuse of an old one is detected.
• Invitations: a person who already has a SorviAI account and accepts an invitation to another workspace is signed in by the invitation link itself, with no password or second-factor step. Treat invitation links as sign-in credentials until they are used or expire.
• Multi-factor authentication is available on the main sign-in. Every staff account can turn on two-factor authentication, as a time-based code from an authenticator app. Enrolment issues single-use recovery codes, the shared secret is encrypted at rest, a code cannot be replayed, and turning it off requires the account password. The challenge is demanded at the application’s sign-in and at the platform administrator console’s sign-in. It is not demanded at two other doors: the Django administration site used by SorviAI’s own super administrators, and the Django administration site of each workspace. Both take a password only.
• What multi-factor authentication does not cover: Opt-in only It is enabled per user, and there is no setting that requires it across a workspace, so an administrator can ask for it but cannot enforce it. It is not offered to Portal users, and there is no support for hardware security keys or for codes sent by SMS.
• Password policy: minimum eight characters. A password is rejected if it is too similar to the account name or email address, if it appears on a list of roughly 20,000 common passwords, or if it is entirely numeric. There is no character-class requirement, and no check against live breached-password data.
• Failed attempts: sign-in is limited to 15 attempts per minute per IP address, and the platform administrator console to 5 attempts per five minutes. The two Django administration sign-ins have no attempt limit at all. Second-factor codes are limited to 5 attempts per five minutes, and a challenge locks after 5 failures. There is no per-account lockout on staff accounts, so the control slows an attacker per address rather than stopping one spread across many. Portal accounts do lock, for 15 minutes after 5 consecutive failures. If the rate limiter cannot reach its cache it allows the request, which is why the flows that matter most carry their own per-token lockout rather than depending on it.
• Single sign-on: not available. SorviAI supports neither SAML nor OIDC. Every account signs in with an email address and password, optionally with a time-based code from an authenticator app. Many UK mid-market and public-sector buyers treat single sign-on and enforced multi-factor authentication as a procurement gate, and we would rather you read that here than discover it in a questionnaire. No date has been set for either.

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.

What least privilege means here in practice

A finance user cannot reach inventory functions unless someone explicitly granted them there. The default for a new user is not “everything except what we remembered to take away”, which is the shape most access problems actually take. Two limits apply. A user with no role still gets a small view-only default set of permissions, such as viewing customers. And a screen that does not declare a required permission is open to any member of the workspace, so the permission model is only as complete as the screens that declare one.

The corollary is that the workspace administrator list is the thing worth auditing, and it is yours to audit rather than ours.

One limit worth knowing in Worklink: the national ID, tax ID and social security ID fields on an employee record are free text and are visible to anyone with access to employee records; they are not restricted to a payroll role. In the UK, National Insurance numbers will usually land in these fields, because Worklink has no dedicated National Insurance field. They are stored in plaintext and returned in full by the API to anyone with employee access. Detail screens show only the last four characters, but the edit form shows the full value. Grant employee access accordingly.

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. The scope is good; the immutability is not, and the last row says so.

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

• Code review before merge: changes reach the main branches through pull requests, under repository rulesets: two approvals for the main and production branches, with review threads resolved, and one for develop. Deleting those branches and force-pushing to them are blocked. There is no code-owner rule, so any reviewer with write access can give an approval.
• Dependency management: no automated dependency scanning is in place. There is no advisory service watching the dependency tree and no scanner in the build. Dependencies are reviewed and upgraded by hand, and no patch window for critical advisories has been set.
• Static analysis, tests and secret scanning: continuous integration runs no tests and no scans today. Its one required check confirms that a pull request exists and nothing more. Linting, formatting, type checking and the test suite exist as local commands a developer runs against their own changes, and are not enforced on merge. There is no static application security testing and no automated secret scanning.
• A credential we have to disclose: an API key for an AI provider, Groq, was committed to our source repository and remains in its history. The key has been revoked. SorviAI does not currently use an AI provider, and no AI provider receives customer data; the code that used it has been removed, although the library is still listed among the backend’s dependencies without being used.
• File uploads: attachments are limited to 10 MB each and Nest files to 100 MB. Uploaded files are not scanned for malware.
• Browser protections: the application does not send a Content Security Policy header, so the browser is not told which script sources to trust.
• Environment separation: production runs from its own settings module, with credentials supplied by the hosting platform rather than stored in the repository. Production data is not copied into development: no import or fixture route exists for it. The staff named under Our people and our own systems can, however, connect to production databases directly from their work computers, and those connections leave no audit record.
• External penetration testing: Not yet carried out No independent test has been performed. One is planned as part of certification readiness, with no date set yet; when a report exists, a summary will be available under NDA.

Framework protections, described as what they are

SorviAI is built on Django. Cross-site request forgery protection, parameterised queries through the ORM, and template auto-escaping against cross-site scripting are all framework defaults that we have left in place rather than disabled for convenience. A Content Security Policy is not among them: Django does not send one by default, and we have not added one.

We state that precisely because reviewers ask, and because there is a difference worth preserving between a control we engineered and a sound default we did not undermine. Both are worth having. Only one of them is a claim about us.

UK buyers increasingly ask about three government frameworks alongside the usual questionnaire. None of them is a certification, and none has been assessed by anyone outside SorviAI. Cyber Essentials, which is a certification, is covered on the Compliance page, where it is the first scheme on our roadmap.

Software Security Code of Practice

Published by the Department for Science, Innovation and Technology and the NCSC in May 2025, the Code sets out, in 14 principles across four areas, what a software vendor is expected to do: secure design and development, build environment security, secure deployment and maintenance, and communication with customers. It is voluntary, and a vendor declares its own conformance through a self-assessment.

We have not yet assessed ourselves against it. The honest preview is on this page already. Code review runs through pull requests under the rulesets described above; tests in continuous integration, dependency scanning, secret scanning, a defined patch window and a penetration test are not in place. The service is built and deployed by DigitalOcean App Platform from our GitHub repository, and access to both is removed on the day someone leaves. A route for reporting vulnerabilities and a breach notification commitment are both published on this page. When the self-assessment exists, it will be published here with its date.

NCSC Cloud Security Principles

The NCSC’s 14 Cloud Security Principles are the structure UK public-sector buyers use to assess a cloud service. Most of them map to sections of this page: data in transit protection and asset protection (Encryption, Infrastructure and hosting), separation between customers (Tenant isolation), identity and authentication (Authentication), secure user management and operational security (Authorisation, Audit logging), personnel security (Our people and our own systems), secure development (Application security), supply chain security (the sub-processor list on the Compliance page) and audit information for users (Audit logging). We have not published a principle-by-principle response. SorviAI is not listed on G-Cloud today.

NIS Regulations and the Cyber Security and Resilience Bill

The Network and Information Systems Regulations 2018 regulate some cloud services as relevant digital service providers, but exempt small and micro businesses. With fewer than 50 people and no revenue yet, SorviAI is outside them. The Cyber Security and Resilience Bill, introduced in Parliament in November 2025 and not yet law, would extend regulation to managed service providers and tighten incident reporting. We will recheck our position when it is enacted and record the answer on the Compliance page.

SorviAI Finance files VAT returns with HMRC under Making Tax Digital for VAT, on your authority. HMRC requires every software vendor to send fraud prevention headers with every API call, and it can restrict a vendor’s production access if they are missing or wrong. Because a failure here would stop your VAT filing, this section describes exactly what we send.

What the connection covers: submitting VAT returns, and reading VAT obligations, liabilities and payments. Past returns cannot be read back from HMRC in the product today. VAT registration numbers with an XI (Northern Ireland) prefix are not accepted, and boxes 2, 8 and 9 of the return are always 0. SorviAI does not support Making Tax Digital for Income Tax. The Compliance page sets out those positions and HMRC’s timetable.

SorviAI runs on DigitalOcean App Platform in London: the application, the managed database and uploaded files are all in DigitalOcean’s London region, for every workspace wherever the customer is. 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: the service relies on DigitalOcean’s platform networking. We have no written network segmentation design beyond it.
• Denial-of-service protection: volumetric protection is provided at the edge by Cloudflare, which App Platform places in front of every app domain. Inside the application, some endpoints reachable without a session carry their own per-address budgets: 60 requests a minute for the public storefront catalogue, and 15 a minute for sign-in. Nest public share links and the public quote and invoice pages have no rate limit.
• Database reachability: the application connects to the database over TLS. The database is not limited to DigitalOcean’s private network: the staff named under Our people and our own systems connect to it directly from their work computers.
• Production access: our director and one or two senior engineers hold direct production database access, and the list is reviewed every quarter. Those sessions leave no audit record.
• Sub-processors: the third parties that can reach customer data, and the services your browser loads from third parties while you use SorviAI, are listed on the Compliance page, with where they are and the transfer safeguard. We announce a new sub-processor on that page and by email to workspace account owners at least 30 days before it begins handling customer data; nothing in the product sends that notice automatically. SorviAI does not currently use an AI provider, and no AI provider receives customer data; if one is added it will be listed as a sub-processor with its transfer basis.

International transfers

Hosting itself involves no transfer: the application, the database and files are in London. DigitalOcean stores database backups off-site and does not publish where. Data still leaves the United Kingdom in three ways, each with its own safeguard, set out in full in the Data Processing Agreement.

• Error reports. Sentry processes them in its EU region, in Frankfurt, Germany, covered by the UK’s adequacy regulations for the EEA.
• Suppliers in the United States. Each is certified under the UK Extension to the EU-US Data Privacy Framework (the “data bridge”), checked on 28 September 2026. Cloudflare, Stripe, Google and Microsoft are certified for HR data too; DigitalOcean, Twilio and Sentry’s parent are certified for non-HR data only. For HR data, such as Worklink records, Twilio’s data protection addendum applies the International Data Transfer Agreement, while DigitalOcean’s agreement adds no safeguard if that data is reached from the United States.
• Our team in India. Everyone on our team in India is employed by SORVI AI LTD. A team member who reaches our UK systems from India is part of the same company, and the ICO does not treat that access as a restricted transfer. Before anyone works for us there as a contractor or through another company, we sign the International Data Transfer Agreement with them, with a documented transfer risk assessment.

The Data (Use and Access) Act 2025 made the test for these transfers a “data protection test”: the protection in the destination must not be materially lower than in the UK. Transfer agreements made under the old rules remain valid.

Data in your workspace is yours, and we treat a request from a public authority for it accordingly.

• We check that the request has a valid legal basis, for example a warrant or notice under the Investigatory Powers Act 2016, an order under the Crime (Overseas Production Orders) Act 2019, or a request made under the UK-US Data Access Agreement, which covers orders from US authorities under the CLOUD Act.
• We disclose only what the request compels, and we refuse or challenge a request that does not have a proper basis.
• We tell you before we disclose, unless the law forbids it, and for only as long as it forbids it. Where we can, we direct a request for your business records to you, because you are the controller of that data.
• Our US sub-processors are also subject to US law, which is one reason they are listed with their safeguards.

The same process, and the UK reporting routes for abuse, are described in our Abuse Policy. We do not yet publish a count of the requests we receive; ask us and we will tell you how many there have been.

Three of the rows below describe the managed database platform, and they are written as its behaviour rather than as an arrangement we built. The ones that are genuinely ours are whether anyone has tested a restore, and what we will commit to on a bad day. Those are the ones not done, which is the honest shape of this section and not an accident of drafting.

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.

A backup is not an archive

Seven days of backups exist to recover the service after a failure. They are not a record-keeping system, they cannot be searched or exported record by record, and they are gone after a week. UK record-keeping duties run for years: HMRC generally expects business and VAT records to be kept for six years, and a private company must keep its accounting records for three years (Companies Act 2006, section 388). That duty is yours, it continues after you stop using SorviAI, and our backups do not meet it. Keep your own exports; today they run per screen or per report, list exports are capped at 20,000 rows, and there is no whole-workspace export. Note too that sent and partly paid invoices can still be edited in place, lines and totals included, so a record you rely on for VAT should be exported or kept as the PDF you sent.

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

• Notification commitment: without undue delay, and in any case within 48 hours of confirming an incident affecting your data.
• Runbook: In place A written incident runbook, adopted by our director, sets out each step. It is internal and not published.
• What you would be told: what happened, which categories of your data and roughly how many people were involved, when it occurred and when we detected it, what we have done, what the likely consequences are, and what you need to do. Where we do not yet know something, we tell you what we know and follow up.
• Who we would tell: the workspace administrators on record, and any additional contact you have given us for this purpose.

Why our commitment is shorter than 72 hours

Under UK GDPR article 33, a controller has 72 hours to notify the Information Commission (the ICO) of a personal data breach, unless it is unlikely to result in a risk to people. For the data in your workspace you are the controller and we are your processor, so our duty is to notify you early enough that you can still meet that deadline.

A commitment of “within 72 hours” would be useless to you, because it consumes your entire window. Ours is 48 hours, which leaves you at least a day of yours. The same commitment is on our GDPR Compliance page and in the Data Processing Agreement, and the three are not allowed to differ.

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. Publishing a clear route is also one of the expectations of the Software Security Code of Practice.

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

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. This is a promise about what we will do. It cannot grant immunity from the law, and it does not bind the police, prosecutors or any third party: the Computer Misuse Act 1990 has no defence for good-faith security research, which is why the boundaries above matter.

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: carried out before anyone is given access to production systems or customer data.
• Security training: security and data protection training at onboarding, with a refresher each year.
• Staff devices: work laptops have full-disk encryption, a screen lock and automatic updates. Personal devices are not used for production access.
• Production access: our director and one or two senior engineers can connect to production databases directly from their work computers to run operational and diagnostic tasks. The list is reviewed every quarter. These sessions are not logged, and a direct database connection bypasses the application’s audit log.
• Access to customer data for support: a SorviAI super administrator can sign in to a customer’s workspace on a user’s behalf through an impersonation route. It is used only to resolve that customer’s support request, to investigate a credible abuse report or to meet a legal duty, and a senior engineer approves each use. The start of each session is recorded in the same database transaction as the access, so it cannot happen unrecorded, and your interface shows a banner for as long as it lasts. That record is kept in SorviAI’s platform audit log rather than in your workspace’s log, and a session can last up to 30 days. What the staff member does during the session is not recorded separately. This route and direct database connections are the two ways SorviAI staff can reach workspace content.
• Where staff work from: our team works remotely, from the United Kingdom and India. How access from India is treated is set out under Infrastructure and hosting.
• Offboarding: access to our code repository, our hosting, our payment provider, email and the platform is removed on the day someone leaves. Our director is accountable for it.
• Physical: we run no data centre, and no office holds customer data.

An honest note about the size of the company

A questionnaire written for a company of a thousand people asks about a dedicated security function, a named CISO and an internal audit programme. We are fewer than 50 people, and for several of those the truthful answer today is that we are too small to have one. We would rather say so than describe a governance structure that does not exist.

What is worth more at our size, and is a fair thing to hold us to, is that the people who can reach production can be counted on one hand and are named on request. A short list that is actually accurate is a stronger control than an org chart nobody maintains.

Three different things, each with its own commitment, so an urgent one does not sit in a queue behind a questionnaire.

Our full company details are on our company information page. This is the first published version. 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 technical meaning, in plain language.