We used AI to draft this article.
We examined 209 retained website audit reports covering 165 distinct domains. We use the findings to frame maintenance questions, not to declare which websites have been breached. A useful report separates an observation from its interpretation and gives the responsible person a next step.
We provide managed hosting and website maintenance at ResaHost, so we have a commercial interest in this subject. We also produced the research discussed here. Our sample came from our own analysis service, not a random survey of Finnish businesses. It cannot tell us how common these issues are across the country.
We used reports stored between 12 August and 10 September 2026 and selected the latest retained report for each domain. Stored time is not necessarily measurement time. Of those reports, 128 contained eligible structured diagnostics. We cannot establish the number of separate companies from these records. We did not independently recheck the original measurements through the published aggregate.
We kept a separate denominator for each check. We did not count missing diagnostics as missing protection, and we do not add overlapping groups or percentages together. We did not investigate actual break-ins, fraud losses or whether a specific weakness had been exploited. These findings do not establish a legal violation.
We start with what the test actually observed
We found no DMARC record at the queried DNS name for 51 of 85 eligible email domains. Another 22 used p=none. Together, 73 of those same 85 domains had no record found at that name or a policy requesting neither quarantine nor rejection. We keep that combined count within its original eligible group.
We do not interpret those observations as proof that a fraudulent invoice would reach someone’s inbox. Recipient filtering and a policy inherited from a parent domain can affect the result. Our statistical analysis did not verify those factors.
We would turn the finding into a practical question: which systems legitimately send email for this domain, and who checks their authentication? That includes billing software and marketing platforms, not just the everyday mailbox. We would review the legitimate senders before tightening the policy. The UK NCSC recommends introducing DMARC gradually, starting with a monitoring phase.
We separate an old version from a confirmed vulnerability
We observed at least one publicly detected plugin version older than its WordPress.org comparison version on 46 of 73 eligible websites. We identified versions from public files or resource information. We did not sign in to verify the installed plugin inventory. A public version string may not describe the installation accurately, so we would confirm it before deciding what to change.
We therefore treat this as a maintenance lead, not a vulnerability finding. A newer release may contain a security fix, a feature change or both. We would verify the installed version, review the release information and known issues, then plan the update with a backup and a functional check.
We distinguish a missing header from browser behaviour
We found HSTS absent from 84 of 127 saved HTTP responses eligible for this check. Those records had saved headers and an HTTP status from 200 to 399. We describe the response that was recorded, not every connection a visitor might make or every way a browser might enforce HTTPS.
We would not turn that count into a claim that 84 websites left their visitors unprotected. A previously stored HSTS policy, a parent-domain policy covering subdomains or a preload entry can affect the browser’s behaviour. We would check the actual hostname and applicable policies before choosing a change.
We would also review subdomains before extending a policy to them. A setting that enforces HTTPS needs to match the services people actually use. We would verify the intended behaviour rather than adding a header simply to improve a report’s appearance.
We turn the report into an owner and a next action
We would record each observation in a short work list: what we saw, what still needs verification, who owns the check and how we will confirm the result. For email, that might mean reviewing senders and authentication reports. For WordPress, it might mean verifying plugin versions and testing an update.
We would also record uncertainty. A missing result is not automatically a missing control. A clean-looking page is not evidence that its underlying software is maintained. Neither a red indicator nor a green one should replace a discussion with the responsible administrator.
We published the full counts and methodology in our research article, now available in English and linked below. The Finnish version describes the same study, not a second dataset. We use these observations as a technical starting point, not a penetration test, a legal compliance assessment or a promise that a website is safe.
Top comments (0)