Plegoit

What Actually Moves Your BitSight Score

Most companies don't know what BitSight is actually measuring. Here's the signal model, how findings are weighted, and what to fix first.

You got the email. Procurement ran a BitSight scan and your score came back at 710. The threshold is 780. The deal is on hold. Now you’re googling “how to improve BitSight score” at 11pm and getting SEO content that explains what BitSight is instead of telling you what to actually do.

This is for you.

What BitSight Is Actually Measuring

BitSight doesn’t scan your systems. It passively observes signals that are already visible to anyone on the internet — DNS records, SSL certificates, traffic to known malicious IPs, data from internet-wide scanning projects like Shodan and Censys, and breach datasets. It then assigns those observations to your organization’s IP space and domains.

Your score is a weighted composite across several signal categories. The categories that matter most:

Compromised systems — This is the highest-weighted category. If any IP in your address space is observed sending traffic to botnet command-and-control infrastructure, or is listed in threat intelligence feeds as actively compromised, it tanks your score fast. This is often a surprise: the offending machine is a forgotten server, a printer, or a remote employee’s router, not your crown jewels.

Distrusted SSL certificates — Expired certs, self-signed certs on public-facing services, or certs issued by distrusted CAs. BitSight runs continuous SSL scans across your IP space and flags anything that fails validation. Every expired cert is a live finding until it’s gone.

Open ports and exposed services — Services that shouldn’t be internet-facing. RDP open to the world. MongoDB with no auth on a public IP. SMB visible on a cloud instance someone forgot to firewall. BitSight uses scan data from multiple sources and this category is consistently where engineering teams are most embarrassed.

SPF, DKIM, and DMARC — Email authentication misconfigurations. Missing or broken SPF records, missing DMARC, DMARC in monitoring-only mode (p=none). These are easy to fix and BitSight weights them meaningfully because they’re a direct indicator of basic security hygiene.

Patching cadence — BitSight infers your patch behavior from observed software versions on public-facing services. If you’re running an nginx version from 2021 on a public server, they know. If you’re running an Exchange version with known critical CVEs, they know.

How the Weighting Works

BitSight doesn’t publish exact weights, but the scoring model is well-understood from observation across hundreds of organizations. Compromised systems and open ports/exposed services cause the most damage per finding. A single active botnet communication from one of your IPs can move your score 30-40 points by itself.

SSL and patching findings are lower-weight individually but often appear in volume — a company with a lot of expired certs or outdated services will have dozens of findings dragging their score steadily down.

Email authentication findings (SPF/DKIM/DMARC) have moderate weight and are almost always fixable in hours.

The grade thresholds matter: BitSight assigns letter grades (A through F) to each category, and the overall score reflects a weighted average of those grades. Moving from a C to a B in a single high-weight category can produce a score swing you’ll actually see.

What to Fix First

Given a deadline — which you have — work in this order:

  1. Compromised systems first. Pull your BitSight findings report and look at the compromised systems list. Every IP on that list needs investigation. The finding won’t clear until the traffic stops, which means finding and cleaning the source. This usually means pulling firewall logs and hunting an infected machine or misconfigured service making outbound calls it shouldn’t.

  2. Exposed services that shouldn’t be exposed. Anything listening on a public IP that has no business being public. This is often cloud hygiene debt — security groups that were opened “temporarily” and never closed. Audit your internet-facing footprint against what should actually be there.

  3. SSL certificates. Expired certs are easy wins. Pull the list, replace the certs, wait for BitSight’s next scan. They scan frequently; findings clear within days of the fix.

  4. DMARC enforcement. If you’re at p=none, move to p=quarantine at a minimum. If you have no DMARC record, create one. This is an afternoon of work and it moves your email security grade.

  5. Patching. This one takes the longest to propagate because BitSight’s patching score is based on observed behavior over time, not just a point-in-time scan. Start now, but don’t count on it to move your score in two weeks.

The Timeline Reality

BitSight re-scans continuously but score updates aren’t instantaneous. Compromised system findings clear quickly once the traffic stops — usually within 3-7 days. SSL findings clear after a rescan, which typically happens within a week of the cert being replaced. DMARC and SPF changes propagate through DNS and clear within a few days.

Open port findings can linger. If you close a port and BitSight doesn’t rescan that specific service for a few weeks, the finding stays. You can request a rescan through the BitSight portal or through your account team if you have a relationship with them.

Realistically: if you attack the right findings in the right order, a 60-90 day timeline to move 50-80 points is achievable. Faster is possible if the score is being dragged down by a small number of high-weight issues.

If you’re looking at a deal timeline and need to understand what’s actually driving your score and what can move in time to matter, that’s exactly the kind of audit we do.