Skip to content
SOLUTIONS · MSSP / MDR

Add tenants without adding drift.

Analyst-to-analyst calibration drift is what breaks MSSP economics. VerdictIQ replaces it with one deterministic decision motor, the same verdict for every tenant, every shift, with the reasoning in every payload.

  • Per-tenant isolation
  • One verdict shape
  • Bulk multi-tenant replay
POST /enrich
any tenantsame verdict
One decision motor
  • acmesame shape
  • globexsame shape
  • initechsame shape
  • +47 tenantssame shape
One motor, every tenant: the same shape at five tenants and at fifty.
01 · WHAT BREAKS MSSP ECONOMICS

Drift. Onboarding cost. Audit per tenant.

Three things bleed margin in a multi-tenant SOC: analyst-to-analyst calibration drift, per-tenant onboarding, and audits that have to be rebuilt for every customer.

Analyst A and Analyst B reach different verdicts on the same IOC. The same analyst reaches different verdicts on different days. Across tenants, the drift compounds. Customer X sees one risk language; Customer Y sees another. The MSSP brand is the consistency the customers cannot see.

Every new tenant means onboarding cost: a fresh playbook, fresh tuning, fresh analyst training. The unit economics that work at 5 tenants buckle at 50. Audit is worse: each tenant demands a defensible answer to why a verdict landed, and the analyst has to reconstruct the reasoning from memory.

The MSSP brand is the consistency the customer cannot see. Lose it, and the renewal is a coin flip.
02 · WHAT LANDS IN EVERY TENANT

One response shape. Tenant scope on the header.

Every call sets X-Customer-Id. The verdict, recommended_action and signal hierarchy land identically across tenants. The parser, the SOAR condition node and the audit query read one shape.

Tenant scope rides on the header

Tenant isolation rides on the header, not on the response. Customer X data never bleeds into Customer Y because the master key plus X-Customer-Id partition the call. The verdict shape is shared on purpose: the MSSP's review queue, dashboards and audits work the same on every tenant.

Per-tenant policy stays in your stack

Per-tenant policy lives in the MSSP's SIEM and SOAR, not in our API. Customer X may block on recommended_action == block_domain; Customer Y may quarantine. The decision motor returns the same verdict; the action lives where it belongs.

The master key plus X-Customer-Id partition the tenant; the verdict body lands identical across every one of them.

03 · THREE JOBS THAT MOVE MSSP MARGIN

Kill the drift. Verify the decisions. Cut the noise.

MSSP use cases lead with consistency (no analyst drift), Decision Verification (bulk re-scoring across tenants) and FP/FN reduction (less tier-2 escalation). All three run on the same verdict shape across every tenant.

JOB 01 · CONSISTENCY

Senior-grade verdicts, whoever's on shift.

Every analyst (tier-1 to senior) reads the same deterministic verdict and signal trail. Calibration drift between people, shifts and tenants disappears.

Two analysts reach two verdicts on the same IOC. The same analyst decides differently on a Friday than on a Monday. Across tenants the drift compounds, and the customer feels a brand that wavers: the consistency they pay for and never see.

Every alert payload calls /enrich and gets one deterministic verdict, recommended_action and signal trail. A tier-1 closes with the reasoning a senior would use; the answer never depends on who is on shift or which tenant called.

Drift stops being a training problem and becomes a system property. Every tenant gets senior-grade decisions, every shift, with one audit trail behind them.

JOB 02 · DECISION VERIFICATION

Bulk-verify the decisions you already shipped.

Bulk-feed a batch of SIEM verdicts per tenant. Surface false positives, false negatives and verdicts whose risk profile has shifted.

Single-call enrichment is fine for live triage. The verdicts your tenants' SIEMs already shipped (block, allow, alert) sit unchecked. False positives kept legitimate traffic out; false negatives let real threats through. No feedback loop closes, and the audit has nothing to read.

POST /enrich_bulk re-scores a full batch of decisions per tenant in one call. VerdictIQ flags FP, FN, inconsistencies and risk-profile shifts. Same verdict shape, same signal hierarchy, per-tenant audit trail. Built for batch jobs and recurring tenant reviews.

Continuous decision quality measurement, per tenant. The MSSP gets a closed-loop signal on what every customer's SIEM kept and what it missed.

JOB 03 · FP/FN REDUCTION

Less tier-2 escalation.

Verify SIEM verdicts at the moment they fire. Tier-1 closes more, tier-2 spends time on the work that needs them.

Tier-1 escalates because the verdict is ambiguous. Tier-2 burns capacity on alerts a Tier-1 should have closed. The escalation rate is the silent margin killer.

Every alert payload calls /enrich. Verdict, recommended_action and the signal trail land in the alert before the analyst opens it. Tier-1 closes the ticket with a defensible reason. Tier-2 capacity goes to real escalations.

Escalation rate drops. Tier-2 capacity frees up for the escalations that genuinely need a senior.

04 · STANDARDIZATION AS A PRODUCT

Decisions stop depending on the analyst, start depending on the system.

Standardization is the property that makes 50 tenants behave like one. Three pillars hold it: deterministic scoring, explainability and a shared audit trail.

Deterministic scoring across every tenant

Same input, same verdict, every tenant, every shift. Vendor updates do not silently shift the score. Drift between analysts becomes a system property, not a training problem.

Explainable trail your customer can read

Every verdict opens to Signal Group, Subgroup, signal, evidence and analyst Q&A. The MSSP review queue and the customer-facing report read the same trail. No black-box defence needed.

The MSSP scales by understanding attacker playbooks, not by storing more analysts.
05 · HOW IT LANDS IN YOUR STACK

One master key. Header partitioning. Existing SIEM and SOAR.

VerdictIQ is API-first. The MSSP holds one org-level master key and sets X-Customer-Id on every call to scope the tenant. Existing SIEM enrichment pipelines and SOAR playbooks call the same endpoint.

Your SIEM enrichment hook, every tenant

Splunk, QRadar, Sentinel, Elastic, Chronicle: the enrichment hook calls POST /enrich. The verdict and recommended_action enrich the alert in every tenant's SIEM. Your detection content stays put. Tenant isolation lives on the API call, not in your detection rules.

Your SOAR runs the per-tenant policy

SOAR consumes the same verdict. XSOAR, Splunk SOAR, Tines, Swimlane: the playbook condition node reads recommended_action or a specific signal. Per-tenant policy lives in the SOAR, not in our API. VerdictIQ feeds the decision; the SOAR executes the action.

Wired into
SIEM
SplunkSentinelElasticChronicle
SOAR
XSOARSplunk SOARTinesSwimlane

Wire one tenant. Re-score one batch.

Get an API key. Issue a tenant-scoped header. Re-score a batch of shipped SIEM decisions with /enrich_bulk. Read the FP, the FN, the risk-profile shifts. Add the next tenant when you have proof.

Master key + X-Customer-IdX-Customer-Id partitioningGDPR alignedAudit-ready signal trail
See trust posture