Security finding ownership and routing
every finding lands on a named owner with a documented routing rule
Most programmes decide who owns each vulnerability finding through chat, default-assignee rules, or analyst memory. The routing record never lands on the finding, the audit trail is a Slack search, and the unowned-finding tail grows quietly. Run ownership and routing as a defensible workflow on the workspace: ten deterministic routing rules read against six dimensions (asset binding, source class, severity, engagement type, asset criticality, cross-team scope), eight operating queues for unassigned, acknowledgement-pending, reassignment, cross-team, escalation, disclosure, source-class, and policy-violation work, and an activity log that captures every assignment, reassignment, acknowledgement, and escalation event with the named actor and the routing rule cited.
No credit card required. Free plan available forever.
Routing turns detected vulnerabilities into accountable remediation work
Every internal security organisation eventually faces the same operational question. A scanner produces a finding. A pentest write-up lands. A code review surfaces an issue. A customer reports something. The finding is real, the severity is calibrated, the asset is identified. The question is: who owns the remediation work, how do they hear about it, and what happens if they do not respond. Most programmes answer this question through a mix of analyst memory, chat threads, default-assignee rules, and a shared inbox that absorbs the edge cases. Routing-by-tribal-knowledge holds together until the security analyst rotates, the asset moves to a different business unit, or the audit lookback asks how long the finding sat in which queue. The ownership and routing workflow fixes the operating record by making every assignment, reassignment, acknowledgement, and escalation an explicit event on the finding record with the named actor, the routing rule cited, the timestamp, and the rationale captured on the activity log.
The routing engine composes with the rest of the vulnerability management operating model. The upstream asset ownership mapping workflow supplies the asset-to-owner mapping the routing engine reads against. The vulnerability finding intake workflow delivers normalised findings with provenance and severity to the routing engine. The downstream state lifecycle workflow records the open-to-in_progress transition the routing rule produces. The SLA management workflow reads the acknowledgement window against the routing policy. Routing sits at the centre as the discipline that turns a queue of findings into accountable remediation work.
Six dimensions the routing engine reads against
A defensible routing engine reads six dimensions on every finding before producing the assignment. Asset binding answers where the finding lives. Source class answers what produced the finding. Severity answers how fast the routing has to move. Engagement type answers under which operating policy the finding lands. Asset criticality answers how tightly the acknowledgement window compresses. Cross-team scope answers whether the routing runs through a single owner or a coordinating committee. The six dimensions together produce a routing decision that maps to the workspace policy rather than to analyst discretion.
Asset binding to owner
The named asset on the finding (host, application, repository, cloud resource, dependency package, identity) carries a recorded owner of record on the engagement metadata. Routing reads the asset binding first because the asset is the most durable handle: a finding may move between scanners, severity bands, and engagement records, but the asset reference points at the team accountable for it. The asset-to-owner mapping is the input the routing engine reads against.
Source class to triage owner
The provenance of the finding (Nessus output, Burp Suite session, authenticated DAST, code scan via Semgrep, manual pentest write-up, third-party report, customer disclosure, internal escalation) decides who triages it before it reaches the remediation owner. Source-class routing prevents the situation where an external scanner finding bypasses AppSec triage and lands directly on an engineering queue that cannot interpret the scanner output without security context.
Severity band to escalation tier
The calibrated severity (the auto-calculated CVSS 3.1 vector on the finding) drives the named escalation tier the routing applies on the open-to-in-progress transition: critical and high-severity findings route to a named tier-one owner with a tighter acknowledgement window; medium findings route to the standard remediation tier; low findings route to the backlog tier. The severity-tier mapping is workspace policy, not analyst discretion.
Engagement type to routing policy
The engagement context (pentest engagement, vulnerability assessment, ISO 27001 audit, SOC 2 readiness, bug bounty intake, security review, incident response) carries its own routing policy because the operating cadence and the stakeholder expectations differ. Pentest findings route to the engagement lead; vulnerability assessment findings route to the asset owner directly; bug bounty findings route through the disclosure triage queue; incident response findings route to the on-call IR owner with a parallel notification chain.
Asset criticality to acceptance window
Asset tier (tier-zero regulated systems, tier-one revenue-critical applications, tier-two customer-facing systems, tier-three internal systems) compresses or extends the acceptance window before the routing escalates. A tier-zero asset with a high-severity finding does not wait the standard acknowledgement window; the routing escalates to the named secondary on the policy at a fraction of the default time so the unaccepted state cannot age silently.
Cross-team scope to coordinating owner
Findings that touch a shared platform service, a shared dependency package, or a shared cloud subscription carry a multi-owner mapping: a designated lead owner under whom the finding routes, and a named coordinating committee whose members read every state change. Cross-team findings do not bounce between teams because the lead owner and the coordinating reads are explicit on the routing record.
Six failure modes that quietly break the routing discipline
Most routing failures look like sensible defaults: route to a shared inbox, set a catch-all rule, decide ownership in chat, let acknowledgement windows slip because everyone is busy. The cost arrives weeks later as an unowned tail the leadership team did not realise had grown, a reassignment chronology nobody can reconstruct, and an acknowledgement-window breach pattern the audit reads as systemic.
The finding routes to a shared inbox with no named individual on the hook
Routing rules that target a group address (security-engineering@, platform-ops@, devops-team@) move the finding off the security side without moving it onto an accountable owner. The first engineer who opens the inbox picks the easy ones; the hard ones sit there until the audit lookback surfaces them. The routing engine must resolve to a named user on the workspace before the open-to-in_progress transition is allowed.
The owner field is populated but no notification reaches the named user
A finding is assigned to a workspace user record, the assigned_to field carries the email, but the named user never receives a notification because the routing rule does not invoke the assignment notification path or the user is inactive on the workspace. The fix is the assignment workflow that writes the activity log entry, looks up the assigned user profile, verifies workspace access, and pushes the notification into the user inbox so the assignment is observable rather than silent.
Routing decisions are made in chat and never make it onto the record
A security analyst decides who owns the finding in a Slack thread, the engineering side picks up the work, and the assignment never lands on the finding record. The audit cycle reads the assigned_to field as null and concludes the routing discipline is absent. The fix is requiring the assignment to land on the record before the in_progress state is reached, with the activity log capturing the actor, the prior owner (none), the new owner, and the routing rationale.
Default-assignee rules silently absorb everything that does not match a rule
A workspace ships a catch-all rule that routes unmatched findings to one named user. The named user becomes the de-facto owner of every edge case the routing engine cannot resolve. Their queue grows without leadership visibility because the policy reads green and the activity log reads consistent. The fix is the unowned-finding queue with an explicit named operator who triages routing exceptions rather than absorbing them into a default-assignee tail.
Reassignment events lose the prior owner and the rationale
A finding is reassigned from one team to another because the asset moved to a different business unit, but the activity log captures only the new owner. The audit query asks how long the finding was in the prior owner queue, who reassigned it, and why; the answer is reconstruction from email. The fix is the reassignment event that stamps the prior owner, the new owner, the reassigning actor, and the reason on the activity log so the routing chronology survives.
Acknowledgement windows expire without escalation and findings age silently
A finding lands on a named owner with a documented acknowledgement window, the owner does not respond within the window, and the finding ages in the open state because no escalation rule reads the unacknowledged signal. The fix is the acknowledgement-window queue that the security operations lead reads against the workspace policy, with notifications to the secondary on the policy and to the named escalation owner under the workspace RBAC.
Ten deterministic routing rules the workspace policy publishes
The routing engine is a published policy, not a black box. The ten rules below cover the bulk of intake patterns an internal security programme encounters. Workspaces extend or adjust the rules to match their operating context (industry sector, regulatory scope, platform architecture), but the underlying discipline is the same: every assignment cites a rule, every escalation cites a rule, and every routing decision is reconstructable from the record.
| Rule | Condition | Routing action |
|---|---|---|
Rule 1 | Critical-severity finding on a tier-zero or tier-one asset | Route to the named primary owner under the workspace RBAC with an acknowledgement window measured in hours rather than business days. Parallel notification to the security operations lead and the engagement lead. Escalation to the named secondary at the half-window mark. |
Rule 2 | High-severity finding from an external scanner with asset binding to a regulated system | Route through the AppSec or security operations triage queue before reaching the asset owner so the scanner context is validated and the finding is calibrated against false-positive history before engineering picks it up. |
Rule 3 | High or medium-severity finding from an authenticated DAST scan with a clean asset binding | Route directly to the asset owner of record on the engagement metadata. The activity log captures the source (authenticated DAST module), the assigned user, and the acknowledgement window applied. |
Rule 4 | Medium-severity finding from a code scan (Semgrep SAST or SCA) on a connected repository | Route to the named code owner on the repository connection. The pull-request reference, the commit SHA, and the affected file path are on the finding so the engineer receives the routing context the scanner produced. |
Rule 5 | Bug bounty submission or third-party disclosure intake | Route through the disclosure triage queue first (the AppSec or security operations triage role under the workspace RBAC), then through the asset binding into the standard remediation tier. The disclosure-to-finding chronology lives on one continuous record. |
Rule 6 | Finding on a shared platform asset, shared dependency, or shared cloud subscription | Route to the named lead owner on the multi-owner mapping. The named coordinating committee is on the notification list with read access. Reassignment between coordinating members is explicit on the activity log rather than implicit on tribal knowledge. |
Rule 7 | Asset binding cannot be resolved to a recorded owner | Hold the finding in the unowned-finding queue. The named security operations or GRC operator updates the asset-to-owner mapping before routing executes. The unowned queue is a programme metric, not a silent absorber. |
Rule 8 | Finding reopened on a regression event | Restore the prior owner of record by default. If the prior owner is no longer active on the workspace, route to the named successor on the asset-to-owner mapping. The reopened transition cites the original closure and the regression evidence so the routing decision reads as continuation rather than restart. |
Rule 9 | False-positive transition on a recurring scanner pattern | Route the workspace-wide suppression update to the named scanner-output operator so the intake exception register receives the dismissal. The finding closes with the named triager; the suppression rule is reviewed on the workspace cadence before being applied to future scan cycles. |
Rule 10 | Acknowledgement window expires without acceptance | Escalate to the named secondary on the workspace policy. The escalation event lands on the activity log with the prior owner, the secondary owner, the elapsed time, and the routing rule cited. The escalation chain reads as a defined ladder rather than a heroic save. |
Six fields the routing record captures on every assignment
A defensible routing record is six concrete fields on the finding at the moment of assignment and at every subsequent reassignment or escalation. The fields make the next triage cycle, the next leadership report, and the next audit lookback reconstructable from the record rather than from email.
Current owner and prior owner
The current value of the assigned_to field on the finding record and the prior owner captured in the activity log so reassignments read as chronology rather than as a snapshot. Both fields support the audit question of how long the finding was in each owner queue.
Routing rule cited at assignment
The routing rule that produced the assignment (Rule 1 through Rule 10 in the workspace policy, or a documented manual override) is recorded on the activity log entry so the routing chronology is reconstructable rather than implicit.
Acknowledgement window remaining
The documented acknowledgement window per severity and per asset tier (hours for critical, days for high, weeks for medium, longer for backlog) and the elapsed time the finding has been in the open state without the named owner accepting the work. The remaining window drives the escalation queue.
Escalation chain on file
The named secondary and the named escalation owner under the workspace RBAC who receive the routing chain when the primary owner does not acknowledge within the documented window. The chain is recorded once on the workspace policy and read on every escalation event rather than rebuilt per-finding.
Reassignment history and rationale
Every reassignment event stamps the prior owner, the new owner, the reassigning actor, the timestamp, and the rationale (asset moved, owner departed, scope changed, severity recalibrated, exception applied) so the routing chronology survives a successor analyst.
Coordinating-committee read access
For findings on shared assets, the multi-owner mapping records the lead owner and the coordinating-committee members who receive read notifications. Routing decisions on shared assets read against this mapping rather than against a default-assignee rule.
Eight operating queues the routing engine runs in parallel during the operating week
Live routing work runs eight queues concurrently. Each queue has a named owner, a documented cadence, and an escalation rule so unassigned findings, acknowledgement-window breaches, reassignment events, cross-team coordination, escalations, disclosure intake, source-class triage, and routing-policy violations do not silently fall behind between standups.
- Unassigned-finding queue with every finding that has landed without a resolved owner, the asset binding that could not be matched, and the named GRC or security operations operator responsible for updating the mapping. The view that prevents the unowned tail from absorbing routing exceptions silently.
- Acknowledgement-pending queue with every finding whose named owner has not yet accepted within the documented window, the elapsed time, and the secondary on the escalation chain ready to receive the routing. The view the security operations lead reads to catch dropped routing before the finding ages.
- Reassignment queue with every reassignment event in the last cycle, the prior owner, the new owner, the rationale, and the routing rule that produced the change. The view the security operations lead reads to validate that reassignments map to documented routing rules rather than to ad-hoc decisions.
- Cross-team coordination queue with every finding on a shared asset, the named lead owner, the coordinating-committee membership, and the lead-owner acceptance status. The view the platform engineering lead and the security operations lead read against the shared-asset register.
- Escalation queue with every finding whose acknowledgement window has expired, the escalated owner under the workspace RBAC, the elapsed time, and the routing rule that triggered the escalation. The view that distinguishes routing-engine breaches from owner-side delay.
- Disclosure intake queue with every bug bounty or third-party disclosure pending routing through the triage role to the asset owner. The view the AppSec triage operator reads against the disclosure inbox cadence.
- Source-class triage queue with every finding from an external scanner, code scan, or pentest write-up pending validation before reaching the remediation owner. The view the AppSec or security operations triage role reads against the source-class routing rule.
- Routing-policy-violation queue with every assignment that bypassed a documented routing rule, every reassignment without a recorded rationale, and every escalation that did not follow the workspace chain. The view the security operations lead reads against the routing-discipline metric.
How routing runs in SecPortal
The routing engine rides on the platform surfaces the security programme already uses. Findings management is the canonical record with the assigned_to owner field, the auto- calculated CVSS 3.1 vector, and the activity log of every routing event. The assignment notification path writes the event to the activity log, looks up the assigned user profile, verifies workspace access, and pushes the notification to the user inbox so the assignment is observable rather than silent. Team management role-based access control governs assignment authority. Engagement management carries the routing policy per engagement type. No bespoke integration is required for the routing itself; the platform capabilities below are enough.
Findings management with the assigned_to owner field
Findings management ships the assigned_to owner field on every finding alongside the auto-calculated CVSS 3.1 vector, the severity band, the source class, and the asset binding the routing engine reads against.
RBAC for assignment authority
Team management role-based access control governs who can write the routing policy, who can assign and reassign findings, and who reads against the routing record. Owners and admins write the policy; members operate within it; viewers read but do not change ownership.
Notifications on assignment
Notifications and alerts push every assignment to the named owner of record, the engagement lead, and the escalation chain where the severity band or the asset tier requires it.
Activity log for the routing chronology
Activity log with CSV export captures every assignment, reassignment, acknowledgement, and escalation event with the actor, the timestamp, the prior owner, the new owner, the routing rule, and the rationale.
Engagement record as the policy anchor
Engagement management holds the routing policy per engagement type (pentest, vulnerability assessment, ISO 27001 audit, SOC 2 readiness, bug bounty intake, security review) so the permitted routing matches the engagement context rather than collapsing to a single global policy.
Compliance tracking on the routing chain
Compliance tracking maps the routing record to ISO 27001 Annex A 5.2 and A.5.3 and A.8.8, SOC 2 CC1.3 and CC2.2 and CC7.1 and CC8.1, PCI DSS 12.1 and 12.4 and 6.3.1, NIST 800-53 PM-2 and PM-29 and RA-5, NIST CSF 2.0 GV.RR and RS, and CIS Controls v8.1 control 7.
MFA on every routing-policy authority
MFA enforcement on every workspace account ensures the named owner and the named escalation owner on the routing record are who they claim to be when they accept a finding or stamp a reassignment event.
AI reports for routing telemetry
AI report generation summarises routing telemetry (assignment-to-acknowledgement latency, reassignment frequency, unowned-queue trend, escalation rate) into a stakeholder narrative without inventing data the activity log does not support.
Bulk finding import preserves source class
Bulk finding import with column-mapping templates for Nessus, Burp Suite, scanner CSVs, and code-scan outputs preserves the source class on every imported finding so the routing engine reads the right triage rule from the moment the finding lands.
Audit frameworks that read against the routing record
Enterprise audit and certification cycles ask for evidence that vulnerability findings are assigned to named owners under defined roles and responsibilities, that escalation chains operate when acknowledgement windows expire, and that routing decisions are recorded rather than improvised. The routing workflow produces the evidence those audits read against.
ISO 27001:2022
Annex A 5.2 (information security roles and responsibilities) and A.5.3 (segregation of duties) read against the routing engine as the operating record of who owns each finding and how routing decisions are made. Annex A 8.8 (management of technical vulnerabilities) reads against the assignment-to-owner discipline as part of the vulnerability management process. Clause 5.3 (roles, responsibilities, and authorities) reads against the workspace RBAC and the documented routing policy as the evidence the organisation has defined and assigned the relevant roles.
SOC 2 Trust Services Criteria
CC1.3 (organisational structure, reporting lines, authorities, responsibilities) reads against the routing chain and the escalation ladder as the operating record of accountability. CC2.2 (internal communication) reads against the notification path on every assignment so the named owner is informed of the work assigned to them. CC7.1 (system operations monitoring) reads against the unassigned-finding queue and the acknowledgement-pending queue as evidence the routing engine is operated rather than aspirational. CC8.1 (change management) reads against reassignment events with their named actors and rationale.
PCI DSS v4.0
Requirement 12.1 (information security policy is established and maintained) and 12.4 (responsibility for protecting cardholder data is formally assigned) read against the asset-to-owner mapping on the routing engine. Requirement 6.3.1 (security vulnerabilities are identified and managed) reads against the assignment-to-owner discipline as the workflow that puts each finding in front of an accountable owner.
NIST SP 800-53 Rev. 5
PM-2 (information security program leadership role) and PM-29 (risk management roles and responsibilities) read against the named routing-policy owner and the escalation chain. RA-5 (vulnerability monitoring and scanning) and SI-2 (flaw remediation) read against the routing engine as the discipline that channels detected vulnerabilities to the right owner with the right acknowledgement window. CA-7 (continuous monitoring) reads against the routing-policy-violation queue as the evidence the discipline is observed continuously rather than once a cycle.
NIST CSF 2.0
The Govern (GV) function reads against the workspace routing policy as the organisational discipline that defines roles, responsibilities, and authorities for vulnerability management. GV.RR (roles and responsibilities) reads against the assignment workflow. The Respond (RS) function reads against the escalation chain on routing breaches. The Detect (DE) function reads against the unassigned-finding queue as a continuous monitoring metric.
CIS Controls v8.1
Control 7 (continuous vulnerability management) reads against the routing engine as the workflow that turns detection signal into accountable remediation work. Control 17 (incident response management) reads against the escalation chain for routing breaches and for high-severity findings on critical assets. The activity log entries the routing produces are the artefacts the audit reads against.
Where routing fits in the wider operating model
Routing is the spine between intake and remediation. The references below trace how the structured routing record carries into the rest of the programme. Each adjacent workflow reads against the same finding record rather than rebuilding a parallel routing register.
Asset ownership mapping
The asset ownership mapping workflow supplies the asset-to-owner mapping the routing engine reads against; routing decisions on findings whose asset is not in the mapping land on the unassigned-finding queue.
Scanner-side routing discipline
The scanner finding routing and owner assignment guide covers the structural conditions on scanner output (six routing fields, recurring detection inheritance, unowned-finding controlled queue) that let the routing rule fire defensibly across native and imported scans.
Vulnerability intake
The vulnerability finding intake workflow delivers normalised findings with the source class, the severity band, the asset binding, and the provenance the routing engine reads against on the open-state transition.
State lifecycle
The state lifecycle workflow records the open-to-in_progress transition the routing decision produces and reads the owner-of-record field at every subsequent state change.
SLA management
The SLA management workflow reads the acknowledgement window against the routing policy and surfaces SLA breach signals when the routing has resolved the owner but the owner has not yet accepted the work.
SLA-breach escalation
The SLA-breach escalation workflow picks up where the routing escalation ladder ends and routes breached findings to the named escalation owner under the workspace RBAC.
Prioritisation
The prioritisation workflow reads the routed-but-unaccepted queue against the asset criticality multiplier to decide which findings the team works first in the operating week.
Scanner-to-ticket handoff
The scanner-to-ticket handoff governance workflow is the downstream discipline that keeps the security finding canonical when the engineering side runs the remediation in a ticketing system.
Asset criticality scoring
The asset criticality scoring workflow supplies the asset-tier multiplier that compresses or extends the acknowledgement window the routing engine applies on critical and tier-zero assets.
Security leadership reporting
The security leadership reporting workflow reads routing telemetry (unowned-queue size, acknowledgement latency, reassignment frequency, escalation rate) as the leading indicators of whether routing is operating against a defined policy.
Buyer audiences for the routing workflow
The ownership and routing workflow serves the operators and leaders responsible for turning a queue of detected vulnerabilities into accountable remediation work. Each audience reads the routing record with a slightly different lens.
Internal security teams
Internal security teams read the routing record as the operating discipline that keeps the queue defensible across many concurrent workstreams.
AppSec teams
AppSec teams read the routing record as the source-class-aware workflow that channels SAST, SCA, DAST, and manual review findings into the right engineering owner with the right triage step in front of them.
Vulnerability management teams
Vulnerability management teams read the routing record as the operating queue they triage, drive, and escalate across the operating week.
Security operations leaders
Security operations leaders read the routing telemetry as the leading indicator that distinguishes a routed queue from a stalled one before leadership reads the breach in the monthly report.
GRC and compliance teams
GRC and compliance teams read the routing record as the chain ISO 27001 Annex A 5.2 and A.8.8, SOC 2 CC1.3 and CC7.1, and PCI DSS 12.1 cite as evidence for assigned roles and responsibilities.
CISOs and security leaders
CISOs read the routing telemetry as the leading indicator of whether the vulnerability programme has a defined operating policy or a shared inbox absorbing the edge cases.
Security program managers
Security program managers read the routing record as the cross-team accountability layer the programme plan depends on to keep workstreams moving against named owners.
Product security teams
Product security teams read the routing record as the disclosure and PSIRT-adjacent intake discipline that channels third-party reports through the named triage role before they reach the engineering team.
Platform engineering teams
Platform engineering teams read the routing record as the cross-team coordination layer for findings on shared platform services and shared dependencies.
Frequently asked questions
What is security finding ownership and routing?
Security finding ownership and routing is the operational workflow that decides who owns each vulnerability finding, how the finding reaches that owner, and how unowned findings are escalated. Ownership is the named user (or named role) accountable for the remediation work. Routing is the decision logic that maps each new finding to the right owner based on the asset binding, the source class, the severity band, the engagement type, the asset criticality, and the cross-team scope. The workflow lives on the workspace finding record so every assignment, reassignment, escalation, and acknowledgement is captured on the activity log rather than improvised in chat.
How is ownership different from asset-to-owner mapping?
Asset-to-owner mapping is the data primitive: a record that says asset X belongs to team Y with named owner Z and named successor W. Ownership and routing is the workflow that reads the mapping and decides which finding goes to which owner under the workspace policy. The mapping answers "who owns this asset"; the routing engine answers "given this finding on this asset, with this severity and this source class, who picks up the work and how long do they have to acknowledge before the routing escalates". Asset-to-owner mapping is the input the routing engine reads against. Both run on the workspace record and both produce evidence the audit can read by line.
Why does routing need to consider source class and severity in addition to asset?
Asset binding alone is not sufficient. A critical-severity scanner finding on a regulated system should not arrive on an engineer queue without security context; it needs the AppSec or security operations triage role to validate the scanner output before the remediation work begins. A medium-severity SCA finding on a connected repository should not go through a manual triage queue because the routing engine can map the affected dependency directly to the named code owner on the repository connection. Source class drives the triage step; severity drives the acknowledgement window and the escalation tier; asset binding drives the destination owner. The three together produce a routing decision that matches the operating reality of an enterprise vulnerability management programme.
How does the routing engine handle unowned findings?
Unowned findings are findings whose asset binding cannot be resolved to a recorded owner. They land in the unassigned-finding queue, not in a default-assignee tail. The named security operations or GRC operator who reads this queue investigates the asset, updates the asset-to-owner mapping on the engagement metadata, and releases the finding into routing. The unassigned-finding queue is a programme metric the leadership pack reads against the routing-discipline indicator. A growing unassigned queue is a signal that the asset-to-owner mapping is drifting; a flat unassigned queue is a signal that the mapping is current. The catch-all rule that quietly routes unowned findings to one named user is the failure mode this discipline replaces.
What happens when the named owner does not acknowledge within the documented window?
The acknowledgement-pending queue surfaces every finding whose owner has not accepted within the workspace policy window. Critical findings on tier-zero assets carry hour-scale acknowledgement windows; high findings carry one to two business day windows; medium and low findings carry longer windows tied to the standard remediation tier. When the window expires, the routing escalates to the named secondary on the workspace policy and, depending on the severity-tier mapping, to the named escalation owner under the workspace RBAC. The escalation event lands on the activity log with the prior owner, the secondary, the elapsed time, and the routing rule that triggered the escalation so the chain reads as a defined ladder rather than a heroic save.
How are reassignments recorded?
Every reassignment is an explicit event on the finding record. The activity log captures the prior owner, the new owner, the reassigning actor, the timestamp, the routing rule cited (or the documented manual override), and the rationale (asset moved to a different business unit, prior owner departed, scope changed, severity recalibrated, exception applied). The reassignment event survives a successor analyst, a successor security operations lead, and a later audit lookback. A reassignment that does not land on the record is a routing-policy violation and shows up on the routing-policy-violation queue alongside assignments that bypassed a documented rule.
How does routing work for shared assets and cross-team findings?
Assets shared across teams (a shared platform service, a shared dependency, a shared cloud subscription, a multi-team application) carry a multi-owner mapping on the engagement metadata. The mapping records the named lead owner under whom the finding routes and the named coordinating-committee members who receive read notifications. Findings on shared assets do not bounce between owners because the lead-owner role is explicit and the coordinating reads are visible. The cross-team coordination queue surfaces every finding on a shared asset with the lead-owner acceptance status so a finding cannot stall in a tribal "who owns the version" debate.
Who has the authority to assign and reassign findings?
Team management role-based access control governs assignment authority. The workspace owner and admin roles can write the routing policy and define the escalation chain. Members can assign and reassign findings within the policy. Viewers can read the routing record but cannot change ownership. The named security operations lead is typically an admin or a member with elevated workspace access. The role each actor held at the time of the assignment is recorded on the activity log so a later role change does not erase the historical attribution. RBAC plus the activity log together produce an authority chain the audit cycle reads as evidence.
How does the assignment notification reach the owner?
When a finding is assigned to a workspace user (via the assigned_to field with the user email), the platform records the assignment event on the activity log, looks up the assigned user profile, verifies the user has access to the workspace, and pushes a notification into the user inbox. The named owner sees the assignment without depending on chat or email forwards. If the assigned user does not have a profile on the workspace (an out-of-org email, a service account, an inactive user), the assignment is rejected at the workflow level and the routing engine surfaces the missing user in the routing-policy-violation queue. Notifications and the activity log together make the assignment observable rather than silent.
Does the workflow require integration with engineering ticketing systems?
No. The ownership and routing engine runs on the workspace finding record itself. Assignment is a field on the finding; the activity log captures every routing event; team management RBAC controls assignment authority; notifications and alerts push the assignment to the named owner. Teams that route findings into engineering ticketing run the scanner-to-ticket handoff governance workflow as a downstream discipline that keeps the security finding canonical while the engineering ticket carries the workstream metadata. SecPortal does not ship native Jira, ServiceNow, Slack, SIEM, or SOAR integrations, and the routing workflow does not depend on them.
How it works in SecPortal
A streamlined workflow from start to finish.
Publish the workspace routing policy as a named set of rules
The routing policy lives as a published workspace document the team operates against rather than as analyst discretion. It defines the routing rules per source class (Nessus output, Burp Suite session, authenticated DAST, code scan, manual pentest write-up, third-party disclosure, customer report), per severity band (critical, high, medium, low), per asset tier (tier-zero regulated, tier-one revenue-critical, tier-two customer-facing, tier-three internal), and per engagement type (pentest, vulnerability assessment, ISO 27001 audit, SOC 2 readiness, bug bounty intake, security review). Each rule names the routing action and the acknowledgement window so the operating cadence reads consistent across engagements.
Resolve the asset binding to the named owner of record before routing
A finding lands on the queue from intake with the asset binding, the source class, the severity band, and the engagement context. The routing engine reads the asset-to-owner mapping (supplied by the asset ownership mapping workflow) to resolve the named owner of record. If the asset binding cannot be resolved (a new application not in the mapping, a shared service without a recorded lead owner, an external surface the workspace cannot remediate), the finding lands on the unassigned-finding queue rather than on a default-assignee tail.
Apply the source-class triage step before the remediation owner receives the work
High-severity scanner findings on regulated systems route through the AppSec or security operations triage role before reaching the asset owner so the scanner context is validated and the finding is calibrated against the false-positive history. Bug bounty submissions and third-party disclosures route through the disclosure triage role first. Code-scan findings on connected repositories route directly to the named code owner because the source class already carries the engineering context. The source-class triage step lives on the routing policy as an explicit decision rather than an analyst habit.
Assign the finding with the routing rule cited on the activity log
The assignment writes the assigned_to field on the finding to the named workspace user, stamps the activity log with the routing rule cited, the actor performing the assignment, the prior owner (none, for new findings), the new owner, the routing rationale, and the timestamp. The platform looks up the assigned user profile, verifies workspace access, and pushes a notification to the user inbox so the assignment is observable rather than silent. Assignments to a user without a workspace profile fail at the workflow level and land on the routing-policy-violation queue.
Read the acknowledgement window against the workspace policy
Each severity band carries a documented acknowledgement window: hours for critical findings on tier-zero or tier-one assets, one to two business days for high findings, longer windows for medium and low findings. The acknowledgement-pending queue surfaces every finding whose named owner has not yet accepted within the window. The escalation rule is on the workspace policy: at the half-window mark the routing notifies the secondary owner; at window expiry the routing escalates to the named escalation owner under the workspace RBAC. The chain reads as a defined ladder, not a heroic save.
Record reassignments as explicit events with rationale and routing rule
Assets move between teams, owners depart, scopes change, severity recalibrations happen, exceptions apply, regressions reopen findings. Every reassignment is an explicit event on the finding record. The activity log captures the prior owner, the new owner, the reassigning actor, the routing rule cited (or the documented manual override), the rationale, and the timestamp so the routing chronology survives a successor analyst and a later audit lookback. Reassignments without a recorded rationale show up on the routing-policy-violation queue.
Coordinate cross-team findings through the named lead owner
Findings on shared assets (a shared platform service, a shared dependency package, a shared cloud subscription, a multi-team application) carry a multi-owner mapping. The routing engine reads the lead-owner role on the mapping and notifies the named coordinating-committee members with read access. The cross-team coordination queue surfaces every finding on a shared asset with the lead-owner acceptance status so the routing does not stall in a tribal who-owns-it debate. The lead-owner accepts on behalf of the coordinating committee; reassignment between coordinating members is an explicit event.
Read the routing record against the activity log on every audit cycle
The activity log captures every assignment, reassignment, acknowledgement, escalation, and routing-policy violation event with the prior owner, the new owner, the actor, the routing rule, the rationale, and the timestamp. ISO 27001 Annex A 5.2 and A.5.3 and A.8.8, SOC 2 CC1.3 and CC2.2 and CC7.1 and CC8.1, PCI DSS 12.1 and 12.4 and 6.3.1, NIST 800-53 PM-2 and PM-29 and RA-5, NIST CSF 2.0 GV.RR and RS, and CIS Controls v8.1 control 7 read the routing record as evidence the programme assigns and operates roles and responsibilities for vulnerability remediation. CSV export of the activity log delivers the routing chronology auditors cite by line.
Features that power this workflow
Vulnerability management software that tracks every finding
Collaborate across your entire team
Notifications and alerts for the people who carry the work
Every action recorded across the workspace
Orchestrate every security engagement from start to finish
Compliance tracking without a full GRC platform
Multi-factor authentication on every workspace
AI-powered reports in seconds, not days
Bulk finding import bring your scanner data with you
Route every finding to a named owner with a documented routing rule
Ten deterministic routing rules, eight operating queues, an acknowledgement-and-escalation ladder, and an activity log that captures every assignment, reassignment, and escalation. Start free.
No credit card required. Free plan available forever.