Security Finding Routing Rules Design Worksheet twelve sections that turn the routing rule library from analyst memory into a versioned design artefact the audit walkthrough reconstructs from
A free, copy-ready design worksheet for AppSec leads, heads of vulnerability management, security engineering leads, cloud security leads, product security leads, platform engineering partners, GRC and compliance teams, internal security teams, and CISOs. Twelve structured sections covering document control and version history, programme scope and rule library boundary, routing inputs and data-shape contract, rule catalogue with per-rule design block, default and fallback routing with the unowned-finding queue and the routing-policy-violation queue, multi-team and shared-asset routing rules with the routing-conflict tie-breaker, source-class triage routing before remediation owner, severity-band and asset-tier window compression, reassignment and prior-owner handover with the named rationale taxonomy, rule versioning and review cadence with per-cycle micro-review and per-quarter focused review and annual full review and named amendment triggers, audit walkthrough preparation with the framework crosswalk and per-rule audit-pack, and known failure modes with structural fixes. Aligned with ISO/IEC 27001:2022 Annex A 5.2 and A.8.8 and Clause 5.3, SOC 2 CC1.3 and CC2.2 and CC7.1 and CC8.1, NIST CSF 2.0 GV.RR and DE.AE and RS.MI and PR.IR, NIST SP 800-53 PM-2 and PM-29 and RA-5 and SI-2 and CA-7, PCI DSS 12.1 and 12.4 and 12.5 and 6.3.1, CIS Controls v8.1 Control 7 and 17, NIS2 Article 21, DORA Article 5 and Article 9, and HIPAA 164.308.
Run the rule library against the live workspace record, not against a static document
SecPortal pairs the versioned routing rules design worksheet to a programme engagement record so the per-rule design block, the per-rule fire pattern on the activity log, the routing-policy-violation queue, the unowned-finding queue, the reassignment-rationale taxonomy, the framework crosswalk, and the per-quarter focused review minutes all live on one workspace with a named-actor activity log. Free plan available.
No credit card required. Free plan available forever.
Twelve sections that turn routing rules from analyst memory into a defensible design artefact
A security finding routing rules design worksheet is the working artefact a security organisation uses to draft, review, refactor, and version the deterministic mapping that turns each new vulnerability finding into a named-owner assignment on the live record. It is not the vulnerability management policy that codifies operating expectations, not the RACI matrix that names which role is Accountable for each lifecycle step, and not the SLA policy that commits remediation windows. It is the section-by-section design layer the AppSec lead, the head of vulnerability management, the security engineering lead, and the platform engineering partner sit down with to write the rule library, then publish the library as a versioned document the operating record reads against and the audit reconstructs from.
Copy the full worksheet (all twelve sections) as one block.
1. Document control and version history
Open the worksheet with the boundary, the version, and the authority. A reviewer should be able to read in the first lines which programme owns the rule library, when it was last revised, which upstream policy authorises it, and how the version history connects the current library to its predecessors. ISO/IEC 27001 Clause 7.5 expects documented information for the management system with controlled identification, format, and review; the header turns the rule library into a traceable artefact rather than a loose collection of routing decisions.
Rule library identifier (cross-referenced from the vulnerability management policy, the RACI, the SLA policy, and the operating record): {{RULE_LIBRARY_IDENTIFIER}}
Rule library name (the name the programme refers to the routing rule library by): {{RULE_LIBRARY_NAME}}
Parent operating record (the workspace programme engagement record the rule library is paired to): {{PROGRAMME_ENGAGEMENT_REFERENCE}}
Current version: {{CURRENT_VERSION}}
Effective date: {{EFFECTIVE_DATE}}
Next scheduled full review date: {{NEXT_FULL_REVIEW_DATE}}
Next scheduled quarterly focused review date: {{NEXT_QUARTERLY_REVIEW_DATE}}
Document classification (per the data classification policy): {{DOCUMENT_CLASSIFICATION}}
Retention period (per the audit evidence retention policy): {{RETENTION_PERIOD}}
Named custodian (the role that maintains the rule library between reviews):
- Role: {{CUSTODIAN_ROLE}}
- Named person at time of publication: {{CUSTODIAN_NAME}}
Named co-owners (the roles that share authority for rule classes):
- AppSec lead (source-class triage routing): {{APPSEC_LEAD_ROLE}}
- Security operations lead (escalation chain and acknowledgement window): {{SECOPS_LEAD_ROLE}}
- Cloud security lead (cloud workload routing): {{CLOUD_SECURITY_LEAD_ROLE}}
- Product security lead (PSIRT-adjacent disclosure routing): {{PRODUCT_SECURITY_LEAD_ROLE}}
- GRC lead (framework crosswalk and audit walkthrough): {{GRC_LEAD_ROLE}}
- Platform engineering partner (asset-to-owner mapping integrity): {{PLATFORM_ENGINEERING_PARTNER_ROLE}}
Upstream chartered authority (the documents that authorise the rule library to exist):
- Vulnerability management programme charter: {{VM_PROGRAMME_CHARTER_REFERENCE}}
- Vulnerability management policy: {{VM_POLICY_REFERENCE}}
- Vulnerability management RACI: {{VM_RACI_REFERENCE}}
- Vulnerability remediation SLA policy: {{VM_SLA_POLICY_REFERENCE}}
- Security exception register reference: {{SECURITY_EXCEPTION_REGISTER_REFERENCE}}
- Risk acceptance form reference: {{RISK_ACCEPTANCE_FORM_REFERENCE}}
Version history (each row carries: version, effective date, summary of change, revision trigger, sign-off references):
- v1.0 {{V1_EFFECTIVE_DATE}}: Initial rule library produced by {{V1_SPONSOR_NAME}}. Trigger: programme founding. Sign-off references: {{V1_SIGN_OFF_REFERENCES}}.
- v{{VN_VERSION}} {{VN_EFFECTIVE_DATE}}: {{VN_CHANGE_SUMMARY}}. Trigger: {{VN_TRIGGER}}. Sign-off references: {{VN_SIGN_OFF_REFERENCES}}.
Revision trigger that produced this version (one of: scheduled annual full review, scheduled quarterly focused review, material asset population change, scanner-stack replacement, organisational reorganisation, post-incident routing-failure root cause, regulatory environment change, audit finding naming the rule library as a control gap):
- {{CURRENT_REVISION_TRIGGER}}
Workspace pairing:
- The rule library is held as a versioned document paired to a programme engagement record through document management.
- The sign-off chain (custodian, named co-owners, accountable operator) is recorded on the workspace activity log with named actor and timestamp.
- The custodian is identified in team management with the role gate applied to amend access.
2. Programme scope and rule library boundary
The scope section names the boundary the rule library applies inside. Without an explicit boundary the rule library is asked to route findings it was never designed to cover, the per-rule fire rate is impossible to read, and the audit walkthrough cannot reconcile coverage. Write scope as four explicit lists: the finding source classes the library covers, the asset classes in-scope, the business units and product lines the routing applies to, and the explicit out-of-scope and shared-responsibility boundaries.
In-scope finding source classes (the named provenance classes the rule library produces routing output for):
- External scanner findings (domain scanner, port and service exposure scanner, public-facing application scanner): {{IN_SCOPE_EXTERNAL_SCANNER_PROVENANCE}}
- Authenticated scanner findings (logged-in application scanner, authenticated network scanner, internal infrastructure scanner): {{IN_SCOPE_AUTHENTICATED_SCANNER_PROVENANCE}}
- Code scanner findings (SAST output, SCA output, secret scanner output): {{IN_SCOPE_CODE_SCANNER_PROVENANCE}}
- Manual security testing findings (pentest write-ups, security review, threat-model output): {{IN_SCOPE_MANUAL_TESTING_PROVENANCE}}
- Bug bounty and external disclosure findings (bug bounty intake, customer disclosure, third-party report, regulator notification): {{IN_SCOPE_DISCLOSURE_PROVENANCE}}
- Internal escalation findings (incident response output, internal security audit, internal red team): {{IN_SCOPE_INTERNAL_ESCALATION_PROVENANCE}}
In-scope asset classes (the asset categories the routing applies across):
- External attack surface: {{IN_SCOPE_EXTERNAL_ATTACK_SURFACE}}
- Public-facing web applications and APIs: {{IN_SCOPE_WEB_AND_API}}
- Internal corporate IT and identity systems: {{IN_SCOPE_CORPORATE_IT}}
- Cloud control plane and workloads: {{IN_SCOPE_CLOUD_PLATFORM}}
- Container registries and runtime: {{IN_SCOPE_CONTAINER}}
- Code repositories and dependencies: {{IN_SCOPE_CODE_AND_DEPENDENCIES}}
- Mobile applications: {{IN_SCOPE_MOBILE}}
- IoT or OT systems (where applicable): {{IN_SCOPE_IOT_OT}}
In-scope organisational scope (the business units, product lines, geographies the routing applies to):
- Business units: {{IN_SCOPE_BUSINESS_UNITS}}
- Product lines: {{IN_SCOPE_PRODUCT_LINES}}
- Geographies and regions: {{IN_SCOPE_GEOGRAPHIES}}
- Acquisition entities under operating integration: {{IN_SCOPE_ACQUISITION_ENTITIES}}
Explicitly out-of-scope (finding sources or asset classes the rule library does not produce routing output for):
- {{OUT_OF_SCOPE_LIST}}
Shared-responsibility boundaries (where the routing intersects a different operating discipline):
- Findings against managed-service vendor surfaces (route through the vendor management programme): {{VENDOR_SURFACE_BOUNDARY}}
- Findings against jointly-operated joint-venture systems (route through the named JV operating model): {{JOINT_VENTURE_BOUNDARY}}
- Findings against customer-managed environments (route through the customer disclosure pathway): {{CUSTOMER_MANAGED_BOUNDARY}}
- Findings against research lab or sandbox environments isolated from production (route to the research operating lead): {{RESEARCH_SANDBOX_BOUNDARY}}
Programme scale band the rule library is sized against (one of: small programme low hundreds of findings per week and three to five business units; medium programme low thousands of findings per week and five to fifteen business units or product lines; large programme tens of thousands of findings per week and fifteen-plus product lines; very large programme multi-region multi-LOB):
- {{PROGRAMME_SCALE_BAND}}
Target rule count band the design targets for this version (informed by the programme scale band):
- {{TARGET_RULE_COUNT_BAND}}
3. Routing inputs and data-shape contract
Routing rules are deterministic mappings from input fields on the finding record to a named-owner output. The six structural inputs are workspace contract that every rule reads against; if the input data shape drifts, every rule that depends on it produces silent misroutes. Section 3 catalogues the six inputs, names the data shape each must carry, and names the operating discipline that keeps the inputs reliable. The catalogue is the contract between the finding record and the rule library.
Input 1: Finding class identifier
- Definition: The canonical class the finding belongs to, drawn from the workspace finding template library and the imported scanner output (web application class, infrastructure class, cloud configuration class, dependency class, code-side static class, secret class, authenticated network class, container image class, mobile class, identity class).
- Data-shape contract: One canonical class identifier per finding, never null, never multi-valued; finding-template provenance recorded on the engagement reference.
- Operating discipline that keeps it reliable: The bulk finding import workflow normalises imported scanner output against the finding template library; the source-class triage role validates ambiguous class assignment at intake.
Input 2: Target asset reference
- Definition: The named asset on the finding (host, application, repository, cloud resource, dependency package, identity) that the routing engine reads against the asset-to-owner mapping.
- Data-shape contract: One canonical asset identifier per finding, resolvable against the asset-to-owner mapping, with the engagement record carrying the asset population for the originating engagement.
- Operating discipline that keeps it reliable: The asset-ownership-mapping workflow keeps the asset-to-owner table current; unresolved asset references surface in the routing-policy-violation queue rather than absorbing into a default-assignee tail.
Input 3: Severity band
- Definition: The calibrated severity (the auto-calculated CVSS 3.1 vector on the finding) plus the workspace severity band the vector resolves to (critical, high, medium, low, informational).
- Data-shape contract: One canonical severity band per finding, calibrated against the workspace CVSS configuration, never null at routing time.
- Operating discipline that keeps it reliable: Triage validates calibration before routing executes; severity overrides land on the finding overrides register with named authority and named rationale.
Input 4: Scanner module identifier
- Definition: The named scanner module that produced the finding (Nessus, Burp, OWASP ZAP, authenticated DAST module, Semgrep SAST, SCA dependency module, secret scanner module, manual pentest, third-party report, customer disclosure).
- Data-shape contract: One canonical scanner module identifier per finding, recorded at ingest by the bulk finding import workflow or the engagement record for manual findings.
- Operating discipline that keeps it reliable: The scanner-onboarding-and-coverage-rollout workflow registers each new scanner module against the workspace catalogue before its output is routed.
Input 5: Engagement identifier
- Definition: The originating engagement record the finding is paired to (pentest engagement, vulnerability assessment, ISO 27001 audit, SOC 2 readiness, bug bounty intake, security review, incident response, recurring scheduled scan).
- Data-shape contract: One engagement reference per finding; engagement type carried on the engagement record itself rather than re-keyed on the finding.
- Operating discipline that keeps it reliable: Engagement management holds the canonical engagement metadata; finding intake binds the finding to the engagement at ingest.
Input 6: Prior-cycle owner identifier (used when the finding is a recurring detection)
- Definition: The named owner of the prior closure of the same finding when the new finding is a regression or reopen of a previously closed finding.
- Data-shape contract: One prior-owner reference per recurring finding; null for first-cycle findings.
- Operating discipline that keeps it reliable: The reopen-and-regression-handling workflow restores the prior-owner pointer on reopen events; the activity log carries the prior-closure provenance.
Field-level data quality expectations (each input has to clear before routing fires):
- All six inputs populated for routing to fire deterministically: {{DATA_QUALITY_GATE_DEFINITION}}
- Unresolved inputs queue the finding in the routing-policy-violation queue rather than producing a fallback assignment: {{UNRESOLVED_INPUT_QUEUE_DEFINITION}}
- Per-input data-quality SLA (the cycle in which an unresolved input must be repaired before the queue is escalated): {{DATA_QUALITY_REPAIR_SLA}}
4. Rule catalogue with per-rule design block
Section 4 is the working spine of the worksheet. Each rule sits in its own design block with the condition, the action, the rationale, the expected fire rate, and the retire-by trigger captured at design time. A rule whose rationale is not on the worksheet is a rule the audit walkthrough cannot defend. A rule whose expected fire rate is not on the worksheet is a rule the per-quarter review cannot evaluate. A rule with no retire-by trigger is a rule the library cannot prune from. Copy the per-rule block below for each rule the library carries.
Rule library size band declared for this version (small 8 to 20 rules, medium 30 to 80 rules, large 100 to 300 rules, very large 300 to 500 rules):
- {{DECLARED_RULE_LIBRARY_SIZE_BAND}}
Total rule count this version: {{TOTAL_RULE_COUNT_THIS_VERSION}}
Rules added since last version: {{RULES_ADDED}}
Rules retired since last version: {{RULES_RETIRED}}
Rules refactored since last version: {{RULES_REFACTORED}}
Per-rule design block (repeat the block below for each rule, sequentially numbered):
Rule {{RULE_NUMBER}}: {{RULE_SHORT_NAME}}
- Condition (the input combination the rule matches): {{RULE_CONDITION}}
- Action (the named-owner output the rule produces): {{RULE_ACTION_OWNER}}
- Secondary-watcher output (the named secondary watcher fan-out, if any): {{RULE_ACTION_SECONDARY_WATCHER}}
- Acknowledgement window (the window the named owner has to accept the assignment before escalation fires): {{RULE_ACK_WINDOW}}
- Escalation chain (the named secondary on the workspace policy who receives the routing at the half-window mark, plus the named tertiary escalation owner): {{RULE_ESCALATION_CHAIN}}
- Rationale (the documented reason the rule exists; the audit walkthrough reads this directly): {{RULE_RATIONALE}}
- Evidence pointer (the prior incident, audit citation, post-incident learning, or chartered authority that produced the rule): {{RULE_EVIDENCE_POINTER}}
- Expected fire rate (the number of findings per operating cycle the rule is expected to match; the per-quarter review reads observed against expected): {{RULE_EXPECTED_FIRE_RATE}}
- Retire-by trigger (the observed condition that would retire the rule: matching finding-class proliferation absorbs it, business reorganisation collapses the source, scanner-stack change supersedes the input, the rule has fired fewer than three times in the last two cycles): {{RULE_RETIRE_BY_TRIGGER}}
- Priority rank (the explicit priority order the routing primitive applies if two rules match the same input combination): {{RULE_PRIORITY_RANK}}
- Framework citation (the framework controls the rule produces evidence for; cross-referenced to compliance tracking): {{RULE_FRAMEWORK_CITATION}}
- Author of record (the named co-owner who wrote the rule): {{RULE_AUTHOR_OF_RECORD}}
- Last reviewed (the most recent quarterly focused review date that confirmed the rule remains accurate): {{RULE_LAST_REVIEWED_DATE}}
(Copy the block above for every rule the library carries. Number rules sequentially. Retired rules stay in the document with the retire date and the supersede pointer so the audit walkthrough can reconstruct the chronology rather than reading a sanitised current state.)
Common rule shapes to seed the catalogue (each shape is a starting design; tune to the programme):
- Critical-severity finding on a tier-zero or tier-one asset: route to named primary owner under workspace RBAC with acknowledgement window in hours; parallel notification to security operations lead and engagement lead; escalation to named secondary at half-window mark.
- High-severity finding from an external scanner with asset binding to a regulated system: route through the AppSec or security operations triage role for scanner-output validation, then to the named remediation owner.
- Medium-severity SCA finding 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 on the finding give the engineer the scanner context.
- Code scanner finding (SAST) on a tier-two application: route to the application's named AppSec partner with the application-tier review window.
- Cloud configuration finding on a cloud subscription owned by platform engineering: route to the platform engineering shared-platform owner with the secondary watcher as the cloud security lead.
- Bug bounty disclosure finding pending triage: route to the AppSec triage operator for validation; on confirmation, route to the asset owner of record with the secondary watcher as the AppSec lead.
- Pentest engagement finding: route to the engagement lead; on close-out, rebind to the asset owner of record for verification.
- Customer-reported finding: route to the disclosure triage role with the secondary watcher as the AppSec lead; on confirmation, route to the asset owner of record.
- Recurring detection (regression of a previously-closed finding): restore the prior-cycle 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.
- Unowned-asset finding (the asset reference does not resolve against the asset-to-owner mapping): hold in the unowned-finding queue; the named security operations or GRC operator updates the asset-to-owner mapping before routing executes.
5. Default, fallback, and unowned-finding routing
The catch-all rule is the most failure-prone part of the library. A workspace ships a default-assignee rule that routes unmatched findings to one named user; that 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. Section 5 names the constraints on default and fallback routing, defines the unowned-finding queue as a programme metric rather than a silent absorber, and names the operator who triages the queue.
Default-rule policy:
- The rule library {{HAS_OR_DOES_NOT_HAVE}} a default catch-all rule.
- If a default rule exists, its named owner is: {{DEFAULT_RULE_OWNER}}.
- If a default rule exists, the rule explicitly captures the rationale that the default-owner is the named triage operator, not an absorber of edge cases.
- If no default rule exists, unmatched findings land in the unowned-finding queue (see below).
Unowned-finding queue definition:
- The queue holds every finding that has landed without a resolved owner output from the rule library.
- The queue is a programme metric read at every weekly micro-review and every per-cycle review.
- The queue depth is reported to leadership as part of the routing discipline metric.
- The queue is never allowed to absorb edge cases silently; the named operator below works the queue every operating cycle.
Named unowned-finding-queue operator:
- Role: {{UNOWNED_QUEUE_OPERATOR_ROLE}}
- Named person at time of publication: {{UNOWNED_QUEUE_OPERATOR_NAME}}
- Operating cadence (how often the queue is reviewed): {{UNOWNED_QUEUE_REVIEW_CADENCE}}
- Repair action (what the operator does with each unmatched finding: update asset-to-owner mapping, add a new rule, raise a finding-class normalisation issue, escalate to the head of vulnerability management): {{UNOWNED_QUEUE_REPAIR_ACTION_LIST}}
Routing-policy-violation queue definition:
- The queue holds 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 queue is the security operations lead's read against the routing-discipline metric.
- Findings in this queue are reviewed before the per-cycle disposition meeting.
Fallback ladder for unresolved input data:
- If finding-class identifier is unresolved, the finding queues in the routing-policy-violation queue with the source-class triage role assigned the data-repair action.
- If the asset reference is unresolved, the finding queues in the unowned-finding queue with the named queue operator assigned the asset-to-owner mapping update.
- If severity is unresolved, triage validates calibration and the finding queues until severity is recorded.
- If the scanner module identifier is unresolved, the bulk-finding-import normalisation step fires before routing.
- If the engagement reference is unresolved, the engagement management bind step fires before routing.
- If the prior-cycle owner is missing on a regression, the reopen-and-regression-handling workflow restores the pointer before routing fires.
6. Multi-team and shared-asset routing rules
Findings that touch a shared platform service, a shared dependency package, a shared cloud subscription, or a multi-tenant identity system need an explicit multi-owner pattern or they bounce between teams while the calendar runs. Section 6 names the coordinating-owner pattern, the secondary-watcher fan-out, and the tie-breaker the routing primitive applies when two rules match the same input combination. A library without an explicit tie-breaker produces non-deterministic routing whose audit walkthrough cannot be reconstructed.
Coordinating-owner pattern (used when a finding touches more than one team's responsibility):
- The designated lead owner under whom the finding routes: named role per shared-asset class on the asset-to-owner mapping.
- The named coordinating committee whose members read every state change: typically the named team owners of the contributing teams plus the security operations lead.
- The coordinating committee's standing decision rights and the escalation path when the coordinating committee cannot agree: {{COORDINATING_COMMITTEE_DECISION_RIGHTS}}
Common shared-asset patterns to map explicitly:
- Shared platform service (auth gateway, payment service, observability platform): {{SHARED_PLATFORM_SERVICE_OWNERSHIP_PATTERN}}
- Shared dependency package (a transitive dependency or shared internal library used across products): {{SHARED_DEPENDENCY_OWNERSHIP_PATTERN}}
- Shared cloud subscription (a subscription that hosts workloads from multiple business units): {{SHARED_CLOUD_SUBSCRIPTION_OWNERSHIP_PATTERN}}
- Shared identity system (the workforce identity provider, the customer identity provider): {{SHARED_IDENTITY_OWNERSHIP_PATTERN}}
- Shared container base image (a base image used across product lines): {{SHARED_CONTAINER_BASE_IMAGE_OWNERSHIP_PATTERN}}
- Shared cryptographic primitive (a shared library, a shared HSM partition, a shared certificate authority): {{SHARED_CRYPTO_OWNERSHIP_PATTERN}}
Routing-conflict tie-breaker (when two rules match the same input combination):
- Explicit priority order: rules carry a numeric priority rank in Section 4 and the routing primitive evaluates rules in priority order.
- Tie-breaker policy when priority ranks are equal: {{EQUAL_PRIORITY_TIE_BREAKER_POLICY}}
- Manual disambiguation queue: the source-class triage role reads conflicting matches and records the chosen owner on the activity log with the rule reference as the rationale.
Secondary-watcher fan-out rules (when the rule fans out beyond the named owner):
- Rules that automatically fan out to the engagement lead on critical-severity findings: {{ENGAGEMENT_LEAD_FAN_OUT_RULES}}
- Rules that automatically fan out to the security operations lead on tier-zero asset findings: {{SECOPS_LEAD_FAN_OUT_RULES}}
- Rules that automatically fan out to the GRC lead on framework-tagged findings: {{GRC_LEAD_FAN_OUT_RULES}}
- Rules that automatically fan out to the CISO on board-reportable findings: {{CISO_FAN_OUT_RULES}}
- Limit on per-finding fan-out (typical ceiling: primary owner plus three named watchers): {{PER_FINDING_FAN_OUT_CEILING}}
7. Source-class triage routing before remediation owner
Asset binding alone is not sufficient. A critical-severity external 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. Source-class triage routing prevents the failure mode where a scanner false positive lands on an engineering queue, the engineer cannot interpret the scanner output without security context, and the cycle latency clock starts running on something that should have been closed at intake.
Source classes that require triage routing before reaching the remediation owner:
- External scanner output (low-confidence modules, mass-vulnerability cluster classes, possibly-false-positive classes): {{EXTERNAL_SCANNER_TRIAGE_CLASSES}}
- Authenticated scanner output requiring credential-context validation: {{AUTHENTICATED_SCANNER_TRIAGE_CLASSES}}
- Code scanner output (SAST and SCA) requiring reachability validation: {{CODE_SCANNER_TRIAGE_CLASSES}}
- Bug bounty and external disclosure intake: {{DISCLOSURE_TRIAGE_CLASSES}}
- Customer-reported findings: {{CUSTOMER_REPORTED_TRIAGE_CLASSES}}
- Internal escalation from incident response: {{INTERNAL_ESCALATION_TRIAGE_CLASSES}}
Named source-class triage roles (the roles the routing layer assigns triage-routed findings to before the remediation owner receives the work):
- AppSec triage operator: {{APPSEC_TRIAGE_OPERATOR_ROLE}}
- Security operations triage operator: {{SECOPS_TRIAGE_OPERATOR_ROLE}}
- Product security triage operator (for PSIRT-adjacent disclosure routing): {{PRODUCT_SECURITY_TRIAGE_OPERATOR_ROLE}}
- Cloud security triage operator (for cloud workload triage): {{CLOUD_SECURITY_TRIAGE_OPERATOR_ROLE}}
Triage acknowledgement window:
- The window the named triage role has to validate the finding and route it to the remediation owner: {{TRIAGE_ACK_WINDOW}}
- The escalation chain if the triage window expires: {{TRIAGE_ESCALATION_CHAIN}}
Triage decision outcomes (the named outcomes a triage operator records on the finding):
- Confirmed and routed to remediation owner: the triage operator records the remediation owner on the finding and the routing primitive moves the assignment forward.
- Confirmed-but-deduplicated: the triage operator records the merge against an existing finding and the duplicate is closed with the supersede pointer.
- Confirmed-but-already-accepted: the triage operator records the link to the exception register and the finding is closed-by-exception.
- False positive: the triage operator records the rationale and the finding is closed-as-false-positive with the named authority and the named evidence pointer.
- Out-of-scope: the triage operator records the rationale and the finding is closed-as-out-of-scope with the named scope reference.
- Insufficient evidence to triage: the triage operator records the evidence request and the finding waits in the awaiting-evidence queue.
8. Severity-band and asset-tier window compression
Severity compresses or extends the acknowledgement window before the routing escalates. Asset tier compresses or extends the window further. A tier-zero regulated system with a critical-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. Section 8 names the windows the routing primitive applies across the severity-and-tier matrix. Without explicit windows the routing produces variable acknowledgement times the audit cannot defend.
Severity-band to acknowledgement-window mapping (the default windows before tier compression applies):
- Critical severity: default acknowledgement window {{CRITICAL_DEFAULT_ACK_WINDOW}}
- High severity: default acknowledgement window {{HIGH_DEFAULT_ACK_WINDOW}}
- Medium severity: default acknowledgement window {{MEDIUM_DEFAULT_ACK_WINDOW}}
- Low severity: default acknowledgement window {{LOW_DEFAULT_ACK_WINDOW}}
- Informational: default acknowledgement window {{INFORMATIONAL_DEFAULT_ACK_WINDOW}}
Asset-tier definitions:
- Tier-zero (regulated systems, customer data store, payment processing, authentication service): {{TIER_ZERO_ASSET_DEFINITION}}
- Tier-one (revenue-critical applications, primary customer-facing systems, internal identity provider): {{TIER_ONE_ASSET_DEFINITION}}
- Tier-two (customer-facing supporting systems, internal business systems, partner-facing systems): {{TIER_TWO_ASSET_DEFINITION}}
- Tier-three (internal systems, internal-only utilities, research and sandbox environments outside production): {{TIER_THREE_ASSET_DEFINITION}}
Asset-tier-by-severity compression matrix (the window the routing primitive applies after the asset-tier compression):
- Tier-zero critical: {{TIER_0_CRITICAL_ACK_WINDOW}}
- Tier-zero high: {{TIER_0_HIGH_ACK_WINDOW}}
- Tier-zero medium: {{TIER_0_MEDIUM_ACK_WINDOW}}
- Tier-one critical: {{TIER_1_CRITICAL_ACK_WINDOW}}
- Tier-one high: {{TIER_1_HIGH_ACK_WINDOW}}
- Tier-one medium: {{TIER_1_MEDIUM_ACK_WINDOW}}
- Tier-two critical: {{TIER_2_CRITICAL_ACK_WINDOW}}
- Tier-two high: {{TIER_2_HIGH_ACK_WINDOW}}
- Tier-two medium: {{TIER_2_MEDIUM_ACK_WINDOW}}
- Tier-three critical: {{TIER_3_CRITICAL_ACK_WINDOW}}
- Tier-three high: {{TIER_3_HIGH_ACK_WINDOW}}
- Tier-three medium: {{TIER_3_MEDIUM_ACK_WINDOW}}
External-exposure boost (the additional compression applied when the affected asset is internet-facing):
- {{INTERNET_FACING_COMPRESSION_BOOST}}
Exploit-known boost (the additional compression applied when the finding has a known public exploit or is on the CISA KEV catalogue):
- {{KEV_OR_PUBLIC_EXPLOIT_COMPRESSION_BOOST}}
Escalation chain windows (the windows after the primary acknowledgement window expires):
- Half-window mark: parallel notification to named secondary on the workspace policy.
- Full-window expiry: named secondary becomes the routed owner; activity log captures the elapsed time, the prior owner, the new owner, and the rule reference.
- Double-window expiry: escalation to named tertiary owner with notification to the security operations lead.
- Triple-window expiry: escalation to the head of vulnerability management with a board-reportable flag on the finding.
9. Reassignment, prior-owner handover, and rationale capture
Reassignment is the most common routing operation and the most often misrecorded. A finding moves from one team to another because the asset moved to a different business unit, the owner departed, the scope changed, the severity recalibrated, or the exception applied; 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. Section 9 names the rationale taxonomy, the reassignment event shape, and the prior-owner-handover discipline the routing primitive records.
Reassignment-rationale taxonomy (the named reasons a reassignment is allowed; rationales outside the taxonomy require explicit approval):
- Asset moved to a different business unit: {{ASSET_MOVED_RATIONALE_DEFINITION}}
- Owner departed the workspace and the named successor on the asset-to-owner mapping takes over: {{OWNER_DEPARTED_RATIONALE_DEFINITION}}
- Scope changed (the original asset boundary expanded or contracted): {{SCOPE_CHANGED_RATIONALE_DEFINITION}}
- Severity recalibrated and the rule-based routing now selects a different owner: {{SEVERITY_RECALIBRATED_RATIONALE_DEFINITION}}
- Source-class reclassified after triage validation (e.g., the finding turned out to belong to a different class than the scanner produced): {{SOURCE_CLASS_RECLASSIFIED_RATIONALE_DEFINITION}}
- Exception applied (the finding is now an accepted-risk register entry and the exception ladder owner takes the residual ownership): {{EXCEPTION_APPLIED_RATIONALE_DEFINITION}}
- Engagement transition (the originating engagement closed and the finding moved to the steady-state remediation owner): {{ENGAGEMENT_TRANSITION_RATIONALE_DEFINITION}}
- Coordinating-owner pattern activated (the shared-asset rules now apply and the routing moves to the designated lead owner): {{COORDINATING_OWNER_RATIONALE_DEFINITION}}
Reassignment event shape (every reassignment landing on the activity log carries):
- Prior owner: the user reference of the previously-named owner.
- New owner: the user reference of the newly-named owner.
- Reassigning actor: the user reference of the person or rule that produced the reassignment.
- Rationale code: one of the rationale codes from the taxonomy above.
- Rule reference: the routing rule that produced the reassignment, or the documented manual override identifier.
- Timestamp: the workspace timestamp of the reassignment.
- Prior-owner queue dwell time: the elapsed time the finding spent on the prior owner queue.
- Notification chain: the named recipients of the reassignment notification (the new owner, the prior owner, the engagement lead, the security operations lead where applicable).
Prior-owner-handover discipline (the steps the routing primitive records when an owner departs the workspace):
- Departure event lands on team management with a named successor declared on the asset-to-owner mapping.
- All findings currently assigned to the departing owner are reassigned to the named successor with the OWNER_DEPARTED rationale code.
- The activity log captures the bulk-reassignment event with the named departure actor and the named successor.
- The departure event triggers a per-owner sweep of the named secondary and named escalation references in the rule catalogue to retire stale references.
Manual-override discipline (when a routing decision is recorded outside the rule catalogue):
- Every manual override carries an explicit override identifier and an explicit override rationale.
- Manual overrides land on the routing-policy-violation queue for security operations lead review.
- A manual override that recurs more than {{MANUAL_OVERRIDE_RECURRENCE_THRESHOLD}} times in a cycle triggers a rule-catalogue amendment to either codify the override as a new rule or refactor an existing rule to absorb the pattern.
10. Rule versioning, review cadence, and amendment triggers
A rule library that is never reviewed becomes a rule library that produces silent misroutes. Section 10 names the layered cadence the worksheet runs against: per-cycle micro-review of the queues, per-quarter focused review of the rule catalogue, annual full review aligned to the vulnerability management programme charter, and out-of-cycle amendments on named triggers. Treating the rule library as a static one-off artefact is a recognisable failure pattern; treating it as a living artefact with a refresh cadence is what the audit and the board expect.
Per-cycle micro-review (typically weekly):
- Owner: {{PER_CYCLE_MICRO_REVIEW_OWNER}}
- Inputs read: the routing-policy-violation queue, the unowned-finding queue, the awaiting-evidence queue, the per-rule fire pattern over the prior week.
- Outputs produced: rule-amendment proposals queued for the next quarterly focused review, data-quality repair actions for the asset-to-owner mapping, source-class triage feedback to the AppSec lead.
- Cadence ceiling (the maximum window between micro-reviews): {{MICRO_REVIEW_CADENCE_CEILING}}
Per-quarter focused review:
- Owner: {{PER_QUARTER_FOCUSED_REVIEW_OWNER}}
- Co-owners: AppSec lead, security operations lead, cloud security lead, product security lead, GRC lead, platform engineering partner.
- Inputs read: the per-rule fire rate over the prior quarter against the expected fire rate captured at design time, the retire-by triggers from each rule's design block, the queued amendment proposals from the per-cycle micro-reviews, the framework crosswalk drift since the prior review, the manual-override recurrence pattern.
- Outputs produced: rules added, rules retired, rules refactored, rules whose expected fire rate is updated, rules whose escalation chain is updated, rules whose framework citation is updated.
- Sign-off: named co-owners countersign the new version on the activity log with timestamp and rationale.
Annual full review:
- Owner: head of vulnerability management or accountable operator named in the upstream charter.
- Cadence: aligned to the vulnerability management programme charter annual review cycle, typically one to two months before the budget cycle so the rule-library posture in the worksheet informs the next-year tooling and headcount conversation.
- Inputs read: the rule library version trajectory over the prior twelve months, the per-quarter focused review minutes, the audit and regulator citations of the rule library, the post-incident reviews citing routing failures, the headcount and tooling stack changes affecting routing capacity.
- Outputs produced: a refreshed rule library version with redlined amendments, a confirmation paragraph that the existing rule library remains accurate where unchanged, a per-co-owner sign-off chain.
Out-of-cycle amendment triggers (any of the following produces an amendment outside the scheduled review cadence):
- Material change in the in-scope asset population (acquisition, divestiture, new product line, new cloud account population, new geography, new on-premise estate).
- Scanner-stack replacement that changes finding-class identifiers, scanner module identifiers, or input data shape.
- Reorganisation that changes business unit owners, named co-owners, or the named escalation chain.
- Material incident whose post-incident review identifies a routing failure (silent misroute, escalation gap, prior-owner-handover failure) as a contributing cause.
- Control finding from an audit, internal audit independent review, regulator, or cyber-insurance underwriter that names the rule library or the routing discipline as the root cause of a gap.
- Regulatory environment change that adds new framework expectations on routing discipline (for example NIS2 activation, DORA activation, sector-specific regulation, CISA Cyber Performance Goals expectation shift).
Amendment-decision documentation (every amendment lands on the activity log with):
- Amendment identifier and amendment effective date.
- Trigger code (one of the trigger codes above).
- Summary of rules added, retired, refactored.
- Named co-owners signing the amendment.
- Cross-reference to the document management version of the worksheet.
11. Audit walkthrough preparation and framework crosswalk
The audit walkthrough is what proves the rule library is operated rather than aspirational. Section 11 names the per-rule sample-finding reconstruction the audit reads, the framework crosswalk the rule library is mapped against, and the audit-pack the GRC lead produces from the workspace. A rule library with no audit-walkthrough preparation is a rule library whose provenance the audit committee cannot reconstruct.
Framework crosswalk (the framework controls the rule library produces evidence against; map every rule to at least one citation):
- ISO/IEC 27001:2022 Annex A 5.2 information security roles and responsibilities; A.5.3 segregation of duties; A.8.8 management of technical vulnerabilities; Clause 5.3 roles, responsibilities, and authorities; Clause 7.5 documented information.
- SOC 2 Trust Services Criteria CC1.3 organisational structure, reporting lines, and authorities; CC2.2 internal communication; CC7.1 detection and monitoring; CC8.1 change management.
- NIST CSF 2.0 GV.RR roles, responsibilities, and authorities; DE.AE adverse event analysis; RS.MI mitigation; PR.IR technology infrastructure resilience.
- NIST SP 800-53 Rev. 5 PM-2 senior accountable official; PM-29 risk management roles and responsibilities; RA-5 vulnerability monitoring and scanning; SI-2 flaw remediation; CA-7 continuous monitoring.
- PCI DSS Requirement 12.1 information security policy; 12.4 responsibility for protecting cardholder data; 12.5 dedicated information security team; 6.3.1 security vulnerabilities are identified and managed.
- CIS Controls v8.1 Control 7 continuous vulnerability management; Control 17 incident response management.
- NIS2 Article 21 technical and operational measures; DORA Article 5 governance with reporting and Article 9 ICT operations security; HIPAA 164.308(a)(1)(i) security management process.
Per-rule audit-pack (for each rule the audit walkthrough samples):
- Rule identifier and rule short name.
- Three to five sample findings the rule fired against in the prior cycle, with the per-finding activity log showing the input combination, the rule reference, the named-owner output, and the named secondary watcher.
- The per-rule fire-rate trace from the activity log: total fires in the cycle, mean acknowledgement-window dwell time, escalation-chain firings, reassignment events with rationale codes.
- The per-rule framework citation showing which framework controls the rule produces evidence against.
- The per-rule design block from Section 4 showing the rationale, the evidence pointer, and the retire-by trigger.
Audit-walkthrough script (the standard order the GRC lead runs the rule library walkthrough against):
- Open with the rule library identifier, the current version, the upstream chartered authority, and the framework crosswalk.
- Walk the rule catalogue inventory (count of rules, additions, retirements, refactors since the prior review).
- Sample three to five rules at random and reconstruct the per-rule audit-pack live.
- Walk the routing-policy-violation queue and the unowned-finding queue depth trace over the prior quarter.
- Walk the reassignment-rationale taxonomy with the prior-quarter distribution.
- Walk the per-cycle micro-review minutes, the per-quarter focused review minutes, and the annual full review minutes.
- Walk the out-of-cycle amendment log over the prior cycle with the trigger codes and the resulting amendments.
- Close with the framework crosswalk reconciliation, naming any controls that no longer map to a live rule and the per-quarter focused review action to repair the gap.
Evidence-of-operation indicators (the leading indicators a defensible rule library produces on the activity log):
- Auto-routed share: the percentage of findings the rule library routed without manual intervention in the cycle.
- First-time-accuracy share: the percentage of routed findings that did not require reassignment in the same cycle.
- Routing-policy-violation queue depth: the number of findings in the queue at the cycle-end snapshot.
- Unowned-finding queue depth: the number of findings in the queue at the cycle-end snapshot.
- Per-rule fire-rate variance from expected: the percentage of rules whose observed fire rate deviates more than {{FIRE_RATE_VARIANCE_THRESHOLD}} from the expected fire rate captured at design time.
- Mean acknowledgement-window dwell time per severity band: the cycle mean against the design window.
12. Known failure modes and structural fixes
Rule libraries fail the audit read in recognisable patterns. Each failure has a structural fix that the worksheet above is designed to enforce. Read this section before customising the worksheet so the customisation does not weaken the discipline that makes the rule library defensible. The failure modes are documented in the order they typically surface; treat each one as a design check on the version about to be published.
Failure mode 1: Routing-by-tribal-knowledge.
- Symptom: The named analyst routes findings by memory; the rule library is implicit; the audit walkthrough cannot reconstruct which rule produced which assignment.
- Structural fix: Section 4 captures every rule with the per-rule design block; the activity log captures the rule reference on every assignment; the audit pack reconstructs the chronology from the workspace record.
Failure mode 2: Catch-all default rule that absorbs every edge case.
- Symptom: Unmatched findings route to one named user; their queue grows without leadership visibility; the policy reads green because everything has an owner; the unowned tail never surfaces.
- Structural fix: Section 5 defines the unowned-finding queue as a programme metric with a named operator and a cadence; the default rule, where it exists, carries an explicit rationale and a named triage role rather than a silent absorber.
Failure mode 3: Routing-policy-violation queue does not exist.
- Symptom: Manual overrides happen but never surface; reassignments happen without rationale; escalations happen outside the workspace chain; the audit reads against the operational record and finds the rule library implicit.
- Structural fix: Section 5 defines the routing-policy-violation queue; the activity log captures every override, reassignment, and escalation with explicit cause codes; the security operations lead reads the queue at every micro-review.
Failure mode 4: Reassignment events lose the prior owner and the rationale.
- Symptom: A finding moves between teams without the activity log capturing the prior owner; the audit query asks how long the finding sat in which queue; the answer requires reconstruction from email.
- Structural fix: Section 9 names the reassignment-rationale taxonomy and the reassignment event shape; the activity log captures the prior owner, the new owner, the reassigning actor, the timestamp, the rationale code, and the rule reference.
Failure mode 5: Prior-owner handover on staff departure is silent.
- Symptom: An owner departs; their findings stay on their queue; the audit asks the elapsed time on the prior owner queue and reads silent dwell time.
- Structural fix: Section 9 names the prior-owner-handover discipline; team management captures the departure event; the bulk-reassignment workflow fires against the named successor on the asset-to-owner mapping with the OWNER_DEPARTED rationale code.
Failure mode 6: Acknowledgement windows expire without escalation and findings age silently.
- Symptom: 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.
- Structural fix: Section 8 names the escalation chain per severity-and-tier; the routing primitive fires the half-window parallel notification, the full-window reassignment, the double-window tertiary escalation, and the triple-window head-of-VM escalation with the board-reportable flag.
Failure mode 7: Rule library accretes past the maintenance break and stops paying back.
- Symptom: The rule library grows linearly; each new rule was added for a real reason at the time; the per-rule fire rate falls; rule branches overlap and produce non-deterministic routing.
- Structural fix: Section 4 captures the per-rule expected fire rate and retire-by trigger; Section 10 runs the per-quarter focused review against the retire-by triggers; the size band declared in Section 4 informs the maintenance budget.
Failure mode 8: Same input combination triggers conflicting rules.
- Symptom: Two rules match the same input combination; the routing primitive produces variable output; the named owner field depends on rule evaluation order rather than on design.
- Structural fix: Section 6 names the routing-conflict tie-breaker; rules carry a numeric priority rank; the routing primitive evaluates rules in priority order; the per-cycle micro-review reads the tie-breaker queue.
Failure mode 9: Triage routing collapses into direct-to-engineer routing.
- Symptom: External scanner findings land on engineering queues without security context; the engineer cannot interpret the scanner output; the cycle latency clock starts running on something that should have been closed at intake.
- Structural fix: Section 7 names the source classes that require triage routing and the named triage roles; the rule catalogue carries source-class triage as the first hop before remediation routing.
Failure mode 10: Rule library is reviewed once a year and treated as a static document.
- Symptom: The rule library is published once a year as a slide; the per-cycle queues, the per-quarter retire-by triggers, and the per-rule fire-rate variance are never read; the audit reads the rule library as a posture rather than as an operating discipline.
- Structural fix: Section 10 names the layered cadence (per-cycle, per-quarter, annual); the activity log captures the review minutes; the framework crosswalk in Section 11 keeps the rule library reconciled against the audit interface.
Eight failure modes the worksheet is designed against
Rule libraries fail the audit read in recognisable patterns. Each failure has a structural fix that the worksheet above is designed to enforce. Read this list before customising the worksheet so the customisation does not weaken the discipline that makes the rule library defensible across audit, regulator, and post-incident reads.
Routing rule library exists only in analyst memory
The named analyst routes findings by memory; the rule library is implicit; the audit walkthrough cannot reconstruct which rule produced which assignment. The fix is Section 4 of the worksheet where every rule sits in its own design block with the condition, the action, the rationale, the evidence pointer, the expected fire rate, and the retire-by trigger captured explicitly, paired with an activity-log entry on every assignment that cites the rule reference.
Catch-all default rule that absorbs the unowned tail
A workspace ships a default-assignee 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 Section 5, where the unowned-finding queue is a programme metric with a named operator and a per-cycle review cadence rather than a silent absorber.
Routing-policy-violation queue does not exist
Manual overrides happen but never surface; reassignments happen without rationale; escalations happen outside the workspace chain. The audit reads against the operational record and finds the rule library implicit. The fix is Section 5, where the routing-policy-violation queue captures every override, reassignment, and escalation with explicit cause codes, and the security operations lead reads the queue at every micro-review.
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 Section 9, which names the reassignment-rationale taxonomy and stamps the prior owner, the new owner, the reassigning actor, and the rationale code on every reassignment event.
Acknowledgement windows expire without escalation
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 Section 8, which names the half-window parallel notification, the full-window reassignment, the double-window tertiary escalation, and the triple-window head-of-VM escalation with the board-reportable flag.
Rule library accretes past the maintenance break
The rule library grows linearly; each new rule was added for a real reason at the time; the per-rule fire rate falls; rule branches overlap and produce non-deterministic routing. The fix is the per-rule expected fire rate and retire-by trigger captured at design time in Section 4, paired with the per-quarter focused review in Section 10 that evaluates the retire-by triggers and the rule-library size band.
Same input combination triggers conflicting rules
Two rules match the same input combination; the routing primitive produces variable output; the named owner field depends on rule evaluation order rather than on design. The fix is the explicit numeric priority rank on every rule in Section 4 and the named tie-breaker in Section 6, with the per-cycle micro-review reading the tie-breaker queue and the per-quarter focused review refactoring rules whose priority ranks overlap unintentionally.
Triage routing collapses into direct-to-engineer routing
External scanner findings land on engineering queues without security context; the engineer cannot interpret the scanner output; the cycle latency clock starts running on something that should have been closed at intake. The fix is Section 7, which names the source classes that require triage routing and the named triage roles, with the rule catalogue carrying source-class triage as the first hop before remediation routing.
Ten questions a per-quarter focused review has to answer
Per-cycle micro-review keeps the rule library responsive to drift in real time. Per-quarter focused review reads the cumulative pattern: is the rule library on the productive side of the size-and-accuracy curve, are the rules paying back their maintenance cost, and is the library design surface still aligned to the operating reality the rules were written for. Run these ten questions at every quarterly focused review and capture the answers on the activity log with the named co-owners as signatories.
1.How many rules did the library carry at the end of the cycle, broken out by rules added, rules retired, and rules refactored since the prior cycle.
2.What was the auto-routed share (the percentage of findings the rule library routed without manual intervention) at the cycle close, and how did it move against the prior cycle.
3.What was the first-time-accuracy share (the percentage of routed findings that did not require reassignment in the same cycle), and how did it move against the prior cycle.
4.What was the routing-policy-violation queue depth at the cycle-end snapshot, and what is the elapsed-time distribution of the findings sitting in the queue.
5.What was the unowned-finding queue depth at the cycle-end snapshot, and how many findings were repaired by asset-to-owner mapping updates versus by new rule additions.
6.Which rules carried an observed fire rate that deviated more than the design threshold from the expected fire rate captured at design time, and what does the per-quarter focused review recommend for each.
7.Which rules met the retire-by trigger captured at design time during the cycle, and have they been retired or scheduled for retirement.
8.How many reassignment events fired during the cycle by rationale code, and what does the distribution suggest about the asset-to-owner mapping freshness, the staff-departure handover discipline, and the exception-application volume.
9.How many escalation chain firings occurred at the half-window, full-window, double-window, and triple-window marks, and how many of them surfaced as a routing failure rather than as a remediation-side delay.
10.How many manual overrides recurred more than the recurrence threshold, and which of them have been codified as new rules versus absorbed into refactored rules in the per-quarter focused review.
How the worksheet pairs with SecPortal as a workspace operating record
The worksheet above is copy-ready as a standalone artefact. If the security team already runs finding tracking, document storage, exception management, and framework evidence packaging on a workspace, the worksheet becomes the design layer of the platform-side routing primitive rather than a separate document. SecPortal pairs the rule library to a versioned document through findings management so the named-owner field, the severity record, the source-class identifier, and the engagement reference that the rule library reads as inputs live on the same record as the rule-output owner field on every finding the library has touched. The bulk finding import path normalises imported Nessus, Burp, OWASP ZAP, Semgrep, SCA, and CSV output against the workspace finding template library so the finding-class identifier and the scanner module identifier inputs land in canonical shape before routing fires. The engagement management feature binds each finding to its originating engagement so the engagement reference input is reproducible and the per-engagement routing pattern is reconstructable cycle on cycle.
The team management feature with role-based access control supplies the workspace user catalogue (owner, admin, member, viewer, billing roles) that the rule-output owner field references, with departed staff surfacing as inactive references rather than silent stale data and the role gate applied to amend access. The activity log with CSV export captures the timestamped chain of every owner assignment, owner change, reassignment, and acknowledgement event with 30, 90, or 365 day retention depending on plan, supplying the auto-routed share, the first-time-accuracy share, the per-rule fire-pattern reconstruction, and the per-handoff latency the per-quarter focused review reads. The finding overrides feature holds the eight-field exception decision chain (named approver, named compensating control, named expiry, named renewal cadence, named residual risk owner, named scope, named justification, named evidence-of-acceptance) for routing exceptions that need explicit authority and rationale.
The document management feature carries the versioned worksheet alongside the upstream charter, the policy, the RACI, and the SLA policy so the rule library is held in document form rather than living only in workspace configuration. The compliance tracking feature pairs the rule library to the relevant framework controls (ISO 27001 A.5.2 and A.8.8, NIST CSF 2.0 GV.RR, NIST SP 800-53 PM-2 and RA-5, PCI DSS 12.4 and 6.3.1, SOC 2 CC1.3 and CC7.1, NIS2 Article 21, DORA Article 5) so the rule-library review reads against the same crosswalk the audit interface uses. The notifications and alerts path routes 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. The multi-factor authentication enforcement on the workspace provides authentication assurance on the named-owner field that the audit citation reads against. The AI reports workflow 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.
Honest scope: SecPortal does not ship a no-code rule editor, does not produce a visual rule-design canvas, does not auto-import rule libraries from third-party platforms, does not validate that the rule library matches the engineering organisation chart, does not enforce maintenance budget on the rule library, does not ship native Jira, ServiceNow, Slack, Microsoft Teams, PagerDuty, SIEM, SOAR, or GRC platform integrations, does not ship SSO, SCIM, or SAML, does not provide asset inventory or CMDB sync, and does not provide customer-logo or ROI or adoption-metric or compliance-guarantee claims. The rule library design and maintenance decisions belong to the security organisation operating the rule library; the workspace keeps the per-finding ownership trail, the activity log, and the override register on one record so the rule library question is reproducible at any moment between cycles.
Vulnerability management teams read the worksheet as the design layer of the routing primitive that decides who owns each finding. Pair the worksheet with the vulnerability SLA management use case for the acknowledgement-window and remediation-window discipline the rule library enforces.
Security engineering and platform engineering teams
GRC and compliance teams and internal audit teams read Section 11 as the audit-walkthrough preparation discipline that maps the rule library to ISO 27001 A.5.2 and A.8.8, SOC 2 CC1.3 and CC7.1, NIST CSF 2.0 GV.RR, NIST SP 800-53 PM-2 and RA-5, PCI DSS 12.4 and 6.3.1, NIS2 Article 21, and DORA Article 5. Pair the worksheet with the audit fieldwork evidence request fulfilment use case.
Cloud security teams read Section 6 as the shared-asset routing pattern the rule library applies across cloud subscriptions and shared container base images. Pair the worksheet with the CSPM finding remediation workflow.