Running a SOC as a managed service on a multi-tenant platform

For a managed security service provider, growth has an awkward shape. Every new client brings revenue, and also another boundary to defend, another set of users to administer and another share of capacity to plan. If each client means another console, the margin goes on context switching.

A multi-tenant platform can fix that, but only if the tenancy model matches how the business actually works. Our view: the boundary between clients must be enforced by the server, not by convention, and the provider must stay the owner of the client relationship.

What the platform must enforce

Some things should never depend on an analyst being careful.

• Isolation on every query. A search, a dashboard or an export should be scoped to one tenant by the server, using the signed-in session, not a parameter someone can change.
• No silent access from above. The platform operator should not be able to browse a client's data. Emergency access should be a separate, time-limited grant with a recorded reason.
• Different service models. Some clients want you to run their SOC. Others want to run their own on your platform, and expect you not to see their data. The platform should know the difference and enforce it.
• Capacity that cannot be oversold by accident. If you have a share of ingest, allocating more than you have should be refused, clearly.
• Changes that need two people. Reducing how long a client's data is kept is the kind of change that should need a second approver.

What the provider owns

The platform carries the boundaries. The provider carries the service:

• the client relationship, from the first proposal to renewal
• onboarding, source connection and tuning
• first-line support, with a defined route to escalate
• the service levels in the client contract
• the brand the client sees on proposals and quotes

A vendor that contacts your clients directly, or sells to them around you, undermines all of this.

Ten questions before you onboard the next client

1. Is each client a separate tenant, with isolation enforced on every query?
2. Can the platform operator see inside a client tenant? Under what conditions, for how long, and is it audited?
3. Which service model is this client on: you run their SOC, or they run it on your platform?
4. In the second case, are you technically prevented from seeing their data?
5. How is your capacity divided between clients, and what happens if an allocation would exceed it?
6. Does your own internal SOC count against the same capacity?
7. Who can reduce a client's retention, and does it need a second person?
8. Which roles exist, and who can grant each one?
9. Is every role change recorded in a tamper-evident log?
10. When the client raises a ticket, who receives it, and where does it go next?

If the answer to any of these is "it depends who is on shift", fix that first.

Plan trials like production

A proof of concept is often where the tenancy model is decided by accident. Set up the trial tenant the way the production tenant will run, with the same service model and roles, so the client tests what they will actually buy.

How kymeer approaches this

kymeer models managed services directly: platform → MSSP → client. The server enforces the tenant boundary on every query, and each client's queue stays inside that client's tenant.

Platform administrators work on MSSPs, not inside client tenants. Reaching a client's data from the platform needs a break-glass grant that is tied to a ticket reference and a reason, has a fixed expiry and is audited.

Each client tenant has a service model, chosen at onboarding:

• SOCaaS. You operate the SOC for the client and can switch into the client's tenant to work.
• PaaS. You host a client that runs its own SOC. You manage only the tenant's lifecycle and limits, and cannot see its data.
• Proof of concept. A trial tenant that behaves as SOCaaS or PaaS, chosen when it is created.

The licence sets the total daily ingest for the installation, the platform sets an envelope for each MSSP, and you divide your envelope between your clients. Your own tenant counts against it too. An allocation that would take you over your envelope is refused, and the refusal states both numbers. Reducing a client's retention needs a second person to approve it.

There are six roles: Analyst, Senior Analyst, Tenant Admin, MSSP Admin, Platform Admin and Auditor. A Tenant Admin can grant Analyst, Senior Analyst and Auditor; an MSSP Admin can grant any role except Platform Admin. Every role change is written to the tenant's hash-chained audit log.

kymeer is sold only through partners. Your clients raise tickets with you, and you escalate to kymeer; kymeer does not contact your clients. You request tenants and trials through the partner portal, and kymeer invites each client's first administrator. Quotes can carry your logo.

Read the MSSP multi-tenancy guide, or see the MSSP partner track.