Guide

CTEM stage five: mobilization without a SOAR

Most CTEM guides assume you have a SOAR platform, bidirectional ITSM integration, and a dedicated staff to manage the remediation pipeline. Most security teams don't.

Most writing about CTEM mobilization assumes a mature security operations environment: a SOAR platform running automated playbooks, bidirectional ITSM integration, and a dedicated staff to manage the remediation pipeline. If your organization has all that, mobilization is an engineering problem. If it doesn't, mobilization is a process problem that no amount of tooling will solve until you've made some decisions that have nothing to do with technology.

The majority of security teams sit in the second category. They have a ticketing system, a spreadsheet that someone updates irregularly, and a standing meeting with the infrastructure team that gets canceled when something more urgent comes up. CTEM guides that treat SOAR as a baseline assumption are not written for them.

This is written for them.

Why mobilization fails at human speed

When confirmed findings have to be manually triaged, manually routed, manually tracked, and manually verified, the throughput ceiling is the size of the security team. That ceiling is almost always lower than the finding volume from a continuously running EASM platform, which means findings age.

When findings age, the infrastructure teams that should be acting on them stop taking them seriously. When those teams stop taking them seriously, the security team stops pushing them hard. The program produces dashboards instead of closures.

This is not an attention or accountability failure. It is a structural one. Manual mobilization does not scale to continuous discovery output. The challenge is how to reduce the per-finding overhead enough that the team's capacity matches the volume.

What mobilization really requires

Strip away the tooling assumptions and mobilization has four components, none of which require a SOAR.

An owner

Every finding needs a specific person or team responsible for it. Not "the infrastructure team" — a named queue, a specific cloud account owner, a team identified by their asset tagging convention. If the finding arrives without an owner, it will wait until someone figures out who should receive it, which is usually never.

A format the owner can act on

A finding that lands as a raw EASM alert — external IP, port, CVE identifier, severity score — requires translation before the recipient can act on it. That translation step is where findings die. The ticket should already contain asset context, business justification, and a clear description of what needs to be done. The security team does that work, not the infrastructure team.

A deadline

Without a defined SLA, findings have no urgency signal. A finding with no deadline competes on goodwill against everything else in the queue, which means it loses. Three tiers is enough: critical findings with confirmed reachability on high-criticality assets get a 48-hour SLA; everything else gets tiered based on severity and asset criticality. The specific numbers matter less than having numbers at all.

A verification step

Closing a ticket is not the same as closing an exposure. The remediation loop is not complete until someone confirms that the fix reduced the external exposure. Most EASM platforms will show whether a finding disappears from the next discovery run. "Verified closed" must be a different ticket status than "patched," and the security team owns that step.

The minimum viable mobilization stack

For teams without SOAR, this is what operational mobilization looks like in practice.

Asset ownership mapping lives somewhere the EASM platform can reference. That might be CMDB tags, cloud account ownership records, or a spreadsheet that the security team maintains and updates. It does not need to be sophisticated. It needs to exist and be current enough that a discovered asset can be matched to an owner without a manual investigation.

The EASM platform creates tickets directly in the ticketing system with pre-populated context: asset details, finding description, severity, confirmed reachability status, owning team, and SLA deadline. Most enterprise EASM platforms have ServiceNow and Jira integrations that can do this without custom development. The configuration work is in the ticket template — making sure the ticket that arrives in the infrastructure queue contains everything the recipient needs to act without coming back to the security team with questions.

SLA tracking runs in the ticketing system, not in a separate spreadsheet. The security team reviews overdue tickets on a defined cadence (weekly is usually enough) and escalates through a defined path when SLAs are missed. That path needs to exist before the first SLA is missed, not after.

Verification is a ticket workflow state. When an infrastructure team closes a finding as remediated, it moves to a "pending verification" state. The security team confirms closure on the next discovery run and moves it to verified closed. Findings that don't verify get reopened. This loop takes two minutes per finding and eliminates the gap between "we patched it" and "the exposure is gone."

Where to invest if you're building toward automation

The first integration worth building is EASM-to-ticketing, not EASM-to-SOAR. Get findings into the right queue with the right context and the right owner before you automate the response. A SOAR sitting on top of a broken manual process automates the broken process.

The second investment is asset ownership mapping. Not because it is exciting, but because every other part of the mobilization workflow depends on it. A finding without an owner is noise. An ownership map that is six months out of date is almost as bad. The maintenance overhead of keeping ownership data current is the actual cost of mobilization, and it is invisible until the first time a critical finding sits unrouted for two weeks because nobody knows which team owns the AWS account it lives in.

When those two pieces are working — findings routing to the right owner with the right context, and closure being verified rather than assumed — you have a mobilization program. It is not elegant. It does not require a SOAR. It produces closures, which is the only metric that matters.