What an MSSP SOC platform has to do that a single-organisation SIEM never will
A managed SOC platform owes you four things a single-organisation SIEM does not: a wall between the customers you serve, unattributable alerts held rather than guessed at, reporting under your brand, and a flat fee.
An MSSP SOC platform has to do one thing a single-organisation SIEM was never asked to do: keep the customers you serve completely apart, while still letting one small bench triage all of them from one screen. Every other difference follows from that — how an unattributed alert is handled, whose name is on the monthly report, and whether your bill grows the month you sign a new customer. Three of the four are invisible on a feature list, which is why they are worth checking before you buy rather than after.
Most providers arrive at multi-customer operations by accident. A SIEM per customer, so nothing can leak but nothing can be seen together either. Or one SIEM with a customer field, a saved search per account, and a boundary that exists in one analyst's head at three in the morning and does not survive the shift handover. Both work until the week you win two customers and lose one analyst.
What an MSSP SOC platform needs that a single-organisation SIEM does not
The whole argument fits in four rows.
| What a provider needs | What a single-organisation tool gives you |
|---|---|
| A wall between the customers you serve, enforced by the product | A field you filter on, and a discipline |
| An alert nobody can attribute held for a person | A best guess, filed under somebody |
| Reports that carry your brand, one customer at a time | One organisation's report, exported and edited by hand |
| A fee that does not move when you win a customer | A meter on volume, endpoints or assets |
None of that is exotic. It is simply a different product question. A SIEM asks what happened in this estate. A provider has to ask what happened in this estate, and prove that nothing from another one got into the answer.
This is the MSSP edition of Seculogik, and it is worth saying plainly at the top: the Free and Client editions are single-organisation. In those two there is exactly one estate — yours — so none of the machinery below exists, and you are not paying for plumbing you will never use. The editions page sets out the three.
Separation is a boundary, not a filter
One customer, one case space. Always.
That is a stronger statement than it looks. It means the same file hash, the same hostname, the same public address and the same technique seen at two customers produce two cases — identical evidence or not — because the alternative is a security platform that tells one customer about another's incident. A case that would span two of them is refused; it never exists in the first place.
The wall is enforced at several independent layers rather than by one check somebody could forget: at the moment an alert arrives, at every question the Correlation Engine asks of the data, and again at the verdict it writes down. Any one of those layers would hold on its own. That redundancy is deliberate, because a single filter is one refactor away from being wrong, and you would find out from a customer.
Separation also has to be invisible, not merely locked. One customer's cases are not hidden from another customer's users behind a permission; they do not appear at all, so even the existence of a case does not leak. A "you do not have access to this case" message is itself a disclosure.
The engine is fitted to each estate — thresholds, benign patterns, what your analysts have already decided — so the detection engineering you do for one customer never reaches another's verdicts. This boundary is the one thing we never make configurable.
The alert nobody can attribute is the one that gets misfiled
Every provider has this alert. A syslog line from a device nobody inventoried. A push from a customer's cloud account before onboarding finished. A source that changed its hostname convention over a weekend.
A platform has two options, and only one of them is honest. It can guess — pick the most likely customer and file it — or it can hold the alert in a quarantine queue and wait for a person to attribute it. Seculogik holds it. Attribution comes before qualification: an alert that cannot be attributed with confidence never enters a customer's case space on a probability.
Guessing looks better on a dashboard and is worse in every other respect. A misfiled alert is a wrong case in somebody's queue, an analyst reading one customer's telemetry under another's name, and an incident report that will not survive being read carefully. Waiting costs you one item in quarantine and a minute of somebody's attention.
This is the same instinct that runs through the rest of the product: SIROC, the AI analyst in the Advanced AI module, has its cited evidence checked against the case's own alerts, and a verdict the evidence does not support is downgraded in front of the analyst rather than quietly accepted.
That guardrail matters more to a provider than to an internal team, because you have to defend the verdict to somebody who is not on your payroll. A platform that would rather say I do not know is more useful than one that always has an answer.
Reporting your customer reads, with your name on it
For an internal SOC, reporting is a quarterly obligation. For a provider it is the product.
It is the artefact your customer receives, the thing their CISO forwards upward, and often the only evidence they have that you were working. The board it reaches asks about business impact, not alert counts.
The MSSP edition carries white-labelling, so what arrives at your customer looks like it came from you. The depth behind it belongs to the SOC Reporting module, licensed on its own: case and organisation reports, scorecards for NIST CSF, ISO 27001, GDPR, DORA and NIS2, and evidence packs that state their own methodology and coverage rather than presenting a number with no provenance. A metric that cannot be computed says so instead of guessing. The six modules are listed with what each one removes from your week.
That coverage statement matters more for a provider than for anyone else, because you are being paid to look. A report that says 3 criticals without saying how much of the estate was actually enumerated is a claim you cannot defend when it turns out a third of the hosts were never scanned.
There is a regulatory edge to this too. CIR (EU) 2024/2690 names managed security service providers as a regulated class in their own right, and DORA puts a clock on incident classification for financial entities you may be serving. We wrote up the actual wording and dates separately, including which parts of what you have been told are vendor folklore.
A price that does not grow every time you win a customer
The MSSP edition is a flat fee per deployment, per year. Serve one customer or fifty for the same fee.
Look at what you are being quoted by everyone else on your shortlist. Almost all of it is metered — by ingested volume, by endpoint, by asset, by monitored customer. That means their invoice grows every time you win, which is to say your commercial success is their revenue event. You end up negotiating against your own growth, or quietly collecting less from the estates you are meant to be watching.
Vendor lock-in rarely announces itself. It arrives as a meter that makes your own growth expensive, and a bill you never renegotiate because the alternative is moving every customer at once.
Two things move a Seculogik quote: the edition you deploy and the modules you switch on. That is the entire model, and it is set out on the pricing page, which publishes no figures because we would rather explain the shape than print a rate card we might have to walk back. Nothing is metered on ingestion, endpoints, seats, retention or the number of customers you serve.
The practical effect for a small bench is that you can afford to send the platform everything. A decision layer that costs more when you feed it more teaches your team to feed it less, which is a strange thing to buy.
Where the cases come from
None of this assumes you replace what your customers already run — and you usually cannot, because they chose it.
Seculogik sits above the detection stack already in place at each estate: market platforms such as Splunk, Microsoft Sentinel, CrowdStrike, Microsoft Defender, SentinelOne and Cortex XDR; open-source SIEM and data stacks such as Elastic, OpenSearch, ClickHouse and Wazuh; cloud telemetry pulled by connector; events pushed through a generic webhook and mapped once. If a customer runs something not on the list, we build the connector. One customer on Sentinel and the next on Elastic reach the same bench, judged the same way, each in its own case space.
What we do not claim
We are pre-GA. We have no customers to name, no logos, no testimonials and no case studies, and we will not invent them. We hold no ANSSI or CSPN qualification, we have no third-party penetration test report to hand you, and we do not offer an SLA yet.
We also do not sell an autonomous SOC. Gartner's formal position is that there will never be one, and we agree with it: the platform decides what deserves attention and explains why, and a person still decides what to do about it.
If you serve several organisations and want to see the wall, the quarantine queue and a white-labelled report against your own alerts, book a demo and bring one customer's traffic pattern with you.