Data Processing Agreement

This is the current version, dated 13 October 2026.

Version: 13 October 2026.

This Data Processing Agreement ("DPA") forms part of the Terms of Service (the "Terms") between MVV Technologies Limited, company number 17300982, registered in England and Wales, registered office Suite 301, 18-24 Turnham Green Terrace, London, England, W4 1QP ("MVV", "we"), and the business that subscribes to the service ("Customer", "you").

It is written to meet Article 28(3) of the UK GDPR and the ICO's guidance on contracts between controllers and processors. It describes the platform as it is really built. Where something is not yet in place, or is done by a person rather than by the software, it says so.

1. Definitions

Words defined in the UK GDPR ("controller", "processor", "personal data", "personal data breach", "processing", "data subject", "supervisory authority") have the same meaning here. In addition:

• Data Protection Law: the UK GDPR, the Data Protection Act 2018, the Privacy and Electronic Communications Regulations 2003, each as amended (including by the Data (Use and Access) Act 2025), and, where it applies to a Customer established in the EU or Switzerland, the EU GDPR or the Swiss Federal Act on Data Protection.
• Customer Personal Data: personal data that MVV processes on the Customer's behalf in providing the service, as described in Annex 1.
• Workspace: the Customer's own copy of the application, with its own web address, its own database project, its own file storage and server functions, separate from every other customer's.
• Sub-processor: a third party MVV engages to process Customer Personal Data. They are listed in section A of MVV's Sub-processor list, which is published with this DPA.
• Restricted Transfer: a transfer of Customer Personal Data to a country outside the UK that is not covered by UK adequacy regulations.
• Account owner: the person named in the Customer's order as the Workspace's first administrator, as in the Terms.
• Control console and control records: MVV's own back-office tool and the database and records behind it, which MVV uses to run the service for every customer.
• Gateway: MVV's service through which every AI request a Workspace's server functions make, and every email a Workspace sends, pass.
• MVV's computer: the computer at MVV's premises in England on which MVV runs its control console and the tools that build, update, back up, restore and export Workspaces.
• Authorised MVV personnel: the people at MVV whom MVV authorises, under a duty of confidentiality (clause 5.1), to hold the highest level of access in MVV's control console and to use MVV's keys. Where this DPA says that only authorised MVV personnel can do something, nobody else at MVV can.
• MVV support: the people at MVV who run the service for customers and answer them.
• Working day: Monday to Friday, excluding bank holidays in England and Wales, as in the Terms (clause 10.3).
• When sign-up opens: the day MVV sends its first invitation to join to a customer. Joining is by invitation; MVV's public sign-up form is not open. A few parts of the service come into use on that day, and this DPA marks each one. No customer's Workspace exists before that day.

2. Roles

2.1 The Customer is the controller, and MVV is the processor, of Customer Personal Data. The Customer decides why that data is collected and how it is used; MVV provides the software and the hosting and acts on the Customer's instructions.

2.2 MVV is a controller of its own business data about the Customer: account and company details, billing, support and cancellation requests, and the service records described in the Privacy Policy. Those service records are counts and measurements about each Workspace, without its content: for example how many staff it has by role, how many signed in recently, the time of the latest office-staff sign-in, how many rows its tables hold, records of AI and email calls without their content, and whether it was reachable. That processing is outside this DPA and is covered by the Privacy Policy.

2.3 MVV processes Customer Personal Data only to provide the service (and as clause 4.3 says), and never uses it to train AI models or to improve the service for other customers. The one exception to "only to provide the service" is the service records in clause 2.2: counts and measurements without content, which MVV derives from each Workspace and uses as a controller to run, secure, bill and improve the service. Where a Workspace has only one or two office staff, some of those counts, such as the time of the latest office-staff sign-in, can relate to a person; MVV uses them for those purposes only. Each Workspace has its own database project, sign-in and file storage; no Workspace's database holds another customer's data. A few parts of the service are shared by every Workspace, each with its own safeguard:

• the email lane: one shared sending address and one provider account. The gateway sets each Workspace's sender name (when sign-up opens, from MVV's control records only), tags each email with the Workspace's short name, and keeps a separate count for each Workspace;
• the backup storage: one Cloudflare R2 bucket, reached with one credential, holds every Workspace's backups, one folder each. Each Workspace's backups are sealed with a key of that Workspace's own (Annex 2, item 19);
• the AI provider accounts: every Workspace's AI requests are made on MVV's own accounts with each provider, through keys the gateway holds and shares between Workspaces. No Workspace has a provider account of its own;
• for live voice, one ElevenLabs account holds every Workspace's voice assistants and the conversations ElevenLabs stores for them. The gateway gives a Workspace voice links for its own assistants only;
• the WhatsApp router, which is switched on automatically for each customer's Workspace once the Terms that offer WhatsApp apply to it (the Terms, clause 8.3). One number run by MVV serves every customer. A person is linked to a company only by tapping "Yes, link me" on that company's link request, or by quoting a yes onto it. The messages a Workspace sends go out through the router, on MVV's credentials, and only to a person linked to that Workspace. A person who leaves the company stays linked until the Customer unlinks them or the Workspace's check for leavers cuts the link, and until then their messages still reach that company;
• the law library, which is not switched on at launch. When MVV switches it on, there is one copy of the public law library in MVV's control database, which every Workspace's Contract Helper searches with its own gateway pass, falling back to the Workspace's own copy when the central one does not answer. The search text (a question, or a case's title, which can name people) passes through and is not stored, and MVV keeps a count per Workspace per day.

Where an assistant "learns", it proposes lessons into that Customer's own Workspace only.

3. The Customer's obligations

The Customer:

(a) is responsible for having a lawful basis for the Customer Personal Data it puts into the Workspace, and for giving its staff, workers, customers and other people the information the law requires. Each Workspace includes a draft privacy notice page, generated with the Customer's details, that names the Customer as controller and describes MVV as its software supplier and processor. It is a starting point that MVV provides as a convenience, not advice: the Customer must review it and adapt it to what the Customer really does, and what the Customer publishes is its own notice. As built, it says that the app sets no cookies of its own and describes what the app keeps in the browser, and MVV's Cookie Notice is the full list of what the app keeps on a device;

(b) obtains any consent needed for messages it sends through the service, and complies with the rules on electronic marketing in anything it sends to prospects or the public (see the Terms, clause 7). Where WhatsApp is switched on for the Workspace, a person's phone is linked to the shared WhatsApp number only after that person taps "Yes, link me" on, or quotes a yes onto, a link message that one of the Customer's Super Admins asked MVV to send. Only the Customer's own staff and the operatives on its Labour board can be linked;

(c) carries out any data protection impact assessment its use requires. MVV will assist as set out in clause 9;

(d) keeps its users' sign-in details secure, removes access for people who leave and, where WhatsApp is switched on, unlinks their numbers (see the Terms, clauses 4.3 and 8.3(d));

(e) does not instruct MVV to process data in a way that breaks Data Protection Law.

4. Processing on documented instructions

4.1 MVV processes Customer Personal Data only on the Customer's documented instructions. The instructions are: the Terms and this DPA; the Customer's configuration and use of the Workspace (including which modules, assistants and connections it switches on); and any further written instruction the Customer gives and MVV accepts. The Customer's instructions include running MVV ID for its users (clause 5.2), so that they can find their Workspace from MVV's phone app.

4.2 The Customer instructs MVV to make the transfers described in Annex 3, which are needed to provide the features the Customer uses.

4.3 If Data Protection Law requires MVV to process Customer Personal Data other than on instructions, MVV will tell the Customer before doing so, unless the law forbids telling it.

4.4 MVV will tell the Customer promptly if, in MVV's opinion, an instruction breaks Data Protection Law.

5. Confidentiality and MVV's access

5.1 MVV makes sure that everyone it authorises to process Customer Personal Data is under a duty of confidentiality.

5.2 How MVV can reach Customer Personal Data, as built. The Customer should know the following:

• The control console. MVV's control console cannot read a Workspace's projects, money records, documents or people. It talks to each Workspace through fifteen fixed operations. Most return counts, sizes and status, including AI use per module per day. Some change the Workspace: switching modules on and off and suspending it; setting how much AI it may use (by a signed instruction); holding its brand; placing or withdrawing a plain-text notice; closing support requests; confirming a cancellation the Account owner filed, which only authorised MVV personnel can do; withdrawing that confirmation at the Customer's word before the leave begins, which only authorised MVV personnel can do; telling it, once its cancellation is confirmed, the day its service ends, so that the Workspace shows the Account owner that date; asking the Workspace to cut the WhatsApp links of people who have left; and asking it to send MVV ID its current list of people. When someone at MVV is shown a view of the Workspace's data in the console (its page, how many people it has, its support requests, a cancellation request it has made, what it uses, its AI spend, changes to its company details) the console's audit log records who, which view and when, never the data. A second look at the same view by the same person within 5 minutes adds no new line, and a view of totals across all Workspaces is not recorded.
• MVV ID (the phone app's sign-in finder). So that a person can find their company from MVV's phone app, each Workspace sends MVV once an hour, through its own gateway pass, the whole list of its people's sign-in email addresses. MVV keeps, per Workspace, only a keyed fingerprint of each address and a hint of its first character and domain, never the address itself. A person the Workspace no longer lists is taken off within the hour (at most 25 an hour), and the entry is deleted 400 days later. When someone types an email address into the phone app, MVV uses it only to look for a match and, when a Workspace lists it, to send a six digit code to that address; the address is not kept. The code, used on the phone that asked, gives the phone the Workspace's name, address and public key, and the person then signs in with the Workspace itself: MVV never sees a password. When a Workspace leaves, every entry for it is taken off MVV ID's list, and no list is taken from it while its leave is in progress.
• Updates. From the same console, authorised MVV personnel, and only they, can start an update of a Workspace. MVV's tools then re-apply the Workspace's database layer and module settings, redeploy its server functions and publish its web app, using MVV's keys. They read back version records and counts, never the Workspace's content. An update always goes to one of MVV's own demonstration Workspaces first (one that a prospective customer is trying out can be among them), never to a customer's first, and then to customers' Workspaces in steps, each started by authorised MVV personnel. A Workspace can be held out of an update for a time (see the Terms, clause 3.3).
• No support access. There is no feature that lets MVV staff sign in as, or view the Workspace of, a customer. MVV does not offer support access at launch. If MVV builds such a feature later, it will not be switched on until this DPA has been changed to describe it, under clause 18.2 of the Terms.
• No password held. MVV holds no password for the Customer's Account owner. The one the build needs to create that account is made for that moment and never written down, the welcome email always carries the link for the Account owner to choose their own, and MVV never sees the password they choose. The console shows a Workspace owner's sign-in only for MVV's own demonstration Workspaces, and records each time it does; a password shown there stops working if that demonstration Workspace is restored into a new project.
• MVV's keys. MVV does hold, on MVV's computer, each Workspace's administrative keys and database password, and the access token for MVV's account with the hosting provider, in which every Workspace's database project sits (together, "MVV's keys"). MVV needs them to build, update, back up, restore and export the Workspace, and to carry out a leave and the deletion that follows it. MVV also keeps there the key with which the Workspace locks the passwords and access tokens of the outside services the Customer connects to it.
• Backups and restores. Nightly backups contain a full copy of the Workspace, with every stored file up to 20,000, sealed with a key of the Workspace's own that MVV holds. A restore test replays a backup into a temporary database on MVV's computer. A restore over the Workspace itself is followed by MVV's current signed instruction for its modules, and leaves the Workspace's cancellation requests, AI use and update records as they were. A restore into a new project, including a recovery of a Workspace whose project was lost, makes every password, passkey, second sign-in step and recovery code the backup carried unusable, in the same step. It ends every sign-in, asks everyone to choose a new password through a one-off link, and keeps out the people the Customer names as having left since the backup. If any of that cannot be done, the restore puts nothing in place.
• An AI coding assistant. MVV operates the platform with the help of an AI coding assistant on MVV's computer, supplied by Anthropic, which the Sub-processor list names for that purpose (A4; see clause 5.3).

5.3 Who may use that access, and how each use is recorded. Only authorised MVV personnel may use MVV's keys for the Workspace, and its backups, either themselves or through MVV's own tools acting on their instructions, and only to run, back up, restore, export or delete the Workspace, or to find and fix a fault, or on the Customer's written instruction. Every use is recorded, as follows:

(a) MVV's tools record each backup, test restore and update of the Workspace in MVV's control database, and each step of a leave and of the deletion that follows in MVV's control records;

(b) since 30 September 2026, every command of MVV's tools that uses one of MVV's keys for the Workspace first writes a line in MVV's key-use record: which tool, which Workspace, which kinds of key, why, and the computer account that ran it. If the line cannot be written, the command stops before any key is read. A restore of the Workspace is also written in the control console's audit log before the Workspace is touched;

(c) the control console's audit log records each change made from the console, and each time someone at MVV is shown a view of the Workspace's data, except a repeat of the same view within 5 minutes (clause 5.2);

(d) any use of a key by hand, outside those tools, is written by authorised MVV personnel in a written access log book, kept from launch: the date, the Workspace and the reason.

The control console's fixed operations (clause 5.2) are separate from MVV's keys. MVV staff whose role in the console allows it can use them, for example to see that a Workspace asked for help and to mark the request done, and each such act is written in the console's audit log.

Three limits apply, and MVV states them plainly. First, the control console uses MVV's keys by itself throughout the day for its automatic checks of each Workspace (its health and status, its security findings and errors, the filing of its records, and similar checks); these automatic checks are not listed one by one. Second, the key-use record names the computer account, not the person: authorised MVV personnel, MVV's tools and the AI coding assistant all work under one account on MVV's computer. Third, the key-use record is a single private file on MVV's computer and the log book is kept by authorised MVV personnel; unlike the control console's audit log, neither is built so that it cannot be changed.

MVV keeps the key-use record, the access log book and the audit log for 7 years after the Customer's last subscription ends, and then deletes what they hold about the Customer's Workspace in its yearly delete (clause 11.5).

MVV does not notify the Customer each time authorised MVV personnel use a key by hand without the Customer having asked for it: the use is recorded as above. If a use amounts to a personal data breach, clause 10 applies.

MVV operates the platform with the help of an AI coding assistant, which acts only on the instructions of authorised MVV personnel. Its supplier, Anthropic, is in the Sub-processor list (A4).

6. Security

6.1 MVV implements the technical and organisational measures in Annex 2, taking into account the state of the art, the cost, the nature of the processing and the risks to people.

6.2 Annex 2 lists, in its final section, the measures MVV has not yet put in place. When one is completed, MVV says so in the next version of this DPA. The Customer has read Annex 2, including that final section, and agrees that, for the processing it instructs, the measures give a level of security appropriate to the risk. If the Customer needs more for a particular use, it tells MVV before it starts that use.

6.3 MVV may change the measures in Annex 2 as the service develops, as long as the overall level of security is not reduced. Such a change is not a breach of this DPA, and MVV describes it in the next version of this DPA. A change that would reduce the overall level of security is made only under clause 18.2 of the Terms, before it takes effect.

7. Sub-processors

7.1 The Customer gives MVV general written authorisation to engage the sub-processors listed in section A of the Sub-processor list for the purposes stated there.

7.2 MVV will give the Customer at least 30 days' notice, by email to the Account owner, before engaging a new sub-processor or changing what an existing one does.

7.3 The Customer may object on reasonable data protection grounds within that notice period. The parties will discuss the objection in good faith. If it is not resolved, the Customer may end the affected part of the service, or the whole subscription, with no charge for ending early, before the change takes effect. Fees already paid are not refunded (the Terms, clause 5.7).

7.4 MVV engages each sub-processor on that provider's own written terms, and remains responsible to the Customer for each sub-processor's performance of its data protection obligations. MVV has not yet collected those terms in one file and checked, for each provider, that its data processing terms are in place and give protection equivalent to this DPA (Annex 2, final section).

8. International transfers

8.1 Some sub-processors process Customer Personal Data outside the UK. Annex 3 and the Sub-processor list say, for each one, where it processes, as far as the platform's own settings decide it, and the transfer mechanism in that provider's terms as MVV understands it.

8.2 Where a Restricted Transfer relies on the International Data Transfer Agreement or the UK Addendum to the EU Standard Contractual Clauses, Data Protection Law requires a transfer risk assessment. MVV has written one for each sub-processor, following the ICO's transfer risk assessment tool, but has not yet signed off any of them (Annex 2, final section).

8.3 The Customer's Workspace database and files are held in the region set by the Customer's country (for UK customers, London). The Customer should not describe the service to others as "UK only": AI processing, email delivery and backups take place outside the UK, and so does WhatsApp delivery, as Annex 3 shows.

9. Assistance

9.1 Data subject rights. Taking into account the nature of the processing, MVV will help the Customer respond to requests from people exercising their rights. The Customer's administrators can find, correct and delete most records in the Workspace themselves, with these exceptions as built: a signed site induction cannot be deleted or changed, only marked void, so that it stays a reliable health and safety record; when some kinds of record are deleted (for example a worker's record, a project, an expense, a note, a report or a document's record), a full copy of the deleted record stays in the Workspace's change history, which only super admins can read and which nothing deletes until the Workspace itself is deleted; and messages and notes that mention a person are not deleted with that person's account. The Workspace has no tool to export everything about one person: the Customer gathers it from the screens. Where the Customer cannot do something itself, MVV will help on request within 10 working days. Copies already held by an AI, email or messaging provider under its own terms (for example its logs) are deleted on that provider's own schedule, and MVV cannot recall them (Annex 3). The conversations that ElevenLabs holds for the Workspace's voice assistants, in MVV's ElevenLabs account, are kept as ElevenLabs' terms and that account's settings decide (the Sub-processor list, A7), and MVV can delete them there on the Customer's request.

9.2 Security, breaches, impact assessments, consultation. MVV will help the Customer meet its obligations under Articles 32 to 36 of the UK GDPR, taking into account the information available to MVV. For impact assessments MVV provides, on request, its written description of the processing, the data flows, the sub-processors and the security measures.

9.3 Requests made to MVV directly. If a person asks MVV, rather than the Customer, to exercise a right over Customer Personal Data, MVV will not answer the request itself (beyond saying it has been passed on) and will pass it to the Customer without undue delay.

9.4 Requests from public authorities. If a court, regulator, law enforcement body or other public authority asks MVV for Customer Personal Data, MVV will, unless the law forbids it, tell the Customer promptly, give it the chance to object, disclose only what the law requires, and keep a record of the request.

10. Personal data breaches

10.1 MVV will notify the Customer without undue delay, and in any event within 72 hours, after becoming aware of a personal data breach affecting Customer Personal Data, including a breach at a sub-processor. MVV becomes aware when it has a reasonable degree of certainty that such a breach has happened; it may take a short time to check what happened first. For a breach at a sub-processor, MVV becomes aware when the sub-processor tells MVV of it. The first notice may be short and say only what is known; more follows in stages (clause 10.2).

10.2 The notice will include, as far as known: what happened; the categories and approximate numbers of people and records affected; the likely consequences; what MVV has done and proposes to do; and a contact at MVV. MVV may give the information in stages.

10.3 Each Workspace is a separate project, but one incident may affect several customers. MVV will notify each affected customer separately.

10.4 MVV will not notify the ICO or any data subject on the Customer's behalf unless the Customer asks it to in writing, or the law requires it.

10.5 MVV keeps a record of every personal data breach affecting Customer Personal Data, whether or not it was notified.

10.6 A notice under this clause, and anything MVV says while helping the Customer, is not an admission of fault or liability.

11. When the service ends: return and deletion

11.1 How leaving works. MVV carries out a leave with its leave command. The command starts only when MVV's control records show that the subscription is ending, in one of two ways: the Customer's Account owner asked to cancel in the Workspace and MVV confirmed it, which both the Workspace and MVV's control records must show; or MVV ended the agreement for non-payment under the Terms (clause 17.3) and the day that takes effect has come. If the agreement ends in any other way (the Terms, clauses 17.2, 17.2A and 17.2B), the leave command cannot yet start by itself, and MVV agrees with the Customer how the leave is carried out. It acts only against the database project MVV's control records hold for the Workspace. It carries out the steps below in order, records each one, stops at the first that fails, and resumes from there, first re-checking that what it already did still holds. No customer's leave has been run yet.

1. MVV exports the Customer's data before anything is switched off: the Workspace database as a standard PostgreSQL file with a list of every table and its row count; the people and their sign-in records; and every stored file in folders, with a list of them. The leave does not continue if any part of the export is missing or empty.
2. The Workspace is suspended by a signed instruction, which MVV's control records note; its access to the AI gateway is switched off; and, where WhatsApp was switched on, its WhatsApp routing is retired and every linked number is unlinked. Its database project is then paused or, where the hosting provider will not pause it (at the date of this DPA it pauses no customer's project), made read-only: every change to it is refused, whoever makes it, and its scheduled tasks are stopped, which the leave checks before it goes on. A read-only Workspace is not taken offline: until it is deleted, its users can still sign in and see its data, but cannot change or save anything. If a pause fails for another reason, the Workspace stays suspended, with its AI switched off and its screens and data still there, until MVV pauses it by hand, which MVV does within 7 days.
3. MVV records the date the service ended and the date 90 days later, and removes the Workspace's voice assistants from MVV's ElevenLabs account. The leave is then recorded as finished in MVV's control records, but only once the suspension and the pause, or the read-only setting, are read again and still hold.
4. Within 30 days after those 90 days, a person at MVV deletes the Workspace's database project, which removes its database, sign-in records and files. The deletion command asks that person to type a sentence naming both the Workspace and its project. It deletes only once MVV's control records confirm that the Workspace was suspended and its leave finished, that no instruction has been sent to it since its suspension and that 90 days have passed by their own date, and it deletes only a project that is paused, or read-only and still found read-only when the command runs. Once MVV's control records record the deletion, MVV removes what MVV's computer still keeps of the Customer: the copies of its company details, the builds and keys for its Workspace, and the sealed copies of the key for its stored connection passwords that are kept with its backups. The command removes almost all of these itself; a person at MVV removes what it leaves. The Workspace's backup key is dealt with under clause 11.3.

If the Customer changes its mind. Until MVV confirms the cancellation, the Account owner can withdraw it in the Workspace. After MVV has confirmed it and before the leave begins, MVV support withdraws the confirmation at the Customer's word: nothing has been switched off, the withdrawal is recorded in MVV's control records and uses up that cancellation, the Workspace shows as active again and says the subscription continues, and a new request can be made later. If that leave had already made its exports, they are moved aside on MVV's computer and MVV support deletes them by hand within 30 days; nothing deletes them by itself.

If the Customer stays after the leave has begun, MVV closes the leave in its records. Where the Workspace's database was made read-only, closing the leave first lets it take changes again, and checks that it does; it does not by itself switch anything else back on: MVV does so by hand. If MVV switches the Workspace back on before the paid period ends, the subscription continues; after that, a new subscription is needed. Closing the leave also uses up the confirmed cancellation, so a later leave needs a new one. The Workspace does not yet let the Account owner ask for a new one there, and the leave command cannot start without one: the Workspace asks them to speak to MVV's support instead, and MVV agrees with the Customer how the leave is carried out.

The Workspace tells the Account owner, when they ask to cancel: *"Your data is kept for 90 days after the service ends, with a full export available, and is then deleted."* This clause says exactly how and when.

11.2 The export is given to the Customer. Within 5 working days after the service ends, MVV sends the Account owner, by hand, a private download link to the export made in step 1. That export is the "full export" that the Workspace's words quoted in clause 11.1 speak of, and it stays available until the Workspace is deleted: if the Customer has not downloaded it, MVV sends a new link on request until then. At launch MVV does not offer a full export while the subscription runs.

11.3 Backups. While a Workspace is in service, MVV keeps its backups for 30 days and then removes them at the nightly clean-up, each Workspace on its own. The clean-up starts by itself: it is part of the nightly run that MVV's computer starts each night, and it runs after the backup, on a night the backup finishes without a fault. Each morning MVV checks that it ran and finished. If it did not, it runs on the next night the backup finishes without a fault, and until then a backup can stay longer than 30 days (Annex 2, item 19). The clean-up never removes the newest complete backup or an incomplete one, nor, when the newest holds none of the Workspace's people, the newest older one that does, nor, when the newest holds none of the Workspace's stored files, the newest older one that does. Nothing is removed from a Workspace whose newest backup does not read back clean out of storage. Since 30 September 2026 a lock at the storage provider stops any backup being deleted or overwritten until it is 30 days old (Annex 2, item 20), so a backup goes at the first nightly clean-up after that.

A departed Workspace. Once the leave is finished the Workspace is no longer backed up, and the same nightly clean-up takes its backups as they pass 30 days, through the storage alone, with no connection to the Workspace's database. It never removes the last ones described above. Then:

(a) within 30 days after the Workspace is deleted under clause 11.1(4), MVV support removes every backup of it from storage and destroys its backup key, together with the sealed copy kept beside the backups and every copy of that key that MVV's tools keep, or had set aside, on MVV's computer. From then on the key is no longer used by MVV's systems;

(b) the key's remaining sealed copies are the dated ones that the storage provider's 30-day lock protects from deletion. They open only with MVV's master backup key, and MVV's tools delete them within about 30 days, at the first nightly clean-up after the lock ends. The removal is then complete and final, apart from the note in (c);

(c) what stays is a short note in storage, and a record on MVV's computer, saying that the Workspace's key was destroyed and when: the Workspace's short name, a fingerprint of the key, the date and the reason. It is kept so that no later recovery can put the key back;

(d) MVV deletes its copies of the export made when the Customer left, the one behind the download link included, when it deletes the Workspace under clause 11.1(4), or within 30 days after. A person at MVV does this; nothing does it automatically.

11.4 Copies MVV does not control. Copies held by sub-processors under their own retention rules (for example email delivery records, AI provider logs, and any backups the hosting provider keeps of a database project for its own purposes) are deleted on those providers' schedules (Annex 3).

11.5 Records MVV keeps after deletion. MVV keeps its own records of the Workspace's existence, plan, seats, the leave and its dates, the AI allowance issued to it each month and any AI added to it, and the service records in clause 2.2, for the periods the Privacy Policy sets out. None of them is kept without end: once a year, with its database's owner account, MVV deletes the records whose period has passed (its "yearly delete"), unless one is needed for a legal claim or the law requires MVV to keep it. MVV also keeps:

(a) records of each AI or email call without its content and, once WhatsApp is switched on, of each WhatsApp routing decision and each "which company?" question without content: as built, for at least 400 days, and then until the yearly delete after 7 years have passed since the end of the financial year they relate to;

(b) once WhatsApp is switched on for a Workspace, WhatsApp link records (a keyed fingerprint of the number, its last three digits and the company it was linked to) and the register of each person's yes, no and STOP to each company (a keyed fingerprint of the number). Nothing deletes them automatically: MVV deletes them in its yearly delete 7 years after that Workspace's last subscription ends;

(c) in MVV's control database, its record of each backup, test restore and update of the Workspace. Each record holds the Workspace's short name, times, counts and, for a failure, its reason in words. It is built never to hold the Workspace's data or the name of any of its stored files: where a failure concerns a file, the record says at most which of the Workspace's storage areas held it. No account MVV's software uses can edit or delete them, and MVV deletes them in its yearly delete 7 years after the Customer's last subscription ends;

(d) the control console's audit log, the key-use record and the access log book, for the 7 years clause 5.3 gives.

11.6 If the law requires MVV to keep any Customer Personal Data, MVV will keep it confidential and use it only for that purpose.

11.7 After a recovery. If MVV recovers the Workspace into a new database project because the original was lost or damaged, and the original still exists, MVV keeps the original for 30 days after the recovery, paused or, where the hosting provider will not pause it, read-only (every change to it is refused and its scheduled tasks are stopped), and then a person at MVV deletes it. Nothing deletes it by itself.

12. Information and audits

12.1 MVV will make available the information reasonably needed to show that it meets this DPA: this document and its annexes, the Sub-processor list, and answers to a reasonable security questionnaire once a year.

12.2 Where that is not enough, or after a personal data breach, or where a supervisory authority requires it, the Customer (or an independent auditor bound by confidentiality) may carry out an audit on 30 days' written notice, during business hours, no more than once a year, at the Customer's cost. An audit may not give access to any other customer's data.

12.3 MVV has no independent security certification, and no outside firm has carried out a penetration test of the platform. MVV tests the platform's security itself.

13. Records

MVV keeps the record of processing activities a processor must keep under Article 30(2) of the UK GDPR.

14. Liability, duration and precedence

14.1 MVV's liability under this DPA is subject to the exclusions and the limit in clause 16 of the Terms. The Customer's liability under this DPA is not limited (the Terms, clause 16.3A).

14.2 This DPA lasts as long as MVV processes Customer Personal Data.

14.3 If this DPA conflicts with the Terms, this DPA prevails on data protection matters, except that clause 16 of the Terms (liability) always applies.

Annex 1: Details of the processing

Categories of data subjects (depending on what the Customer uses):

• the Customer's office staff and other users of the Workspace;
• operatives, direct employees, agency workers and subcontractors;
• the Customer's own customers (for example homeowners), including those given their own sign-in to follow a project;
• architects, designers and other professionals, including those given their own sign-in;
• suppliers and their contacts;
• sales prospects found through the outreach and planning tools, including names that appear in public planning registers, once those tools are switched on (the Business Development module is switched off for every plan when sign-up opens: the Terms, clause 7.2);
• site visitors and workers who sign a site induction through a public link;
• people who appear in photographs, documents, messages or voice recordings;
• people who receive emails, or WhatsApp messages, sent from the Workspace, including the operatives on the Customer's Labour board, who may be self-employed subcontractors.

Categories of personal data (depending on what the Customer uses):

• names, job roles, work email addresses and phone numbers, sign-in records;
• project records: site addresses, customer names and emails, schedules, reports, photos, drawings;
• money records: quotes, invoices, costs, payments, the Customer's bank details printed on its invoices;
• workforce and pay records: day rates, rate history, pay runs; and, in a separate table readable by super admins and by any prime or basic admin to whom a super admin grants payroll access (read-only), tax and payroll identifiers (UTR, CIS verification and status), salary and pension percentages and payroll notes;
• competence card numbers and photographs of competence cards;
• attendance and absence, including days marked sick;
• employment contract particulars;
• messages (email, in-app, and WhatsApp where switched on), voice recordings and their transcripts;
• health and safety records;
• legal case records, where the Contract Helper module is used.

Special category and criminal offence data. The service is not designed to collect special category data. It can hold some incidentally: sickness absence (health), injuries visible in site photos, and anything a person writes or says. The platform contains no face-recognition or other feature that identifies people from photographs.

Annex 2: Technical and organisational measures (as built)

Each line describes the platform as built on the date of this version: how it is built to work, not a promise that it will never fail. Where a line says that MVV aims to do something, it is an aim, not a promise. These are the measures the Customer accepts in clause 6.2, and MVV may change them as clause 6.3 says. The lines describe a customer's Workspace, which is built from the current release of the software. Where a line says "when sign-up opens", the measure is built and tested and comes into use on that day (clause 1).

Separation of customers

1. Each Workspace is its own database project, with its own sign-in, file storage and functions; there is no shared customer database.
2. MVV's control database holds no customer business data. MVV's control console reaches a Workspace only through fifteen fixed operations, with no passthrough and no query of its own. Most return counts, sizes and status; the rest switch modules and set how much AI the Workspace may use, hold the brand, place a notice, close support requests, confirm a cancellation and tell the Workspace the day its service ends, or withdraw that confirmation before the leave begins, cut leavers' WhatsApp links, or ask the Workspace to send MVV ID its list of people, which MVV keeps only as keyed fingerprints. Separately, authorised MVV personnel can start from the console an update of a Workspace (its database layer, server functions and web app), which reads back version records and counts only.
3. MVV's build and backup tools refuse a fixed list of named projects that are never theirs to touch; the build works only inside MVV's own organisation at the hosting provider; and the backup tools back up only Workspaces whose database password the build created. A new Workspace whose name would end in "-r" and eight digits, the way the project of a recovered Workspace is named, is refused by MVV's tools and, when sign-up opens, by the sign-up page.

Access control

4. Inside a Workspace, users have roles (for example super admin, prime admin, basic admin, client, architect). Tax and payroll identifiers, salary and pension are in a separate table readable by super admins and by any prime or basic admin to whom a super admin grants payroll access, read-only; only a super admin can give that grant. Passwords need at least 12 characters, and a password a person chooses must also hold a letter and a digit. Changing a password needs a fresh sign-in. When a super admin sets another person's password, that is written first to the Workspace's own audit record (who set whose, and when, never the password); if that record cannot be written, nothing changes.
5. The Workspace's knowledge base can be encrypted in the browser under a key derived from the Workspace owner's password, so the database holds only the encrypted text.
6. MVV's control console listens only on MVV's computer. Its staff roles are enforced by the server, staff can use two-step sign-in, and every change is written to an audit log that can only be added to: no account MVV's software uses can edit or delete a line. Only the database's owner account could remove that protection. A member of staff being shown a view of a Workspace's data is written there too (a repeat of the same view within 5 minutes adds no new line). MVV keeps no password for a customer's Account owner.

Keys and secrets

7. AI, email and voice provider keys are held by MVV's gateway, not in the Workspace. A Workspace holds only a gateway pass, which MVV stores as a hash and can revoke.
8. Provider keys are held either as the encrypted function secrets of MVV's control project or in its key store, encrypted with AES-256-GCM, never as plain values in the database. If that project is down and MVV runs its standby gateway on MVV's computer, authorised MVV personnel put the keys in a file there, on an encrypted disk, for as long as the standby runs. At other times that computer holds none of them.
9. MVV's keys and passwords are kept in files on MVV's computer, on an encrypted disk. MVV has rented a server in London (OVHcloud, listed as planned in the Sub-processor list) to take over this work. It was delivered on 29 September 2026 and is being set up. The control console, the backups and the other work described in this Annex still run on MVV's computer and have not moved to it. Moving them is a change to the Sub-processor list, which clause 7 governs.

Data in transit and in the browser

10. The Workspace is served over HTTPS with Strict-Transport-Security and a content security policy that lets the browser connect only to the Workspace's own server and the voice provider, and show pictures only from the Workspace itself and its own server. It also has frame blocking, a strict referrer policy, a cross-origin opener policy and a permissions policy. MVV's build tool is set to refuse a build missing any of these.
11. Workspaces load no fonts or scripts from third parties and contain no analytics or advertising code.
12. Signing out removes most of what the app stores on the device: the cached copy of the data, the image cache with the browser's list of the pictures and documents viewed, and the app's own stored drafts, settings and AI task results. It does not remove the Workspace's colours and logo, the last bookkeeping check (up to 5,000 cost lines), two layout preferences, the short list of call-back notes a user has put away, notes from calls with the Project Manager that a user chooses to keep (for at most 14 days), another user's unsaved expenses or, where the Design Centre is switched on, its panel and page settings and the last prices seen of up to 12 designs, as the Cookie Notice sets out. Ending the sign-in session needs a connection to the server: signed out with no signal, the session stays on the device. Viewed images, and the device's copy of the records, are kept for at most 24 hours. Both are also cleared when the app finds that nobody is signed in any more. Links to stored files are kept in memory only.

AI

13. AI requests made by the Workspace's server functions leave through MVV's gateway, which allows only the providers and operations the platform declares, refuses every other AI service, removes the user's IP address headers, and caps the number of AI calls each Workspace can make in a day. When sign-up opens, the gateway also holds each Workspace to a daily ceiling on the cost of its AI, the in-app help assistant included, which MVV can raise, or remove, for a Workspace. The Workspace itself stops AI once the AI allowance carried on its signed instruction from MVV is used; the Terms say what a plan includes and how more can be added. Live voice is the exception: after the gateway has fetched a one-off signed link, the conversation runs directly between the user's browser and ElevenLabs, outside the gateway's IP stripping, records and limits, where the voice assistant's language model processes it. For three of the six voice assistants that model is set in the platform: OpenAI's gpt-4.1-mini for Vera and the Accountant, and OpenAI's gpt-4.1 for the Project Manager. For Support, Atlas and the Contract Helper it is the model set in MVV's account with ElevenLabs rather than in the platform's code (see the Sub-processor list).
14. The gateway records each call's time, Workspace, provider, function, result and duration, never its content. The Workspace's own usage meter records token counts and cost, not content. The conversations themselves are Customer Personal Data held in the Workspace: assistant chats and call transcripts are stored there.
15. Where the Customer's plan includes the Master Brain page, the Customer's super admin can switch off there each assistant that page lists. The assistants of the core app and of the Estimator, Health and Safety and Calendar modules have no off switch, and a plan without that page has none. If the Workspace cannot read its own settings at that moment, the assistant does not run, even if it is switched on (the Terms, clause 9.6 and Schedule 2).
16. Assistants that produce figures, documents or decisions only draft or suggest; a person reviews and approves. A few assistants can change records without a person approving each change; the Terms (clause 9.5 and Schedule 2) list what each can read and change. The main one, the in-app assistant (and the WhatsApp assistant where WhatsApp is switched on), is open to the Customer's super admins who have access to it. It can read records, money figures included, and make low-risk changes. It can create an invoice or a credit note, mark an invoice paid or record a part payment, only after a YES, a one-time code and the Money PIN, which belongs to the Customer's Account owner. It can never pay anyone, and messages to outside parties are refused.

Email and WhatsApp

17. Email is sent only through the gateway, from one shared address. When sign-up opens, these limits apply: at most 50 recipients, 12 MB in all and 5 MB of attachments per email; and, for each Workspace, 200 recipients a day and 60 recipients in any hour (password emails apart: 150 a day and 40 an hour). Password emails are then written by MVV, go to one person only and are never copied; their links work for 15 minutes and only on the Workspace's own address.
18. WhatsApp is switched on automatically for each customer's Workspace once the Terms that offer it apply to it (the Terms, clause 8.3). As built: the WhatsApp router stores no message content and no phone number; it keeps a keyed fingerprint of each linked number and its last three digits. It passes a message to a Workspace only when that Workspace has a confirmed link to the number; a number linked to several Workspaces is asked which company it means, and its messages then go to the chosen company for the next 12 hours. Messages a Workspace sends, and the photos and voice notes it fetches, go through the router, which sends them with MVV's own credentials (the Workspace holds none) only to a number with a confirmed link to that Workspace, holds each Workspace to 200 messages a day, and keeps no message content. It keeps each person's yes, no and STOP to each company as a keyed fingerprint, which MVV deletes only in its yearly delete (clause 11.5(b)). The router refuses any number without that person's own confirmed "Yes, link me" (a tap, or a yes quoted onto the link request). STOP or Unsubscribe sent to MVV's number cuts every link, except that a bare "Stop" sent as a reply to one of a company's own messages is passed to that company as an instruction and does not unlink the person. A message from a number linked to no company is logged without its content and passed to no Workspace. MVV's records of WhatsApp hold no message content.

Backups and recovery

19. MVV aims to back up every Workspace each night: database, people and sign-in records, and every stored file up to 20,000. A Workspace holding more, or a night its files cannot be exported, is backed up without its files, and MVV is alerted and tells the Customer. Each part is re-read and checked against its fingerprint after upload. Every part of every backup is sealed by MVV before upload with a key that belongs to that Workspace alone, so the storage provider holds only sealed data and no file names. The key is kept in a file on MVV's computer, on an encrypted disk. At each nightly run every Workspace's key is also sealed to MVV's master backup key, whose private half is kept only in a password manager held by authorised MVV personnel, never in a file on MVV's computers. That sealed copy is stored beside the backups and on MVV's computer, with a dated copy that the storage provider's 30-day lock protects from deletion, and each copy is checked at each nightly run. The key with which a Workspace locks the passwords of the services it is connected to, which MVV also keeps on MVV's computer, is sealed to the master backup key in the same way: when the key is made or, if that cannot be done at that moment, at the next nightly run that succeeds. When MVV deletes the Workspace after its leave (clause 11.1), MVV's tools destroy that key and most of its copies, and a person at MVV removes the rest; a dated copy under the storage lock goes once the lock allows. The nightly run is started on MVV's computer. Since 6 October 2026 that computer starts it by itself each night, at about 02:12 UK time. On a night the backup finishes without a fault, the same run then carries out the nightly clean-up (clause 11.3). Each morning MVV checks that the backup and the clean-up ran and finished. If the backup did not, a person at MVV runs it by hand; the nightly run has missed nights before. If the clean-up did not, it runs on the next night the backup finishes without a fault. The Terms (clause 10.5) say what MVV aims for when a Workspace has to be restored, and the worst case.
20. Backups are stored in Cloudflare R2 restricted to the EU jurisdiction, one folder per Workspace. For a Workspace in service MVV keeps backups for 30 days; for a departed one, see clause 11.3. Since 30 September 2026 a backup cannot be deleted or overwritten, even with MVV's own storage key, until it is 30 days old.
21. MVV runs restore tests by hand; nothing schedules them yet. A restore over a Workspace itself puts back today's module settings by MVV's signed instruction and leaves the Workspace's cancellation requests, AI use and update records as they were. A restore into a new project, including a recovery, makes every password, passkey, second sign-in step and recovery code from the backup unusable and keeps out the people the Customer names as having left (clause 5.2). After a recovery, an original project that still exists is kept for 30 days, paused or read-only, and then deleted by a person at MVV (clause 11.7).

Leaving

22. Leaving is carried out by MVV's leave command, which will not proceed without a complete, non-empty export, and records the suspension and the finished leave in MVV's control records. It runs only on a cancellation MVV confirmed, or on MVV's termination for non-payment once its day has come. The deletion command deletes only after 90 days, only once MVV's control records independently confirm the leave, only a project that is paused or read-only (checked when it runs), and only when a person types a sentence naming both the Workspace and its project. No customer's leave has been run yet.

Monitoring

23. MVV measures each Workspace's availability and response time every five minutes while its control console is running, and reads each Workspace's own health figures hourly.

Measures not yet in place

• Since 6 October 2026 MVV's computer starts the nightly backup run, and the checks that go with it, by itself each night, at about 02:12 UK time. The nightly clean-up, which removes backups older than 30 days and, once the storage lock lets them go, a destroyed key's dated copies (clause 11.3), is part of that run: it starts by itself after the backup, on a night the backup finishes without a fault. Each morning MVV checks that the backup and the clean-up ran and finished. If the backup did not, a person at MVV runs it by hand; if the clean-up did not, it runs on the next night the backup finishes without a fault (item 19). The server that will run both is rented and being set up, and is not in use.
• Restore tests are run by hand; nothing schedules them (item 21).
• Every Workspace's backup key is on the same computer as the storage credential and MVV's other keys.
• About 36 backups of MVV's own Workspaces, made between 19 and 26 September 2026 before sealing began, are not sealed, so their file names can be read in storage. The storage lock keeps each one until it is 30 days old; the last of them goes at the first nightly clean-up after about 26 October 2026. No customer's backup is unsealed.
• After a departed Workspace's 90 days, deleting the Workspace, removing its backups and destroying its key, and deleting its export are each done by a person at MVV, within the times in clause 11. Nothing does them automatically. MVV's nightly job lists every departed Workspace past its 90 days until it is deleted.
• The export is handed over by hand (clause 11.2). There is no download feature in the Workspace.
• A customer who stays after their leave has begun is switched back on by hand, and cannot yet ask to cancel again in the Workspace (clause 11.1).
• Signing out does not end the sign-in session without a connection, and the last bookkeeping check, two layout preferences, the list of call-back notes put away, Project Manager call notes a user chooses to keep, another user's unsaved expenses and, where the Design Centre is switched on, its settings and the last prices seen of up to 12 designs stay on the device (item 12).
• Some assistants have no off switch (item 15).
• Live voice conversations bypass the gateway's IP stripping, records and limits (item 13).
• Use of a key by hand is recorded by hand; the control console's automatic checks are not recorded one by one; and the key-use record names the computer account, not the person (clause 5.3).
• The transfer risk assessments for the sub-processors are written but none has yet been signed off, and MVV has not yet collected each sub-processor's terms in one file and checked its data processing terms against this DPA (clauses 7.4 and 8).
• No penetration test by an outside firm, and no security certification (clause 12.3).
• Server functions, AI processing and email delivery are not pinned to the UK (Annex 3). MVV plans to pin server functions to London after launch.
• WhatsApp through MVV's own number waits for Meta to verify MVV's business; until then it runs only on a Meta test number and carries no customer's messages.
• MVV's own sealed backup of its control database is built and not yet running.
• The measures marked "when sign-up opens" are not in use before that day.

Annex 3: Sub-processors and transfers

The list is section A of the Sub-processor list, which forms part of this Annex. For each sub-processor it states what it does, what data it receives, where, and the transfer mechanism in that provider's terms as MVV understands it.

Summary of where processing happens for a UK customer: