External Cybersecurity Risk Assessments

An attacker doesn't start by trying your front door. They start by looking at everything your organization exposes to the public internet — the forgotten subdomain nobody decommissioned, the employee credential sitting in a breach dump from three years ago, the vendor portal nobody remembers is still connected. An external cybersecurity risk assessment is built to answer one question: what does your business actually look like from that vantage point, and how much of it is exposure you don't know about? Most internal security reviews never ask that question, because they're built to look inward, not out.

Key Takeaways

• 59% of SMEs experienced a cyberattack in the past 12 months, per Hiscox's 2025 Cyber Readiness Report — a rate that hasn't meaningfully improved year over year despite growing security spend.
• An external cybersecurity risk assessment looks at your business from an attacker's vantage point: public-facing infrastructure, exposed data, and digital footprint — distinct from an internal audit, which examines controls you already know exist.
• 62% of breaches still involve a human element, per Verizon's 2026 Data Breach Investigations Report; an exposed external asset is frequently the thing that turns a human mistake into an actual breach.
• An automated scan is a starting point, not a finding. Confirming that an exposed asset actually belongs to your organization — and actually matters — takes human verification, not just a scan result.
• We map an organization's external exposure through OSINT and public-source research, then verify ownership and business relevance of every finding before it reaches a report — rather than handing over a raw scan output and calling it an assessment.

The Threat Landscape Hasn't Improved

Security budgets have grown for years, and the headline attack rate for small and mid-sized businesses hasn't moved in the direction that spending would suggest. Hiscox's 2025 Cyber Readiness Report — a survey of 5,750 businesses across the US, UK, France, Germany, Spain, Ireland, and Portugal conducted in July and August 2025 — found that 59% of SMEs experienced a cyberattack in the past year. That's not a niche problem affecting a small, unlucky minority; it's close to a coin flip for any given business in that size range, in any given year.

The cost of getting this wrong extends past the incident-response bill. Vercara's Consumer Risk Report, based on a November 2024 survey of 1,000 US adults, found that 70% of consumers would stop shopping with a brand after it suffered a security incident. That figure sits alongside a broader, well-documented pattern: customers rarely announce that they've quietly moved to a competitor after a breach story breaks. They just stop showing up, and the connection to the incident often goes unmeasured internally.

Why this matters: most organizations size their security investment against the direct cost of a breach — incident response, regulatory fines, remediation. The customer-trust cost is larger, slower to show up, and almost never appears on the same balance sheet line as the incident itself, which is precisely why it tends to get underweighted when a business decides how much external risk visibility is actually worth paying for.

What an External Risk Assessment Actually Is

An external cybersecurity risk assessment examines an organization the way an attacker does: from outside, using only what's publicly visible or discoverable, without any privileged access to internal systems. That's a fundamentally different exercise from an internal security audit, which reviews controls, configurations, and processes the organization already knows about and has some visibility into.

The distinction matters because the two exercises catch different things. An internal audit can confirm that a firewall rule is configured correctly. It has no way of telling you that a marketing team spun up a test environment eighteen months ago, forgot to take it down, and it's still resolving to a public IP address with a default admin password. Open-source intelligence methods applied specifically to cybersecurity exist precisely to surface that second category — exposure that's real, public, and invisible from inside the organization's own systems because nobody inside remembers it exists.

A genuine external assessment typically covers four categories of exposure:

• Public attack surface. Domains, subdomains, exposed services, and any technical signal visible to an outside party scanning your infrastructure.
• Exposed data. Credentials, internal documents, or configuration details that have surfaced in a breach dump, a misconfigured public repository, or an unsecured cloud storage bucket.
• Digital footprint and impersonation risk. Lookalike domains, spoofed social profiles, and other infrastructure built to imitate your organization rather than belong to it.
• Third-party and vendor exposure. Public signals suggesting a connected vendor or partner carries risk that could reach your own environment through that connection.

Why this matters: each of these categories is invisible to a tool that only checks configurations you already know about. An organization can pass every internal control review it runs and still be carrying exposure that any attacker with basic reconnaissance skills would find in an afternoon.

Where an Automated Scan Stops and Verification Has to Start

A technical scan is a legitimate, necessary part of an external assessment — it's the only practical way to enumerate a large attack surface quickly. But a scan output and a finished assessment are not the same thing, and treating them as interchangeable is where a lot of external risk programs quietly fall short.

A scan tells you that a subdomain resolves, that a certificate is expired, that a port is open. It does not tell you whether that subdomain still belongs to your organization or was spun off to a vendor two years ago and never cleaned up in DNS. It doesn't tell you whether an exposed email address in a breach dump belongs to someone who still works there, or whether a lookalike domain registered last week is a coincidence, a trademark issue, or active preparation for a phishing campaign against your own staff. Practical OSINT techniques for mapping an organization's public digital infrastructure — DNS records, certificate transparency logs, infrastructure relationships — are what turn a raw scan result into a confirmed finding an organization can actually act on.

We treat every scan result the same way we treat any unverified claim in an investigation: as a lead, not a conclusion. Our process runs in three stages:

1. Reconnaissance. Map the public-facing footprint — domains, subdomains, exposed services, and the methods used to check whether employee email addresses and credentials have already surfaced in a breach, plus any other infrastructure that shouldn't be publicly visible but is.
2. Verification. Confirm ownership, currency, and actual business relevance of each finding. A shared server or an expired certificate doesn't automatically mean the asset is yours, still in use, or worth prioritizing — human analysts check that before it goes in a report.
3. Prioritized reporting. Deliver findings ranked by actual business impact and exploitability, with source references and enough context that a security team can act on them immediately rather than re-investigating each item first.

This is the same methodology behind Molfar's cyber risk management practice, which combines OSINT, exposed-data review, infrastructure signals, and human analysis rather than relying on scan output alone.

Why this matters: a report full of unverified scan findings creates its own kind of risk — a security team burning hours chasing false positives, or worse, deprioritizing a genuinely serious exposure because it looked the same on paper as ten harmless ones. Verification is what makes a report usable on the day it lands, not a research project in itself.

How Molfar Verifies What an Automated Scan Misses

A mid-sized logistics company came to us after running a standard external vulnerability scan through its existing security vendor. The scan came back clean — no critical findings, a handful of low-priority items already on the team's backlog. Nothing suggested urgency.

Our OSINT-based assessment of the same public footprint turned up something the scan hadn't flagged at all, because it wasn't a technical vulnerability in the sense a scanner looks for: a legacy customer-facing subdomain, set up years earlier for a regional partner integration that had since ended, was still live and still resolving. The certificate had lapsed, which is why the automated scan had noted it — as a low-priority expired-cert item, indistinguishable in the report from dozens of routine renewals. What the scan couldn't tell was that the subdomain was still connected to an authentication endpoint nobody on the current security team knew existed, because the engineer who built the original integration had left the company two years earlier and the internal documentation never made it into the asset inventory that came after a subsequent system migration.

Confirming that took the kind of work a scanner doesn't do: tracing the subdomain's registration and hosting history, cross-referencing it against old partner-integration documentation and public DNS records, and confirming with the current infrastructure team — who had no institutional memory of the asset — that it was, in fact, still theirs to fix. The finding went from "expired certificate, low priority" to "live authentication endpoint tied to a decommissioned integration, no owner, immediate priority" once someone actually verified what the scan had only glimpsed.

Why this matters: the gap between a scan result and a verified finding isn't cosmetic. The same technical signal — an expired certificate on an obscure subdomain — can mean nothing or mean everything, and the only way to tell the difference is doing the verification work a scan was never designed to do.

FAQ

What is an external cybersecurity risk assessment?

It's a security evaluation conducted entirely from outside an organization's systems, using publicly available and discoverable information to identify exposure an attacker could find and use — public-facing infrastructure, exposed data, impersonation risk, and connected third-party exposure. It's distinct from an internal audit, which reviews controls the organization already has visibility into.

How is this different from a penetration test?

A penetration test actively attempts to exploit vulnerabilities to demonstrate real-world impact, typically with some level of authorized access or scope negotiated in advance. An external risk assessment is broader and non-intrusive — it maps what's visible and discoverable about an organization's public footprint without attempting to breach anything, which makes it a reasonable starting point before a more invasive test is commissioned.

Can an automated scanning tool do this on its own?

A scan can enumerate a large attack surface quickly, and it's a genuinely useful first step. It cannot, on its own, confirm whether a flagged asset still belongs to the organization, is still in active use, or actually carries the business impact its technical severity rating suggests. That confirmation step requires human verification against ownership records, infrastructure history, and business context — not a second automated pass.

How often should a business run an external assessment?

At minimum annually, and additionally after any material change to public-facing infrastructure — a new product launch, an acquisition, a significant vendor integration, or a cloud migration. Attack surfaces change continuously as new services go live and old ones are quietly forgotten; a point-in-time assessment from eighteen months ago tells you little about what's exposed today.

Is this only relevant for large enterprises?

No. Hiscox's 2025 data puts SME cyberattack exposure close to 59% in the past year alone, and smaller organizations frequently carry more unmanaged legacy infrastructure relative to team size — fewer people responsible for tracking what's still live, not less exposure to begin with.

What does Molfar's assessment process actually involve?

Reconnaissance of the public-facing footprint through OSINT and public-source research, verification of ownership and business relevance for every finding, and a prioritized report ranked by actual exploitability and impact — with source references throughout, so a security team can act on it directly rather than re-verifying our findings before doing anything with them.