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.

• As a UK company, our first step is Cyber Essentials, then Cyber Essentials Plus. They are cheap and fast, and they close the multi-factor authentication and patching gaps our Security page states, which every later framework would also demand.
• For German buyers, and for larger enterprise buyers generally, the usual answer is ISO 27001, which is the third stage.
• The Software Security Code of Practice self-assessment costs little, so it runs alongside Cyber Essentials rather than after it.
• BSI C5 and a GoBD software opinion are not on the roadmap. C5 matters mainly for public-sector buyers and for health data, which SorviAI is not offered for, and a GoBD opinion would first need the bookkeeping changes the Records in Germany section lists.
• 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, 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.

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 a body accredited by a national accreditation body, in Germany the DAkkS.

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.

BSI C5

The Cloud Computing Compliance Criteria Catalogue of the Federal Office for Information Security (BSI). An auditor reports on a cloud service against it, as a Type 1 report on the design of the controls or a Type 2 report on how they operated over a period, and the report also discloses facts such as where data is processed and which jurisdictions apply. It is not a certificate, and it attaches to the hosting as much as to the software.

GoBD and software opinions

The GoBD are the tax administration’s principles for keeping books and records electronically: complete, correct, timely, orderly and unalterable, with a written description of the process (Verfahrensdokumentation). They bind the business that keeps the books, not the software maker, and no authority certifies software against them. What exists is an auditor’s opinion on a software product (under the IDW PS 880 standard), which says the software can be used compliantly; the business must still use it compliantly.

Certified technical security devices for tills

A business that records transactions in an electronic till must protect the system and its records with a certified technical security device (TSE), certified by the BSI, give a receipt for every transaction, and register the till with its tax office (section 146a of the Fiscal Code, AO). It is also forbidden to market or supply, in Germany, till systems or till software that do not meet those requirements (section 146a (1) AO).

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.

SorviAI does not currently use an AI provider; if one is added it will be listed as a sub-processor with its transfer basis.

Why none of these rows says “compliant”

“GDPR compliant” as a standalone claim carries almost no information. Nobody certifies it, and a reviewer asking about the GDPR is not looking for the adjective. They need two concrete things: a data processing agreement, and a lawful mechanism for each transfer. The first is published; the second is set out, transfer by transfer, in the agreement, including the gap that remains for HR data reached from the United States by our hosting provider.

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.

German tax, commercial and employment law reach into how a product behaves, not only into what its policies say. SorviAI Finance is offered in Germany, and this section sets out plainly what it does and does not do for the records German law requires, so that you and your tax adviser (Steuerberater) can decide how to use it before you rely on it. SorviAI POS is not offered in Germany. This is not tax or legal advice.

Tax returns and filing

SorviAI Finance keeps your books and produces reports from them. It files nothing with the German tax authorities or any register: no tax returns, no annual financial statements and no filings to the commercial register. It has no SKR03 or SKR04 chart of accounts and no DATEV export. You will need separate software or a tax adviser for those, and filing on time remains your responsibility.

Where your books are kept

German law requires books and records to be kept in Germany (section 146 (2) of the Fiscal Code, AO). Electronic books may be kept in another EU member state (section 146 (2a) AO). Keeping them in a country outside the EU needs the approval of your tax office, on your written or electronic application, and the tax office can revoke it and require the books to be moved back to the EU (section 146 (2b) AO). Moving electronic books outside the EU without approval, or failing to give data access, can lead to a late-compliance charge of EUR 2,500 to EUR 250,000 (section 146 (2c) AO).

SorviAI holds all data in London, in the United Kingdom, which is outside the EU for this purpose, and offers no EU hosting region. If you keep books or records in SorviAI Finance that the law requires you to keep, you need your tax office’s approval first. Applying for it is your task; ask your tax adviser.

GoBD and unalterable records

An entry or record may not be changed in a way that leaves its original content undeterminable (section 146 (4) AO), and the tax administration’s principles for electronic books and records (GoBD) build on that, including a written description of your process (Verfahrensdokumentation). The duty is yours as the business keeping the books. SorviAI does not meet that standard today: a posted invoice can be permanently deleted from Trash, sent and partly paid invoices can be edited in place, lines and totals included, a posted accounting entry is not locked by a period close, and the audit log is not tamper-evident. We provide no process description for you to build on.

Tax audits

In a tax audit the tax office may access your data, have it evaluated to its specification or ask for it on a data carrier in a machine-readable form (section 147 (6) AO). SorviAI Finance has no export in the form tax auditors specify and no read-only role for an auditor. Produce audit data from the software or the tax adviser that keeps your books of record.

Electronic invoices

Between businesses established in Germany, invoices are moving to structured electronic invoices that meet the European standard, such as XRechnung, or ZUGFeRD from version 2.0.1 in its qualifying profiles. Since 1 January 2025 every business in Germany must be able to receive them. Until 31 December 2026 a business may still issue other invoices; that transition runs to 31 December 2027 for a business whose turnover in the previous year was no more than EUR 800,000; from 1 January 2028 the duty to issue applies, with few exceptions, to all. A PDF on its own is not an electronic invoice in this sense.

SorviAI Finance produces PDF invoices only. It has no structured e-invoice output and cannot read, validate or keep the structured data of an e-invoice it receives. Receive and keep your e-invoices in software that can, and issue them from it when the duty reaches you.

Record retention is separate from our backups

German law requires you to keep books, inventories and annual financial statements for ten years, booking vouchers, including invoices, for eight years, and business letters for six years (section 257 of the Commercial Code, HGB, and section 147 AO, as amended from 1 January 2025). That duty is yours, and it continues 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.

One more point for your records: because an invoice that has been sent, or partly paid, can still be edited in place in SorviAI Finance, lines and totals included, an issued invoice should be corrected by a cancellation or correction invoice and a booked entry by a counter-entry, never by editing. If you need the invoice as issued, keep the PDF you sent or export it at the time.

Point of sale

SorviAI POS is not offered in Germany. German law requires an electronic till to be protected by a certified technical security device, and forbids marketing or supplying till systems or till software in Germany that do not meet that requirement (section 146a (1) AO). SorviAI POS has no such device, so we do not offer it to businesses in Germany.

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.

• Working time. German law requires employers to record the start and end of each employee’s daily working time, overtime included (Federal Labour Court, 13 September 2022, 1 ABR 22/21), and to keep records of time worked beyond eight hours a day for at least two years (section 16 (2) of the Working Hours Act, ArbZG). Worklink’s attendance records can support that, and the attendance records export (CSV or Excel) carries each day’s times, breaks, hours and overtime; no automatic deletion applies to them. The records are not tamper-evident.
• Right to work and identity documents. Worklink has no right-to-work field or document type. Copies can be uploaded as general employee documents, but nothing tracks them or applies a retention rule, so keep the official record elsewhere.
• Tax and social security numbers. Without the employee’s consent, a business may use the tax identification number only for its dealings with the tax authorities or where a law expressly allows it (section 139b AO); do not use it, or the social security number, as an identifier. Worklink has no dedicated payroll field for them, so they go into the free-text national ID, tax ID or social security ID fields. Those fields are stored in plaintext and returned in full by the API to anyone with access to employee records; they are not restricted to payroll roles. Detail screens show only the last four characters, but the edit form shows the full value. 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. Both are health data, a special category under the GDPR; record the fact and duration of an absence, not a diagnosis, and do not use Worklink for occupational health records.
• Employees and the works council. Where there is a works council, introducing and using a technical system able to monitor employees’ conduct or performance needs its agreement (section 87 (1) number 6 of the Works Constitution Act, BetrVG), and Worklink falls within that rule. Agreeing it, usually in a works agreement, and telling employees what is recorded are the employer’s duties. We provide no template works agreement or works council information pack today. Worklink records the IP address of every check-in and check-out, and our error reporting records some sessions on screen, for every workspace, with no setting to switch it off (see the sub-processor table): include both when you inform them.
• Who decides. The employer is the controller 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 storefront run from Germany is the business’s own website, so it needs its own Impressum (section 5 of the German Digital Services Act, DDG) and 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 or EN 301 549, and no audit is scheduled yet. A customer whose storefront must meet an accessibility standard, for example as a public-sector body, 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 what safeguard is in place, 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 its transfer basis.

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. Data still leaves the United Kingdom in a few ways, each needing a lawful basis of its own, set out below.

Everything we host is in London today, and the Data Processing Agreement records it: we make no international transfer beyond those listed without your authorisation, so moving hosting out of the UK would need your agreement first. We offer no EU data residency; only error reports are processed in the EU.

Why this section carries dates and the others do not

Transfer law has moved repeatedly, through court decisions and successive replacement frameworks, and each move has invalidated arrangements that were correct the day before. The European Commission renewed its adequacy decision for the UK in December 2025, and the EU-US Data Privacy Framework is still being challenged in the courts. It is the one part of this page that can become wrong without anything at SorviAI changing and without anybody here noticing.

So the mechanism 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. Write in English; 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 Impressum.

Data protection and regulatory contacts

The regulators

If you are not satisfied with our answer on a data protection matter, you can go to a supervisory authority at any time. In Germany that is the data protection authority of the federal state (Land) where you live or work, whose contact details are listed by the Federal Commissioner for Data Protection and Freedom of Information (BfDI) at www.bfdi.bund.de. We have no establishment in the EU, so there is no lead authority for us. You can also go to the authority where you live or work elsewhere in the EU; the European Data Protection Board lists them at edpb.europa.eu. For content we host, the Bundesnetzagentur (Federal Network Agency) is the Digital Services Coordinator in Germany (www.dsc.bund.de).

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.