An analyst reviews a finding on a legacy appliance. There is no patch. She documents the compensating control, a network restriction that limits who can reach the management interface, gets the system owner to sign off, and records the risk as accepted until the appliance is retired next quarter. Two weeks later the scheduled scan runs. The finding comes back as open. The ticket is duplicated. Nobody did anything wrong, and yet the decision has evaporated.
The scanner did not know what had been decided. Remembering that is the vulnerability management layer’s job, and it is where many programs quietly fail.
Why a forgetful tool loses the team
When a known-accepted risk reappears as new work, someone re-investigates a decision that was already made, and every other item in the queue becomes suspect. Teams respond rationally: they export the findings and keep the real state in a spreadsheet. The spreadsheet becomes the system of record and the tool a data feed, with no decision history. The same happens with false positives: if a verdict is overwritten by the next run, analysts stop recording verdicts.
Two kinds of state
Separate what the scanner observed from what the organization decided. A scan contributes observations: this host, this check, this date, this output. A person contributes decisions: risk accepted, not a real issue, belongs to that team. Each new scan adds observations. It does not, on its own, delete decisions.
When a new run reports an issue that already has a finding, it updates that finding, refreshing the latest observation and preserving the first. If the finding had been resolved, with remediation supported by a clean rescan, and the scan engine now sees the issue again, the finding should reopen with a visible marker of when: the issue returned.
If the finding was risk accepted or marked a false positive, the new observation is attached and the decision stands. A repeated observation should not silently erase an existing decision. New exploitation evidence, changed exposure, a failed compensating control or contradictory assessment evidence should trigger review, with the previous decision preserved. The difference is between “reopened because the issue returned,” “review required because the evidence changed,” and “status reset because the tool forgot.” The first two are information. The third is a defect.
Two different verdicts
A false-positive verdict disputes that the vulnerability exists: the check misfired, or the backported fix is in place. A risk acceptance concedes that it is real and decides not to remediate it for now. Both deserve protection, but a false-positive verdict should be revisited when the check or the assessment evidence changes; a risk acceptance, when the risk changes.
NIST SP 800-40 Rev. 4 treats acceptance as one possible risk response, alongside mitigation, transfer and avoidance, and recommends regular review of maintenance exceptions. Acceptance is a decision, and it has to be stored as one.
What a risk acceptance should carry
An acceptance without structure is just a suppressed finding. To be defensible it needs a reason, an approver, an expiry, an affected scope, supporting evidence and review triggers.
The reason is the text an auditor or a successor will read: what the compensating control is, or why the impact is acceptable here. “Low priority” is not a reason. The approver has authority to accept the risk on behalf of the asset owner; separating the analyst who proposes an acceptance from the person who approves it is a recommended governance practice. The scope names the assets or environments covered, so a new host with the same issue does not inherit the acceptance by accident. The supporting evidence is the artifact behind the reason: the firewall rule, the configuration export, the end-of-support notice.
The expiry date is the item most often omitted, because open-ended acceptances are convenient, and they are why accepted piles grow for years. When the expiry passes, the finding comes back into the queue as something that needs a decision. It should not stay accepted by inertia, and it should not silently flip to open as if the earlier decision never happened. The right state is: acceptance expired, previous reason and approver on record, decision required.
Review triggers cover what happens before the expiry. Take the appliance again, as a hypothetical. The acceptance rested on the management interface being reachable only from an administrative network. In month two, a network change places the appliance behind a public load balancer, and the next external scan observes the same issue from the internet. That observation does not contradict the vulnerability; it contradicts the compensating control. The finding moves to “review required,” with the acceptance intact. The analyst who proposed it and the approver who signed it review the new observation, the exposure data and the change record. If the restriction is restored, the acceptance is renewed with a note. If not, it is withdrawn and the finding returns to the open queue with a deadline. The history shows both decisions and the evidence between them.
Keep the decision history
Every status change, whether made by a person or triggered by a scan, should be recorded with who, when and why, naming the person or process and the reason or scan run. This is what lets a manager answer what was resolved last quarter, who accepted this, and on what basis. A finding resolved on the third and reopened on the eleventh should show both dates; deleting the closure because the issue returned destroys the evidence that it was ever fixed.
Ownership and deadlines
A prioritized queue that nobody owns is a report, not a work plan. Every finding should resolve to an owner, rule-based where possible, because rules survive staff turnover. CIS Controls v8.1, Safeguard 7.2 asks for a documented, risk-based remediation process that is reviewed monthly or more frequently, and a process without named owners cannot be reviewed.
Set remediation deadlines through a documented risk-based policy. Show the deadline, its basis, the responsible owner and any approved exception. A deadline is useful when it drives the queue and counterproductive as a number to be defended; if the only way to hit it is to accept risks or close findings without evidence, it measures the wrong thing. Severity alone is a poor basis, as Severity is not priority explains.
In practice
- Pick three risk-accepted findings and run a scan. Are they still accepted afterward, with reason, approver, scope and expiry intact?
- Find a finding that was resolved and later reopened. Can you see both dates, and who or what resolved it the first time?
- List every active acceptance. How many have no expiry date, and how many name a condition that would trigger an early review?
- Pick ten open findings at random. Does each have an owner and a deadline whose basis you could explain to a new hire?
Sectie’s Exposure & Vulnerability Management product follows this rule: a scan can reopen a resolved finding, but it never silently overrides a risk acceptance or a false-positive decision; changes in evidence trigger review, and every change is recorded with who, when and why.
