← Back to Blog
Enterprise19 min read

Security Finding Reopen Rate Operating Playbook: How to Measure, Govern, and Reduce Remediation Rework

Most vulnerability management programmes report throughput. A smaller number report durability. Reopen rate is the durability signal. It is the share of findings closed inside an observation window that returned to an open state inside a defined lookback window. Two programmes that close the same number of findings can carry very different reopen-rate profiles, and the reopen-rate profile is the one that reads whether the closures held across change cycles, retests, dependency upgrades, configuration deployments, and scanner refreshes. This playbook is the operating model a CISO, a vulnerability management lead, an AppSec manager, a product security lead, and a GRC owner use to run reopen rate as a measured signal: how to define it without ambiguity, which lookback windows to run in parallel, which cuts to read it on, how to name the regression classes that drive it, how to govern the cadence that acts on it, how to escalate when the rate moves, and what audit evidence the metric leaves behind.

Why Reopen Rate Is the Durability Companion to Throughput

Throughput is the most reported vulnerability metric: the count of findings closed in a window, the mean time to remediation, the SLA attainment rate. Throughput answers how fast the programme moves work. It does not answer whether the work it moved stayed moved. Reopen rate is the metric that answers durability. A programme that closes a thousand findings a quarter at a five percent ninety-day reopen rate is operating at a different durability level than a programme that closes a thousand findings at a twenty-five percent ninety-day reopen rate. The throughput numbers are identical; the operating reality is not. The leadership group that reads only throughput reads a flat number; the leadership group that reads throughput paired with reopen rate reads the programme honestly.

Reopen rate sits alongside three other durability signals: aging (how long open findings have been open), staleness (how long the evidence on a finding has been unrefreshed), and SLA breach distribution (which severity bands and source pipelines breach the remediation SLA). The four signals interlock. Aging reads the work that has not been closed. Staleness reads the work that looks closed but the evidence has decayed. SLA breach reads the work that is past its target date. Reopen rate reads the work that was closed and did not hold. A programme that measures throughput alone improves on speed without confirming the speed is producing durable outcomes. The four durability signals together produce a leadership read the board, the audit committee, and the engineering organisation can act on. See the security finding aging and staleness management guide for the aging and staleness companions and the vulnerability remediation SLA policy guide for the SLA layer.

The econometrics of reopen rate (rate behaviour, lookback windows, distribution shapes, the relationship to verification discipline) are covered in the vulnerability reopen rate research note. This playbook is the operating layer that sits on top of the econometrics: the cuts the leadership group reads, the cadence the team runs the metric on, the escalation criteria the programme defends, and the audit evidence the metric produces.

Definition That Survives the First Operating Review

Reopen rate looks like a single number on a slide, but the definition is where most programmes lose alignment between the security lead, the engineering lead, and the audit lead. A definition that survives the first operating review names six things explicitly.

The numerator

The count of distinct finding records that transitioned from a closed-state set (verified, closed, resolved, or false_positive) to an open-state set (open, reopened, in_review) inside the lookback window. The transition is counted once per finding regardless of how many times the finding moved back and forth, so a flapping finding does not inflate the numerator.

The denominator

The count of distinct finding records that were in a closed-state set at any point inside the lookback window. The denominator includes findings that stayed closed and findings that reopened. Programmes that put the denominator at intake (rather than closure) produce a number that is mathematically valid but operationally misleading because intake-versus-closure mismatches distort the rate.

The lookback window

Run three windows in parallel: thirty days for retest discipline, ninety days for regression resilience, one hundred eighty days for structural durability and rediscovery. A single window hides where the durability is failing; three windows read the failure mode.

The reopen identity rule

The same-asset-same-CWE reopen rule on intake. When the new detection reads the same asset binding and the same CWE classification (or for SAST findings, the same repository and the same vulnerable code path), the workflow reopens the original record. Programmes that mint a new ID on each fresh scanner output deflate the reopen counter and inflate the inflow counter at the same time; the durability signal is lost.

The exclusions

Findings that closed inside the window and stayed closed do not count as reopens. Findings that closed before the window and reopened inside it do count, because the reopen is a durability event the leadership group should read. Watch-window closures (verified findings moved to closed at the expiry of the regression watch window without recurrence) count as closed-and-stayed-closed, not as reopens.

The cut dimensions

A flat reopen rate is unactionable. The leadership read requires cuts: by source pipeline (external scan, authenticated scan, SAST, SCA, manual, imported third-party), by severity band (critical, high, medium, low, informational), by team (the named owner of the original remediation cycle), by application or asset, by regression class (the structured reason the reopen happened). Each cut names where the durability is failing and who owns the response.

Seven Regression Classes the Reopen Workflow Should Name

A reopen rate that does not carry the regression class on each reopen transition is a number without a root cause. Naming the class on the reopen converts an aggregate metric into an actionable one. Seven classes cover most reopen events; the structured metadata on the reopen transition makes the cut by class readable in the leadership report and reproducible at the audit cadence.

Class 1 Scanner re-detection after verified closure. The next external, authenticated, or code scan against the same target reproduces a previously verified-fixed finding. The fix was deployed; a regression event undid it (a refactor, a base-image update, a configuration drift, a dependency replacement). This is the most common class and the one that reads against control durability rather than retest discipline.
Class 2 Failed retest on a claimed-fixed finding. The remediation owner reported the fix deployed; the retest replayed the original attack path and the finding still reproduces. The engineering claim did not survive verification. This class reads against retest discipline and the closure gate.
Class 3 Partial fix that leaves residual variants. The retest confirms the original payload no longer reproduces, but the workspace catalogue links additional variants on the same CWE and one or more still reproduce. Treating it as a full closure inflates the closed count; treating it as a regression loses the named residuals. The class names the partial-fix pattern and keeps the residual variants visible.
Class 4 Dependency or base-image downgrade reintroducing a vulnerable component. An SCA-sourced finding was closed when the vulnerable dependency was upgraded. A later build pinned a transitive dependency to an earlier version, or a base-image rebuild pulled an earlier patch level. The vulnerable component is back in the production dependency graph.
Class 5 Configuration drift undoing a hardened control. The original closure cited a configuration change: a security header set, a TLS cipher list pruned, an authentication setting enabled, a firewall rule added. A later configuration deployment regressed the setting. The next external scan or manual review surfaces the original finding against the same asset and the same control surface.
Class 6 Overturned dismissal of a false positive. A finding was triaged as false_positive when reproduction failed. A later signal (a customer report, a third-party assessment, a new scanner version, a changed attack technique) shows the original detection was right and the dismissal was wrong. The reopen carries the overturn evidence on the lineage.
Class 7 Same-asset rediscovery under a new identifier. The new detection should have reopened the original finding but the intake workflow minted a new ID instead. Strictly this is not a reopen; operationally the durability signal is the same. The metric should flag the class so the intake reopen-identity rule can be tightened rather than the rediscovery silently inflating new intake.

The structured workflow that decides which class applies to each reopen, how the severity is handled on the reopen, and which audit evidence the reopen transition carries is documented in the security finding reopen and regression handling workflow page. This playbook reads the operational metric on top of that workflow.

The Reopen Rate Dashboard the Leadership Group Should Read

A dashboard that shows reopen rate as one large number is a dashboard that hides where the durability is failing. A dashboard that shows reopen rate on the right cuts at the right windows produces a leadership read the team can act on. The cuts below describe a minimum viable dashboard. Programmes that want a richer read add a per-application cut, a per-scanner cut, and a per-source-of-original-finding cut (was the finding originally sourced from a scan, a pentest, an internal disclosure, or a third-party import). The mechanism is the same on every cut: aggregate the reopen count and the closed count from the workspace finding records and divide.

By window

Three rates side by side: thirty-day, ninety-day, one hundred eighty day. The pattern of the three reads the failure mode: thirty-day high alone reads retest discipline; ninety-day high without thirty-day high reads regression risk; one hundred eighty day high alone reads structural durability and rediscovery. The shape of the three is the operating signal.

By source pipeline

Reopen rate on external scan, authenticated scan, SAST, SCA, manual triage, and imported third-party output. Each pipeline carries its own durability profile; a flat rate hides which pipeline is producing the rework. AppSec and product security read this cut to know whether the rework is concentrated on code-side or environment-side findings.

By severity band

Reopen rate on critical, high, medium, low, and informational. The leadership group reads whether the durability problem is concentrated in the bands that carry the most risk. A high reopen rate on criticals is a different conversation with engineering than a high reopen rate on informationals.

By regression class

Reopen rate split across the seven regression classes. The class cut names the root cause: a rate driven by failed retests is a different problem than a rate driven by configuration drift, which is a different problem than a rate driven by dependency downgrades. Each class points at a different upstream control.

By team

Reopen rate per remediation owner (engineering team, platform team, application team). The cut surfaces whether the durability problem is broad or concentrated. A concentrated rate is a targeted engineering conversation; a broad rate is a programme-wide conversation about closure gates and verification discipline.

By application

Reopen rate per registered application or service. The cut reads whether one application is carrying most of the rework. Product security leads read this cut to identify the applications that need a deeper control review, a refactor, or a dedicated remediation campaign rather than another round of patching.

The structured data each cut reads from is the finding record itself: the source pipeline field, the severity band, the named owner of the current cycle, the application or asset reference, the regression class on the most recent reopen transition. The activity-log lineage gives the timestamped chronology the lookback windows query against. Findings management holds the record and the structured fields; activity log holds the append-only chronology of state changes that the metric reads.

Operating Cadence: Weekly, Monthly, Quarterly, Annual

A metric that is not on a cadence is a metric the team rediscovers at the audit. Reopen rate runs on four cadences. Each cadence has a named owner, a window the cadence reads, and a documented action the cadence produces.

Weekly: vulnerability management lead, thirty-day window

The vulnerability management lead reviews the thirty-day reopen rate every week. Retest discipline failures move on the weekly cadence; a fix that did not survive its verification cycle should not wait a month to surface in the leadership read. The action the weekly review produces is the named follow-up cycle on every failed-retest reopen: which finding, which named verifier, which engineering owner, and which target date for the next retest.

The weekly read sits on a saved workspace query against the finding records filtered by reopened state inside the past thirty days, with the regression class field surfacing the failed-retest count specifically. The cadence outcome lands as a meeting note on the programme record with the named decisions and the named owners.

Monthly: AppSec, product security, cloud security leads, ninety-day window

The AppSec, product security, and cloud security leads each review the ninety-day reopen rate on the cuts they own. AppSec reads the SAST and SCA cuts. Product security reads the per-application cut. Cloud security reads the configuration-drift and IaC cuts. The action the monthly review produces is the named programme intervention on every cut that has moved outside the agreed band: a code-side intervention (a refactor, a developer-training cycle, a pre-commit hook), an environment-side intervention (a configuration baseline review, a policy-as-code rule), a process-side intervention (a tighter closure gate, a verification cadence change).

The monthly read includes a comparison to the prior month so movement is visible. Month-on-month decay in the ninety-day rate on one cut is the signal the intervention is working; month-on-month inflation is the signal the intervention is missing the root cause.

Quarterly: CISO and security leadership, all three windows

The CISO and the security leadership group review reopen rate across all three windows quarterly. The quarterly read pairs reopen rate with the throughput metric, the aging metric, the staleness metric, and the SLA breach distribution metric so the durability picture sits in context. The action the quarterly review produces is the agreed target band for the next quarter and the agreed programme priorities to drive the rate toward the band.

The quarterly read is the input to the security programme report to the leadership group, the audit committee, and (depending on the programme governance) the board. The structured comparison across windows and cuts is the evidence the report defends rather than a single aggregate number.

Annual: board report, year-over-year

The annual report reads reopen rate against the prior year baseline. Year-over-year movement is the durability narrative the board reads alongside the throughput and SLA narratives. The annual cadence is also the cadence at which the leadership group revisits the agreed target bands and the cut dimensions; targets that defended the operating reality last year may need to defend a different operating reality this year as the portfolio, the team, and the scanner stack change.

Escalation Criteria: When a Cut Triggers a Review Outside the Cadence

Most rate movement is gradual and the cadence catches it. Some movement is sharp and the cadence misses it for too long. The escalation criteria below define the thresholds that trigger an off-cadence review with a named owner and a documented response. The criteria are programme specific; the structure of naming them is universal.

Trigger 1 The thirty-day reopen rate on any source pipeline doubles inside a single week. The escalation names the pipeline owner and the verifier responsible for retest discipline on the pipeline. The expected response is a documented retest-process review inside the next two weeks.
Trigger 2 The ninety-day reopen rate on the critical severity band exceeds the agreed band for two consecutive months. The escalation names the security leadership group and the engineering leadership counterpart. The expected response is a joint programme intervention review inside the next month with a documented action plan.
Trigger 3 Any single regression class accounts for more than forty percent of reopens inside the ninety-day window. The escalation names the upstream control owner (the closure-gate owner for failed retests, the configuration-as-code owner for drift, the dependency-management owner for downgrades). The expected response is a named upstream-control intervention with a documented owner and target date.
Trigger 4 Any single application or team accounts for more than thirty percent of reopens inside the ninety-day window. The escalation names the application owner and the engineering team lead. The expected response is a targeted control review inside the next month with the security partner embedded into the review.
Trigger 5 The same-asset rediscovery class (Class 7) accounts for more than ten percent of reopens. The escalation names the intake workflow owner. The expected response is a tightening of the same-asset-same-CWE reopen-identity rule and a backfill review on the records that minted a new ID instead of reopening the original.

The Closure Gate Is Where Reopen Rate Is Won or Lost

Reopen rate is reported downstream of the closure gate, but it is produced upstream. The durability of the metric is the durability of the gate. A closure gate that closes findings on the engineering claim alone produces a healthy closed count and a long tail of failed retests; a closure gate that requires structured verification evidence on every closure produces a slightly slower throughput and a much healthier reopen rate. The trade-off is real and the leadership group should make the call on it explicitly rather than discovering it after the fact.

A defensible closure gate names four things on every closure transition: the named closer, the verification evidence (the retest scan ID, the targeted retest transcript, the manifest diff for dependency closures, the configuration export for hardening closures, the customer-report reference for incident-driven closures), the verification timestamp, and the closure rationale that reads against the original finding. The same four pieces are what an audit asks for after the fact. Building the closure gate around the evidence pattern means the audit is reading the same record the team operates against, not a reconstructed narrative.

The retesting workflows feature pairs the retest evidence to the original finding so closures read against a verified outcome rather than an engineering claim alone. The finding overrides register is where compensating-control closures and accepted-risk closures live with a named reviewer, a documented rationale, a scope, and an expiry, so the leadership read can distinguish verified-fix closures from override closures. The scan comparison and diff feature surfaces the reopened-finding event as a structured change event the dashboard reads against rather than as a manually reconstructed comparison.

Audit Evidence the Metric Produces

Reopen rate is a programme metric, but the audit reads it as evidence of remediation durability against several frameworks. The audit does not usually ask for the rate as a number; it asks for the underlying records and reconstructs durability from the chronology. The audit is satisfied when the lineage is continuous, the evidence is timestamped and named, and the chronology reads as a sequence of events on one record rather than as parallel records that the auditor has to reconcile.

ISO 27001 Annex A 8.8 and Clause 9

Annex A 8.8 (management of technical vulnerabilities) reads against the reopen lineage as the durability discipline of the technical vulnerability lifecycle. Clause 9 (performance evaluation) reads against the reopen-rate trend as a measurable performance signal. The audit evidence is the activity-log lineage on the sampled findings and the workspace query that produced the rate.

SOC 2 CC7.1, CC7.2, CC7.3

CC7.1 (system operations and monitoring) reads against the closure-and-reopen chronology as evidence that closures are tracked across change cycles. CC7.2 (anomalies in operation) reads against the regression-class metadata as the structured signal of where durability is failing. CC7.3 (security incident management) reads against the reopen evidence chain for findings whose containment depended on a remediation that regressed.

PCI DSS 6.3.1, 11.3.1.3, 11.4.4

Requirement 6.3.1 (security vulnerabilities are identified and managed) reads against the reopen workflow as the discipline that keeps the vulnerability lifecycle continuous through regression events. Requirement 11.3.1.3 (rescanning to confirm remediation) reads against the failed-retest queue. Requirement 11.4.4 (penetration testing findings remediated and rescanned) reads against the reopen lineage for pentest-source findings that fail retest.

NIST 800-53 SI-2, RA-5, CA-7, AU-2, AU-12

SI-2 (flaw remediation) reads against the reopen workflow as the discipline that converts regression events into named remediation cycles. RA-5 (vulnerability monitoring and scanning) reads against the scan-baseline diff and the regression-against-closed queue. CA-7 (continuous monitoring) reads against the failed-retest queue and the partial-fix queue. AU-2 and AU-12 (audit events and audit record generation) read against the activity-log stamp on every reopen transition.

NIST CSF 2.0 ID.RA, DE.CM, RS.MI, GV.RR

ID.RA reads against the regression-class cut as the structured risk signal on durability. DE.CM-01 and DE.CM-09 read against the regression-against-closed queue as the recurring detection control. RS.MI-01 (incidents are mitigated) reads against the reopen workflow as the discipline that keeps the mitigation cycle continuous. GV.RR reads against the named-actor stamp on every reopen transition.

CIS Controls v8.1 Control 7

Control 7 (continuous vulnerability management) reads against the regression-against-closed queue, the failed-retest queue, and the reopen-SLA queue as the operational discipline that confirms remediation actions hold across scan cycles rather than only registering as closed-count throughput. Safeguard 7.7 (remediate detected vulnerabilities) reads against the regression-class metadata on reopens.

How the Metric Runs Off the Workspace Record

Reopen rate is producible by any team that holds the finding record in a place where state transitions are append-only, named, and timestamped. SecPortal is one such place; the metric is not unique to SecPortal. The mechanism below describes how reopen rate reads off the platform primitives without inventing capabilities the product does not ship.

The finding record

The findings management surface holds the structured per-finding fields the cuts read against: source pipeline, severity band, named current owner, application or asset reference, CVSS 3.1 vector. The same record is the identity the same-asset-same-CWE reopen rule resolves against on intake.

The activity log

The activity log holds the append-only chronology of every state transition with the named actor, the timestamp, the prior state, the new state, and the transition metadata. The lookback windows query against this chronology; the audit reads the same chronology as evidence.

The retest evidence

The retesting workflows feature pairs the retest finding to the original finding so the closure carries verification evidence rather than an engineering claim. The failed-retest queue is a direct read off the retest outcome field on the paired finding.

The scan baseline diff

The scan comparison and diff feature surfaces the reopened-finding event as one of the structured change-event classes between two scans against the same target. The regression-against-closed queue reads against this stream rather than against a hand-built comparison.

The override register

The finding overrides register holds compensating-control closures, accepted-risk closures, and false-positive dismissals with a named reviewer, a documented rationale, a scope, and an expiry. The overturned-false-positive class on reopens reads against this register so the dismissal lineage is preserved on the reopen transition.

The leadership narrative

The AI reports surface composes an executive narrative from the structured finding records and the activity log. The narrative reads the reopen-rate trend, the cut breakdown, and the regression-class composition into a defensible leadership view rather than a hand-built slide each quarter.

The recurring detection

The continuous monitoring and scheduled scans surfaces produce the recurring scan cycles against which regressions surface. The frequency bands (daily, weekly, biweekly, monthly) determine how quickly a regression becomes a reopen event the dashboard reads.

The third-party import

The bulk finding import surface lets external scanner output (Nessus, Burp, CSV) enter the same finding catalogue under the same reopen-identity rule, so regressions surfaced by a third-party scanner reopen the original record rather than mint a new ID under a different source pipeline.

Honest scope is part of the operating model. SecPortal does not ship native Jira, ServiceNow, Slack, SIEM, SOAR, or GRC integrations; the metric is producible without them, but a programme that routes reopen events into an external ticket queue runs the routing outside the workspace. SecPortal does not ship enterprise SSO, SCIM, SAML, asset inventory, or CMDB sync; the reopen rate reads off the workspace finding record rather than an external asset graph. The platform does not produce vendor-specific compliance certificates or compliance guarantees; the audit evidence is the workspace chronology, and the auditor reads it as evidence under whichever framework the programme is operating against.

How Each Reader Should Read Reopen Rate

The same metric reads differently for the CISO, the vulnerability management lead, the AppSec lead, the product security lead, the engineering lead, the GRC owner, and the board. Each reader has a different question reopen rate answers, and the dashboard cut they read should match the question.

CISO and security leadership

Reads the ninety-day rate across all cuts and the year-over-year movement. Asks: is the programme producing durable closures, where is durability failing, what is the named intervention, who is the named owner, and how does the rate compare to the agreed target band. See the playbook in the SecPortal for CISOs page for the surrounding programme operating model.

Vulnerability management lead

Reads the thirty-day rate weekly, the ninety-day rate monthly, and the regression-class cut. Asks: is retest discipline holding, which pipeline is producing the rework, which named follow-up cycles are open, and which engineering teams need a targeted conversation. See SecPortal for vulnerability management teams for the operating context.

AppSec lead

Reads the SAST and SCA cuts at the ninety-day window. Asks: is the closure gate on code-side findings holding, is the dependency-management discipline driving the SCA reopen rate down, are the partial-fix and residual-variant events concentrated in one application or spread across the portfolio. See SecPortal for AppSec teams.

Product security lead

Reads the per-application cut at the ninety-day window. Asks: which products are carrying the durability problem, what is the named control review on each, and how does the rate move with each product release cycle. The cut is the input to the product-side conversation about investment in security debt reduction rather than another patch round.

GRC owner

Reads the reopen-rate trend and the regression-class composition as audit evidence on remediation durability against the framework crosswalk. Asks: does the lineage support the control assertion, is the evidence chain continuous on the sampled findings, and is the metric reproducible at the audit cadence. See SecPortal for GRC and compliance teams.

Board and audit committee

Reads the annual reopen-rate trend against the prior year baseline alongside throughput, aging, and SLA breach. Asks: is the programme operating with the durability the organisation requires, what is the leadership group doing about the cuts that have moved outside the band, and what is the named programme investment that will defend the next year of operating discipline.

Six Failure Modes That Hide a Durability Problem

Reopen rate is a sensitive metric. Several common operating patterns deflate it without improving the underlying durability. Naming the failure modes makes them harder to hide and easier to fix.

Failure 1 Reporting a single flat rate without cuts. The leadership group cannot act on a flat number; the cuts are what name where the durability is failing.
Failure 2 Minting a new ID on rediscovery rather than reopening the original. The reopen counter looks healthy and the new-intake counter looks inflated; the durability problem is invisible.
Failure 3 Reading reopen rate without the regression class on the reopen transition. The rate moves and the leadership group cannot say which root cause moved it.
Failure 4 Running one lookback window in isolation. The thirty-day rate reads retest discipline; the ninety-day rate reads regression resilience; the one hundred eighty day rate reads structural durability and rediscovery. One window hides where the failure lives.
Failure 5 Closing findings administratively at the end of an engagement, a quarter, or a fiscal year without verification evidence. The reopen rate looks healthy until the next scan cycle reads the administratively closed findings back as open and the durability problem catches up to the report.
Failure 6 Quietly downgrading severity on reopen so the open-critical count stays flat. The structured severity-recalibration record on the reopen transition catches this when it is enforced; an unstructured reopen invites the deflation.

Programme Checklist: What to Stand Up in the First Ninety Days

A programme that does not measure reopen rate today and decides to start typically reaches a defensible operating model inside ninety days. The checklist below is the order most programmes run, adapted to the workspace primitives that produce the metric.

Day 1 to 15 Confirm the same-asset-same-CWE reopen-identity rule on intake so rediscoveries land on the original record. Backfill the rule against the recent intake cohort and reconcile the new-finding cohort with the closed-finding cohort to surface the rediscoveries that should have been reopens.
Day 15 to 30 Define the closed-state set and the open-state set explicitly. Decide which finding states count as closed (verified, closed, resolved, false_positive) and which count as open (open, reopened, in_review). Document the regression-class enumeration the reopen workflow records.
Day 30 to 45 Stand up the saved workspace queries that produce the rate on three windows and the named cuts. Confirm the rate is reproducible against a frozen workspace snapshot so the audit can query the same numbers later.
Day 45 to 60 Agree the target band with the leadership group. Bands are programme specific; the structure of agreeing them with named defenders is universal. Document the bands on the programme record so the next quarterly review reads the same number the team committed to.
Day 60 to 75 Stand up the cadence: weekly with the vulnerability management lead, monthly with the AppSec and product security and cloud security leads, quarterly with the CISO. Each cadence has a named owner, a saved query, an agenda template, and a programme-record decision log.
Day 75 to 90 Run the first end-to-end quarterly read. Pair reopen rate with throughput, aging, staleness, and SLA breach distribution. Document the leadership narrative and the named interventions for the next quarter. The metric is now a programme signal rather than a slide.

The vulnerability management program scorecard is the companion artefact teams use to capture the bands, the cuts, and the cadence in one programme record. The security leadership reporting workflow describes the wider leadership-reporting model reopen rate sits inside.

Frequently Asked Questions

What is security finding reopen rate?

Reopen rate is the share of vulnerability findings that were closed inside an observation window and returned to an open state inside a defined lookback window. It is the durability companion to throughput metrics.

What lookback window should we use?

Run three windows in parallel: thirty days for retest discipline, ninety days for regression resilience, one hundred eighty days for structural durability and rediscovery.

Who owns reopen rate as a programme metric?

The vulnerability management lead owns the rate as a programme signal. The AppSec lead owns the SAST and SCA cut. The cloud security lead owns the configuration-drift and IaC cut. The CISO reads it at the leadership cadence.

What is a reasonable target for reopen rate?

Targets are programme specific. A starting frame: a thirty-day rate under five percent reads as healthy retest discipline; a ninety-day rate under ten percent reads as healthy regression resilience. The right target is the band the leadership group agrees to defend.

How does reopen rate read against compliance frameworks?

It reads against ISO 27001 Annex A 8.8 and Clause 9, SOC 2 CC7.1 and CC7.2, PCI DSS 6.3.1 and 11.3.1.3 and 11.4.4, NIST 800-53 SI-2 and RA-5 and CA-7, NIST CSF 2.0 ID.RA and DE.CM and RS.MI, and CIS Controls 7. The audit reads the lineage on sampled findings as evidence.

What is the most common operating mistake?

Reporting a single flat rate without cuts by source pipeline, severity band, and team. A flat rate hides where the durability is failing.

How do we tell reopens apart from rediscoveries?

The same-asset-same-CWE reopen rule on intake. When the new detection reads the same asset binding and the same CWE classification, the workflow reopens the original record rather than minting a new ID.

What evidence does the metric leave for the audit?

The activity-log lineage on every reopened finding: the prior closure timestamp and rationale, the regression class, the named reporter and named owner, the regression evidence, the recalibrated severity if recalibrated, and the reopen-SLA target date.

How often should we review reopen rate?

The VM lead weekly against the thirty-day window. The AppSec and product security and cloud security leads monthly against the ninety-day window. The leadership group quarterly. The board annually. Off-cadence escalation when a cut crosses a documented threshold.

Run reopen rate on one workspace record

SecPortal holds the finding record, the append-only activity log, the override register, the retest evidence chain, the scan baseline diff, and the AI-generated leadership view in one workspace, so the reopen rate dashboard reads off live data rather than spreadsheet snapshots.

Get Started FreeSee SecPortal for Vulnerability Management Teams

Free plan available. No credit card required.