Investigating and Appealing Diligence Findings

Bitsight’s data sources are rigorously tested and evaluated to ensure that every record included in your security rating is verifiable. However, if you believe a diligence finding is incorrect or there is an issue with how your company has been rated, please use the following guide to investigate findings and understand the requirements for filing a successful appeal.

Investigating Findings Before You Appeal

Before submitting an appeal, you should use the platform's features to investigate the finding and validate internally whether the asset is out of scope or incorrectly attributed.

• Review Forensic Information: Detailed forensic information is provided on the findings detail page for each finding.
• Understand Valid Findings: If you have remediated a finding, you cannot appeal it; the finding must live out its lifetime before it stops impacting your rating. For risk vectors that utilize Dynamic Remediation, you can eliminate findings by initiating a new scan, with removal typically occurring by the following day.
• Guest Network Activity: Findings originating from guest networks are considered valid because they occurred on your company’s network. 
  • If this is a concern, we recommend requesting a self-published rating that excludes your guest Wi-Fi network or creating a public infrastructure tag for the IP addresses handling this traffic.
  • Organizations can also self-attest and exclude guest networks and honeypots from their Bitsight rating for a renewable one-year period, allowing you to maintain full visibility into potential threats without negatively impacting their security score.

When to Submit an Appeal

You should submit an appeal when you believe a specific diligence finding is invalid or not attributable to your entity's assets. Common scenarios include:

• Open ports reported on an asset your organization does not own.
• Weak TLS reported on a host you do not control.
• A self-signed certificate that belongs to a different entity.
• Desktop software findings where acceptable logs prove the host connection did not occur.

Gathering Required Evidence

To ensure a timely review, you must provide comprehensive evidence supporting your claim. Screenshots of logs or dashboards from your internal systems are generally preferred over CSV or text files.

Ensure your evidence includes the following information based on the finding type:

• General Event Details: Date of observation, type of observation, the asset involved (domain/hostname/IP), timestamps (including a buffer of ±24–72 hours), and your reason for contesting the result.
• Proof of Ownership/Control: Updated DNS, registrar/WHOIS records, or contract/vendor termination documents proving the asset is not associated with your organization. If the issue relates to a vendor platform, include their confirmation.
• Technical and Troubleshooting Proof: Scan results showing ports closed, or network captures (headers, redirect chains), dig/nslookup outputs, and traceroutes. For desktop software, include firewall/proxy egress logs, endpoint EDR/MDM logs, or DNS logs showing no network activity to the target host.
• Certificate Details: Issuer/subject information and chain validation proving a certificate belongs to a different entity.
• Logging Details: Dates and times, source/destination ports, and source/destination IPs.

How to Submit an Appeal

Once your organization has compiled the recommended logging information and artifacts, you must submit a ticket to the Bitsight Support team.

• Attach your compiled evidence (screenshots, HAR logs, firewall logs) and a detailed explanation of why the detection or attribution is incorrect.
• Bitsight agrees to mutual confidentiality provisions with all customers, and you are welcome to submit redacted screenshots.

What to Expect

Once submitted, your case will be reviewed internally, and may require input from research, data science, and engineering teams.

• Please allow 7-10 business days for Bitsight to complete its time-intensive analysis of the data.
• Our team will verify public observables (like DNS/WHOIS/PDNS and endpoint reachability) against collection records.

If the finding is confirmed as a false positive or misattribution, the finding will be removed, severity-adjusted, or suppressed. If an endpoint remains publicly reachable or still has public associations with your organization, the findings will persist until the underlying issue is resolved.

• Depending on the scope of the correction, Bitsight will trigger a Manual Refresh (2–3 business days) or a History Refresh (1–2 business days) to update ratings and company reports. Bitsight may also apply Grace Periods where appropriate to protect your rating during these corrections.

Best Practices to Prevent Recurrence

To streamline future appeals and maintain data accuracy:

• Maintain accurate DNS/WHOIS records, promptly removing stale labels and entries.
• Standardize your log retention and retrieval procedures, and maintain an internal appeal template to speed up submissions.
• Tag egress IPs to specific business units for improved traceability.