Delhi NCR · Operating since 2002
A co-managed SOC splits one security operations function between your team and ours. You keep the platform, the day shift and the business context; we take nights, weekends, public holidays and the L2/L3 work a day shift cannot absorb — with a written escalation matrix agreed before go-live, because ambiguous 3 a.m. ownership is how incidents get dropped.
Co-management is a delivery variant of SOC as a Service, built for an organisation with a working day-shift SOC and no realistic path to staffing 24×7. With no SOC at all, fully managed SOC as a Service is usually cleaner. The commercial side sits on our managed SOC services page, platform operation on our SIEM services page.
The definition
What co-managed actually means, and who it suits
Co-managed is a staffing arrangement, not a product: one security operations centre across two payrolls, yours during business hours and ours the rest of the time, both working the same queue on the same platform.
The buyer it suits is precise: a SIEM licensed and feeding, two or three competent office-hours analysts, a detection set somebody maintains — but no credible way to cover the other 123 hours of the week, and no path to the deep specialisms (forensics, malware analysis, threat hunting) a two-person team cannot hold. Staffing 24×7 yourself means roughly 4.6 full-time equivalents per continuous seat.
It does not suit everyone: with no day shift to share, you are outsourcing, not co-managing. The honest test is one question — who, exactly, reads an alert at 3 a.m. tonight?
“Co-managed means the provider advises and we do the work”
That is consulting. In a co-managed SOC the provider’s analysts work your console on their shift — investigate, escalate and, within the authority you grant, contain. If nothing changes hands at 6 p.m., nothing is co-managed.
Accountability does not split
Indian regulators hold the regulated entity, and its CISO, accountable regardless of who watches the console. Co-management shares the work, not the responsibility.
Division of labour
Who does what, by hour and by tier
The split below is our standard starting point, adjusted per engagement but always written down in this form, one owner per row. A division of labour that exists only in a sales deck fails at the first weekend incident.
Scroll the table sideways →
| Function | Your side | Our side | Where it is agreed |
|---|---|---|---|
| L1 triage, 09:00–18:00 Mon–Fri | Your analysts, your queue | Overflow cover during spikes and leave | SOW hours schedule |
| L1/L2, nights, weekends, holidays | Not staffed | Our watch from Delhi NCR | SOW hours schedule |
| L3 — forensics, malware, hunting | Usually not hired in-house | Our specialist tier, on demand | Escalation matrix |
| Detection engineering | Application context, change approval | Rule writing, tuning, deployment | Content SLA in the SOW |
| SIEM platform & licence | You own and administer it | We advise; we never hold your licence | Contract, access annexure |
| Regulatory reporting | You file; accountability stays with you | We supply timelines, evidence, log extracts | Incident runbook |
| Risk decisions & leadership | Yours, always | We recommend; we do not sign your risk | Governance charter |
Notice the rows where one side is deliberately empty: co-management fails quietly when a function has two owners and loudly when it has none. The table is how every row gets exactly one.
The platform question
Your SIEM, monitored by us — or ours
Most engagements run on the platform you already pay for: we monitor customer-licensed Microsoft Sentinel, Splunk, FortiSIEM and Wazuh estates through named accounts in your tenant, under your access policies — no shared credentials, no standing privilege beyond the role.
Keeping your own SIEM matters commercially too: the licence, the data and the detection content stay in your tenant, so at exit nothing must be extracted from a platform you do not control. On Sentinel estates, ingestion stays on your Azure bill — the published Central India reference is ₹568.25 per GB for analytics-tier ingestion — so platform spend stays visible.
The first step on an inherited platform is an audit, not a go-live: a SIEM run without a dedicated team almost always has rules nobody has reviewed in a year and log sources that stopped reporting unnoticed. Our managed SIEM team baselines the platform before the night shift takes its first watch; if you would rather not own one, the same model runs on PrahiX Ora, our own SIEM/SOAR.
The part that fails in practice
The escalation matrix is written before go-live, not during the first incident
Every co-managed SOC that has dropped an incident dropped it the same way: two teams, one alert, each assuming the other had it. The fix is a matrix stating, for every severity and hour, who investigates, who may contain and who gets woken — signed before the first night shift.
Scroll the table sideways →
| Severity | 09:00–18:00, Mon–Fri | Nights, weekends, holidays | Containment authority |
|---|---|---|---|
| P1 — confirmed active compromise | Your incident lead takes the bridge; we stay on until stood down | We validate and phone your on-call within 15 minutes | We isolate hosts and disable accounts at any hour, per pre-approved playbooks |
| P2 — likely compromise, contained | You investigate with our L2 on support | We investigate and contain; written handover at 09:00 | We contain; eradication scope decided with you |
| P3 — suspicious, unconfirmed | Your queue | Our queue; escalates to P2 on evidence | No containment without your approval |
| P4 — policy breach or noise | Your tuning backlog | Logged for the monthly tuning review | Not applicable |
This is not only operational hygiene. CERT-In’s six-hour reporting window runs from when an incident is noticed, and the first person to notice is often our night analyst — so the matrix names who declares the incident, who drafts the report and who files it, turning the regulatory clock into a runbook step rather than a dawn surprise.
Between the shifts
Handover discipline: the unglamorous thing that makes the model work
A co-managed SOC lives or dies at 09:00 and 18:00. Both shifts work one shared queue, and every open case carries a written note: what happened, what has been ruled out, the next step, who owns it now.
Anything P2 or above also gets a short call at the boundary — five minutes, named people — because prose misses how confident the analyst actually is. A weekly joint review is where drift surfaces: a rule your day shift tuned that our night shift did not know about, a false positive each side assumed the other owned.
The failure mode to design against is the verbal handover: if it is not written against the case, it did not happen. That one rule does more for reliability than any tooling choice.
Detection content
Who writes detections for your applications, and how fast
Generic detection content catches generic attacks. The alerts that matter are written against your applications — the core banking batch window, the ERP role change that should never happen on a Sunday, the service account that only ever authenticates from one subnet.
The writing is done by our detection engineers — the skill a two-person day shift cannot justify hiring — while your team supplies application context, change windows and final approval. The SOW fixes turnaround (standard requests within agreed working days, threat-driven content within 48 hours), and a monthly tuning review retires noisy rules.
Ownership is stated plainly in the contract: detection content written on your licensed platform is yours, catalogued as written and exported at exit. Our MDR vs SOC as a Service guide covers where detection engineering sits in each model, and who owns the content.
India, specifically
How Indian regulators view the split
No major Indian framework objects to a shared SOC. What they care about is that the function exists, is tiered, and that someone accountable can be named — all satisfied if the split is documented.
RBI — Annex-2 tiers
The Cyber Security Framework requires a C-SOC under the CISO, and Annex-2 names the L1/L2/L3 structure directly while listing why banks struggle to staff it. It does not require every tier to be your employee: co-managing nights and L3 fits the structure as written.
SEBI — CSCRF third-party model
The CSCRF expressly permits a third-party managed SOC alongside the entity’s own or the Market SOC — the model co-management extends. ISO 27001 for the provider is mandatory for market infrastructure institutions, “recommended” for Qualified REs after the August 2025 clarification; our SOC sits inside our certified ISO/IEC 27001:2022 scope either way.
CERT-In — clock and retention
Specified incidents must be reported within six hours of being noticed; logs must be retained for 180 rolling days within Indian jurisdiction. The trigger frequently fires on our watch, so declaration and filing duties belong in the escalation matrix, and retention stays in India regardless of whose SIEM you run.
The DPDP Act 2023 layers over all of this where personal data is concerned; IRDAI’s framework applies to insurers. Our compliance services page maps obligations to instruments.
Money
The cost comparison: co-managed vs fully managed vs nights in-house
Do the staffing arithmetic first. A week has 168 hours; a five-day, nine-hour shift covers 45, leaving 123 off-hours, about 6,400 console-hours a year. One analyst delivers roughly 1,900 productive hours after leave and training, so off-hours alone need about 3.4 FTE per seat — four hires per chair in practice.
Co-managed converts that into a monthly fee priced against monitored assets and log volume, and includes the L3 tier you were never going to hire. Versus fully managed SOC as a Service it is cheaper in fees — you buy roughly two-thirds of the week plus specialists — but compare total cost: our fee plus your SIEM licence, day-shift salaries and your own retention problem. The full in-house floor is roughly ₹1.4 crore a year in base salary for a three-tier 24×7 roster, before overheads.
The rule of thumb: co-managed wins when your day shift is real and the gap is genuinely the other 123 hours; if the day shift is theoretical, fully managed is cheaper than pretending. We quote a specific monthly figure with both comparisons beside it; pricing mechanics are on our managed SOC services page.
The way out, and the way forward
Migrating to fully managed later — and exiting cleanly
Co-managed is not a trap in either direction. Moving to fully managed later is a contract variation, not a re-onboarding: we already know your estate, detections and escalation contacts, so the change is extending our hours and, if you wish, taking over the platform. Organisations move the other way too, once the business case exists.
Exit terms deserve the same bluntness at signing: ours commit to a defined notice period, export of your detection content and playbooks in usable form, and delivery of your historical logs. None of this costs a provider anything to promise, so a refusal to write it down tells you something.
Straight answers
Co-managed SOC, answered
Who owns an incident at 3 a.m.?
Whoever the escalation matrix says owns it — which is why the matrix is signed before go-live. In our standard split we own detection, validation and first containment at night, phoning your on-call within 15 minutes for a P1; ownership transfers at the morning handover unless the incident bridge stays open. CERT-In’s six-hour clock runs from noticing, not from agreeing whose job it was.
Can you work on our existing Sentinel, Splunk or FortiSIEM?
Yes. We monitor customer-licensed Microsoft Sentinel, Splunk, FortiSIEM and Wazuh estates through named accounts in your tenant, under your access policies. The first step is an audit of inherited rules and log sources, because an unattended platform usually has detections nobody has reviewed in a year. Prefer not to own a platform? The same model runs on our PrahiX Ora SIEM/SOAR.
What is the minimum team we need to keep?
Two to three people is the workable floor: one or two day-shift analysts plus someone who owns the relationship, approves changes and can make risk decisions. Below that the model inverts, and if you cannot sustain a day shift at all, fully managed is the honest option.
How do shift handovers work in practice?
At fixed times, in writing, against one shared queue. Every open case carries a handover note recording what happened, what was ruled out, the next step and the current owner; anything P2 or above also gets a short call at the boundary, and a weekly joint review catches drift. Incidents die in the gap between we-thought-you-had-it and we-thought-you-had-it.
Who tunes and writes detections?
Our detection engineers write, test and deploy the content; your team supplies application context and approves change windows. Turnaround is fixed in the SOW — standard requests within agreed working days, threat-driven content within 48 hours — and a monthly tuning review retires noisy rules. Anything written on your licensed platform is your property.
What does a co-managed SOC cost compared to fully managed?
Less in fees, because you buy the off-hours and specialist tiers rather than the whole function — but compare total cost: our fee plus your SIEM licence, day-shift salaries and your retention exposure. Against extending in-house, the 123 off-hours a week need about 3.4 full-time equivalents per seat, four hires per chair before night allowances.
Can we move to fully managed later?
Yes, and it is a contract variation rather than a re-onboarding: we already know your estate, detections and escalation contacts, so the change is extending our coverage into your business hours and, if you wish, taking over the platform. Some clients later move the other way, rebuilding a day shift once headcount is approved.
What happens to our detection content if we exit?
You keep it. Detection rules, custom parsers and playbooks written on your licensed platform are your property, and the exit clause commits us to export them in usable form, along with your historical logs, within the notice period. Ask every provider this before signing: content held hostage is the quietest lock-in in this market.
Next step
See the split written down for your estate
We will map your day-shift coverage, draft the division-of-labour table and escalation matrix for your estate, and quote a specific monthly figure with the in-house nights arithmetic beside it. If fully managed fits better, we will say so.
P J Networks Pvt Ltd · C-160, Mayapuri Phase II, New Delhi 110064
+91 98183 61787 · sanjay@pjnetworks.com
Related
Related to co-managed SOC: SOC as a Service for the fully managed model, the virtual SOC for teams keeping their own tooling, managed SOC services for pricing and RFP questions, managed SIEM services for the platform underneath, MDR vs SOC as a Service for the boundary between models, and our SOC services and SLA page — or go straight to contact.