Methodology

What this is

A tiered cyber-security posture platform for small and mid-sized businesses. It starts with a free, public scan of what a domain already reveals to the world and escalates — under progressively stronger authorisation — to an in-depth, owner-only vulnerability assessment. Every tier is built for two audiences at once: a non-technical owner sees what each result means and how to fix it, while a technical reviewer can expand any finding for a professional-grade explanation. That two-tier writing is deliberate — most scanners speak only to engineers, which leaves the people who actually make risk and purchasing decisions unable to act.

Guiding principle: the gate is proportional to the harm

The platform's organising rule is that the strength of the authorisation required scales with how much a check could affect its target. Reading public information needs no permission; actively probing someone's infrastructure needs proof you're entitled to. This keeps the tool defensible, lawful, and safe to expose to anonymous users at the free end while still offering real depth to verified owners at the top.

• Passive scan, self-assessment & readiness questionnaires — no gate (zero harm).
• Exposure check — light gate: a soft per-browser usage limit (no account).
• In-depth vulnerability scan — strong gate: proven domain ownership via a private claim link, paid, run on a separate engine; results auto-deleted after a short grace window.

Privacy-first by default. The platform runs without accounts: no sign-up, no email, and nothing retained beyond a short grace window. Authorisation for the in-depth tier is carried by a secret claim link rather than a login; the self-assessment and readiness questionnaires are computed in your browser and your answers aren't stored. Collecting as little as possible is itself a security and governance choice — data we never hold can't be breached, misused, or demanded.

The tiers

1. Passive security-posture scan — free, no login

Enter a domain and the tool inspects publicly observable signals — HTTP security headers, TLS/certificate configuration, email-authentication DNS records (SPF, DMARC), DNS hygiene (CAA, DNSSEC) and the domain's infrastructure reputation against public threat-intelligence databases — and returns a graded report card with plain-language explanations and an optional technical deep-dive per finding.

Every check here is passive: it reads information the domain already publishes — DNS records, the certificate presented on a TLS handshake, the headers returned with a normal web request. It never probes ports or enumerates services; nothing it does is distinguishable from routine, authorised internet traffic. That is a governance decision, not a technical limit: active scanning of infrastructure you don't own sits in a legal grey area under computer-misuse statutes (e.g. the US CFAA or the UK Computer Misuse Act), so the free, anonymous tier is kept strictly passive.

The newest passive check, infrastructure reputation, follows the same rule: it resolves the domain's public IP and asks free threat-intelligence databases — AbuseIPDB, VirusTotal and URLhaus — whether the domain or IP has been reported as malicious. It queries those third parties, never the target, so it stays fully passive. Each provider is optional, enabled per deployment by its own API key, and the check degrades gracefully if none are configured. Where the domain resolves to shared CDN/edge infrastructure, an IP-reputation hit reflects the CDN rather than the customer's server, so it is downgraded to an informational caveat rather than raised as an alarm.

Because this tier only sees what is published, the report is framed honestly: a low grade means recommended public signals are missing, not necessarily that a site is insecure. Large platforms and CDN-fronted sites often omit these headers on their root domain on purpose (scanning a big provider's apex frequently hits a redirector rather than the real application), and headers can differ per endpoint. The report says so, so a red-heavy result is never mistaken for a verdict.

2. Cyber-hygiene self-assessment — free, login optional

A guided questionnaire mapped to NIST CSF 2.0. It scores maturity across the framework's functions, draws a radar chart, and produces a plain-language gap report with prioritised recommendations. This captures the internal practices the outside world can't observe — the other half of a posture picture.

3. Exposure check — login + usage limits (the "shallow active" tier)

A TCP-connect check across a curated set of ~16 high-signal ports (web, mail, databases, remote administration). It reports what is exposed, not exploitation — which services answer the public internet and which usually shouldn't. Findings are explained in plain language with concrete remediation.

This tier needs no account: simply observing what a host already exposes is low-harm, so it's open to anyone, protected only by a soft per-browser usage limit that deters casual over-use (a determined user could run the same check with off-the-shelf tools anyway). Nothing is stored. If the site sits behind a CDN, the results reflect the CDN's edge rather than the origin, which the tool states plainly.

Because this tier actively touches its target, some targets are declined outright — see "Targets we won't scan" below.

4. In-depth vulnerability scan — paid, owner-verified, separate engine

The intrusive top tier, and the one the platform is really built around. It runs without an account: before it runs, the requester must (a) prove they control the domain and (b) acknowledge the scope of what's being scanned.

• Ownership verification offers two self-serve routes — a token file at the web root or a DNS TXT record — mirroring how reputable commercial scanners and bug-bounty programmes establish authorisation. Proven ownership is the legal basis for testing. Verifying issues a private claim link: a secret, unguessable URL that is the only handle to the scan. The owner pays once, runs the scan, and returns to that same link for the report — no login, nothing tied to their identity. Lose the link and you simply re-verify.
• Scope acknowledgement reminds the owner that they may test their own site and application, but the servers and network beneath it usually belong to their hosting/cloud provider — so they should check that provider's penetration-testing / acceptable-use policy first.

Because the job runs asynchronously on the separate engine, the owner can close the page mid-scan and return to the claim link later — the scan keeps running. The finished report, and the verification behind it, are automatically deleted after a short grace window; payment is handled by a third-party processor in guest mode, so we never hold card details or build a customer profile.

The scan itself runs on a dedicated engine, decoupled from the web app via a job queue, so the heavy, long-running tools live outside the serverless platform. It combines nmap (port sweep with service/version detection) and nuclei (template-based checks for known CVEs and misconfigurations).

The differentiator is not the scanning engine — those tools are industry standard — but the interpretation layer on top of it. Each finding is translated into plain language and mapped to NIST CSF 2.0, ISO/IEC 27001:2022 and CIS Controls v8, and a "what this means for your setup" summary explains, per exposed service, what an owner can realistically change on shared/managed hosting versus their own server (always caveated, since the plan can't be known from outside). A verified owner can re-scan within a window to confirm fixes, and every report states its own coverage so a partial scan is never presented as complete.

Targets we won't scan

The exposure check and the in-depth scan actively touch a target, so two limits sit in front of them.

Scans are keyed to a domain, never a bare IP address. A domain is something an owner can prove they control — that proof is the entire basis of the in-depth tier — whereas an IP address proves nothing and very often hosts many unrelated customers, so scanning one would reach systems that aren't yours.

We decline to run the exposure check against government, military, policing and healthcare domains. The check is deliberately shallow: it looks at which doors are visible from the street, never at what's behind them. But shallow describes our intent, not how it looks from the other end. To a monitoring team an unexpected port scan is indistinguishable from the first step of a real attack, because that is genuinely what the first step of a real attack looks like — so it gets logged and attributed long before anyone asks why. These organisations also have their own security teams and formal testing routes that will give a far better answer than we can. When a scan is declined we say so plainly, show which pattern matched, and explain the reasoning rather than simply refusing.

Two honest caveats. First, this is not a legal test. Under computer-misuse law what makes security testing lawful is authorisation from the system's owner, not how gentle the test is or who the target happens to be — which is why every user confirms they're authorised before an active scan runs. That confirmation is the primary control; the list is a second layer beneath it. Second, coverage is good, not complete: government and military domains are identifiable with high confidence, UK health and policing domains likewise, but critical national infrastructure is largely indistinguishable from any other business in DNS. We'd rather state the limit than imply a guarantee.

The passive tools are unaffected. The posture scan, email-spoofing check, link checker and readiness cross-checks read only what a domain already publishes to the world, so they remain open for any domain — including the ones above.

Cyber Essentials readiness — cross-checking what you say against what we see

Cutting across the tiers is a Cyber Essentials readiness report, mapped to the UK government-backed scheme's five controls (firewalls, secure configuration, security update management, user access control, malware protection). It adds no new scanning — it re-projects the signals the platform already gathers onto those five controls — so it inherits every existing gate.

As a free, logged-out questionnaire it returns a per-control readiness verdict in plain English, with the same honesty discipline as the rest of the platform: one mandatory item failing (e.g. MFA missing on any account, an unchanged default password, unsupported software) flips the whole verdict to "would fail today", however green everything else is — mirroring how a real assessment works.

The engine can also do the one thing a self-assessment alone cannot: cross-check the self-declared answers against what our scans actually observed — "you said you patch critical updates within 14 days, but our in-depth scan found an unpatched CVE." Every line is labelled by evidence strength — verified (seen by a scan), self-declared, contradiction (a claim a scan disproves), or genuinely unverifiable from outside (e.g. endpoint anti-malware). That contradiction detection is exactly the gap between standard Cyber Essentials (self-assessed) and Cyber Essentials Plus (hands-on audit). In the account-less default this cross-check still runs with no login: name a website and we perform a fresh, zero-harm passive read (security headers + TLS) and contradict your answers against it — covering the everyday cases (weak encryption in transit, missing secure-config). The deeper contradictions from a full vulnerability scan (known CVEs, exposed services) are added when a signed-in account can supply the user's own stored scans.

This is a readiness / gap report to help you prepare — not a certification, and we are not an IASME Certification Body; to certify, an organisation applies through an accredited body. The same generic engine already powers a second pack — a UK GDPR / data-protection readiness check (a plain-English self-assessment across the areas the ICO examines, explicitly not legal advice) — and is designed to take further frameworks (ISO/IEC 27001, NIS2) as additional rule packs over time.

Scoring (passive scan)

The passive report begins at 100 and deducts points per failed check, weighted by severity (critical 30, high 15, medium 8, low 3, info 0). The total maps to a letter grade (A ≥ 90, B ≥ 75, C ≥ 60, D ≥ 40, otherwise F).

Two honesty principles govern it:

• Unverifiable is not the same as failed. When a check can't be completed — a site refusing an automated connection, say — it's recorded as informational with zero penalty, not scored as if the protection were absent.
• Severity reflects real-world impact, not checklist completeness. Email-spoofing exposure and expired certificates outweigh a missing low-risk header, because they map to materially larger business consequences.

Framework alignment

Findings across the tiers map to internationally recognised, jurisdiction-neutral controls. These mappings are indicative — to help an organisation connect a finding to its existing control framework — not a claim of certification or audit.

The platform deliberately avoids region-specific regimes as its primary frame so it remains applicable across global markets; sector- or region-specific frameworks can be layered on as an optional mapping later.

Known limitations

Stated plainly, because acknowledging them is part of doing this credibly:

• The passive legacy-TLS check is best-effort. It flags a weakness only on a successful handshake with an old protocol version, and the runtime may itself decline to offer TLS 1.0/1.1, which can mask a server that still accepts them.
• A single request, one vantage point, one moment. Passive results reflect what the domain returned to one automated request; geo-distributed and repeat sampling are out of scope.
• CDN edge vs origin. Both the passive and exposure checks may reflect a CDN rather than the origin server; this is surfaced in the results.
• Reputation is optional and only as good as what's been reported. The threat-intel check runs only where API keys are configured and queries third-party databases, not the site itself — so a clean result means nothing has been reported, not that a site is guaranteed safe; and on shared CDN/edge IPs a hit is treated as an informational caveat, not the customer's own server.
• The in-depth scan is only as complete as the run. A scan can be limited by time budgets or template coverage; every deep report states what each tool did (including partial or skipped steps) so coverage is never overstated.

Roadmap

• Continuous monitoring — scheduled re-scans with change alerts and exportable, saved history so on-screen and PDF reports always match a point in time.
• More framework rule packs — ISO/IEC 27001 and NIS2 readiness on the same generic engine that already powers the Cyber Essentials report; each new framework is a content pack and a signal adapter, not an engine rewrite.
• Broader interpretation — tuning the framework and deployment mappings as real scan output is observed, and optional sector/region framework overlays.
• Operational hardening for multi-customer use (managed review workflows, SSRF hardening on the verification fetch).

About

grc-scan was founded by Andrew Siropiatov, a financial-services risk professional with 20+ years assessing counterparty, credit and operational risk at institutions including the EBRD and Crédit Agricole. The platform began from a single conviction: the discipline that governs risk inside regulated finance — repeatable frameworks that turn scattered signals into clear, comparable, evidenced verdicts — is exactly what smaller businesses lack when they try to understand their cyber exposure.

That work most recently included leading venture due diligence on technology start-ups: designing one consistent assessment framework and applying it across teams, markets and technologies to produce comparable, defensible conclusions. The same approach shapes every design decision documented above — the gate-proportional-to-harm model, the honest scoring that refuses to mistake "unverifiable" for "failed", and the mappings to NIST CSF 2.0, ISO/IEC 27001:2022 and CIS Controls v8.

That risk-and-governance foundation is paired with formal security credentials, and the platform is being built to a professional standard from day one. We are now building out the team and an advisory board across cyber security and operational-risk governance to guide the platform's next stage of growth.

grc-scan is deliberately scoped today and expanding with intent. We welcome conversations with prospective customers, partners and advisors.

Andrew Siropiatov, Founder — LinkedIn