How the score works
How a domain becomes a score: the baseline, the six modules and their weights, how findings add risk, and what the score cannot see.
Last reviewed
TrustSek scores an organisation's cyber risk from the outside in. You give it a domain; it collects public evidence about that domain and the services behind it, and turns what it finds into findings and a score. Nothing is installed and nothing inside your network is touched.
This page explains the method in plain words. Every number on it comes from the scoring code, and every score records the policy version that produced it, so a change to the method is never mistaken for a change in the domain.
What the score represents
We start from a baseline: a 2% chance that an average organisation has a cyber incident in a year. The score is a multiplier on that baseline. It starts at 1.0×, the baseline, which is where a domain with no findings lands; findings only ever add to it. 3.0× is roughly three times as likely.
Each finding adds risk to its module: its severity out of 100, times how much that kind of finding contributes, times how confident we are in it. Module risk is weighted by the module weights below, and the multiplier is 1.0 plus 10 times that weighted risk. Annual likelihood is capped at 95%, because no model should claim certainty.
Some findings are serious enough on their own to set a minimum score, as long as we are at least 70% sure of them:
- A finding of severity 95 or more sets the score to at least 5.0×.
- A finding of severity 90 or more sets the score to at least 3.5×.
Risk bands
- Low under 2.0×
- At or near baseline risk.
- Medium from 2.0×
- Elevated risk; remediation recommended.
- High from 5.0×
- Significant security concerns.
- Critical from 15.0×
- Severe issues requiring immediate action.
The six modules
20%
SPF, DMARC, DKIM, MTA-STS, TLS-RPT, CAA, DNSSEC and nameserver redundancy.
20%
Whether HTTPS is served, certificates, protocol versions and ciphers, redirects, security headers and cookie flags.
20%
Claims naming the organisation on ransomware leak sites, from two independent trackers.
15%
The domain and its addresses on threat-intel, malware, phishing and botnet lists.
15%
Advertised software versions matched against known-exploited and published vulnerabilities.
10%
Subdomains, high-risk hostnames, open non-web ports, domain age and lookalike domains.
Weights from scoring policy v2.1.0. Every run records the policy version that scored it.
Finding severity
Every finding has a severity from 0 to 100. The examples are real findings from the scoring code.
- Critical
90 to 100
- No HTTPS: website served without encryption 95
- TLS certificate on malware blacklist 95
- Active ransomware claim: domain listed on leak site 95
- High
70 to 89
- High-Risk threat categories identified 88
- Recent malware indicator match 88
- Domain flagged for malware by Google Safe Browsing 85
- Medium
40 to 69
- Insufficient nameservers 65
- Weak TLS version 65
- Insecure cookie configuration 65
- Low
0 to 39
- No web service detected 35
- TLS reporting not configured 30
- Software versions disclosed in responses 30
Sources and coverage
Only public, non-intrusive sources. We do not penetration-test or send unsolicited scans. Every source ends a run in one of four states, and only one of them means clean.
- FoundThe source answered and returned evidence.
- No matchThe source was asked and had nothing on this domain. This is the only state that means clean.
- FailedThe source errored or timed out. Nothing was learned, and it is not read as clean.
- Not checkedThe source was not asked, for example because it needs a licence key that is not set up.
A source that failed or was not checked adds nothing to the score. It shows up as coverage instead, beside the number.
Collected directly
- DNS
- TLS
- HTTP
Threat intelligence
- AlienVault OTXLicence key
- URLhausLicence key
- Google Safe BrowsingLicence key
- AbuseIPDBLicence key
- ThreatFoxLicence key
- Feodo Tracker
- abuse.ch SSLBL
- Phishing.Database
Victimization
- ransomware.live
- RansomLook
Vulnerabilities
- Retire.js, NVD, CISA KEV, EPSS, OSV
Attack surface
- NetlasLicence key
- Team Cymru
- mnemonic
- WHOIS
- Lookalike scan
Confidence
Each finding carries a confidence that says how strong its evidence is. A run’s confidence is the average of its findings’ confidences, weighted by how much each one contributes, and is shown as High (from 0.75), Medium (from 0.5) or Low.
- Vulnerability matched on an advertised version0.8
- Same, on software known to backport fixes (Apache, nginx, PHP)0.6
- Subdomain estate from two CT logs / one / none0.9 / 0.8 / 0.3
- Subdomain resolution that hit the 200-name cap0.6
How recency counts
- Ransomware leak-site claimWithin 12 months: severity 95 (floor applies). Older: 75.
- Threat-intel pulses (OTX) and ThreatFox sightingsActivity within 30 days is a separate, higher finding.
- URLhaus and Feodo listingsActive listings score above historical ones.
- IP abuse reportsCounted over the last 90 days.
- Certificate expiryFlagged when under 30 days remain.
- Domain ageVery new and recently registered domains are flagged; age is read from WHOIS.
What the score cannot see
- Ransomware matching is deliberately conservative: an organisation name is matched only against the victim name or title of a post, never against its free text, because leak-site blurbs routinely name other companies. A victim listed under a trading name we do not know may be missed.
- Vulnerability detection is version-based and passive: we read what the site advertises. It cannot see a backported fix, so a distribution that patches without changing the version number may be reported as vulnerable. Version-only matches are capped at 80% confidence, 60% on backport-prone software.
- Technology fingerprinting covers common stacks rather than every framework, so an absence of detected technologies is not proof that none are present.
- DKIM has no enumeration mechanism, so selectors are discovered by probing 58 common names. A domain using an uncommon selector may be reported as having no DKIM; the number probed is recorded with every run.
- Subdomain counts include names generated by a wildcard DNS record. The estate map groups them by address so the real size is visible, but the "many subdomains" finding still counts every name.
- Threat-intel reputation is keyed on the domain string. Pulses that merely mention a well-known domain can inflate its reputation findings.
- The 2% baseline and the module weights are policy, not measurement. Every run records the policy version that scored it so a change in policy is never mistaken for a change in the domain.