Two Risks. One Blind Spot.

We ran a first external scan for a customer last year. Thirty-two of the risks we surfaced in month one appeared in their auditor's report six months later. Same findings. Six months apart. 

Nothing was wrong with their compliance programme. They had the register, the framework, the assessments, the evidence. What they did not have was a view of what was already visible from outside.

That gap is what this piece is about.

Two risks, one blind spot

Most organisations now carry two distinct categories of risk, and they usually manage them in separate rooms.

Regulatory risk sits with compliance. It produces penalties, enforcement, legal costs, notification obligations and scrutiny that does not go away after the first finding.

External cyber risk sits with security. It produces breaches, downtime and losses that show up on the P&L before anyone writes a report about them.

Different owners, different reporting lines, different budgets. But when you look at what actually causes each one, the underlying failure is identical. A risk exists and the organisation does not have enough visibility to act on it.

Regulation stopped being a documentation exercise

For years, compliance meant having the policy. Write it, approve it, produce it when asked.

That has changed. DPDPA puts direct accountability on Indian organisations for how they protect data. Financial sector regulators here have become considerably more prescriptive about technology and cyber risk. In Europe, NIS2 and DORA moved resilience out of the IT department and into the boardroom, with named accountability for individuals.

The question a regulator asks now is not whether you have a policy. It is whether you can demonstrate that you understand and manage the risk the policy was written to address.

Those are very different questions, and a lot of organisations can answer the first one confidently and the second one not at all.

The risk that does not wait for an audit

External risk behaves differently. It does not appear on a compliance calendar or arrive as a regulatory notice. It is already visible on the internet, and it has been for a while.

An exposed cloud asset. A forgotten subdomain from a project that ended two years ago. A dev environment someone left publicly indexed. A leaked credential circulating on a forum. A lookalike domain registered last month. An administrative interface reachable from anywhere.

An attacker does not care about the assets your security team knows about. They care about what they can find.

We see the same pattern in nearly every first scan. The customer's internal asset inventory and their actual external footprint do not match. Not because anyone was negligent, but because the footprint moves faster than the inventory does. Cloud accounts, SaaS tools, APIs, third-party integrations, AI services. Every one of those adds surface, and most of them are stood up by people who do not think of themselves as making a security decision.

When External Exposure Becomes the Entry Point

This is not theoretical. In June 2026, Symantec reported a ransomware attack against an unnamed IT services company in South Asia where attackers gained initial access through an internet-facing IIS web server. They uploaded an ASP.NET web shell, established persistence, disabled security controls, and moved through the environment before deploying ransomware. The initial access came from an asset that was already exposed to the internet.

The lesson is not simply that the server should have been patched or better secured. It is that the organisation had an externally reachable asset that became the first step in an attack chain. What was visible from the outside became the attacker's opportunity on the inside.

That is exactly the gap external attack surface monitoring is designed to address: continuously understanding what is exposed, whether it is still required to be exposed, and whether the risk associated with that exposure has changed.

Absence of an alert is not absence of risk

This is the assumption that costs the most: nobody has reported it, so it must be fine.

A forgotten asset stays unnoticed for months. A vendor system introduces a vulnerability that never enters your inventory because it was never yours. A leaked credential circulates privately long before anyone uses it. A vulnerability is publicly known while the affected company has no idea the vulnerable asset is still live.

Nothing alerted, because nobody was looking in the right place.

Where the two risks collide

Take an internet-facing application that was never properly secured.

To security, that is external exposure. To compliance, it is a failure to implement an appropriate control. If someone exploits it and data is compromised, it becomes both at once, and the cost is no longer additive. A single weakness can become simultaneously a security incident, a regulatory event, and a business continuity problem. 

That is the argument for not separating these two disciplines as cleanly as most org charts do. A compliance framework tells you what controls should exist. External monitoring tells you what an attacker can actually reach. The distance between those two answers is where your real risk lives.

What a board should be asking

Not "are we compliant" and not "how many open findings do we have."

How much regulatory exposure do we carry, and where. How much external exposure, and where. Which of these could produce a penalty, which could produce an incident, and which could produce both. Are we reducing risk, or are we documenting it more thoroughly than last year.

A risk register is only as good as the data feeding it. If the external environment changes daily and the assessment behind the register is six months old, the register describes a company that no longer exists.

Where we sit

At NMT Security we built NOVA AI around the view that these two pictures belong in one place.

External attack surface monitoring gives an outside-in view: applications, network, email, public exposure, brand risk, dark web. Third-party risk extends that to the companies you depend on. AI governance covers the systems that got deployed in the last eighteen months without going through anyone's approval process. Compliance mapping turns all of it into evidence.

The output is not another list of findings. It is a ranked view of what to fix first, weighted by what actually matters in that environment. The same vulnerability is critical for a company holding patient records and irrelevant for a retailer, and a severity score that ignores that is not helping anyone.

Going back to where this started: those thirty-two risks were always there. The auditor found them because that is the job. We found them six months earlier because we were looking from outside, continuously, rather than once a year from inside.

Your organisation has risk. That was never in question.

The question is whether you can see it before someone else does.