Remediation validation and Support ticket creation

Question

When I submit a finding for remediation on a scorecard, there is no email being received with an update if the issue has been fixed or not fixed.

Answer

Starting July 2025, the process for the remediation of findings has been updated to include near instant re-scanning and validation. As a result, a Support Case (and its email communication) may not be created anymore. 

There are 3 options when submitting a finding for remediation:

1. 'technical_remediation': I have fixed this
2. 'compensating_control': I have a compensating control
3. 'false_positive': I cannot reproduce this issue and I think it's incorrect

1. 'technical_remediation': I have fixed this

Selecting this option means that the finding has been fixed and the criteria that triggered the observation are not met anymore.

For example: if 1.2.3.4:80 had a tls_weak_protocol SSLv3,TLS1.0,TLS1.1 observed, selecting 'technical_remediation' option would mean that 1.2.3.4:80 do not offer SSLv3,TLS1.0,TLS1.1 anymore.

Upon submitting using this option, a near instant scan will be triggered. If the scan reveals that the issue is not observed anymore, it will be approved. On the other hand, if the scan reveals that the issue is still observed, it will be denied and the finding will remain. No Support Case (and its email communication) will be created.

The denial of a 'technical_remediation': I have fixed this remediation always means that our scanners still observe the issue.

If the finding was approved for removal at day0 because it was not observed, but is re-observed on subsequent scanning at dayX, the finding will be re-raised on the scorecard. Indeed, that would mean that it isn't fixed anymore. 

2. 'compensating_control': I have a compensating control

Selecting this option means that the finding is still present, the criteria that triggered the observation are still observable, but there is an additional control that reduces the risk of this finding. 

For example: if 1.2.3.4:80 had a tls_weak_protocol SSLv3,TLS1.0,TLS1.1 observed, selecting 'compensating_control' option and providing in the text field a detailed description of the compensating control in place, would mean that 1.2.3.4:80 does offer SSLv3,TLS1.0,TLS1.1 but there is this control that reduces its risk.

Upon submitting using this option, a near instant scan will be triggered. Regardless of the outcome of the scan, the Compensating Control will be noted and the finding will be approved. No Support Case (and its email communication) will be created.

If the finding was approved for removal at day0 with the noted Compensating Control, but is re-observed on subsequent scanning at dayX, the same finding will NOT be re-raised on the scorecard as long as the Compensating Control is present.

3. 'false_positive': I cannot reproduce this issue and I think it's incorrect

Selecting this option means that the finding should have never been raised, the criteria that triggered the observation are still observable, but those criteria are incorrectly/inaccurately satisfied.

For example: if 1.2.3.4:80 had a tls_weak_protocol SSLv3,TLS1.0,TLS1.1 observed, selecting 'false_positive' option and providing in the text field a detailed description of the reason for it to be a false positive, would mean that 1.2.3.4:80 doesn't actually offer SSLv3,TLS1.0,TLS1.1 and that our scanners are misinterpreting the evidence.

Upon submitting using this option, a near instant scan will be triggered. If the scan reveals that the issue is not observed anymore, it will be approved. On the other hand, if the scan reveals that the issue is still observed, then it could be a false positive. A Support Case (and its email communication) will be created.

If the finding was approved for removal at day0, but is re-observed on subsequent scanning at dayX, the same finding will NOT be re-raised on the scorecard.

Additional Info

There are additional edge cases for which a Support Case (and its email communication) will be created, that are not detailed above. Because edge cases (rare, unusual, or special situations) are always shifting, evolving, or being discovered, it’s not possible to provide a complete, final list of them. In other words, new exceptions or odd scenarios keep appearing over time, so any list would quickly become outdated or incomplete.

 

Summary Table