Why do legacy SOAR platforms create margin pressure for managed security providers at scale?

Why Legacy SOAR Economics Break Down for Managed Security Providers

Managed security providers sell repeatability, but legacy soar often behaves like a custom integration layer instead of a reusable service layer. Each client variation adds connector work, exception handling, script upkeep, and validation effort, so the cost of delivering the same operational outcome rises with every added environment. The result is not just higher engineering load, but a structural mismatch between fixed-service pricing and variable delivery effort.

That matters because margin pressure does not come only from building the first workflow; it accumulates every time a playbook must be adjusted for a new log source, identity source, approval path, or customer-specific exception. For providers, the financial risk is less about visible incident response labour and more about the hidden operational drag of keeping automations alive across many tenants. The NIST Cybersecurity Framework 2.0 helps frame that issue as a resilience and operating-model problem, not just a tooling problem, because operational continuity depends on controls that remain maintainable as environments change.

In practice, many security teams discover the true cost of SOAR only after the service has scaled far enough that maintenance work starts competing with delivery work.

How Legacy Automation Becomes a Recurring Service Tax

Legacy SOAR platforms tend to centralise orchestration while leaving the underlying integrations brittle. That creates a pattern where the platform appears efficient in a pilot, but each additional customer introduces more edge cases: different EDR schemas, different ticketing systems, different approval chains, and different evidence requirements. The platform still works, but the operating model changes from “build once, run many” to “build, adapt, and re-verify for each tenant.”

The main cost drivers are usually predictable. Connectors need updates when vendor APIs shift. Scripts need rework when input fields or response formats differ. Playbooks need repeated testing because one customer’s safe default can become another customer’s false positive. Tuning also becomes continuous, because managed service providers are judged on consistency and speed, not on whether a workflow is technically clever.

• More customers usually means more integration variants, not more reuse.
• More automation often means more regression testing, especially after small platform changes.
• More conditional logic increases fragility, which pushes labour from operations into maintenance.
• More bespoke exceptions make service delivery harder to standardise and price.

Where this guidance breaks down is in highly standardised environments with a narrow tool stack, stable APIs, and low customer diversity, because the maintenance burden may stay low enough that the platform remains economically acceptable. In those cases, the problem is not SOAR itself, but the degree of variation the provider has to absorb.

Where the Cost Curve Worsens and What Providers Misjudge

Tighter orchestration often improves response consistency, but it also increases dependency on fragile integrations, so providers must balance automation breadth against the cost of keeping it trustworthy. The pressure rises fastest when services are sold as managed detection and response, incident response automation, or shared SOC operations across many client stacks, because the same playbook logic must survive different security controls, different governance constraints, and different data quality.

Industry practice does not fully agree on how much customisation is acceptable before a SOAR programme stops scaling economically, but there is broad agreement that the tipping point appears when platform maintenance becomes a standing operational function rather than an occasional engineering task. That is where providers often misjudge the economics: they price the outcome as if the automation were reusable, while the actual delivery model has become a portfolio of semi-custom services.

Legacy SOAR also creates hidden commercial risk when the platform encourages deep workflow coupling to a specific customer’s environment. That increases switching friction, but it does not improve provider margin, because the same coupling makes onboarding slower and support more labour intensive. In short, the more a provider relies on bespoke playbook logic to demonstrate value, the more it inherits the cost of preserving that logic at scale.

Practitioner Guidance

What to prioritise: Separate reusable orchestration from customer-specific exception handling. If a workflow cannot be deployed with the same evidence model, logging expectations, and test harness across multiple clients, treat it as a bespoke service component rather than a reusable automation asset.

What to measure: Track onboarding hours, connector maintenance time, regression-test effort, and the share of playbooks that require per-customer edits. Those signals tell you whether the platform is reducing labour or merely moving it into a less visible queue.

Common mistake: Assuming that more playbooks automatically create more scale. In managed services, scale comes from standardisation and controlled variation, not from multiplying logic paths that each need separate upkeep.

Practitioner takeaway: The margin problem is usually not automation volume itself, but the point where automation stops being reusable and starts behaving like custom integration work that must be carried on the delivery payroll.

Related resources from NHI Mgmt Group

• Why do playbook-based SOAR platforms create operational risk at scale?
• How should security teams evaluate AI SOAR platforms against legacy SOAR?
• Why do Microsoft-centric SOC stacks create scaling pressure for managed security teams?
• Why do legacy Java applications create a bigger security problem than patching alone?