Remove a security finding you believe is incorrect

TL;DR — If a finding looks wrong, do not delete evidence or ignore it. Open the finding, record exactly why you believe it is incorrect, attach proof such as a screenshot or command output, and change its status to your platform’s equivalent of "False positive" or submit it for review. The most common fix is using the finding’s built-in dispute workflow instead of closing it as "Resolved." Reading time: ~5 min

Goal

When you finish, the incorrect finding is no longer counted as an active issue: it is either marked as a false positive (a result that looks like a problem but is not), suppressed with a written reason, or submitted with evidence so your agency can remove it quickly.

Prerequisites

• Access to the security dashboard where the finding appears
• Permission to edit findings, change status, or add comments and attachments
• The finding ID or exact title
• Evidence that proves the finding is wrong, such as:
  • a screenshot from the dashboard or cloud provider
  • the exact URL affected
  • the exact hostname, IP address, repository, or asset name
  • command output, if you have terminal access
• If you have command-line access, one of these tools:
  • curl 8.x or later — check with curl --version
  • openssl 3.x or later — check with openssl version
  • dig 9.x or later — check with dig -v

Steps

Step 1: Open the finding and capture its exact scope

In your provider’s dashboard, open the security findings list, then select the finding. Look for these fields and copy them into a note:

• Finding ID
• Severity
• Asset or resource name
• Detection time
• Evidence shown by the scanner
• Current status

Typical menu path in most dashboards:

Dashboard → Security → Findings → click the finding title

What you should see when this succeeds: a detail page showing one finding, not the full list, with the affected asset and evidence visible.

Step 2: Check whether the finding is actually about a different asset or old data

Use the exact asset name, hostname, URL, or IP from the finding and compare it to the system you own. If the finding is for a hostname or IP, verify it directly.

If the finding references a website URL, run:

curl -I https://example.com

If the finding references a TLS certificate (the HTTPS identity certificate), run:

openssl s_client -connect example.com:443 -servername example.com < /dev/null | openssl x509 -noout -subject -issuer -dates

If the finding references DNS (the internet address book), run:

dig example.com +short

Replace example.com with the exact hostname from the finding.

What you should see when this succeeds: output that clearly matches or contradicts the finding’s evidence, such as the current certificate dates, current IP, or current HTTP response.

Step 3: Collect proof in a format support can act on immediately

Prepare one short note and attach evidence. Use this exact template in the finding comment box or your internal note:

I believe this finding is incorrect.

Finding ID: FINDING-ID-HERE
Asset: ASSET-NAME-HERE
Reason: The finding reports CURRENT-PROBLEM-HERE, but the live system shows EXPECTED-STATE-HERE.
Checked at: 2026-10-01 12:00 UTC
Evidence attached: screenshot and command output
Requested action: mark as False Positive or suppress this finding for this asset

If you have command output, paste the exact output below the note. If you only have dashboard access, attach a screenshot that shows the correct state and includes the date/time if possible.

What you should see when this succeeds: the finding has a clear written explanation plus at least one attachment or pasted output.

Step 4: Use the finding workflow for incorrect results

Do not set the finding to "Resolved" unless you actually changed the system. Instead, use the status that means the finding is not valid.

Common labels across platforms are:

Typical menu path:

Dashboard → Security → Findings → click finding → Status or Actions → False Positive

If your dashboard requires a reason, enter this exact text and then edit the asset details:

Incorrect finding. Evidence attached showing the reported condition is not present on the affected asset.

What you should see when this succeeds: the finding status changes from Open/Active to False Positive, Suppressed, or Pending Review.

Step 5: Add an expiration date if you must suppress it

If your system only offers suppression, set a review date so the finding does not disappear forever without a check.

Typical menu path:

Dashboard → Security → Findings → click finding → Actions → Suppress → Expiration date: 30 days from today

Use this exact reason:

Suppressed pending validation. Evidence attached. Review after next scan cycle.

What you should see when this succeeds: the finding shows as suppressed and includes a visible expiration or review date.

Step 6: If there is no dashboard option, send a complete removal request

If you cannot change status yourself, send one message with all required details. Use email, ticket form, or the comment field—whatever your agency uses.

Paste this exactly and replace the placeholders:

Subject: Request to remove incorrect finding FINDING-ID-HERE

Please review and remove or mark this finding as a false positive.

Finding ID: FINDING-ID-HERE
Title: FINDING-TITLE-HERE
Asset: ASSET-NAME-HERE
Detected at: DATE-TIME-HERE
Why it is incorrect: SHORT-REASON-HERE
Evidence: ATTACHED SCREENSHOT / PASTED COMMAND OUTPUT / LINK TO PROVIDER SCREEN
Business impact if left open: incorrect reporting

What you should see when this succeeds: your request contains the finding ID, the asset, the reason, and proof in one place, which is enough for a reviewer to act without asking follow-up questions.

Verify it works

Check both the finding itself and the summary counts.

Use these checks:

Dashboard → Security → Findings → search by FINDING-ID-HERE

Expected result: the finding shows one of these statuses:

False Positive
Suppressed
Pending Review
Closed as False Positive

Then check the summary page:

Dashboard → Security → Findings or Dashboard → Security Overview

Expected result: the finding is no longer counted under Open or Active findings, or it is clearly listed under Pending Review instead.

If the platform rescans automatically, wait for one full scan cycle and confirm the finding does not reopen without new evidence.

Common pitfalls

Marking it as "Resolved" instead of "False Positive"

Mistake: You close the finding as if you fixed the system.

Symptom: The finding reopens on the next scan because nothing changed on the asset.

Fix: Reopen it and change the status to False Positive or Suppressed with evidence attached.

Attaching a screenshot without the asset name

Mistake: The screenshot shows a healthy system but not which hostname, account, or resource it belongs to.

Symptom: Reviewers cannot tell whether your proof matches the finding.

Fix: Attach a screenshot that includes the asset name, URL, account ID, or resource ID in the same image.

Using evidence from the wrong time

Mistake: You paste current output for a finding generated days or weeks earlier without noting that timing.

Symptom: The reviewer cannot tell whether the issue was fixed later or was never real.

Fix: Include Checked at: YYYY-MM-DD HH:MM UTC in your note and state whether the system changed after detection.

Suppressing the finding forever

Mistake: You choose suppression with no expiration.

Symptom: A real issue can be hidden if conditions change later.

Fix: Set a review date for 30 days from today or the next scan cycle.

Verifying the wrong hostname or environment

Mistake: You test www.example.com while the finding is for api.example.com, or you check production while the finding is for staging.

Symptom: Your evidence looks correct but does not match the finding scope.

Fix: Copy the exact hostname, URL, IP, repository, or environment name from the finding before you test anything.

Expecting the dashboard count to change instantly

Mistake: You change the status and immediately expect all summary widgets to refresh.

Symptom: The finding detail page is updated, but the overview still shows the old count.

Fix: Refresh the page and wait for the dashboard’s next data refresh cycle; verify by searching the finding ID directly first.

This article was written by an AI system and published pending human review. Verify anything you intend to act on.