Data processing

When your organisation uses CubeMSP, you decide what data goes into your workspace and what it is used for. You are the controller of that data, and Cube Systems Limited is your processor.

MSPs often hold their clients’ data as processors themselves, for example user and device records synchronised from a client’s Microsoft 365 tenant. Where that is the case, we act as your sub-processor, and the commitments on this page cover that data in the same way.

Separately, we are a controller for the small amount of data we need to run our own business, such as the details of your account contacts and our billing records. That is covered by our privacy policy.

Every customer agreement includes a data processing agreement that meets Article 28 of UK GDPR. Under it, we:

• process workspace data only on your documented instructions, which include using CubeMSP as designed with the configuration you choose, and tell you if we believe an instruction breaks the law;
• make sure everyone with access to it is bound by confidentiality;
• maintain the technical and organisational measures described below;
• use sub-processors only under written contracts with equivalent obligations, and give you notice before any change;
• help you answer requests from people exercising their rights, and with data protection impact assessments and any consultation with the ICO;
• notify you of a personal data breach affecting your workspace without undue delay;
• delete or return your data when the contract ends; and
• make available the information you need to demonstrate compliance, and allow for audits, including inspections, by you or an auditor you appoint.

To review the agreement before you sign, email hello@cubemsp.co.uk and we will send you a copy.

Your workspace data is stored in the United Kingdom:

• application servers, databases, queues and backups in UK data centres operated by Crushed Ice, part of Crushed Ice Group; and
• uploaded files and email attachments in Amazon S3, and system email sent through Amazon SES, both in the AWS London region.

When someone in your workspace uses an AI feature, the content that feature needs is sent to the relevant provider, processed in the United States, and the result stored back in your workspace in the UK. See AI features for exactly what is sent.

Between customers

• Every table that holds workspace data carries your workspace identifier, and the data layer scopes every query to it. Isolation does not depend on each piece of code remembering to add a filter.
• Your workspace is identified from your signed-in session and the address you are using, never from anything a browser sends in a request.
• A request for another customer’s record returns “not found”, so it does not even confirm that the record exists.
• Every route and every data model has an automated test proving this, including AI search, and a release cannot ship without them.

Between you and your clients

• Clients invited to a shared board use a separate part of the application, with its own access checks.
• Tasks and comments marked internal are removed on the server before anything is sent, and every client response is built from an explicit list of permitted fields.
• Tickets, services, financial information, internal notes and other clients are never available to a client user.
• Cost and margin are visible only to roles you give that permission to, and are removed on the server for everyone else.

Access, encryption and resilience

• Encryption in transit on every connection, and encryption at rest.
• Passwords stored only as hashes, multi-factor authentication for workspace staff, and Microsoft single sign-on.
• Credentials for connected services, and multi-factor secrets, encrypted with a separate application key and never returned to the browser.
• Role-based permissions, and an audit log recording who changed what and when, which cannot be edited or deleted and is kept for at least 6 years while your workspace exists.
• Uploaded files checked for mismatched types and stored outside the web server; email attachments virus-scanned before release; files served only through short-lived signed links.
• Rate limiting, stricter on sign-in and AI features.
• Nightly encrypted backups held off-site in the UK, with documented restore tests every month.
• Access by our staff limited to the people who need it to run and support the service.

CubeMSP uses AI to help your team work faster, never to make decisions for it. This is what each feature sends, and to whom.

Whichever feature is in use:

• only the content that feature needs is sent, and retrieval is scoped to your workspace before anything is scored, so another customer’s data can never be included;
• content sent is never used to train the provider’s models;
• output is a draft or suggestion that a person reviews, and nothing is published, sent to a client or applied automatically;
• the assistant can only propose changes, which run after the user confirms them, and who can use it is controlled by role;
• figures always come from your data, never from the model;
• retrieved content is passed to the model as data rather than instructions, to guard against prompt injection;
• every interaction is logged in your workspace with the model, prompt version and outcome; and
• if a provider is unavailable, CubeMSP carries on working without it.

CubeMSP can connect to services your organisation already uses, including Microsoft 365, NinjaOne, UniFi, Pax8, ICUK and your own mailboxes. You choose which to connect and what they can access, and you can disconnect them at any time.

• Connections use the provider’s own consent flow, such as OAuth, wherever it offers one, and ask only for the permissions each feature needs.
• Credentials and tokens are encrypted, and never shown again once saved.
• Where a connection only needs to read, it only reads. Mailbox and network integrations, for example, are read only.

Those services are not our sub-processors. You have your own agreement with each of them, and the data they hold is covered by their terms.

We use a small number of sub-processors, each named on our sub-processors page with what it does, what it processes and where. We give customers at least 30 days’ notice by email before adding or replacing one, and you can object during that period. If we cannot resolve a reasonable objection, you may terminate the affected part of the service.

When someone asks you to exercise their data protection rights, you can find, correct and delete the records relating to them in your workspace, and we will help you extract anything you cannot export yourself. If a request about your workspace comes to us directly, we will pass it to you without undue delay and will not answer it ourselves unless you ask us to.

If we become aware of a personal data breach affecting your workspace, we will notify your nominated contact without undue delay, and in any event within 48 hours, so that you can meet the 72-hour deadline for reporting to the ICO. We will tell you what happened, the data and people likely to be affected, the likely consequences and what we are doing about it, and keep you updated as we learn more.

You can export your data at any time in open formats, not only at the end. When a contract ends:

1. your workspace stays available for export for 30 days;
2. we then delete your workspace data from live systems within a further 60 days, including the audit log, and confirm in writing when we have; and
3. copies in backups expire on their normal rotation within 90 days after that, and are not restored in the meantime.

We keep only what the law requires of us, such as invoices, which our privacy policy covers.