Draft — pending legal review

This document is a structured draft prepared for review and completion by a qualified solicitor. It is not legal advice, it has not been reviewed, and it must not be relied upon or offered to customers as a binding Article 28 agreement until that review is complete. Items marked [REVIEW] are commercial or legal decisions that have deliberately been left open. The factual descriptions of hosting, data, retention and security below reflect the product as built on 28 July 2026 and should be re-verified before publication.

Legal

Data Processing Agreement

Draft prepared 28 July 2026 · Article 28 UK GDPR · MSP Dashboard is operated by Cloudworks Services Ltd, a company registered in England and Wales.

Scope and roles

This agreement is entered into between you (the Customer) and Cloudworks Services Ltd trading as MSP Dashboard (the Processor). It forms part of the Terms of Service and sets out the terms required by Article 28(3) of the UK GDPR.

  • → For data drawn from the Customer's connected systems and presented through the Service, the Customer is the controller and MSP Dashboard is the processor. The Customer decides what is connected and what is reported; the Service renders it.
  • → For the Customer's own account and billing data — sign-in identities, organisation contact details, subscription records — MSP Dashboard is the controller. That processing sits outside this agreement and is described in the Privacy Policy.

Terms defined in the Terms of Service have the same meaning here. "UK GDPR", "controller", "processor", "personal data", "data subject", "processing" and "personal data breach" have the meanings given in the UK GDPR and the Data Protection Act 2018.

[REVIEW: signature and acceptance] — decide how this agreement is executed. Publishing it on the website does not evidence acceptance; a click-through or countersigned document is needed.

1. Subject matter and duration

Subject matter. The processing of personal data contained in the Customer's connected systems, for the purpose of producing dashboards, analytics and reports through the Service.

Duration. Processing continues for the Subscription Term and for the short period afterwards needed to return or delete the data under clause 11. This agreement remains in force for as long as we process personal data on the Customer's behalf.

2. Nature and purpose of the processing

We retrieve data from the systems the Customer connects, store it in the Customer's isolated area of our Azure environment, and present it as dashboards and reports to the users and recipients the Customer designates. Specifically, the processing consists of:

  • →collection from connected systems using credentials the Customer supplies;
  • →storage in Azure Blob Storage and Azure Table Storage, with credentials held in Azure Key Vault;
  • →aggregation, structuring and analysis to produce dashboard views and metrics;
  • →disclosure by display to authorised users, and by email where the Customer configures scheduled report delivery;
  • →erasure, on the Customer's instruction or under the retention rules in clause 11.

We do not use the Customer's personal data for our own purposes, do not sell it, and do not use it for advertising, profiling or model training. There are no third-party analytics, advertising or tracking services in the Service.

3. Types of personal data

The categories depend on which systems the Customer connects. As the Service is currently built:

Source Personal data
HaloPSAAgent names, time logged per agent, client and site names, ticket subjects and detail.
HaloPSA opportunitiesContact name, email address, phone number, address, company and deal value.
Microsoft 365User lists, licence assignments, sign-in and audit activity, privileged roles, MFA and authentication methods, mailbox delegates, Teams call records, device compliance.
ZendeskTicket contacts, organisation names, agent names, CSAT ratings and free-text comments.
Pax8Licensing and pricing per customer tenant — largely commercial rather than personal data.
Hudu, NinjaOne, UniFiProxied on request; content depends on the Customer's own systems.
Product usersSign-in email address, role, capability and visibility scopes, organisation ownership.
Report deliveryRecipient email addresses on scheduled reports, chosen by the Customer.
Administrative auditAction, username, IP address and timestamp for actions taken in our internal admin area.

The most sensitive categories are the free-text CSAT comments from Zendesk and the Teams call records from Microsoft 365, because their content is not constrained by us. Site traffic counting records only a page path and a UTC timestamp, with no IP address, user agent or identifier, and is not personal data.

[REVIEW: special category data] — the Service is not designed to process special category data under Article 9 or criminal offence data under Article 10, but free-text fields could contain it if a Customer's own users put it there. Decide whether to prohibit that contractually, and confirm the wording.

4. Categories of data subjects

  • →The Customer's own staff — technicians, agents, administrators and other employees whose activity appears in the connected systems.
  • →Staff and end users of the Customer's own clients, who appear as ticket contacts, requesters or survey respondents.
  • →The Customer's sales and prospect contacts, where opportunity data is connected.
  • →Users the Customer authorises to sign in to the Service.
  • →Recipients the Customer nominates for scheduled report delivery.

5. Processing on documented instructions

We will process personal data only on the Customer's documented instructions, including in relation to transfers of personal data outside the UK, unless we are required to do otherwise by law. Where we are required by law to process beyond the Customer's instructions, we will inform the Customer of that requirement before processing, unless the law prohibits us from doing so on important grounds of public interest.

The Customer's documented instructions consist of this agreement, the Terms of Service, and the configuration choices the Customer makes in the Service — which systems are connected, which data is retrieved, which users and clients may see which data, and which reports are scheduled to which recipients.

We will inform the Customer if, in our opinion, an instruction infringes the UK GDPR or other data protection law.

The Customer warrants that it has a lawful basis for the processing it instructs, that it has provided any necessary privacy information to the data subjects concerned, and that it is entitled to connect each system it connects.

6. Confidentiality of personnel

We will ensure that anyone we authorise to process the Customer's personal data is subject to a duty of confidentiality, whether contractual or statutory, and that access is limited to those who need it to provide or support the Service.

Access to the internal administrative area, where the personal data of Customers can be reached, is restricted, protected by two-factor authentication, and logged. See the Annex.

[REVIEW: personnel controls] — confirm what staff screening, data protection training and written confidentiality undertakings are actually in place, and state only what can be evidenced.

7. Security of processing (Article 32)

We will implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, taking account of the state of the art, the costs of implementation, and the nature, scope, context and purposes of the processing. The measures currently in place are described in the Annex to this agreement.

We may update those measures over time, provided the level of security is not materially reduced.

[REVIEW: certifications] — decide whether to claim any certification or assurance standard, such as Cyber Essentials or ISO 27001. Nothing should be stated here that is not held.

8. Sub-processors

The Customer gives general written authorisation for us to engage sub-processors. We will impose data protection obligations on each sub-processor that are no less protective than those in this agreement, and we remain fully liable to the Customer for a sub-processor's performance of its data protection obligations.

The sub-processors currently engaged are:

Sub-processor Purpose Location
Microsoft Azure hosting and storage (Blob, Table, Key Vault); Entra ID for sign-in; Microsoft Graph API for Microsoft 365 data collection; Microsoft Graph sendMail for delivery of scheduled reports. United Kingdom (Azure UK South)

Microsoft is the only sub-processor engaged. The Service also makes outbound calls to the Customer's own systems — HaloPSA, Zendesk, Pax8, Hudu, NinjaOne, UniFi and Microsoft Graph — but those are the Customer's own suppliers, not ours, and the Customer is responsible for its arrangements with them.

[REVIEW: sub-processor change notice] — set the notice period for adding or replacing a sub-processor, how notice is given, and whether the Customer may object and, if it does, whether its remedy is to terminate without penalty.

9. International transfers

The Customer's personal data is stored and processed in the United Kingdom, in the Azure UK South region. We do not deliberately transfer personal data outside the UK.

[REVIEW: Microsoft support access outside the UK] — data at rest is in UK South, but it has not been established whether Microsoft support or engineering personnel located outside the UK can access the environment or its data in the course of support. This must be confirmed against the Microsoft Products and Services Data Protection Addendum before this clause is published. If such access can occur, the transfer must be disclosed here and the safeguard relied on identified — the UK International Data Transfer Addendum to the EU Standard Contractual Clauses, or the UK Extension to the EU-US Data Privacy Framework, as applicable — together with the transfer risk assessment.

10. Assistance with data subject rights

Taking into account the nature of the processing, we will assist the Customer by appropriate technical and organisational measures, so far as is possible, in fulfilling its obligation to respond to requests to exercise data subject rights under Chapter III of the UK GDPR — access, rectification, erasure, restriction, portability and objection.

If we receive a request directly from a data subject relating to data we process on the Customer's behalf, we will not respond to it substantively. We will pass it to the Customer without undue delay and direct the individual to the Customer as controller.

Because the Service reflects data held in the Customer's own systems, the practical route to rectification or erasure is usually for the Customer to correct the source system, after which the change flows through on the next refresh. Where data must be removed from our storage directly, we will do so on the Customer's instruction.

[REVIEW: assistance response times and charges] — set the period within which we will acknowledge and act on an assistance request, and whether any charge applies for assistance beyond what is reasonably necessary.

11. Assistance with Articles 32 to 36, and breach notification

Taking into account the nature of the processing and the information available to us, we will assist the Customer in meeting its obligations under:

  • →Article 32 — security of processing, by maintaining the measures in the Annex and providing information about them on request.
  • →Article 33 — notification of a personal data breach to the ICO. We will notify the Customer without undue delay after becoming aware of a personal data breach affecting the Customer's personal data, and provide the information reasonably needed for the Customer to make its own notification.
  • →Article 34 — communication of a breach to data subjects, by providing information and support. The decision whether to notify data subjects rests with the Customer as controller.
  • →Articles 35 and 36 — data protection impact assessments and prior consultation with the ICO, by providing information about the Service reasonably required for that purpose.

[REVIEW: breach notification deadline] — "without undue delay" is the statutory standard, but many customers will expect a fixed period such as 24 or 48 hours. Set a period that can genuinely be met given the monitoring and out-of-hours cover actually in place.

12. Retention, deletion and return

While the Service is in use, the following retention rules apply:

Data Retention
Weekly HaloPSA archivesPurged automatically after 12 weeks.
Dashboard data blobsOverwritten on each refresh; no version history is kept.
Per-tenant credentialsHeld in Azure Key Vault while the connection is configured; removed when the connection is removed.

On termination of the Service, and at the Customer's choice, we will delete or return all personal data processed on the Customer's behalf and delete existing copies, unless we are required by law to retain them.

[REVIEW: deletion on termination — process gap] — deletion is currently a manual operation carried out through the internal admin area; there is no automated deletion when a subscription ends. Before this commitment is published, either build the automated process or set a deletion period this clause can honestly promise, and decide the default where the Customer expresses no choice. Also set the period within which a return of data would be provided, and in what format.

13. Audit and information rights

We will make available to the Customer all information necessary to demonstrate compliance with the obligations in Article 28, and allow for and contribute to audits, including inspections, conducted by the Customer or an auditor it mandates.

[REVIEW: audit mechanics] — set the reasonable conditions: notice period, frequency (typically once in any twelve months unless there has been a breach or a regulator requires more), business hours, confidentiality undertakings from the auditor, exclusion of competitors, whether a completed security questionnaire or third-party report may be offered in the first instance, and who bears the cost.

An audit may not extend to the infrastructure of a sub-processor beyond the information that sub-processor makes available to us, and may not compromise the confidentiality or security of other customers' data.

14. General

This agreement is governed by the laws of England and Wales, and the courts of England and Wales have exclusive jurisdiction. If any provision conflicts with the Terms of Service on a data protection matter, this agreement prevails.

[REVIEW: liability under this agreement] — confirm how liability arising under this agreement interacts with the cap in the Terms of Service, and whether losses arising from a data protection breach are capped separately.

Questions about this agreement, and formal notices under it, should be sent to privacy@mspdashboard.io. [REVIEW: notices address] — confirm this address and whether a postal address for formal notices is also required.

Annex

Technical and organisational measures

The measures below are those in place as at 28 July 2026, described for the purposes of Article 32 and clause 7.

Credential protection

Credentials for each Customer's connected systems are held per tenant in Azure Key Vault, never in configuration files or data blobs. They are retrieved only to make a call to the Customer's own system and are not written to logs.

Encryption in transit

TLS is used throughout — for browser access to the Service, for calls to Azure storage, and for outbound calls to connected systems.

Tenant isolation

Every request is checked server-side against the requesting user's tenant before any data is returned. Isolation is not enforced in the browser and cannot be bypassed by altering a request. Visibility is further scoped per client and per Microsoft 365 tenant, so a user sees only the subset the Customer has granted them.

Access control and authentication

Customer users sign in through Microsoft Entra ID. The internal administrative area is protected by TOTP two-factor authentication with single-use codes and a short session lifetime, and administrative passwords are hashed using PBKDF2. Administrative actions are recorded with the action, username, IP address and timestamp.

Application hardening

Mutating endpoints carry cross-site request forgery origin checks. Customer-supplied URLs are validated against server-side request forgery, so the Service cannot be induced to call internal or unintended network addresses.

Storage exposure

Public blob access is disabled and static website hosting on the storage account is switched off, so no stored data is world-readable. Verified 28 July 2026.

Infrastructure

Hosting is on Microsoft Azure in the UK South region, which provides physical security, redundancy and encryption at rest for Blob Storage, Table Storage and Key Vault. There are no third-party analytics, advertising or tracking components.

Measures still to be confirmed

[REVIEW: resilience and restoration] — Article 32(1)(b) and (c) require a description of how availability and access to personal data are restored after an incident. Confirm the backup and restore position and describe it accurately, or state that the Service is not a system of record and that the Customer's source systems are the point of recovery.

[REVIEW: testing regime] — Article 32(1)(d) requires a process for regularly testing and evaluating the effectiveness of these measures. Describe what testing is actually performed and how often, including any penetration testing or vulnerability scanning.

[REVIEW: pseudonymisation and encryption at rest] — confirm what is relied on beyond the platform-level encryption Azure provides, and whether any application-level encryption or pseudonymisation is claimed.