What the score measures and what it does not
The Security Score rates the externally visible attack surface of your domains. This means everything an outsider can see without login credentials: your website, your mail servers, your DNS records and the reputation of your addresses. From this come the categories network security, application security, DNS, IP reputation, email security and data leaks, each with its own score from 0 to 100.
This is deliberately an outside view. Attackers start there, and many incidents go back to simple misconfigurations: missing security headers, weak email authentication, outdated software on a forgotten server. Findings like these are often fixed quickly once you know about them.
What the score does not measure is just as important. It does not see what lies behind the login, how your staff are trained or whether your backups work. It replaces neither a penetration test nor a management system. A good grade means a clean outside view, not a secure company. That is why, in Sightadel, the score sits next to the compliance progress for each framework rather than taking its place.
How to work through the issues
Start with the issues that make the biggest difference. The list can be filtered by severity, and each issue shows its impact on the score. Critical and high findings come first, then the medium ones. Low and informational findings you deal with when there is time, or you make a conscious decision to ignore them.
Open each issue in the detail view. It contains the description, detection details, affected assets and a suggested fix. First check whether the affected asset still belongs to you and is still needed. Sometimes the best fix is to switch off an old service.
Set the status to “In progress” as soon as someone is working on it. For larger changes, create an action plan with an owner and a deadline and link it to the matching control. Once the issue is fixed, mark it accordingly. A new scan confirms the fix before the issue is closed.
If a finding is intended in your case, set it to “Ignored” and give the reason for the decision. This keeps the score honest and the decision traceable.
Communicating the score properly
A score from 0 to 100 and a grade from A to F are easier for management to understand than a list of header names. Make use of that, but explain the score. Its development matters more than the number itself. The history over 7, 30, 60 and 90 days or one year shows whether the situation is improving.
Report the score together with the categories. A good overall score can hide strong email security alongside weak application security. The categories show where the problem lies and who is responsible: web development, mail operations or network.
Do not make the score a goal in itself. Anyone who only looks at the number is tempted to ignore inconvenient findings. A better goal is one like this: critical and high issues stay open no longer than a fixed period that you set in your policy.
You show your status externally through the Trust Center. The Sightadel seal there links to your scorecard. This shows customers that your information comes from a maintained system.
What auditors take from it
When auditing vulnerability management, an auditor does not check whether you have no vulnerabilities. Nobody has none. The auditor checks whether you have a process to identify, assess and treat them, and whether that process is actually followed.
The Security Score provides evidence for this. The list of issues shows when a finding was first and last detected, its status and how it affects the score. An action plan linked to the control shows how the technical finding became a managed measure. The score history shows the effect over time.
Make sure this matches your documents. If your policy states that critical vulnerabilities are fixed within a certain deadline, the auditor will want to see examples. Ignored findings without a reason also stand out.
Here, too, the scope boundary matters. The outside view covers only part of vulnerability management. Internal systems, workstations and applications behind the login need their own checks. You store their results as evidence in the archive.
