What is scanner finding routing and owner assignment?

Scanner finding routing and owner assignment is the scanner-side discipline that produces the data the engagement record reads when it decides who owns each vulnerability finding. The workflow on the engagement record (a routing rule reads the finding, evaluates the rule conditions, and writes an assigned_to value) is a different discipline. The scanner-side discipline is everything that has to be true about the scanner output before the routing rule can fire defensibly: the asset binding has to resolve to a register entry that carries an owner, the finding category has to carry a workspace value rather than a vendor signal, the severity has to match the workspace policy for the asset class, the engagement scope has to carry the routing inputs the rule reads, and the recurring detection has to inherit the prior assignment rather than reset on every scan. When the scanner-side discipline holds, the routing rule fires once per finding with a defensible record. When it breaks, the same finding lands in the unassigned queue every scan cycle and the routing decision becomes an analyst chore rather than a controlled operation.

Why does scanner output not just emit an owner directly?

Scanners do not know who owns the asset because the asset register and the owning team live outside the scanner. Nessus emits a host and a plugin identifier. Burp Suite emits a URL and an issue type. Semgrep emits a file path and a rule reference. SCA scanners emit a component coordinate. None of these tools carry the workspace assignment of which team or named individual owns the affected asset right now. The owner is a workspace decision the scanner has no way to make. The clean pattern is the scanner emitting the asset reference, the workspace resolving that reference to a register entry, and the register entry naming the owner. Programmes that hard-code owner names into scanner configuration inherit a backlog where every reorganisation requires editing scanner profiles, and where scanner output rejected by a routing engine produces an opaque error rather than a recoverable record.

How is scanner finding routing different from the security finding ownership and routing use case?

The two pages cover sequential layers of one chain. The security finding ownership and routing use case covers the workflow side: the routing rules the workspace operates, the queues that hold unassigned and acknowledgement-pending findings, the escalation chain when an owner does not acknowledge, and the activity log of every assignment decision. This page covers the scanner side: the structural conditions on scanner output that let those routing rules fire defensibly, the assignment inheritance across recurring scans, the boundary between scanner-emitted data and workspace decisions, and the controlled queues the scanner side produces when the routing rule cannot resolve an owner. The two layers are run by the same security team in practice but they fail in different ways. A workspace that operates the routing workflow well can still inherit an unrouteable backlog if the scanner side does not produce findings the rule can read. A workspace that operates the scanner side well can still inherit an unowned backlog if there are no routing rules to read the scanner output.

What scanner output fields does a routing rule need to read?

Six fields carry the load. The asset binding answers what is affected (the register foreign key plus the source-emitted reference). The finding category answers what kind of vulnerability it is (the workspace controlled vocabulary, not the vendor signal). The severity answers how urgent the finding is under the workspace severity policy. The engagement reference answers which scope the scan ran under (which team owns the engagement, which client the engagement is for, which programme the engagement belongs to). The source class answers where the finding came from (external scan, authenticated scan, code scan, imported third-party, manual entry). The scan execution reference answers when the finding was detected and against which scanner generation. A routing rule that reads only one or two of these fields ends up routing on guesses. A routing rule that reads all six can decide on a named owner with a defensible record of which conditions matched.

How should the scanner side handle a finding that has no resolvable owner?

Unowned findings are not silently dropped and they are not routed to a default queue with no follow-up. The defensible pattern is a controlled queue that holds every finding whose asset binding cannot resolve to a register entry that names an owner. The queue requires a recorded decision per finding: the asset register is updated to add a missing entry, the existing register entry is updated to name an owner, the finding is bound to a different asset that already has an owner with documented rationale, or the finding is closed with a documented decommission decision. The activity log captures the queue entry, the decision, the actor, and the timestamp. Programmes that route unowned findings to a catch-all assignee inherit a backlog where the catch-all owner accumulates findings nobody is actually accountable for. Programmes that operate an unowned queue with a recorded resolution turn the gap into a controlled exception rather than into a silent accumulation.

When a recurring scan fires, should the owner inherit or reset?

The owner inherits when the recurring detection matches a finding the workspace has already triaged and routed. The finding template identifier plus the canonical asset reference produce the match key; if both match the existing finding, the scanner-emitted detection updates the last-seen timestamp on the existing record and the assignment stays on the named owner. The owner reset pattern is a documented failure mode in scanner UIs that key on scan execution rather than on the finding-target tuple; every scheduled scan creates a new record, the prior assignment is lost, and the named owner has to be re-attached manually each cycle. The clean pattern is keying both the finding identity and the suppression and assignment state to the workspace, the template, and the target, so the recurring detection inherits the prior routing decision without rewriting per-finding history.

How does the scanner side handle a finding that crosses multiple owners?

Some scanner output does not collapse cleanly to one owner. A finding can affect an asset that lives in one register entry but with a different team owning the application layer and a different team owning the infrastructure layer. A finding can be detected on a shared component that is reused across many product teams. A finding can be raised against a repository that two teams maintain through a shared OWNERS file. The defensible pattern is a primary assignment that names the named owner accountable for closing the finding plus a watcher set that names the secondary owners with an interest in the finding lifecycle. The activity log captures both the primary assignment and the watcher set so the audit trail reads the full accountability picture. Programmes that hard-collapse multi-owner findings to one default assignee lose the secondary signal; programmes that fan out the finding into multiple records lose the closure signal because each record closes on a different schedule.

How should imported third-party scanner output be routed?

Imported findings need the same six routing fields the native scanner output produces. The import workflow resolves each row against the asset register at ingest time, so the canonical asset reference is attached before the routing rule sees the record. The category translates from the source-emitted tag to the workspace controlled vocabulary through a documented mapping; the source-emitted tag stays on the evidence section so the audit chain stays intact. The severity translates from the source-emitted severity to the workspace severity through the workspace severity normalisation rules; the source-emitted severity stays on the evidence section. The engagement reference is set explicitly at import time so the routing scope is unambiguous. Imported findings without the six fields land in the unowned queue rather than auto-routing to a default assignee, so the analyst confirms the missing fields before the routing rule fires. Programmes that route imported findings on the source-emitted tag alone inherit a backlog where the same logical vulnerability lands with different owners depending on which tool fired first.

What does a defensible routing rule revision workflow look like?

Routing rules are workspace policy, not analyst memory. A defensible revision workflow runs at named events: a new asset class is onboarded into the programme and needs a new owner mapping, the team responsible for a category changes through a reorganisation, the workspace severity policy changes and the routing band has to follow, a recurring misroute pattern surfaces during the routing review and needs a structural fix. The revision is captured as a change to the routing rule with the prior version preserved, the new version effective from a named date, and the activity log noting the change. Existing findings keep the assignment they had under the prior rule unless the team runs an explicit re-route sweep against the new rule. The clean pattern is treating the routing rule as a versioned artefact with effective dates rather than as a live in-memory configuration that changes silently. Programmes that mutate routing rules without versioning inherit an audit conversation about whether the rule that produced a sampled assignment is even the rule that exists now.

How do compliance frameworks read scanner finding routing and owner assignment?

Auditors read routing and owner assignment through three artefacts. The routing policy (the rule set, the queues, the escalation chain, the unowned-finding handling, the review cadence) is the policy evidence; it is read at audit kickoff as the operating discipline that bounds how findings get to owners. The finding-level assignment history (the assigned_to value, the routing rule that produced it, the acknowledgement, the reassignment events) is the operating evidence; it is sampled at audit fieldwork as proof the policy ran consistently across the backlog. The unowned-queue resolution record (which findings entered the queue, how they were resolved, how long the resolution took) is the programme evidence; it is read as proof the team operates the routing gap as a controlled exception rather than as silent backlog. ISO 27001 Annex A 8.8 technical vulnerability management reads routing as the assignment to remediation; SOC 2 CC7.1 and CC7.2 read routing as detection-to-response; PCI DSS 6.3.3 reads routing as part of the ranking-to-remediation chain; NIST 800-53 RA-5 and SI-2 read routing as part of flaw remediation; NIST CSF 2.0 RS.AN reads routing through the analysis-and-response function. A routing record that cannot answer who owns each finding, which rule put the name there, and how unowned findings are resolved fails every one of these readings.

How does SecPortal support scanner finding routing and owner assignment?

SecPortal stores each scanner-emitted finding with the structured fields a routing rule needs: an asset binding through verified_domains or connected_repos foreign keys, a category string for the primary technical class, a severity band that the workspace severity policy reads, an engagement reference for the scope, a source class (external, authenticated, code, manual entry, imported third-party), and a scan execution reference where applicable. The 300 plus finding templates ship with pre-set category strings, severity bands, and CVSS 3.1 vectors so the routing inputs for known classes are anchored to workspace values rather than to vendor signals. Recurring detections of the same template against the same canonical asset reference match the existing finding so the assignment inherits without per-cycle rewriting. Finding overrides are keyed to the workspace, the template, and the target so suppression and severity decisions travel with the recurring detection. The activity log captures every assignment change, status transition, severity adjustment, and category revision with the named actor and the timestamp; CSV export of the activity log is available for evidence packaging. RBAC scopes who can assign, reassign, and override at the workspace level. Honest scope: SecPortal does not synchronously create tickets in Jira, ServiceNow, Slack, PagerDuty, or Opsgenie through packaged connectors; it does not read owner names from an enterprise IdP or HRIS through SCIM or SAML; it does not maintain a managed CMDB beyond the verified_domains and connected_repos registers and the engagement scope record; it does not run an autonomous routing engine that fires rules without human review at the workspace level. The routing decision is operated as a workspace discipline against the structured fields the platform exposes, with the audit trail living on the engagement record rather than on a packaged enterprise integration.

What are the common failure modes that defensible routing guards against?

Five failure modes cover most of what surfaces during audit fieldwork. A scanner output backlog with no canonical category, only vendor signals, so the same logical vulnerability routes to different owners depending on which scanner fired first. A scanner output backlog with free-text affected_asset values and no register foreign key, so the routing rule cannot resolve an owner without a manual lookup. A recurring scan cadence that resets every assignment because the workspace keys on scan execution rather than on the finding-target tuple, so the named owner falls off the record every scheduled run. An unowned-finding queue with no recorded resolution, so the gap accumulates silently and the audit conversation reads it as an unbounded exposure. A routing rule that mutates without versioning, so the audit cannot reproduce why a sampled assignment landed where it did. The defensible programme structures the scanner side so each of these failure modes surfaces as a named queue with a recorded decision and a continuous audit trail, rather than as a silent accumulation the team has to reconstruct from chat logs at fieldwork.

← Back to Scanner Information

Scanner guide14 min read

Scanner Finding Routing and Owner Assignment

Every vulnerability finding needs a named owner before the SLA clock starts running. The routing decision is a workspace discipline; the scanner side is the structural condition that lets the routing decision fire defensibly. When the scanner side is in place, the routing rule picks up the finding once, attaches a named owner, and inherits the assignment across recurring scans. When the scanner side is missing, the same finding lands in the unassigned queue every scan cycle and the named owner is lost between cycles. External, authenticated, and code scanners all emit asset references, category signals, and severity values, but none of them know who owns the affected asset right now. The owner is a workspace decision that resolves through the asset binding, not a scanner field. This guide covers the scanner-side discipline that produces the data the routing rule reads, the inheritance pattern across recurring scans, the unowned-finding queue that catches gaps before they become silent backlog, and the audit trail every framework observation expects.

This page covers the six scanner output fields a routing rule reads, the boundary between scanner-emitted data and workspace decisions, how recurring detections inherit the prior owner without rewriting per-finding history, how multi-owner findings carry a primary owner plus a watcher set, how imported third-party scanner output resolves to the same register entries as native findings, the routing rule revision workflow that keeps the rule set as a versioned artefact, and how ISO 27001, SOC 2, PCI DSS, NIST SP 800-53, and NIST CSF 2.0 read the routing and owner assignment chain.

What scanner finding routing is

Scanner finding routing is not a single action and it is not a single component. It is a two-layer chain. The scanner side produces a finding with a structured set of fields that the workspace controls; the routing rule reads those fields and writes an assigned_to value to the finding record. Both layers have to work for the chain to be defensible. A workspace that operates good routing rules over scanner output that carries free-text affected_asset values and vendor-emitted category strings inherits a routing engine that fires on guesses. A workspace that operates good scanner output with no routing rule on top inherits a backlog where every finding lands unassigned.

The scanner side is the focus of this guide. The workflow side, including the deterministic routing rules, the queues, the acknowledgement window, and the escalation chain, is covered by the security finding ownership and routing use case. The boundary between the two layers is one of the clearest indicators of whether a programme has structured ownership at all: when the scanner side and the workflow side are operated as one discipline, sampled assignments at audit fieldwork can be reproduced from the rule version, the input fields, and the activity log.

The six fields a routing rule reads

A routing rule that decides on a named owner has to read more than the source-emitted severity. The six fields below are the minimum carrying surface a defensible routing decision rests on; missing fields force the rule to fall back to defaults that the audit cannot reproduce.

Field	What it carries	Why the rule reads it
Asset binding	Foreign key into the asset register plus the source-emitted reference.	The register entry names the owner; the binding is how the rule resolves the assignment.
Workspace category	Controlled vocabulary value from the workspace taxonomy.	Category routes between AppSec, platform engineering, cloud security, and vulnerability management owners.
Severity	Workspace severity band derived from CVSS plus the asset-class severity policy.	High and critical findings may escalate immediately; low and medium findings may batch into the standard queue.
Engagement reference	Foreign key to the engagement that ran the scan.	The engagement carries the scope, the workspace, and the routing inputs that vary by programme.
Source class	Where the finding came from (external scan, authenticated scan, code scan, imported, manual).	The owner for a code finding may differ from the owner for an external scan finding on the same asset.
Scan execution reference	Foreign key to the scan execution that produced the detection.	Anchors the routing decision to a reproducible scanner run and a known scanner generation.

A routing rule that reads only severity inherits a backlog where every critical finding routes to one queue regardless of which team owns the asset. A rule that reads only the asset binding inherits a backlog where a code finding and an external scan finding on the same asset get the same owner even when the owners differ in practice. The defensible pattern is reading all six fields and naming the rule that fired in the activity log so the audit can reproduce the decision later.

Five failure modes the scanner side has to guard against

Scanner-side discipline is not optional. The five failure modes below cover most of what surfaces at audit fieldwork as a routing record the team cannot reproduce.

Vendor-emitted category instead of workspace category

The scanner output is routed on the vendor-emitted tag (Nessus plugin family, Burp Suite issue type, Semgrep rule identifier) rather than on a workspace controlled vocabulary. The same logical vulnerability lands with different categories depending on which tool fired first, and the routing rule reads inconsistent inputs across scanners. The right pattern is the workspace category as a separate field on the finding, derived from the vendor-emitted tag through a documented mapping, with the original tag preserved on the evidence section.

Free-text affected_asset with no register foreign key

The scanner output is routed on the source-emitted hostname or path string with no normalisation against an asset register. The same asset appears under five different strings, the routing rule cannot resolve a single owner, and the analyst becomes the routing engine. The right pattern is a register foreign key resolved at intake plus the source-emitted reference preserved as evidence; the routing rule reads the foreign key while the audit reads the verbatim string.

Owner reset on every recurring scan

The scanner keys finding identity on the scan execution rather than on the finding-template-and-target tuple. Every scheduled scan creates a new record, the prior assignment is lost, and the named owner has to be re-attached manually each cycle. The right pattern is keying the finding identity to the workspace, the template, and the canonical asset reference so the recurring detection inherits the prior assignment, suppression, and severity override without rewriting history.

Unowned-finding catch-all assignee

Findings whose asset binding cannot resolve to a register entry that names an owner route to a default catch-all assignee (often the security manager, the AppSec lead, or the workspace owner). The catch-all owner accumulates findings nobody is actually accountable for, and the unowned tail looks like assigned work in every leadership rollup. The right pattern is a controlled unowned queue that requires a recorded resolution per finding (add the register entry, update the existing entry, re-bind, or close with rationale) rather than auto-assignment to a default.

Routing rule mutating without versioning

The routing rule is treated as live in-memory configuration that changes silently when the team reorganises, the severity policy updates, or a new asset class onboards. The audit cannot reproduce which rule produced a sampled assignment. The right pattern is versioned routing rules with effective dates; the activity log captures which rule version was in force when each assignment fired, so the sampled assignment reads back to a reproducible rule.

Routing inheritance across recurring scans

Routing is not a per-scan decision. The first time a finding is detected and routed, the assignment lands on the finding record. Every subsequent recurring detection of the same finding template against the same canonical asset reference inherits the prior assignment without firing the routing rule again. The recurring detection updates the last-seen timestamp and the scan execution reference, but the assigned_to value, the workspace category, the severity (subject to any documented override), and the status stay as they were.

The mechanism is the match key. A defensible scanner side keys the finding identity to the workspace, the finding template identifier, and the canonical asset reference. A recurring detection that matches all three is the same finding, not a new finding. Programmes that key only on the source-emitted detection string create a new record every scan cycle, lose the prior assignment, and reset the SLA clock unnecessarily. Programmes that key on the structural tuple inherit assignment continuity without per-cycle analyst work.

For the deeper treatment of how finding identity matches across cycles and how recurring scans produce continuity rather than churn, the scanner output deduplication guide covers the dedup discipline that the recurring assignment inherits from.

The unowned-finding queue as a controlled exception

Not every finding lands with a resolvable owner on first detection. The asset register may be missing an entry for the affected target. The existing entry may have an empty owner field because the prior owner left and the role has not been reassigned. The scanner may have detected the finding on an asset that crosses register boundaries. Each of these cases is real and the defensible response is the same: the finding enters a controlled unowned queue that requires a recorded resolution before the routing rule can fire.

Unowned reason	Resolution pattern
Missing register entry	Add the asset to the verified domains or connected repos register, attach the owning team and named owner, then re-route.
Empty owner on existing entry	Update the register entry to name an owner (named individual plus owning team), then re-route. Document why the owner was empty.
Asset crosses register boundaries	Pick a primary register entry, name a watcher set for the secondary owners, and document the boundary decision.
Asset decommissioned	Close the finding with documented decommission evidence and a pointer to the asset register decommission event.
Asset out of scope	Close the finding with documented scope rationale; flag the scope record for review at the next engagement kickoff.

The activity log captures the queue entry, the resolution decision, the actor, and the timestamp. The leadership rollup reads the unowned queue depth as a programme metric rather than as silent backlog. The audit reads the resolution rate and the median queue dwell time as proof the team operates the routing gap as a controlled exception rather than as accumulating exposure.

Multi-owner findings and the watcher set

Some scanner output legitimately crosses owners. A code finding on a shared library affects every product team that depends on the library; the library maintainer is the primary owner of the fix while the dependent teams have a secondary interest in the lifecycle. A configuration finding on a shared platform asset affects the platform team as the primary owner while the application teams running on the platform have an operational interest. A finding on a cross-team service has split accountability that does not collapse cleanly.

The defensible pattern is a primary assignment plus a watcher set. The assigned_to field carries the named owner accountable for closing the finding; the watcher set carries the secondary owners who need visibility but are not on the hook for closure. The notification chain reaches both groups but the SLA clock and the escalation chain apply to the primary owner. The audit trail reads the full accountability picture without conflating closure responsibility with awareness responsibility.

Programmes that hard-collapse multi-owner findings to one default assignee lose the secondary signal and produce leadership reports where shared findings look like single-team work. Programmes that fan out the finding into separate records per owner lose the closure signal because each record closes on a different schedule and the same logical vulnerability ages independently in every record. The primary-plus-watcher pattern keeps both the closure accountability and the visibility intact on one finding.

Imported third-party scanner output

Findings imported from Nessus, Burp Suite, CSV exports of other tools, and manual entry from consultancy deliverables need the same routing inputs the native scanner output produces. The import workflow is where the missing fields are reconciled against the workspace controlled vocabulary; the routing rule on the engagement record reads the same six fields whether the finding came from a native scan or from an import.

Asset binding at import time

Each imported row is resolved against the asset register at ingest. Hostnames, URLs, file paths, and repository references map to the corresponding verified domain or connected repository entry, with the source-emitted reference preserved on the evidence section. Rows whose targets cannot be resolved enter the unowned queue rather than auto-assigning to a default. The importing third-party scanner results guide covers the import workflow end to end.

Category translation at import time

The source-emitted tag (Nessus plugin family, Burp Suite issue type, scanner- specific category) translates to the workspace controlled vocabulary through a documented mapping. The source-emitted tag stays on the evidence section so the audit chain reads the original signal alongside the workspace decision. The scanner finding tag and label taxonomy guide covers the workspace taxonomy the routing rule reads.

Severity normalisation at import time

The source-emitted severity translates to the workspace severity through the workspace normalisation rules; the original severity stays on the evidence section. Programmes that route on the source-emitted severity inherit a backlog where the same logical vulnerability routes to different owners depending on which tool calibrated severity differently. The scanner output severity normalisation guide covers the normalisation discipline.

Routing rule revision as a versioned artefact

Routing rules change over time. The team responsible for a category reorganises. A new asset class onboards into the programme and needs a new owner mapping. The workspace severity policy updates and the routing band has to follow. A recurring misroute pattern surfaces during the routing review and needs a structural fix. Each of these events is legitimate and each one needs a controlled revision.

The defensible pattern treats the rule set as a versioned artefact with effective dates. The new version takes effect from a named date; existing findings keep the assignment they had under the prior version unless the team runs an explicit re-route sweep. The activity log captures which version was in force when each assignment fired, so the sampled assignment at audit reads back to a reproducible rule. The rule change itself is reviewed against the named trigger event (the reorganisation, the severity policy change, the new asset class, the misroute pattern), so the rationale for the change lives in the record.

Programmes that mutate routing rules without versioning inherit an audit conversation about whether the rule that produced a sampled assignment is even the rule that exists now. The clean pattern is the same shape as a versioned policy artefact anywhere else in the security programme: prior version preserved, new version effective from a date, change rationale captured, sweep against existing records run deliberately or skipped deliberately.

Where this fits in the wider scanner evidence chain

Routing and owner assignment sit on top of several scanner-side disciplines. Asset binding produces the foreign key the routing rule reads. The taxonomy produces the workspace category the rule routes against. Severity normalisation produces the workspace severity band the rule uses to choose a queue. Deduplication produces the recurring detection identity that lets the prior assignment inherit. Suppression and override produce the per-finding workspace decisions that travel with the recurring detection rather than reset on every scan.

For the asset binding chain that resolves the foreign key the routing rule reads, the scanner finding asset binding guide covers the seven asset classes, the canonical key per class, and the five failure modes that break the binding. For the wider evidence chain from scanner output to finding, the scanner evidence chain guide covers the seven structural layers. For the suppression and severity override discipline that travels with each recurring detection, the scanner finding suppression and deferral controls guide covers the workflow.

For the operational workflow that operates on top of the scanner-side discipline, the security finding ownership and routing use case covers the routing rules, the queues, the acknowledgement window, and the escalation chain. The asset ownership mapping use case covers the upstream discipline of keeping the asset register entries the routing rule reads current and accurate.

For the cross-target cluster identity that lets routing decisions surface a primary cluster owner at the root cause alongside per-target owners across the fleet, the scanner finding merge across targets guide covers the scanner-side cluster signature discipline that lets shared libraries, base images, OS images, configuration templates, and rule references group as one cluster while each per-target finding inherits its own assignment through the routing chain.

How compliance frameworks read routing and owner assignment

Auditors read routing through three artefact classes: the routing policy, the finding-level assignment history, and the unowned-queue resolution record. Each artefact answers a different question. The policy is the operating discipline that bounds how findings get to owners; the assignment history is the proof that the policy ran consistently across the backlog; the unowned-queue record is the proof that the routing gap is operated as a controlled exception rather than as silent backlog.

Framework	Where it reads routing
ISO 27001:2022	Annex A 5.9 inventory and ownership; Annex A 5.24 to A 5.28 incident management roles; Annex A 8.8 technical vulnerability management with assignment evidence.
SOC 2	CC4.1 monitoring controls; CC7.1 and CC7.2 detection and response; CC1.3 organisational structure and reporting lines for assignment.
PCI DSS v4.0	6.3.3 ranking and risk-based remediation including assignment; 11.3 internal and external scans and the assignment of remediation activity.
NIST SP 800-53 Rev. 5	RA-5 vulnerability monitoring and the assignment of flaw remediation; SI-2 flaw remediation; PM-9 risk management strategy with named accountable roles.
NIST CSF 2.0	RS.AN analysis and response with assignment evidence; GV.RR roles, responsibilities, and authorities at the programme layer.
CIS Controls v8.1	Control 7 continuous vulnerability management with the assignment of remediation tasks to named owners.
HIPAA	164.308(a)(1) security management process including assignment of responsibilities; 164.308(a)(2) assigned security responsibility.
DORA	Article 5 ICT risk management framework with roles and responsibilities; Article 8 identification and assignment of accountable owners for ICT assets.

A routing record that cannot answer who owns each finding, which rule version put the name there, which scan execution produced the original detection, and how unowned findings are resolved fails every one of these readings. The discipline is not optional; it is the assignment chain that the audit reads as proof the programme operates findings as work that has named owners rather than as a queue that nobody specifically owes.

How SecPortal supports scanner finding routing and owner assignment

SecPortal stores each scanner-emitted finding with the structured fields a routing rule reads. The mechanism is the same shape across external, authenticated, and code surfaces; the register entry and the source class differ by surface.

Structured routing inputs on every finding

Every finding carries an asset binding through a verified_domains or connected_repos foreign key, a category string for the primary technical class, a severity band, an engagement reference for the scope, a source class (external, authenticated, code, manual, imported), and a scan execution reference where applicable. The 300 plus finding templates ship with pre-set categories, severity bands, and CVSS 3.1 vectors so the routing inputs for known classes are anchored to workspace values rather than to vendor signals. The findings management feature covers the data model.

Recurring detection inherits the prior assignment

Finding identity is keyed to the workspace, the finding template identifier, and the canonical asset reference. Recurring detections of the same template against the same target match the existing finding so the assigned_to value, the workspace category, the severity (subject to any documented override), and the status stay as they were. The last-seen timestamp and the scan execution reference update; nothing else resets. The continuous monitoring feature covers the recurring scan cadence.

Override scope survives recurring scans

Finding overrides (false positive, accepted risk, severity adjustment, category revision) are keyed to the workspace, the template, and the target so they travel with the recurring detection without re-application each cycle. The routing rule reads the workspace severity after the override is applied, so the routing decision reflects the workspace decision rather than the scanner-emitted value. The finding overrides feature covers the override mechanism.

Imported scanner output resolves at ingest

Bulk imports from Nessus, Burp Suite, and CSV exports of other tools resolve each row against the asset register at ingest time. The workspace category, severity, and engagement reference are attached during the import workflow so the routing rule reads the same six fields whether the finding came from a native scan or from an import. The source-emitted tag and severity are preserved on the evidence section.

Activity log captures every assignment event

The activity log records every assignment, reassignment, status change, severity adjustment, and category revision with the named actor, the timestamp, and the engagement reference. CSV export of the activity log is available for evidence packaging. The activity log feature covers the audit trail mechanism.

RBAC scopes who can assign and reassign

Workspace roles (owner, admin, member, viewer, billing) carry granular permissions on findings, including assignment authority. The role that can assign or reassign a finding is recorded in policy rather than left to ad-hoc custom. The team management feature covers the role model.

Notifications reach assigned owners

The notifications system surfaces new assignments, status changes, and acknowledgement events to the assigned owner. The notifications and alerts feature covers the notification model. Assignment events do not synchronously create tickets in third-party systems through packaged connectors; the routing decision lives on the engagement record and the notification reaches the workspace user with the assignment.

Honest scope: SecPortal does not synchronously create or update tickets in Jira, ServiceNow, Slack, PagerDuty, or Opsgenie through packaged connectors. SecPortal does not federate user identity from an enterprise IdP through SCIM or SAML. SecPortal does not read named owners from an HRIS or directory service. SecPortal does not maintain a managed CMDB beyond the verified_domains and connected_repos registers and the engagement scope record. SecPortal does not run an autonomous routing engine that fires arbitrary rules without human review at the workspace level. The routing decision is operated as a workspace discipline against the structured fields the platform exposes; the audit trail lives on the engagement record rather than on a packaged enterprise integration.

An operational checklist

When designing the routing inputs

Every finding carries the six routing fields (asset binding, category, severity, engagement, source class, scan execution reference).
The workspace category is a controlled vocabulary, not a vendor-emitted tag passed through.
The asset binding is a foreign key into a register entry that names an owner, not a free-text string.
Severity is the workspace value after any override, not the source-emitted value.

At scanner output

First-detection findings route through the rule once and land on a named owner.
Recurring detections inherit the prior assignment without rewriting history.
Findings whose binding cannot resolve to an owner enter the unowned queue rather than auto-assigning to a default.
Multi-owner findings carry a primary assignment plus a watcher set rather than fanning out into separate records.

At the routing rule revision

The rule set is a versioned artefact with effective dates, not live in-memory configuration.
The change rationale is captured against a named trigger event (reorganisation, severity policy change, new asset class, misroute pattern).
The activity log records which rule version was in force when each assignment fired.
Existing findings keep the prior assignment unless an explicit re-route sweep runs against the new rule.

At audit fieldwork

Sampled assignments can be reproduced from the rule version, the input fields, and the activity log.
The unowned-queue resolution record reads as a controlled exception rather than as silent backlog.
Multi-owner findings show a primary owner plus a watcher set rather than collapsed single-owner records.
The routing policy artefact reads as workspace policy rather than as analyst memory.

Scope and limitations

Routing only works when the underlying finding record is durable and the asset binding holds. Programmes that store findings in spreadsheets or in scanner UIs that reset asset references on rule updates cannot operate the routing chain at all. The leverage point is consolidating findings into a workspace with stable foreign keys and a controlled vocabulary before attempting to govern the routing.

SecPortal does not replace an enterprise ticketing system, an identity directory, an asset inventory CMDB, or an autonomous routing engine. The routing decision is operated against the structured fields the workspace exposes and the audit trail lives on the engagement record. Where the wider enterprise stack carries owner attribution through an HRIS, an IdP, or a CMDB, the mapping between that stack and the SecPortal register entries is the team's discipline rather than a platform automation.

For the analytical view of how ownership decays inside the assessment cycle when the scanner-side discipline stops being maintained, the security finding ownership decay research covers the four-layer re-attribution sweep model. For the engineering handoff latency that compounds on top of slow routing, the security engineering handoff latency research covers the latency model. For the data-model design that the routing rule reads against, the vulnerability program data model and record design research covers the structural choices that make routing reproducible.

Frequently Asked Questions

Run scanner finding routing on a record auditors and security leaders can both read

SecPortal stores every scan execution and finding against verified asset register entries, with structured category, severity, and engagement fields that workspace routing decisions read. The activity log captures every assignment, reassignment, and status change with the named actor and timestamp so the audit trail is reproducible without reconstructing the routing chain from chat logs.

Start free See the routing workflow