Methodology
This page sets out exactly how the figures in our reports are produced. We would rather you be able to challenge a number than be asked to trust it, so the formulae are written down here in full, with their weights, their thresholds and the points at which we have deliberately chosen caution over precision.
Our position, stated once so the rest of the page reads correctly: everything we publish is an observation drawn from public information, not a verdict on how an organisation is run and never an accusation against anyone. A report describes what can be seen from the outside on the day it was produced. It is not a penetration test, an audit, or a statement that a company has been breached.
The Cyber Exposure Score
The Cyber Exposure Score is a single number from 0 to 100 — higher is better — built only from signals an outsider can observe without touching anything an organisation has not published. It is the weighted mean of six dimensions:
| Dimension | Weight | What it measures |
|---|---|---|
| Email authentication | 24% | SPF, DKIM and DMARC — whether the domain can be spoofed in email, and how strictly its own policy is enforced. |
| Exposure | 20% | The internet-facing surface: open and risky service ports and known vulnerabilities on the primary address. A CDN edge's shared ports are set aside, not counted against the organisation. |
| TLS | 16% | HTTPS and certificate hygiene: a valid, current certificate, redirection from HTTP, and HSTS. |
| Credential exposure | 16% | Public infostealer and breach telemetry associated with the domain — counts and dates only, never credentials. |
| Breach history | 14% | Public records of breaches that name the domain, and ransomware leak-site listings. |
| DNS | 10% | DNSSEC and the structural health of the domain's DNS and mail records. |
The current formula is version 1.6.0. The version is stored with every score so that a figure can always be read against the formula that produced it.
Only what we actually measured
A dimension with no evidence is left out of the average, not scored as if it were perfect. If a domain's breach catalogue never loaded, that dimension is dropped and the remaining weights are renormalised — because scoring an unchecked dimension as 100 is the quiet way a risk score becomes a lie, flattering exactly the organisations about which we know least.
Bands
The number is summarised in one word, which is the part most readers act on:
| Band | Score |
|---|---|
| Good | 82 – 100 |
| Fair | 72 – 81 |
| Poor | 60 – 71 |
| Critical | 0 – 59 |
These thresholds were fitted to the real distribution of scores across the directory, not chosen for effect, and they are refitted when the formula changes materially.
One deliberate exception: the band floor
If a domain has been named on a ransomware group's public leak site within the last 90 days, its band cannot read "good", whatever the arithmetic says. A recent leak-site claim sitting beside the word "good" is not a defensible one-word summary, so the band is held down by one step. The number itself is never changed — it stays the honest weighted mean — and the report says plainly that the band was held and why. A leak-site listing with no readable date does not trigger this: unknown is not the same as recent.
What moves each dimension
Within each dimension, specific, observable shortcomings subtract points. The larger ones:
- Email: no enforcing DMARC policy, an SPF record that cannot be evaluated, DMARC applied to only part of the mail, or a policy that leaves subdomains unprotected.
- TLS: no certificate or an expired one, no redirect from HTTP to HTTPS, and no (or weak) HSTS.
- Exposure: each open port beyond a small baseline, and a heavier penalty for risky services (remote desktop, databases, admin interfaces) and for vulnerabilities that are known to be exploited.
- DNS: a domain signed with a deprecated DNSSEC algorithm.
- Breach history / credential exposure: the count and recency of public breach records and infostealer telemetry naming the domain. These only ever add risk; "none found" is reported as "none found", never as "verified clean".
Lookalike (impersonation) risk — a separate score
A lookalike is a registered domain that resembles the one being analysed — a typo, a different extension, a word bolted on. We publish a risk score from 0 to 100 for each one. This is a separate figure and never feeds the organisation's Cyber Exposure Score: a third party's domain is not the analysed organisation's hygiene, and it would be wrong to mark a company down for a name someone else registered.
The score (formula version 1.1) weighs the signals that a name is being set up to be used against the signals that it is harmless or the brand's own:
| Signal | Effect |
|---|---|
| Listed on a phishing feed, or its host shows a "suspected phishing" warning | Top band (100) |
| Serves a sign-in page using the brand's name or images | +30 |
| Can receive mail (has an MX record) | +25 |
| Registered within 30 days (+25) / within 90 days (+12) | up to +25 |
| Email authentication set up to send (SPF/DMARC on the lookalike) | +15 |
| Loads images or styles from the brand's own website | +15 |
| Resolves to an address (+15); serves a live page (+10); presents a certificate (+8) | up to +33 |
| Visually deceptive spelling (+15) / ordinary lookalike spelling (+8) | up to +15 |
| Same registrar / mail host / nameservers as the brand (likely brand-owned) | −25 to −30 |
| Redirects to the brand, or its certificate also covers the brand's domain | −35 |
| Shows a parking or for-sale page; or resolves to nothing and cannot receive mail | −10 to −20 |
The resulting score maps to critical (70+), high (45–69), medium (20–44) and low (<20). Every lookalike in a report carries the exact list of factors that moved its own score, so the number is auditable rather than asserted. A name whose registration date we have not yet established is never treated as "new".
How we inspect a lookalike's website
To tell a dangerous impersonation from a harmless same-name business, we look at what a lookalike's home page actually serves. We do this the way a single visitor's browser would, and no more:
- One ordinary request to the home page, following normal redirects, reading a bounded amount of the page. No JavaScript is executed against the site by default, no form is ever submitted, no password is ever entered, and no address is guessed at.
- At most one request every ten seconds to the same host, and each lookalike is looked at roughly weekly.
- We identify ourselves honestly for ordinary names. For a name we already have reason to suspect of impersonation — one on a phishing feed, a deceptive spelling, a brand keyword, or a very recent registration — we make the request as an ordinary browser would, because phishing pages routinely hide from anything that announces itself as automated and show the real page only to a browser. Our purpose is solely to see the page a potential victim of our customer's impersonator would see.
- We keep findings, never content. We record flags — "a sign-in form is present", "the brand's logo is loaded", "redirects to the brand", "a parking page" — and never store a copy of the page, a screenshot, or any text from it.
Limits we are candid about: a page that hides behind an interactive challenge, or that cloaks in ways a simple request cannot see through, may look harmless to this check — so the absence of a flag is never reported as a clean bill of health. Where a page refuses our request or answers with an anti-bot challenge, we record exactly that: "could not inspect", not "nothing found".
Where the data comes from
The suite is built on public information and free, openly-licensed data. The main sources, each credited where its data appears:
- Vulnerability data: CISA's Known Exploited Vulnerabilities catalogue, the National Vulnerability Database (NVD), FIRST's EPSS exploitation probabilities, and MITRE ATT&CK technique mappings.
- Breach & impersonation telemetry: public breach catalogues, public infostealer telemetry, ransomware leak-site postings (reported as the publishing group's claim, not as fact), and public phishing feeds.
- Infrastructure: live DNS, mail and TLS records queried directly; Certificate Transparency logs; RDAP registration data; and a public-domain IP-to-network mapping.
We query live DNS, mail and web records the same way any mail server or browser does. We do not scan third-party networks: an ordinary protocol request to a published service is not a scan, and active probing of other people's infrastructure is not something we do from our platform.
Principles, and how to reach us
- Observation, not accusation. We describe what is publicly visible. We do not state or imply that any organisation is negligent, compromised or at fault.
- No personal data, no credentials. We never publish passwords, usernames, email addresses or the contents of any breach — only counts and dates.
- Verify it yourself. Most findings can be checked with standard
tools — for example,
dig TXT _dmarc.yourdomain.comfor your DMARC policy. Our reports are meant to be a starting point you can confirm, not a black box. - Corrections. If you believe something about your organisation is inaccurate or out of date, contact us at info@quiescence.eu and we will review it.
This page describes the method as of 21 October 2026. The scoring formulae are versioned; material changes are reflected here and in the version stored with each score.