Attack surface management tools promise to route discovered exposures to control teams — the groups that own remediation for a given exposure type, such as cloud security, IAM, or infrastructure — for reduction, but routing capability varies widely. Some platforms deliver notifications while others confirm control team intake and track reduction outcomes. The difference changes whether your ASM program can measure routing completion or only notification delivery.
Notification delivery creates a false completion signal. Your routing dashboard shows assets processed to control teams while those teams have no structured work records to act on. The operational consequence: routing appears complete in your ASM program while control teams operate from incomplete handoff data, creating reduction delays and accountability gaps.
Routing Completion: The Evaluation Frame
Routing completion requires three confirmations that notification delivery cannot provide. First, the receiving control team created a work record from the structured handoff — not just received an alert. Second, the control team acted on the exposure with a documented outcome. Third, the exposure state changed or was formally accepted with governance controls.
Notification-based routing marks assets complete when the webhook delivers or the email sends. Routing completion capability tracks assets until the control team confirms intake, documents action, and validates exposure state change. Test this distinction during vendor demonstrations: ask what happens in the receiving system when an asset routes through their platform.
The business impact surfaces during audit preparation. Notification-based programs produce routing metrics without reduction evidence. You can report that 847 critical exposures were routed to cloud security, but cannot confirm how many were reduced, accepted, or remain unaddressed. Routing completion capability provides reduction confirmation rates separate from notification delivery rates.
What You Are Not Evaluating
Four platform capabilities appear related to routing effectiveness but do not indicate routing completion capability. Integration connector count measures how many tools the platform can notify, not whether those notifications create actionable work records. More connections without intake confirmation does not improve routing completion.
Notification delivery speed measures alert transmission performance, not control team response. Faster delivery of notifications that do not create structured work records does not improve reduction outcomes. The routing pipeline performance matters after you confirm the pipeline produces complete handoffs.
Ticket creation automation can generate records in connected ITSM platforms, but automation without structured handoff fields does not produce control team intake capability. Evaluate whether automated tickets contain the routing fields your control teams need: surface type, exposure tier, business function, and validated exposure evidence.
Dashboard visualization displays routing activity and status summaries, but visualizing routing without reduction status does not confirm governance capability. Focus evaluation on the underlying workflow mechanics, not the presentation layer.
Six Routing Completion Capabilities To Test
Each capability addresses a specific failure mode from notification-only routing. Test these during vendor demonstrations with realistic scenarios from your control team workflows.
Control team intake confirmation distinguishes notification delivery from work record creation. Ask the vendor to demonstrate what happens in your VEM (vulnerability and exposure management) platform when an ASM asset routes through their tool. The expected outcome: a priority queue entry appears in VEM with structured handoff fields including surface type, exposure tier, and business function context.
The red flag: VEM shows an email notification or alert without a corresponding work record. Intake confirmation capability requires bidirectional integration where the receiving system confirms work record creation, not just notification receipt.
Reduction status tracking confirms whether control teams acted on routed assets and validates exposure state changes. Ask vendors how their platform distinguishes between a ticket closed with configuration changes and a ticket closed without action. Routing completion capability tracks action types: reduced, accepted, or decommissioned. A status of
reduced, however, must be confirmed by independent re-verification of the finding — a re-scan or evidence-based check that the exposure state actually changed — not accepted on the control team's reported action alone. A closure signal from the control team is a claim of remediation; re-verification is the proof, and the two should not be conflated.
The capability gap: routing records that end at control team intake without reduction status confirmation. Your ASM program needs reduction confirmation rates separate from routing completion rates to measure control team effectiveness and identify workflow bottlenecks.
Exception and acceptance governance enforcement prevents control teams from closing exposures as accepted without structured review. Test the acceptance workflow during vendor demonstrations: what fields are required, who can approve acceptances, and how does the platform surface exceptions past their re-review date.
Required acceptance fields include accepting authority at configured levels, rationale text, exposure state at acceptance, and re-review dates. Acceptance without structured governance creates an unauditable exception portfolio where accepted risks cannot be validated for authority level or exposure context.
Aging and escalation for unresolved routings automates SLA enforcement without manual review. Ask vendors what happens automatically when a critical exposure routed to VEM has no intake confirmation after 48 hours. The expected capability: configurable SLA thresholds by surface type and exposure tier with automatic escalation to designated authorities.
The red flag: SLA tracking requires manual dashboard review with no automatic escalation workflow. Your security team discovers SLA violations during periodic reviews rather than receiving escalation alerts when thresholds exceed.
Routing rule configurability and coverage completeness ensures every combination of surface type, exposure tier, and business function maps to a named control team. Test coverage gap detection: ask vendors how their platform handles asset combinations with no configured routing rule.
Complete routing capability flags unmapped combinations for rule completion rather than routing to default queues. Without coverage gap detection, your program cannot identify which surface and exposure tier combinations lack routing rules, creating random assignment patterns.
Native integration depth with your stack determines whether every capability above actually works in your environment. The confirmations that matter — bidirectional intake, closure signals with action type, and re-verification hooks — depend on how natively the platform integrates with the specific VEM, ITSM, cloud, and ticketing systems your control teams already run. Evaluate integration against your actual stack, not the vendor's marquee logos: ask the vendor which of your systems they support for bidirectional confirmation and closure capture versus one-way notification, and to demonstrate the integration for the exact tools you operate.
The capability gap: a large connector catalog where, for your systems specifically, integration is a one-way webhook or a generic API that needs custom engineering to reach parity. Integration depth should be evaluated per system you actually operate, because a "supported" connector that only notifies cannot deliver intake confirmation, reduction tracking, or re-verification. This is distinct from connector count in "What You Are Not Evaluating" — the question is not how many tools the platform can reach, but how deeply it integrates with the ones you use.
The Control Team Intake Test
Schedule this test with your VEM or ITSM platform administrator present during vendor demonstrations. The test scenario: route a sample critical cloud misconfiguration through the vendor's platform to your VEM system.
Document the VEM outcome in real time. Routing completion capability produces a priority queue entry with structured fields: asset identifier, surface type (cloud misconfiguration), exposure tier (critical), business function context, and exposure evidence summary. The VEM record appears automatically without manual intervention from your team.
Notification-only platforms produce email alerts or webhook notifications in VEM without structured work records. Your VEM administrator should confirm whether the routing created an actionable queue entry or only delivered an alert requiring manual processing.
Test the confirmation mechanism: how does the ASM platform know VEM created the work record? Bidirectional confirmation requires the receiving system to signal successful intake, updating the routing record from "notified" to "intake confirmed."
The Exception Governance Test
Ask vendors to demonstrate an acceptance record for a previously accepted risk in their platform. The record should contain accepting authority identification, rationale text, exposure state at acceptance, and re-review date with all fields populated as required inputs.
Test field enforcement: attempt to accept a risk with incomplete governance data. The platform should prevent acceptance closure without required fields rather than allowing binary accept/reject toggles.
Verify re-review automation: how does the platform surface accepted risks past their re-review dates? Exception governance capability automatically flags overdue reviews for re-evaluation rather than requiring manual tracking.
The governance gap appears during compliance preparation when accepted risks cannot be audited for rationale, authority level, or exposure context at acceptance time. Your exception portfolio becomes a collection of binary decisions without decision criteria or review schedules.
Evaluation Matrix
| Evaluation Criterion |
Routing Completion Capability Indicator |
Notification-Only Red Flag |
Question to Ask the Vendor |
| Control team intake confirmation |
Tool considers routing complete only when the receiving control team's system confirms a work record was created with the structured handoff fields; confirmation is automated, not manual; routing records distinguish "notified" from "intake confirmed" |
Routing is marked complete when the notification webhook or email was delivered; the tool has no mechanism to confirm the control team created a work record; "complete" means "sent" |
Show me a routing record for an asset routed to VEM; how do you know VEM created a priority queue entry from this handoff? What is the confirmation mechanism, and how does the record distinguish notification delivery from VEM intake confirmation? |
| Reduction status tracking |
Tool receives closure signals from control teams with action type; reduction records distinguish action types (reduced, accepted, decommissioned); the tool can produce reduction confirmation rate separate from routing completion rate; a status of reduced requires independent re-verification — re-scan or evidence-based exposure-state confirmation — not the control team's closure signal alone |
The routing record ends at control team intake confirmation; what the control team did is tracked in the control team's tool only; the ASM routing program has no reduction status record; routing completion and reduction confirmation are the same metric |
After an asset is routed to cloud security and the cloud team closes the ticket, what record does your tool produce? Does it distinguish a configuration change that confirmed exposure state change from a ticket closed without validation? |
| Exception and acceptance governance enforcement |
Tool has an acceptance workflow with required fields: accepting authority (at configured authority level), rationale text, exposure state at acceptance, re-review date; acceptance without all required fields is not a permissible closure path; re-review due dates are surfaced automatically |
Accepted risks are closed tickets; acceptance is a binary status; no rationale or re-review workflow exists; the exception portfolio cannot be audited for authority level or exposure state at acceptance |
Show me the acceptance workflow; what fields are required, who can approve an acceptance, and how does the tool surface exceptions that are past their re-review date? |
| Aging and escalation for unresolved routings |
SLA thresholds are configurable by surface type and exposure tier; assets past SLA are automatically escalated to the configured authority; escalation history is auditable; the escalation record distinguishes routing SLA violation from reduction SLA violation |
SLA tracking is a dashboard that requires manual review; no automatic escalation exists; aging is visible in reports but does not trigger a workflow; the security team discovers SLA violations during periodic reviews |
If a critical exposure asset routed to VEM has no intake confirmation after 48 hours, what does the tool do automatically? Show me an escalation record and the authority it notified |
| Routing rule configurability and coverage completeness |
Tool supports routing rule definitions with surface type, exposure tier, and business function dimensions; unmapped combinations are flagged for rule completion rather than routed to a default queue; routing rule coverage report shows which combinations are mapped and which are gaps |
Routing is configured as a set of filters and destination webhooks; unmapped assets route to a default "security team" queue; no routing rule gap detection exists; the program does not know which surface type and exposure tier combinations have no routing rule |
Show me how you configure a routing rule for a vendor-linked cloud surface with critical business function designation; if my routing rule library has no rule for that combination, what does the tool do, and how does it surface the gap to me? |
| Native integration depth with your stack |
The platform natively supports bidirectional intake confirmation, closure signals with action type, and re-verification hooks for the specific VEM, ITSM, cloud, and ticketing systems you operate; integration depth is documented per system, not as a connector count |
The platform advertises a large connector catalog, but for your systems the integration is a one-way webhook or generic API that needs custom engineering to confirm intake or capture closure; depth is not disclosed per system |
Which of my specific systems (name them) do you natively support for bidirectional intake confirmation and closure capture, versus one-way notification? Show the integration for my VEM/ITSM specifically, not a reference platform. |
Use this matrix during vendor demonstrations to distinguish routing completion capability from notification delivery. Each criterion tests specific workflow mechanics that affect whether your ASM program can measure reduction outcomes or only routing activity.