Methodology

Built around evidence, not unexplained scores.

What is measured, how a status is assigned, how the score is weighted, how evidence is preserved, and where the method stops being able to tell you anything. Read this before you quote a number from the tool.

Measurement

Only what an outsider can observe.

Every control in the catalog is answered from the public internet, without credentials and without privileged access. In practice that means five kinds of observation:

  • DNS queries for records the domain publishes: addresses, mail routing, policy records and delegations.
  • Mail authentication policy read from TXT records: SPF, DMARC and discoverable DKIM selectors.
  • TLS handshakes against the public endpoint, including protocol version, cipher and certificate chain.
  • HTTP response headers from a single unauthenticated request per control.
  • Protocol-level reachability of specific high-risk ports, with at most a negotiation exchange — never a login, a listing or a payload.

Nothing behind a login is examined. Nothing on a private network is reached. Nothing is enumerated, fuzzed, brute-forced or exploited.

Vantage point and reproducibility

External observation depends on where it is made. A record can resolve differently for a different resolver, and a firewall can answer one network and drop another.

That is why every finding quotes the observation itself. A reader can repeat the query from a machine outside their own network and compare the answer. If the two disagree, the finding is stale or vantage-specific — and the report says that is a normal result, not a tool fault.

Statuses

Four outcomes, and the difference between them matters.

The distinction between a failure and an absence of an answer is the core of the evidence model.

Score credit is shown per status. Inconclusive controls are excluded from both the numerator and the denominator of the score.
StatusMeaningScore credit
PassThe observed control meets the published expectation.100%
WarningThe control exists but is weaker than intended, or partially configured.partial
FailThe control is absent, or what was observed contradicts the expectation.0%
InconclusiveNo conclusive answer arrived before the timeout. This is not a failure.excluded

Scoring

How the 0–100 score is calculated.

The score is a weighted mean over the controls that reached a conclusive status. It is arithmetic, not judgement, and it is reproducible from the report.

  1. Each control resolves to a status: pass, warning, fail or inconclusive.
  2. Each control carries a severity weight from 1 to 5, reflecting the consequence of the exposure it describes.
  3. Pass earns full credit, warning earns partial credit, fail earns none. Inconclusive controls are excluded from both sides of the fraction.
  4. Control results roll up into the five categories using the category weights below.
  5. The final score is rounded to the nearest integer and mapped to a grade band.

If every control that ran passed, the score is 100. If none passed, it is 0. Partial configurations land in between, weighted by how much the individual control matters.

A high score means the measured controls met their expectations. It does not mean the business is secure.
Category weights. The public sandbox reports a read-only subset, so a sandbox score is derived from the subset that ran and is not directly comparable to a full 22-control assessment.
CategoryWeightControlsWhat it covers
DNS & domain integrity20%5Whether the name resolves as intended, whether answers can be tampered with in transit, and whether the zone leaks control to a stranger.
Email authentication25%5Whether a stranger can send mail that looks like it came from your domain - the exposure behind invoice fraud and business email compromise.
Transport security20%4How the site proves its identity and which protocols and ciphers it is willing to negotiate with a visitor's browser.
Browser security headers15%4The instructions a server sends to the browser. They are cheap to add, commonly missing, and directly affect how much a single scripting mistake can do.
Network & service exposure20%4Whether high-risk services answer on the public internet. Detection is protocol-level only: no login, no share listing, no payload.

Grade bands

The same bands apply to every target. The current recorded assessment is grade B.

A90-100StrongEvery control that completed meets its published expectation, or is one minor gap away.
B80-89StrongWell configured overall. The gaps are informational or low-impact hardening items.
C65-79FairMeaningful gaps in at least one category. Worth a planned fix, not an emergency.
D50-64Needs workSeveral controls are missing or weak across more than one category.
F0-49UrgentCore controls are absent. Start with the highest-severity findings and work down.

Evidence

No claim without evidence.

Every conclusive finding quotes the record, header or handshake behind it. The report is designed so that a sceptical reader can check it without running the tool.

Quoted observation

An evidence string is a literal fragment: a DNS answer, an SPF policy, a certificate subject, a header value, a negotiate response code.

Copy and re-check

Every evidence block in this site can be copied with one click. Re-run the equivalent query yourself and compare — that is the intended workflow.

Consent travelled with it

Each report embeds the hash-chained consent receipt recorded before the run, including the policy version and its digest.

A failed control is not a confirmed vulnerability. It means the published expectation was not met. It is not an exploit, it is not proof of compromise, and it is not a verdict on the business. Treat every finding as a reason to look, then verify.

Boundaries

Where this method stops.

The limitations are part of the methodology, not a footnote to it.

What the method cannot see

  • Anything behind authentication: applications, admin panels, customer portals
  • Internal networks, directory services and endpoint configuration
  • People, process and physical security
  • Whether a weakness is actually exploitable
  • Compromise, past or present
Full limitations

Known sources of error

  • Resolver and location differences producing different answers
  • Rate limiting or filtering creating inconclusive results
  • Configurations that are correct for the business but unusual for the standard
  • Time: a finding describes one moment, not a permanent state

When an error is possible, the report states the observing condition instead of hiding it.

Reporting

Every report carries proof of authorisation.

Before a run, the operator accepts the privacy policy and records a receipt. Receipts are hash-chained, so a deleted or altered entry breaks the chain and verification fails.

  • ContentsConsent ID, ISO-8601 UTC timestamp, operator, target, policy version and digest, previous receipt hash and this receipt's hash.
  • StorageWritten to the machine that ran the assessment. Never uploaded to this website.
  • VerificationOne command re-walks the chain and reports whether it is intact.
consent receipthash chain intact
{ "consent_id": "CONSENT-20261028-A91144E4", "timestamp_utc": "2026-10-28T17:25:30Z", "operator": "public-demo", "target": "example.com", "policy_version": "2026.10-sandbox-v2", "statement": "authorised sandbox use", "receipt_sha256": "b068e643725c90429199d458b31a0749b08b4af1caae57fe4ea8878f412820a6" }

Sanitised excerpt of the receipt embedded in the recorded report. The operator label is the demonstration identity used for the public run.

Read the method, then check the evidence.

The catalog documents every control; the sample report shows what the output looks like when the method is applied.