Security Finding Routing Rule Economics

Routing rules are a programme asset with a maintenance curve

The routing primitive on the platform records the named owner, the secondary watcher, and the timestamped activity-log entry. The rule library that produced the assignment lives in the programme operating model. The platform stores the output and the chain of custody; the security organisation maintains the rules. The asset value of the rule library is the share of findings that land on the right named owner without manual intervention multiplied by the cycle time the auto-routing saves. The asset cost is the per-cycle maintenance hours required to keep the library producing that throughput at acceptable accuracy.

Reading the asset value against the asset cost converts the rule-library question from "we should probably add a rule for this" into a sized decision. The decision frame asks: what coverage does the current library produce, what accuracy does it hold, what does it cost to maintain at the current rule count, and where does the curve break against any further addition without a refactor first. The finding ownership and routing use-case covers the operating loop the rule library runs against; this research prices the library that the loop consumes.²³

Programmes that argue routing from anecdote add a rule each time a finding routes to the wrong owner, never retire rules, and accumulate exceptions instead of refactoring. Programmes that argue routing from economics size the library against the inflow shape, refactor when the curve approaches its break, retire rules whose fire count drops below a threshold, and read the rule library against the activity log on a named cadence. The two postures look identical at small programme sizes and diverge sharply at scale.

Rule libraries sit in recognisable size bands

Defensible rule libraries fall into observed shapes across enterprise programmes. The shape is not a target. It is what the routing primitive produces when the accuracy is acceptable, the maintenance is bounded, and the audit walkthrough reads the rule provenance cleanly. Programmes that grow the library past these bands without refactoring usually pay a maintenance tax that exceeds the manual-routing tax the library was meant to eliminate.^3,4

The boundary between bands is not the rule count alone. It is the maintenance shape: at what point does the per-cycle micro-review stop fitting inside a single triage analyst's normal hours; at what point does the per-quarter focused review require a dedicated time block; at what point does the per-engagement boundary review need its own scheduling. Programmes that track the maintenance shape rather than the rule count usually see the next band approaching before they hit it.

Three named break points on the curve

The rule library curve has three named break points. Each break sits at a different rule count band, each shows in a different operational signal, and each requires a different response. Programmes that read all three breaks at once and refactor when any one binds preserve routing throughput without paying the unbounded maintenance tax.^3,5,8

The three breaks compound. A library that has hit the coverage break but is being grown through new rules usually starts overlapping with itself within a quarter. A library that has hit the accuracy break but is being maintained without refactoring usually loses cadence within two quarters. A library that has hit the maintenance break is usually being held together by exception register accumulation that no operator can defend at the next walkthrough. Reading the three breaks at once is how the programme decides whether the next rule is worth adding or whether the next move is a refactor.

Six ageing mechanisms that erode a rule library

Rules age. The ageing is structural rather than accidental: each mechanism comes from a real programme change that has happened since the rule was written. The mechanisms repeat across enterprise programmes and each shows in the routing-accuracy reading before it shows in the headline closure rate.^3,4,6

• Organisation drift. Named owner team or person no longer exists; responsibilities have shifted; legacy team identifier persists in the rule output. The rule produces a stale owner and the finding routes to an empty queue.
• Scope drift. The application or product surface the rule was written for has been decommissioned, sold, refactored into a different finding class, or absorbed into a different team. The rule still matches inputs but the matched scope no longer exists.
• Signal drift. The scanner-pack changed how the finding class is labelled, the severity-band threshold moved after a vendor recalibration, or the engagement-class field is sourced from a different programme record. The rule input criteria no longer represent what they did when the rule was written.
• Severity drift. The finding class was high-severity by default when the rule was written; the severity has been recalibrated to medium; the rule still routes everything in the class to the named high-severity owner.
• Inheritance drift. The rule was written when recurring findings inherited the prior-cycle owner; the inheritance pattern has changed; the rule now produces conflicting outputs with the inheritance primitive.
• Exception accumulation. The rule was correct when written; ten exceptions have been added since to cover edge cases the rule did not anticipate; the exception list is now larger than the rule and the maintenance has moved from the rule itself to the exception register.

Each mechanism is recoverable. Recovery is what the per-cycle micro-review and the per-quarter focused review exist for. Programmes that run both reviews against the activity log and the exception register usually catch the ageing inside one or two cycles. Programmes that run only the headline closure rate usually catch the ageing two to four quarters after it has compounded into routing-accuracy decay. The ownership decay research reads the downstream consequence of stale-owner routing as a single-owner phenomenon; the rule-library angle reads the upstream cause that produces the stale-owner field at scale.²⁷

Seven failure modes on the live record

The seven routing-rule failure modes are predictable and observable on the live record. Each shows in the activity-log timestamps and the named-owner field, often well before it shows in the closure-rate trend. Reading the seven failure modes as a named checklist on a cadence is what catches rule-library decay before it shows in the audit walkthrough.^3,4,13

1. Stale-owner routing. Rule produces a named owner who no longer exists; finding routes to inactive reference; activity log timestamps the assignment but no acknowledgement event follows.
2. Overlapping-rule conflict. Two rules match the same input combination with different owners; the routing primitive picks the rule with higher priority but the priority order itself is opaque to operators; both candidate owners disclaim ownership at the next walkthrough.
3. Catch-all dependency. The library has no terminal catch-all, or has a catch-all that routes to a generic intake queue without an active owner; unrouted findings dwell in the new state until a manual sweep.
4. Severity-band reroute drift. The rule was written before a vendor severity recalibration; the severity band that now triggers the rule does not match the original routing intent; the rule routes lower-priority work to the high-severity owner.
5. Inheritance loop on recurring findings. The rule and the inheritance primitive disagree on which owner should hold the recurring detection; the finding bounces between two owners across cycles.
6. Engagement-scope leak. The rule was written for one engagement class but matches an adjacent engagement class with the same finding class identifier; findings route to an unrelated owner outside the engagement scope.
7. Exception-register surrogacy. The rule has been overridden so many times that the active routing decision lives in the exception register rather than the rule library; the rule cadence reviews the rule and concludes it is healthy while the exception register holds the actual decisions.

Each failure mode is recoverable through review. None of them is recoverable through more rules. Adding a rule to fix stale-owner routing does not address the underlying organisation drift; adding a rule to fix overlapping conflict usually compounds the conflict; adding a rule to fix exception-register surrogacy usually adds an exception of its own. The defensible response to each failure mode is rule retirement, rule refactoring, or exception register reconciliation rather than rule library expansion.

A four-track review cadence keeps the library current

The realistic cadence is four tracks. Each track has a different scope, a different participant set, and a different output. The four tracks together keep the rule library aligned to the operating model without the cadence itself becoming a programme-shaped maintenance burden.^3,4,6,7

The cadence reads the activity log on each track. Without the activity log, none of the tracks can identify which rules fired, how often, with what acknowledgement-rejection rate. The activity-log feature supplies the timestamped chain of every assignment and acknowledgement event with retention that supports quarterly and annual lookback. The cadence reads findings management for the named-owner field and the input criteria the rules reference, and reads finding overrides for the exception register depth.

A defensible routing rule artefact has seven fields

The artefact below is what audit walkthroughs expect from each rule. Each field has a separate failure mode when absent. Programmes that document only the rule identifier and the named output owner usually fail at audit walkthrough because the input criteria, the effective period, and the approver chain cannot be reconstructed from the live record alone.^2,3,6,7

At audit walkthrough, the assessor reads a routing decision off the activity log, looks up the rule identifier, verifies the rule was effective at the time of the decision through the effective period, traces the approver chain through the provenance field, and confirms the output owner has the documented authority for the routing intent. A library where every rule carries the seven fields produces a clean walkthrough. A library where rules carry only the identifier and the output produces a walkthrough that ends with the auditor asking for the rule library to be reconstructed from operator memory.

Per-rule maintenance hours size the library against the team

Sizing reads against per-rule maintenance hours, not against rule count. Per-rule hours hold roughly steady across well-maintained libraries; the cycle work and the periodic review work both scale with rule count plus a fixed cost per rule for the artefact maintenance. The hours below are observed steady-state values for stable enterprise programmes; new programmes and programmes in heavy reorganisation usually carry higher per-rule hours until the underlying patterns stabilise.^3,5,8

• Small library (under 30 rules): 0.5 to 2 maintenance hours per rule per quarter; total quarterly load is bounded; one triage analyst carries the library as part of normal duties.
• Medium library (30 to 100 rules): 0.3 to 1.5 hours per rule per quarter; total load justifies a dedicated time allocation but not a dedicated FTE; a vulnerability management lead or senior triage analyst owns the library.
• Large library (100 to 300 rules): 0.2 to 1 hour per rule per quarter; total load typically requires a named owner who carries routing as one of their primary programme responsibilities; the role pairs with the staffing economics frame as a recognised programme role.²⁸
• Very large library (300-plus rules): programmes either refactor down through rule consolidation, or accept the maintenance load as a multi-FTE responsibility and budget for it explicitly; without explicit budget, the library drifts into the maintenance break within two to four quarters.

The hours include the per-cycle micro-review, the per-quarter focused review, the per-engagement-boundary review, the scanner-pack response, the exception-register reconciliation, and the audit walkthrough preparation. Programmes that argue routing maintenance is a free side-effect of triage usually end up with stale libraries and routing decisions that no operator can defend at the next walkthrough.

Multi-team and multi-region programmes use a two-layer library

Multi-team programmes pay routing tax in two dimensions: the team-count dimension (each additional named team adds routing-output branches and adds intra-team naming maintenance) and the team-overlap dimension (each pair of teams that shares a finding-class surface adds a tiebreak rule). Multi-region programmes add a third dimension: regional ownership of shared finding classes. The defensible response is a two-layer rule library.^3,4,13

• Global layer. Finding-class and severity-band patterns shared across regions and business units; the same input combination produces the same output across the programme. The global layer absorbs the bulk of routing volume with a small bounded rule count.
• Regional or per-LOB overlay. Region-specific or LOB-specific named owners; reads on top of the global layer and substitutes the regional named owner where applicable. Regional change rolls through the overlay rather than rewriting the global layer.

The two-layer structure keeps the global rule count bounded and concentrates regional maintenance where regional change actually happens. Programmes that flatten into one global library without the overlay tend to grow the rule count past 500 entries with high overlap and low first-time-accuracy. The cross-team ownership transfer latency research covers the latency consequence when the layered library is misaligned; this research prices the layered design that prevents the latency from compounding.²⁵

Recurring detections inherit; the rule library overrides only when needed

Recurring detections (findings that fire repeatedly against the same target over consecutive scan cycles) usually inherit the prior-cycle owner; the inheritance primitive overrides the rule library on those findings to preserve continuity. The interaction matters because the rule library and the inheritance primitive can disagree, and the disagreement needs an explicit policy. The defensible pattern reads the inheritance primitive first on a recurring detection, the rule library second only when the inherited owner is no longer valid.^3,4

The named conditions where the rule library overrides inheritance are limited and explicit: the team that owned the prior-cycle detection has disbanded; the named person has left the workspace; the scope has rotated to a different engagement; the severity recalibration has moved the finding into a different owner's scope; a new policy artefact has changed the routing intent for the finding class. Outside those conditions, the inheritance primitive holds and the activity log records the inheritance event against the original rule identifier that produced the initial assignment.

Programmes that route every cycle of a recurring detection through the rule library without honouring inheritance usually produce ownership churn that disguises real ownership decay. Programmes that honour inheritance indefinitely without checking the inherited owner against the rule library usually produce silent stale-owner routing that fails at the next walkthrough. Reading the two together is what keeps the audit trail intact across cycles.

Rules retire in three named cases

Retirement is not deletion. Retired rules carry a retired-state flag and a retirement-rationale field; the rule definition stays available so audit walkthroughs covering historical periods can reconcile decisions to the rules that existed at the time. The retirement record is part of the rule provenance chain rather than a removal event.^2,3,6

• Coverage retirement. The rule fires fewer than a threshold count per quarter for two consecutive quarters; the finding pattern the rule was written for no longer occurs at meaningful volume; the rule moves to an archived state.
• Refactoring retirement. The rule is absorbed into a parameterised rule that covers a broader pattern; the original rule is retired and the audit-citation map is updated to reference the new rule.
• Owner-scope retirement. The named team or person the rule routes to has been retired; the rule is either reassigned to the inheriting team or retired if the work no longer exists.

Programmes that retire rules on a cadence keep the library size aligned to the inflow shape rather than the cumulative addition history. Programmes that only add rules and never retire them usually drift past the maintenance break within four to eight quarters depending on inflow volume and programme stability.

Five numbers for the leadership routing report

Five numbers communicate routing health to leadership without requiring operational depth. Reporting the five alongside the inflow-and-closure trend gives leadership the routing question, the maintenance question, and the curve-break signal on one record. The numbers are produced from the activity log, the findings management record, and the exception register; no extra instrumentation is required.^3,4,9,11

Reporting the five numbers on a per-quarter rhythm alongside the operating cadence gives leadership a sized read on the routing surface. Reading the state-machine throughput decomposition research alongside the five routing metrics lets the programme see where the transition bottleneck is and whether the routing rule layer is producing the bottleneck or absorbing it cleanly.²⁹

Framework citations read the routing surface at three points

Enterprise frameworks do not name routing rule economics directly. They name the underlying expectations the rule library implements: documented role and responsibility allocation, documented approver authority, and periodic role review. Routing rule economics prices the rule library so the per-rule review cadence stays operable and the audit citation reads against a library whose provenance is intact.^1,2,3,4,6,7

• ISO 27001:2022 Annex A 5.2. Documented allocation of information security roles and responsibilities; the rule library output owner field reads against this surface, and the per-rule provenance chain reads against the documented-approval expectation.
• NIST CSF 2.0 GV.RR. Roles, responsibilities, and authorities with documented separation of duties; the rule library is the operating realisation of GV.RR for finding routing specifically.
• NIST SP 800-53 Revision 5 PM-2. Senior agency information security officer with documented authority; the rule provenance chain that traces back to a named approver reads against this surface.
• PCI DSS v4.0 Requirement 12.5. Documented security responsibilities for cardholder data environment in-scope roles; the rule library routing findings affecting the CDE reads against this surface where applicable.
• DORA Article 5. ICT governance and organisational framework with named senior management responsibility; the rule provenance and the per-quarter review cadence read against this surface for in-scope financial entities.
• CIS Critical Security Controls v8.1 Safeguard 17.1. Designated personnel and explicit routing for incident and finding response; the named-owner field and the routing rule output read against this safeguard for IG2 and IG3 programmes.

The pattern across frameworks is the same: named documented allocation, named approver authority, periodic review record. Routing rule economics is the discipline that keeps all three observable on the rule library cadence; without the discipline, the framework citations are aspirational rather than operational.

How SecPortal supports the routing rule economics surface

SecPortal keeps the per-finding routing output, the named-owner field, the activity log, and the override register on one workspace record so the rule economics measurements read against the same data the operating cadence runs against. The platform stores the output of every rule and the chain of custody around every assignment; the security organisation maintains the rule library against that record.^{15,16,17,18,19,20,21,22}

• Findings management holds the named-owner field, the severity record, the finding-class identifier, and the engagement reference that the rule library reads as inputs. The same record carries the rule-output owner field on every finding the rule library has touched.
• Team management with RBAC supplies the workspace user catalogue (owner, admin, member, viewer, billing roles) that the rule-output owner field references; departed staff surface as inactive references rather than as silent stale data; the role assignments support the documented-allocation surface frameworks read against.
• Activity log with CSV export captures the timestamped chain of every owner assignment, owner change, and acknowledgement event with 30, 90, or 365 day retention depending on plan. The log supplies the auto-routed share, the first-time-accuracy share, the per-rule fire pattern reconstruction, and the per-handoff latency the leadership report reads.
• Engagement management binds the finding to the originating engagement so per-engagement routing patterns are reproducible against the same record. The lead role can read the routing impact of each engagement class separately.
• Finding overrides hold the eight-field exception decision chain for routing exceptions that need explicit authority and rationale. The exception register stays auditable and the per-quarter focused review reads against the same record.
• Compliance tracking maps the routing-related framework citations (ISO 27001 A.5.2, NIST CSF 2.0 GV.RR, NIST SP 800-53 PM-2, PCI DSS 12.5, DORA Article 5) so the routing review reads against the same crosswalk the audit interface uses.
• Notifications and alerts route assignment events to the named owner so the acknowledgement-rejection signal is observable in the lifecycle log and the per-cycle micro-review has the data it needs.
• MFA TOTP enforcement on the workspace provides authentication assurance on the named-owner field that the audit citation reads against.
• AI reports can summarise the auto-routed share, the first-time-accuracy share, the per-rule fire pattern, and the exception register depth for the leadership routing read.
• Finding comments and collaboration supplies the secondary-watcher and witness conversation surface for fan-out rules; the watcher list stays attached to the finding rather than living in shadow channels.

What the platform does not do is also part of the routing design. SecPortal does not author the rule library, does not enforce a specific routing taxonomy, does not auto-route based on inferred policy, does not integrate with HR systems to validate named owners, does not push to ticket systems, Slack, Teams, PagerDuty, or workforce-management platforms, does not validate that the rule library matches the engineering organisation chart, and does not enforce maintenance budget on the library. Those decisions and validations belong to the security organisation operating the rule library. The platform keeps the per-finding ownership trail, the activity log, and the override register on one record so the rule economics question is reproducible at any moment between cycles.

Read against the rest of the SecPortal research library, routing rule economics is the design and maintenance layer of a wider operational discipline. The finding ownership and routing use-case covers the operating loop the rule library produces output for; the scanner-side routing and owner assignment discipline covers the data-shape inputs the rule library reads; the cross-team ownership transfer latency research covers the latency consequence when the rule library is misaligned; the ownership decay research covers the downstream effect of stale-owner routing on the per-finding record; the mean time to assignment economics research covers the headline MTTA metric that the auto-assignment effectiveness and routing-rule fall-through rate read against from this library. Reading the surfaces together produces a programme whose routing decisions are reproducible against the same record the operational cadence runs against, and whose audit-committee answer to the routing question reads against a library whose provenance is intact.^23,24,25,27

Frequently asked questions

Sources and further reading

1. ISO/IEC, ISO 27001:2022 Information Security Management Systems
2. ISO/IEC, ISO 27002:2022 Information Security Controls Annex A 5.2 Roles and Responsibilities
3. NIST, SP 800-53 Revision 5 Security and Privacy Controls (PM-2, PM-9, RA-5)
4. NIST, Cybersecurity Framework (CSF) 2.0 with GV.RR Roles, Responsibilities, and Authorities
5. NIST, SP 800-40 Rev. 4 Guide to Enterprise Patch Management Planning
6. PCI Security Standards Council, PCI DSS v4.0 Requirement 12.5 Security Responsibilities
7. European Union, Digital Operational Resilience Act (DORA) Article 5 ICT Governance
8. OWASP, Software Assurance Maturity Model (SAMM) Operations Practices
9. FIRST, Common Vulnerability Scoring System (CVSS) Specification
10. FIRST, Exploit Prediction Scoring System (EPSS)
11. CMU SEI, Stakeholder-Specific Vulnerability Categorization (SSVC)
12. CISA, Binding Operational Directive 22-01 Known Exploited Vulnerabilities (KEV) Catalog
13. CIS, Critical Security Controls v8.1 (Safeguard 17.1 Designated Personnel and IG2 Routing)
14. NIST, SP 800-137 Information Security Continuous Monitoring (ISCM)
15. SecPortal, Findings Management
16. SecPortal, Team Management and RBAC
17. SecPortal, Activity Log
18. SecPortal, Engagement Management
19. SecPortal, Finding Overrides
20. SecPortal, Compliance Tracking
21. SecPortal, AI Reports
22. SecPortal, Notifications and Alerts
23. SecPortal Use Cases, Security Finding Ownership and Routing
24. SecPortal Scanner Info, Scanner Finding Routing and Owner Assignment
25. SecPortal Research, Cross-Team Finding Ownership Transfer Latency
26. SecPortal Research, Security Engineering Handoff Latency
27. SecPortal Research, Security Finding Ownership Decay
28. SecPortal Research, Vulnerability Program Staffing and Throughput Economics
29. SecPortal Research, Vulnerability State Machine Throughput Decomposition