ClearSkies iISOC for MSSPs
Separate by Design.Correlated by Default.
Where separation is enforced is an architectural decision made before the first event arrives, so it cannot be added later. That decision is what lets one deployment carry a whole book.
Multi-tenancy
Built multi-tenant below the application
Switching an operator between single-client systems is not multi-tenancy, and you still pay to run each one in full. A shared database with client data hidden inside the application is not separation, and it will not survive a regulated client's due diligence.
Shared across the book, never across tenants
Federated learning shares derived detection intelligence, indicators and watchlist entries, so detection tuned for one regulated client sharpens protection for every comparable client. Client data, alerts and cases never leave their tenant, and no tenant holds, sees or infers the data of another.
The operator console
Run the book from one place
Cross-tenant view
Detections, alerts, service levels and analytics across the entire client base.
Bulk operations
Policy, playbooks and exports applied to many tenants in one audited action.
Delegated control
You govern centrally and delegate tenant control where the operating mode allows.
Aggregate analytics
Campaign patterns visible only across the book, with scope separation preserved.
Templated onboarding
Cloud, on-premises, hybrid and legacy brought live from templates, not custom builds.
Cross-layer visibility
What one correlation core sees across many tenants
The iCollector normalizes telemetry at collection, the Centric-AI Fabric resolves events to the same entities across sources, and the TDIR engine assembles one incident mapped to MITRE ATT&CK on a single explainable score. Across tenants the same infrastructure and technique sequences recur, and that recurrence is itself a detection signal.
| What each layer sees alone | What the platform resolves |
|---|---|
| A look-alike domain registered against the brand of client A. Informational | Registered as an entity and linked to the brand before any user contacts it |
| Three resolution attempts to that domain from two hosts at client B, a separate tenant | An informational finding becomes an active-contact signal inside tenant B |
| A finance login at client B from an unfamiliar location, then an MFA registration. Medium | An ATT&CK-mapped phishing to valid-accounts sequence on the same hosts |
| A signed binary spawning a scripting host on one of those endpoints. Medium | Endpoint behavior lands on the same timeline, raising confidence by correlation |
| Four alerts in four consoles across two clients. None escalated, no incident, no owner | One incident in tenant B, one score, an orchestrated response, a preventive watchlist entry across the book, and one campaign visible to you with separation preserved |
Illustrative and technically representative rather than drawn from a named engagement.
Governed autonomy
Every autonomous conclusion carries the evidence it was reached on, so an analyst inspects the reasoning rather than accepting a verdict. Response sits behind approval gates configured per tenant, with blast radius bounded by scope rules, a defined reversal path and a documented stop control, all on one audit trail. That is also the answer to whether the autonomous analyst is real or a wrapper: it reasons over normalized, correlated data rather than over raw alerts from tools it does not understand.
Delivery
Every SOC operating model, configured per tenant
A fully managed mid-market client and a co-managed enterprise client run side by side, without a separate build for either.
One TDIR deploymentconfigured per tenant
Fully managed
provider's SOC, end to end
- AI-SecOps analyst + provider team
- Triage · investigation · response
- Client consumes outcomes via portal
Best for mid-market with no in-house SOC
Co-managed
provider & client share workflow
- Shared case ownership
- Role-based handoff
- Joint investigation view, scoped RBAC
Client analysts in the same console
Hybrid / tiered
provider L1–L2 · client L3 / IR
- Resource-aware routing
- Escalates to client tier with context
- Client retains senior IR
Front line outsourced, IR kept in-house
Self-run + assurance
client runs it, provider assures
- Client operates the platform
- Provider assurance & oversight
- Full platform capability retained
For mature in-house security teams
A client's model can change over time — without a separate build or re-onboarding
The same deployment serves a fully-managed mid-market client and a co-managed enterprise whose own analysts work alongside the provider's. A provider that forces one model loses the client when their needs move — this one moves with them.
Why it matters commercially
Moving a client along this range, deepening to fully managed or accommodating one that insists on holding response authority, keeps accounts through changes that would otherwise trigger a re-procurement. Growth happens inside the book rather than by displacement.
Time to value
From contract to first reporting cycle
Onboarding is templated per environment type rather than built per client, so a new tenant inherits a known-good baseline instead of a bespoke project.
- 01
The first day
Tenant established, baseline policy inherited from the service package, ingestion begins from the sources the client already runs.
- 02
The first week
Connector coverage completed, baseline tuned against observed traffic, first exposure picture delivered.
- 03
The first month
First full reporting cycle, initial ATT&CK coverage and gap view, and the tuning backlog that sets the next cycle.
The client supplies administrative access to the sources in scope, an escalation contact tree, and the response authority matrix that governs what may be actioned without approval. Deployment, enablement and ongoing optimization can also be bought as ClearSkies Professional Services.