When your product is assurance, your own records have to be assurable.

Early access

CubeMSP for cyber security providers

For MSSPs and security consultancies: incident history that stands up to scrutiny, evidence for accreditation, and reviews clients can hand to an auditor.

A security provider is held to a standard its clients are not. The incident record has to be complete and tamper-evident, the access model has to be defensible, and the client-facing report has to withstand a question from an auditor rather than merely reassure a finance director. CubeMSP was built with an immutable audit log, server-enforced visibility rules and per-tenant isolation as architectural properties rather than configuration options - which is a different proposition from a platform that offers a compliance tier.

  • Append-only

    Audit log, no role can edit it

  • 404

    What a cross-tenant request returns

  • Per tenant

    AI can be disabled entirely if required

What goes wrong

The recurring problems in security

Not every business has all five. Almost every business we speak to has three.

  • Evidence assembled retrospectively

    Accreditation and client audits ask what happened and when. If the answer lives in an inbox and a memory, producing it is a week of work and the result is still arguable.

  • Access that is hard to defend

    A provider with credentials to thirty client estates needs a role model it can explain in a sentence. "Everybody can see everything, and we trust each other" is true and unhelpful.

  • Findings that are not tracked to closure

    Assessment findings are delivered in a report and then followed up over email. Six months later nobody can say which of the twenty-two recommendations were actually implemented.

  • Recurring assessments run as projects

    Annual reviews, penetration tests and accreditation renewals recur, but are managed as though each one were new. The previous year’s work is a document rather than a starting point.

  • Reporting that reassures rather than evidences

    A client report full of green ticks is easy to produce and worth very little. Reporting that shows volume, response and remediation over time is harder and considerably more defensible.

What we do about it

How CubeMSP is set up for security

Configuration, not a separate edition. Everything here is in the same product - it is switched on and shaped during implementation.

  • An immutable audit log

    Every state change, assignment, note and time entry recorded with actor and timestamp. Included as standard rather than sold as a compliance edition.

  • Role-based access you can explain

    Roles and permissions enforced on the server, with a defensible model for who can see which client and which commercial data. Not a display rule.

  • Findings tracked to closure

    Assessment findings as tasks on a shared board with owners and dates, visible to the client. Which recommendations were implemented becomes a matter of record.

  • Recurring engagements as templates

    Annual assessments and accreditation renewals as board templates, so this year starts from last year’s work rather than from a blank document.

  • Per-tenant isolation by construction

    Client data is scoped at the data layer, cross-tenant access returns a 404, and every route ships with an automated isolation test. For a security provider this is the first question, and it deserves a structural answer.

  • Reviews built from evidence

    Client reviews composed from the period’s recorded incidents, response times and remediation progress - computed figures narrated, never figures invented.

In practice

Two situations from this sector

Anonymised, but not invented. These are the situations businesses describe before they change anything.

  • An audit that took a week to answer

    The situation

    A client’s insurer asked for evidence of every security incident raised over eighteen months, including detection and response times. The provider had the information across a mailbox, a monitoring tool and two spreadsheets, and it took five days to assemble.

    What changed

    The same request is now a filtered export from the incident record, with the audit trail attached. It took under an hour the next time it was asked.

  • Findings that quietly went nowhere

    The situation

    A security assessment produced twenty-two recommendations. Follow-up happened over email, and at the next annual review nobody on either side could say with confidence how many had been actioned.

    What changed

    Findings are tasks on a board shared with the client, with owners and dates. The following year’s assessment started from a documented position rather than from a fresh discovery exercise.

How it happens

What implementation involves

The same five stages whatever you make. Discovery, training and go-live are done on your site, because most of what the system needs to know is learned in the building.

  1. Discovery

    A structured session mapping how you run now - the PSA you have outgrown, the spreadsheet of renewals, the shared mailbox that is really your ticket queue, and the review deck somebody rebuilds by hand every six months. We come back with what the platform covers as standard and what needs building.

  2. Configuration

    Your service catalogue, ticket taxonomy, boards, roles, approval limits and review templates set up to match how you actually work - not a demo tenant with your logo dropped on it. Your categories, not ours.

  3. Data migration

    Clients, contacts, sites, services, renewal dates and enough ticket history to make the knowledgebase and similar-incident retrieval useful on day one. An empty AI is a useless AI, so the history matters more here than in most migrations.

  4. Training & rollout

    Role-based training - the service desk learns logging and resolution, account managers learn reviews and renewals, directors learn the reporting. We usually pilot with one technician and one client before opening it up.

  5. Ongoing support

    UK support from the people who built the platform and use it themselves, with a named contact, agreed response times, and a roadmap you can influence. Being a small vendor is an advantage here and we intend to keep it.

Questions

What this sector asks first

  • Audit entries are append-only and are not editable through the application by any role, including platform administration. Every mutating action writes one, and a route that does not write one does not ship.

  • Scoping is applied at the data layer rather than by an application filter, cross-tenant requests return a 404, and every route carries an automated isolation test that must pass before release. We are happy to walk a technical reviewer through the architecture.

  • Retrieval is scoped to your tenant by construction. Content sent to generate a draft is not used to train the model, and AI features can be disabled per tenant if your own clients require it.

  • For case management, evidence and client reporting, yes. It is not a SIEM and does not attempt to be one - your detection platform raises the incident, CubeMSP manages it and evidences it.

  • The platform is in early access and we will not claim certifications it does not yet have. We will tell you exactly where it stands, what is in progress, and what the hosting and backup arrangements are - in writing.

If your process really is unusual

Some requirements are specific to one business rather than one sector. Those get built against the same documented API everybody else uses - not bolted on to the side of a database nobody is allowed to look at.

How the platform is built

Security

Show us a real job from your security operation

Bring one order that went wrong and the paperwork that went with it. That tells us more about whether this fits than any list of features.