A useful remediation ticket explains what was observed, where it was observed, and what success should look like. The overall score is helpful context, but it is rarely enough to tell an operator what to change.
Prepare the work
- Confirm the report date and the affected service’s purpose.
- Record the finding, hostname, IP and port where available, and the supporting evidence.
- Identify who controls the setting: the CDN, load balancer, origin server, DNS provider, registrar, or mail provider.
- Define the expected result, such as an intended certificate being served or a deprecated protocol no longer being supported.
- Schedule the change with the relevant compatibility and availability requirements in mind.
For example, a certificate ticket should identify every affected endpoint and the expected certificate names. A missing-HSTS ticket should identify where HTTPS response headers are set and what policy the service can support.
Run a fresh retest
Open the full report through your purchase link or qualifying account and use the retest control, labeled Run it now where offered. Purchases include a 30-day free-retest window under the current product model. Check the displayed eligibility and price before starting a retest outside that window.
A retest produces a new report. Returning to an old link does not update its evidence, and a home-page submission can reuse a recent result. Confirm the new scan time is after the deployment change.
Verify the finding, then the score
Check the specific endpoint and observation first. The expired certificate should be replaced, the deprecated protocol should no longer be observed, or the intended policy should be visible. Confirm that other relevant addresses received the same change.
Only then compare category and overall scores. Discovery changes, different eligible populations, and scoring revisions can affect those numbers. A new finding elsewhere does not mean your original fix failed.
When a finding persists
Check whether the change reached the public TLS terminator, whether a process needs to reload, whether DNS still returns an old address, and whether IPv6 or a secondary node was missed. For DNS policies, consider caching and delegation as well as the record you edited.
If the new report has missing evidence instead of the original finding, that is not yet proof of resolution. Use result states and connection errors to decide what the retest actually established.