SDG 2107
Methodology

How we test, what we cite, what we don't claim.

The audit works because it's verifiable, not because it's authoritative. This page is how we'd answer a lawyer asking "where did you get that?"

The core principle

We test only what your servers willingly return to any visitor. We do not attempt unauthorised access, do not submit form input, do not test credentials, and do not perform any action that modifies your systems. The audit is observational analysis of public information.

Every finding maps to a documented standard, statute, or primary source. The list below covers the test categories. The full per-dimension reference (200+ specific checks) is the Methodology appendix included in every audit PDF.

Test categories

A. DNS & email authentication

SPF (RFC 7208), DMARC (RFC 7489), DKIM (RFC 6376), MX reachability. Records pulled via standard DNS queries; TCP-25 connection tested but no SMTP commands sent. We don't claim email will have deliverability issues — only that configuration is or isn't present.

B. WHOIS & domain registration

RDAP queries via auDA (.au) and per-TLD authoritative servers (RFC 7480–7484). Privacy-shielded fields are reported as such.

C. TLS & HTTPS

OpenSSL handshake, cipher list, certificate chain, HSTS header, Certificate Transparency log analysis via crt.sh (RFC 6962). Cipher quality benchmarked against NIST SP 800-52r2 and RFC 7457.

D. HTTP security headers

CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, cookie security flags (RFC 6265bis). Each with its OWASP-referenced threat model.

F. Source code & configuration exposure

One GET request to a small list of known-default paths (.git, .env, wp-config backup, phpinfo, server-status). We report only paths returning HTTP 200 with expected content type. OWASP CWE-548 and A05:2021.

G. Admin interface exposure

TCP connection test plus HTTPS GET against common admin ports (cPanel 2083, WHM 2087, Plesk 8443, Webmin 10000, phpMyAdmin, Adminer). We do not attempt to log in.

H. CMS & framework fingerprinting

Generator meta tag, public WP REST endpoints, JS/CSS path patterns. WordPress EOL status sourced from wordpress.org/about/security. Plugin CVE histories cross-referenced against Patchstack and Wordfence public vulnerability databases.

K. Privacy & compliance presence

Privacy policy / T&C path probing (Privacy Act 1988 (Cth) APP 1.3), cookie consent mechanism detection, ABN/ACN extraction. Vertical-specific licence number checks (AHPRA s.133; NSW Property and Stock Agents Act 2002 s.36; Corporations Act 2001 Part 7.6; ACECQA; NSW Home Building Act 1989).

L. Performance — Core Web Vitals

Largest Contentful Paint, Interaction to Next Paint, Cumulative Layout Shift via Google PageSpeed Insights API (the same measurement Google uses for ranking). Source: Google Search Central Page Experience update.

M. SEO

Title tag, meta description, H1 hierarchy, schema.org JSON-LD, Open Graph, sitemap.xml validity, robots.txt syntax. Each observation; we don't predict ranking outcomes.

N. Accessibility (WCAG 2.1 AA)

lang attribute, alt text presence, form labels, heading hierarchy, computed colour contrast. We report measurable criteria; subjective UX qualities are flagged as qualitative.

P. Copy quality

LanguageTool en-AU rules plus curated patterns for subject-verb agreement, tense consistency, AU vs US English drift. Lorem Ipsum and template-default text via regex match.

The remaining categories (UX patterns, trust signals, local SEO, payments/PCI, mobile-specific, Wayback freshness, and Far Post pattern findings) are documented in full in the audit PDF Methodology appendix and in our public taxonomy file.

Defensibility

What we explicitly do not claim.

Every audit reproduces this section. It's part of why the audit stays defensible — both for us and for the prospect's own legal advisers.

  1. We don't claim your site has been compromised. We describe observable exposures that, if exploited, could lead to compromise.
  2. We don't quantify revenue loss for specific findings without baseline data. Where we estimate, we explicitly state we're inferring from industry rules-of-thumb and name the source.
  3. We don't make claims about competitors' security postures unless we've explicitly audited them with the same methodology.
  4. We don't attest that the site is or isn't compliant with any specific law. We describe observable indicators of compliance gaps and cite the relevant statute. Your legal advisers make the compliance call.
  5. We don't represent ourselves as a regulator. We're an external observer reporting on what's publicly visible.
  6. We don't store credentials or test them. Our audit performs zero credential operations.
  7. We don't fabricate sources. Every cost figure, statistic, or regulatory framing in any audit traces back to a named primary source.

Every finding is verified to matter to a real user.

It would be easy to write an audit that lists everything technically wrong with a site. Most agencies do exactly that, and most of those audits read as look how many things we found rather than here's what's actually worth fixing.

Our audits classify every finding into one of four user-impact classes before they reach the headline list:

Direct (verified)
The finding is measured against a real user-facing surface — Core Web Vitals from a real Chrome render, axe-core run against the rendered DOM, mobile tap-target sizes at actual viewport widths. Verified by construction.
Indirect (conditional, with precondition)
The finding is true now but materialises only when a specific event occurs. A missing DMARC record matters when an attacker spoofs your domain in email. A missing privacy policy matters during a regulator audit or a data-breach response. We name the precondition so you can judge whether you care.
Conditional, verified
True in the source, and confirmed to surface to a real consuming user — a typo verified to appear in a Google search result, a schema error verified by Google's Rich Results test. If verification passes, the finding stays at full severity.
Hygiene (rolled into a single low-severity row)
True but with no observable impact in normal use — a missing loading="lazy" on a below-fold image, a too-short HSTS max-age. Worth knowing about, but never the headline. Listed in a hygiene rollup so the audit reads as here are the things worth your attention, not here are 200 minor nits.

A finding classified as conditional that fails verification (or where we can't externally verify) is demoted to hygiene. Never silently promoted. Every demotion is logged with the evidence we used. An audit that hands you a long list of findings nobody actually encounters is selling fear, not service.

How to verify our work

Anyone who wants to verify any finding in an SDG audit can do so:

  1. Read the finding and the source named in the consequences citation.
  2. Reproduce the test using the methods described above. The full technical detail of every probe is documented in our public methodology file.
  3. Compare. If a finding doesn't reproduce, we want to know — every regression makes the audit better.

We make our process this transparent on purpose. Audits work because they're verifiable, not because they're authoritative.

Want the same depth applied to your site?

Commission an audit. Every test described above, run against your domain, in 48 hours, with sources cited inline.

Commission an audit