Data Processing Agreement

Two parties, two roles, one body of data.

1. This agreement is between the organisation that has accepted our Terms of Service (“you”, the customer) and SORVI AI LTD, a company registered in England and Wales with company number 16927720, whose registered office is at Unit 5a Victoria Road, Stoke-On-Trent, England, ST4 2HS (“SorviAI”, “we”, “us”).
2. You are the controller of the personal data in your workspace: you decide why it is processed and how. That includes everything you and your authorised users enter, upload, sync or send through SorviAI.
3. We are your processor. We process that data only to provide the service to you, on your documented instructions, and for no purpose of our own.
4. This agreement does not apply to personal data we control ourselves: our own signup, account, billing, support, website, newsletter and careers data. Our Privacy Policy governs that data.
5. We are registered with the Information Commission (the ICO) under number ZC254426. We are established in the United Kingdom, so no UK representative is needed.

This agreement is not signed on its own: it travels with the Terms of Service.

1. This agreement forms part of the Terms of Service and is concluded when they are: when a workspace is created or the service is first used for your organisation, or when both parties sign an order form. It applies for as long as we process personal data for you under the Terms of Service.
2. If you need a copy signed by us for your records, ask at [email protected] and we will send one. A signed copy carries the same terms as the version published here on the date it is signed.
3. If documents conflict, they apply in this order, each only to the extent of the conflict: (a) the UK transfer terms in Annex 4, for a restricted transfer they cover; (b) this agreement, for personal data we process for you; (c) an order form, for the commercial terms it sets out, where it says expressly that it overrides the Terms of Service; (d) the Terms of Service; and (e) the other documents the Terms of Service list. It is the same order the Terms of Service set out.

1. Customer personal data means personal data in your workspace that we process for you, as described in Annex 1.
2. Data protection law means the UK GDPR and the Data Protection Act 2018, as amended by the Data (Use and Access) Act 2025; the Privacy and Electronic Communications Regulations 2003 where they apply; and, to the extent it applies to your processing, the EU General Data Protection Regulation (the EU GDPR).
3. Sub-processor means a third party we engage that can reach customer personal data. Services you connect yourself are not sub-processors, as Sub-processors explains.
4. Restricted transfer means sending customer personal data, or making it accessible, to a recipient outside the United Kingdom that is a separate legal entity from us.
5. Personal data breach means a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, customer personal data.
6. Working day means a day other than a Saturday, a Sunday or a public holiday in England.
7. Other terms, such as controller, processor, data subject and processing, have the meanings they have in data protection law.

Article 28(3) requires the agreement to describe the processing itself. Annex 1 does that module by module; this section sets the frame.

1. Subject matter. Providing the SorviAI platform and the applications you subscribe to, such as Finance, Inventory, Worklink, Repairs, Storefront, the Customer and Vendor Portals, Nest and TeamEmail.
2. Duration. For as long as the Terms of Service run, and after that until the data is deleted under Deletion and return at the end.
3. Nature. Hosting, storing, backing up, retrieving, displaying, transmitting, syncing, exporting and deleting, together with the support, security and incident work needed to run the service.
4. Purpose. Only to provide, support and secure the service for you. We do not use customer personal data for our own purposes, we do not sell it, we do not use it for advertising, and we do not use it to train artificial intelligence models.
5. SorviAI does not currently use an AI provider. If we add one, it will be listed as a sub-processor with its transfer basis, under Sub-processors.

1. We process customer personal data only on your documented instructions (article 28(3)(a)). Your instructions are: (a) the Terms of Service and this agreement; (b) what you and your authorised users do in the product, such as creating a record, uploading a file, connecting a mailbox, sharing a Nest link or sending a document by email; and (c) any further written instruction you give us that is consistent with the service, for example about a rights request or a breach.
2. The one exception is where UK law requires us to process the data in some other way, such as under a lawful order from a court or a public authority. In that case we tell you before we act, unless the law forbids it on important grounds of public interest. Requests from public authorities describes how we handle those requests.
3. We tell you promptly if, in our opinion, an instruction infringes data protection law. We are not obliged to carry out an instruction we reasonably believe is unlawful while we discuss it with you.
4. As controller, you are responsible for having a lawful basis for what you put into SorviAI, for telling the people concerned what you do with their data, and for the lawfulness of your instructions. For Worklink in particular, Worklink: employee data in the United Kingdom sets out what UK employment and data protection law expects of you.

Our people reach workspace content in two ways only. Both are described plainly here, including what neither of them records.

1. Everyone at SorviAI who can reach customer personal data is bound by a duty of confidentiality, by contract or by law (article 28(3)(b)).
2. Support access. A SorviAI super administrator can sign in to your workspace on a user’s behalf through an impersonation route. We use it only to resolve a support request from you, 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 our platform audit log 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. A session can last up to 30 days. What the staff member does during the session is not recorded separately.
3. Direct database 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 of people with this access is reviewed every quarter. These connections leave no audit record.
4. Before access. Background checks are carried out before anyone is given access to production systems or customer personal data. Security and data protection training is given at onboarding, with a refresher each year.
5. Devices. Work laptops have full-disk encryption, a screen lock and automatic updates. Personal devices are not used for production access.
6. Leavers. When someone leaves, their access to our code repository, our hosting, our payment provider, email and the platform is removed on the day they leave. Our director is accountable for it.
7. Where we work. Our team works remotely, from the United Kingdom and India, and no office holds customer personal data. Transfers outside the United Kingdom explains how access from India is treated.

1. We apply the technical and organisational measures in Annex 2 (articles 28(3)(c) and 32). Annex 2 is taken from our Security page, row for row, with each measure’s status today. Where a measure is not in place, Annex 2 says so, and we do not claim it.
2. We may change the measures as the service develops, but we will not reduce the overall level of protection they give. When a measure listed as not in place is put in place, we update Annex 2 and the Security page together.
3. You are responsible for the security of what sits on your side: who you give access to, which roles they hold, and whether your users turn on two-factor authentication, which an administrator cannot yet require.

1. General authorisation. You give us general written authorisation to engage sub-processors (article 28(2)). Those in place on the date of this version are listed in Annex 3, and the maintained list is published on our Compliance page.
2. Notice. Before a new or replacement sub-processor starts handling customer personal data, we announce it on the published list and email your workspace account owners at least 30 days in advance. There is no separate subscription for these notices.
3. Objection. You may object on reasonable data protection grounds within that period by writing to [email protected]. We will discuss the objection with you in good faith. If we cannot resolve it, you may end the affected subscription by written notice before the change takes effect, and we will refund, pro rata, the fees you have paid for the unused part of the period.
4. The same obligations, passed down. Each sub-processor that holds or processes customer personal data for us (our hosting, email, payment, error monitoring and support mailbox providers) is bound by a written contract imposing data protection obligations no weaker than those in this agreement, including sufficient guarantees on security (article 28(4)). Google Fonts, Google Docs Viewer, jsDelivr, unpkg and GeoNames are public services we use under their providers’ standard terms, with no separate data processing contract; Annex 3 states what each receives.
5. We stay responsible. We remain liable to you for the performance of each sub-processor’s obligations as if they were our own.
6. Services you connect are not our sub-processors. HMRC Making Tax Digital for VAT, UPS, FedEx and DHL, Microsoft 365 for TeamEmail, and your own Stripe account receive data because you switch them on for your workspace. That data goes at your direction and under your own agreement with each provider, and Annex 3 lists them separately. One works differently: online invoice payment through the Customer Portal uses Stripe Connect, so payments go to your own connected Stripe account, but SorviAI creates that account and makes the charges with its own Stripe platform key, and the payer’s email address and the invoice number are sent to Stripe.

The application, the database and uploaded files are hosted in London. Personal data still leaves the United Kingdom in a few ways, and each needs a lawful basis of its own.

1. We host customer personal data on DigitalOcean in its London region: the application, the database and uploaded files, for every workspace wherever the customer is. DigitalOcean keeps database backups off-site and does not publish where.
2. The restricted transfers we make are to the sub-processors in Annex 3 that are outside the United Kingdom or reach the data from outside it. We make no other restricted transfer without your authorisation.
3. 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. The ICO does not treat that access as a restricted transfer, and it is covered by this agreement’s confidentiality and security terms.
4. UK data protection law, as amended by the Data (Use and Access) Act 2025, makes a restricted transfer lawful where the protection the data receives abroad is not materially lower than in the United Kingdom (the “data protection test”). The table below sets out the mechanism for each transfer and whether it is in place today; Annex 4 sets out the terms.
5. Before we rely on the International Data Transfer Agreement or the UK Addendum for a transfer, we carry out and record a transfer risk assessment confirming that the data remains protected to the data protection test.
6. If the law or practice in a destination changes so that a transfer no longer meets the data protection test, we tell you promptly and either put a further safeguard in place or stop that transfer.
7. You can ask for a copy of the safeguards that apply at [email protected].

1. A request from an individual about data in your workspace is yours to answer, because you are the controller. If one reaches us, we pass it to you without undue delay and do not answer it ourselves, unless you instruct us to.
2. We help you answer it by appropriate technical and organisational measures, as far as that is possible, taking into account the nature of the processing (article 28(3)(e)). Where a request needs our help, we respond within 10 working days of your written request.
3. When we help with an access request, we search to the standard UK law sets: reasonable and proportionate searches.
4. If a data protection complaint concerns processing we carry out for you, we help you answer it within the same 10 working days.

What SorviAI supports today

You generally have one month to answer the individual, and our 10 working days is set well inside it. Under the Data (Use and Access) Act 2025, the month does not run while you wait for the identity checks you need or, where you reasonably ask, for the person to clarify the request; and you must acknowledge a data protection complaint within 30 days and respond without undue delay.

You have 72 hours to notify the ICO of a personal data breach, unless it is unlikely to result in a risk to people. Our commitment is set so that you can still meet yours.

1. If we become aware of a personal data breach affecting customer personal data, we notify you without undue delay, and in any case within 48 hours of confirming it (article 33(2)).
2. We notify the workspace administrators on record, and any additional contact you have given us for this purpose.
3. We tell you 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; the likely consequences; and what you need to do. Where we do not yet know something, we tell you what we know and follow up as we learn more.
4. We take reasonable steps to contain the breach and reduce its effects, keep a record of it, and cooperate with your investigation.
5. We do not notify the ICO, or the people in your workspace, about your data on your behalf, unless you ask us to or the law requires it.
6. A suspected incident can be reported to us at [email protected] or by telephone on +44 20 7509 3731.

Where a breach affects data we control ourselves, we notify the ICO within 72 hours of becoming aware of it, unless it is unlikely to result in a risk to the people concerned, as our Privacy Policy explains.

The ICO expects an impact assessment for most monitoring of workers, which is how it will usually treat Worklink attendance records and connected TeamEmail mailboxes.

1. Where your processing needs a data protection impact assessment, or prior consultation with the ICO, we give you the information we reasonably can about our processing to support it (articles 28(3)(f), 35 and 36). We answer your assessment questions within 10 working days of your request.
2. We cooperate with the ICO in the performance of its tasks.

When the Terms of Service end, you take your data back by exporting it, and we delete it when you ask us to (article 28(3)(g)).

1. Return. There is no whole-workspace export, and no export is made for you when the agreement ends. You export what you need yourself, module by module, before it ends: list exports are capped at 20,000 rows, Nest downloads one file at a time, and TeamEmail, Storefront, POS and Escalate have no export. When a subscription ends, every application locks at once, leaving only sign-in and billing, and there is no retrieval period afterwards.
2. Deletion. Nothing deletes a workspace automatically. Customer personal data stays in our systems, on the terms of this agreement, until you ask us in writing to delete it, so that you can re-subscribe and regain access. We delete it from our live systems within 30 days of that request.
3. Backups. Deleted data remains in backup copies until they are overwritten, within 7 days after deletion from our live systems. We use backups only to recover the service from a failure.
4. What the law makes us keep. Where UK law requires us to keep something, we keep only what that law requires, protect it under this agreement, and use it for nothing else.

Your own retention duties continue

Deleting your workspace does not end what UK law requires you to keep. HMRC generally expects business and VAT records, including the digital records Making Tax Digital requires, to be kept for six years, and a private company must keep its accounting records for three years (Companies Act 2006, section 388). Our seven-day backups are not an archive and meet none of those duties, so export and keep your records before the agreement ends.

SorviAI holds no third-party security certification or attestation today: no Cyber Essentials certificate, no ISO 27001 certificate and no SOC 2 report. Cyber Essentials is first on our roadmap. Until a certificate exists, this section is how you check us.

1. We make available to you the information reasonably necessary to show that we meet article 28, and we allow for and contribute to audits, including inspections, by you or an auditor you mandate (article 28(3)(h)).
2. We offer first: our Security page, which is the source of Annex 2, with the gaps stated; your security questionnaire, completed on your own form at no charge, within 10 working days; and a call with an engineer who has read the code, usually within a week.
3. If that information does not answer a reasonable concern, you may audit our processing of your data: on at least 30 days’ written notice; no more than once in any 12 months, unless a personal data breach or a regulator requires it; during working hours and without unreasonably disrupting the service; by you or an independent auditor who is not our competitor, under a written duty of confidentiality; and at your own cost.
4. An audit may not give access to another customer’s data, or to our systems beyond what is needed to verify our processing of yours.
5. We tell you immediately if, in our opinion, an audit instruction infringes data protection law.

1. If a public authority asks us for customer personal data, 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.
2. We disclose only what the request compels, and we refuse or challenge a request that does not have a proper basis.
3. Where we can, we direct a request for your business records to you, as the controller.
4. We tell you before we disclose, unless the law forbids it, and for only as long as it forbids it.

1. Each party’s liability arising out of or in connection with this agreement is subject to the limitation of liability in the Terms of Service and counts towards the same limit: the fees paid or payable by the customer in the 12 months before the event giving rise to the claim. Claims under this agreement sit inside that limit, not beside it.
2. Nothing in this agreement limits or excludes liability for death or personal injury caused by negligence, for fraud or fraudulent misrepresentation, or for any other liability that cannot lawfully be limited or excluded.
3. Nothing in this agreement limits the rights of individuals against either of us under article 82 of the UK GDPR, or the powers of the ICO.

For employee records you are the controller as employer, with the obligations UK employment and immigration law add, and we process the data on your instructions. What Worklink does today, and what that means for you:

• Health data. SorviAI sets up a “Sick Leave” leave type in every workspace that uses Worklink, and every leave request needs a free-text reason, so details of an illness can be typed into the record. A leave request can also carry a supporting document such as a fit note. Health information is special category data: you need a condition under Schedule 1 to the Data Protection Act 2018, usually the employment condition, and for that condition an appropriate policy document, for which the ICO publishes a template. Record the fact and dates of absence, tell staff not to put a diagnosis in the reason field, and ask for a fit note only where you need it.
• National Insurance numbers. Worklink has free-text national ID, tax ID and social security number fields, and no dedicated National Insurance field, so in a UK workspace the number will usually go in one of them. The numbers are stored in plaintext and returned in full by the API to anyone you give employee access, with no separate restriction; detail screens show only the last four characters, but the edit form shows them in full. Leave them empty unless you need them in Worklink, and limit who has employee access.
• Right-to-work documents. Worklink has no right-to-work field or document type. A copy uploaded to an employee record is an ordinary document, visible to anyone with access to that record, and nothing deletes it automatically. Employers must keep these copies for the whole employment and two years after it ends, and then delete them: restrict access and diarise the deletion.
• Working-time records. Employers must keep records adequate to show compliance with the Working Time Regulations 1998 for two years (in Northern Ireland, the Working Time Regulations (Northern Ireland) 2016). Worklink records check-in and check-out times, hours, breaks and overtime, and deletes none automatically. The records are not tamper-evident, and there is no dedicated working-time report; the attendance records export (CSV or Excel) carries each day’s times, breaks, hours and overtime, so export it and keep it for the period the law sets.
• Monitoring. Worklink records the IP address of every check-in and check-out, and there is no setting to switch it off, so tell your staff. It uses no biometrics, no location coordinates and no photographs at check-in; the only image it holds is an optional profile picture. We will not add biometric check-in without a separate data protection review.
• Automatic records. Worklink marks employees absent automatically each day when no check-in is recorded, and can clock people out automatically if you switch that on (off by default). These are records for you to review and correct, not decisions: nothing in Worklink takes a decision with legal or similarly significant effect on its own.
• Visitors. The visitor desk can record a visitor’s ID type and number, including passport and residence-permit numbers. They are hidden in API responses but stored as entered, and nothing deletes them automatically. Record them only where you need them.
• Connected mailboxes. Access to employees’ email through TeamEmail is monitoring too, and the same ICO guidance applies. Tell staff which mailboxes are connected and who can read them.

An employee who asks us about their record is referred to you, and we help you answer.

1. We may update this agreement to reflect changes in the law, in the service or in our sub-processors. Changes to the sub-processor list follow Sub-processors.
2. For any other change that reduces your rights or our obligations, we give workspace account owners at least 30 days’ notice by email, and you may leave before it takes effect. A change the law requires takes effect when the law requires.
3. Version 1.1 records that Session Replay runs only for users who allow analytics in our consent banner. 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.
4. This agreement ends when we have finished deleting customer personal data under Deletion and return at the end. The duties in Confidentiality of our people, Deletion and return at the end and Liability continue for any data we still hold after that.

1. This agreement, and any dispute or claim arising out of or in connection with it or its subject matter (including non-contractual disputes or claims), is governed by the law of England and Wales, and the courts of England and Wales have exclusive jurisdiction, as under the Terms of Service.
2. The transfer terms in Annex 4 are governed by the law they themselves specify.

This agreement is between businesses, and the same law and forum apply to business customers across the United Kingdom, including in Scotland and Northern Ireland. The UK GDPR applies in the same way in all four nations. Employment law in Northern Ireland is devolved and differs in places, so check the Northern Ireland rules for employees there.

Three kinds of request, each with its own commitment. All three reach the same desk, so an urgent one is never parked behind a routine one.

No data protection officer is appointed, and none is required; Deepak Gupta, director, is responsible for data protection. Our reasoning is on our GDPR Compliance page.

The processing this agreement covers, module by module. It is also the description our article 30(2) record will be built from.

Data subjects, overall. Your authorised users (for their activity in your workspace; their accounts with us are covered by our Privacy Policy); your employees and other staff, including repair technicians, and the family members and dependants an employee record names; visitors signed in at your visitor desk; your customers and suppliers and their contact persons; people who report a repair, raise a help desk request, send a storefront enquiry, sign in to your portals or open a file you shared by public link; people who exchange email with your team; and shipment recipients.

Frequency. Continuous, for the duration set out under What we process, for how long, and why.

Special category data. Health information in Worklink: every workspace that uses it has a Sick Leave type, every leave request needs a free-text reason, and a fit note can be attached. Any special category data you choose to put in an uploaded file, an email or a free-text field. SorviAI processes no biometric data and has no field for criminal offence data; what you type into a free-text field or upload is yours to control.

Other sensitive data. National Insurance and other identification numbers, held in plaintext free-text fields; bank details and pay; copies of right-to-work documents, which contain passport and immigration details; and visitors’ passport and residence-permit numbers.

These measures come from our Security page, with the same status. Where a row says a measure is not in place, it is not promised.

The sub-processors in place on the date of this version. The maintained list is on our Compliance page.

Contracts. DigitalOcean (which engages Cloudflare for App Platform), Twilio, Stripe, Functional Software (Sentry) and Microsoft process data under their data processing terms. Google Fonts, Google Docs Viewer, jsDelivr, unpkg and GeoNames are public services used under their providers’ standard terms, with no separate data processing contract.

Our own team. Not a sub-processor. Everyone on our team in India is employed by SORVI AI LTD, so a team member who reaches our UK systems from there is part of the same company. Anyone who worked for us there as a contractor or through another company would make a restricted transfer, covered by the terms in Annex 4, signed before their access began.

Services you connect (not our sub-processors)

The terms on which we make restricted transfers of customer personal data, and the International Data Transfer Agreement we would sign for access from India by anyone who is not our employee.

Part A: how restricted transfers are made

1. Adequacy. A transfer to a country or territory covered by UK adequacy regulations, including the EEA and Switzerland, is made on that basis, with no further safeguard.
2. The data bridge. A transfer to a recipient in the United States that is certified under the UK Extension to the EU-US Data Privacy Framework relies on that certification, but only for the kinds of data the certification covers: HR data, non-HR data or both, as the recipient has declared.
3. Transfer agreements. Any other restricted transfer is made under the International Data Transfer Agreement (version A1.0), or the International Data Transfer Addendum to the EU Standard Contractual Clauses (version B1.0), both issued under section 119A of the Data Protection Act 2018 and in force since 21 March 2022, entered into between us, as exporter, and the recipient, as importer. Where the recipient is our sub-processor, its own data processing terms may supply them, as Twilio’s do.
4. Transfer risk assessment. Before relying on a transfer agreement, we carry out and record a transfer risk assessment confirming that the data remains protected to the data protection test, and we repeat it when the law or practice in the destination changes.
5. EEA-origin data. Where the EU GDPR applies to your processing, your transfer to us relies on the European Commission’s adequacy decision for the United Kingdom, renewed on 19 December 2025 and valid until 27 December 2031. Onward transfers from us are made on the bases above, using the EU-US Data Privacy Framework in place of the UK Extension and, where the EU GDPR requires it, the EU Standard Contractual Clauses (module 3, processor to processor) with the recipient.

Part B: the International Data Transfer Agreement for access from India

We sign it before anyone in India who works for us as a contractor or through another company can reach customer personal data. Today no one does: our team there is employed by SORVI AI LTD. Its tables are completed as below, and its mandatory clauses are used as the Information Commissioner issued them, without change.

Four phrases this agreement uses that most readers will not have met before.