From Secureworks Taegis (Sophos) to In-house SOC (open stack)

Secureworks built Taegis on decades of counter-threat research, and that research is the reason customers pay. The 2025 Sophos acquisition put it inside a company with its own established MDR line, which is a reasonable prompt to ask what your renewal looks like in two years. Insourcing is one credible answer. Like every MDR exit, it is a staffing decision first, but Taegis has a structural feature that makes the planning cleaner than most: the platform and the service are genuinely separable, and you should decide about them separately.

Separate the platform from the service

Taegis is a cloud XDR that ingests endpoint, network, cloud, and identity telemetry, applies Secureworks-authored detection content, and surfaces investigations. On top of that sits a managed service where Secureworks analysts triage, investigate, and advise.

Cost the replacements independently, because they are different projects:

Replacing the platform is a familiar exercise. Wazuh or Elastic Security for endpoint and log telemetry, Graylog if volume is dominated by network and application logs, plus a case system. This is a normal deployment with a normal engineering cost, and your team almost certainly has the skills.

Replacing the service is the five-to-six-people-per-continuously-covered-seat arithmetic, plus a detection engineer, plus a platform engineer, plus recruitment and retention risk in a tight labour market.

Many organisations run this analysis and conclude they can absolutely replace the platform, and cannot economically replace 24x7 analyst coverage. That conclusion points at a hybrid, running your own platform with contracted out-of-hours coverage, and it is a perfectly good outcome rather than a failure to commit.

Mine the investigation history, because it is the specification

Secureworks’ detection content is theirs. Your incident history is about you, and it is the most valuable thing you can extract.

Pull the closed-investigation record and read it as a document rather than a log. It tells you which detections have ever produced a real finding in your environment, what your actual threat profile looks like as opposed to the industry average, which applications generate the false positives that needed tuning, and how long things took. That is precisely the specification for the detection content you now have to write, and it will stop you from building coverage for threats you have never faced while missing the ones you have.

Also extract the asset and identity inventory the platform maintains, which is often more accurate than your CMDB because it was built from observed telemetry, and any tuning exclusions applied on your behalf, which represent months of noise reduction.

Ask for all of it in writing, early, while you are a customer rather than a departing one. Check the contract for what you are entitled to and request the rest as goodwill.

Building the replacement

• Telemetry and detection: Elastic Security is the closest architectural analogue to Taegis if you want a unified endpoint-plus-log XDR with a real detection-rule engine; Wazuh is the lighter, simpler alternative if endpoint and compliance coverage matter more than analytics depth.
• Detection content: start from open rule libraries (Sigma, ATT&CK-mapped rulesets, the platform’s own bundled rules) and prioritise using your investigation history.
• Case management: TheHive, so shift handovers and evidence have a home.
• Threat intel: MISP or OpenCTI, plus the community and commercial feeds you choose to buy.
• Automation: Shuffle or StackStorm, which is how a small rota copes with volume a large provider used to absorb.
• Endpoint agents: whatever you keep, deployed in rings alongside the Taegis agent through the shadow period.

Name the intelligence gap out loud

There is one capability here that open tooling does not replace, and pretending otherwise is how insourcing projects lose credibility internally.

A provider like Secureworks sees attacks across a large customer base and writes detections for a campaign before it reaches you. That early warning is the substance of the “counter-threat” pitch. Community intel through MISP, open rule libraries, and sector ISACs recover a meaningful part of it, and for many threat profiles that is genuinely sufficient. But it is later and thinner.

The right handling is to state it in the business case as an accepted, quantified risk with a mitigation (intel feed subscriptions, ISAC membership, a named detection-engineering owner), not to bury it. Executives who discover the gap after the fact stop trusting the whole analysis.

Order of operations

1. Cost the platform and the service separately, and test a hybrid against both.
2. Get the Sophos roadmap position for Taegis in writing from your account team, and factor it into the renewal maths.
3. Extract investigation history, asset inventory, and tuning exclusions while the contract is healthy.
4. Map the notice deadline backwards through the shadow quarter, the platform build, and hiring lead times.
5. Hire or contract the rota before building the platform.
6. Deploy the stack, onboarding first the telemetry sources Taegis detections depended on.
7. Write detection content prioritised by your own investigation history, not by rule-library size.
8. Run both agent estates in parallel, testing for conflicts on a pilot ring before broad rollout.
9. Shadow for a full quarter, your team owning every alert while Secureworks remains responsible.
10. Serve notice after the shadow period succeeds, then remove the Taegis agents ring by ring.

Clearing the bar before you serve notice

Your team has independently detected and worked the classes of incident that appear in the extracted history. The rota is staffed, tested out of hours, and has survived a holiday period. Detection content is version-controlled and owned by a named engineer. Agent conflicts have been ruled out across every OS in the estate. The intelligence gap is documented with an accepted mitigation. And the endpoint estate is fully covered by your own agents before a single Taegis agent is removed.

The short version

Taegis to an in-house SOC divides cleanly into a platform replacement your team can probably do and an analyst-coverage replacement that most organisations cannot do economically. Use the acquisition as a prompt to price both properly and to negotiate with a real alternative in hand. Extract your own investigation history early, because it is both the best specification for your new detection content and the thing you lose permanently at contract end. Name the counter-threat intelligence gap honestly. The calculator above gives illustrative per-endpoint economics; the rota is the number that decides it.