The Gap in Your Compliance Stack Is the Part the Internet Can See

The stack that passes the audit

By the time a company reaches its first SOC 2 or ISO 27001 audit, the control stack usually looks like this: a GRC platform collecting evidence through integrations, MDM attesting that laptops are encrypted, cloud security posture management watching the AWS or Azure accounts it was connected to, dependency and code scanning in CI, perhaps an internal vulnerability scanner, and a penetration test once a year. It is a genuinely good stack. It passes audits, and it should.

It also shares a single structural property that nobody writes on the controls matrix: every one of those tools monitors an enrolled population. MDM sees the laptops that were enrolled. CSPM sees the cloud accounts that were connected. The scanner scans the target list it was given. The GRC platform aggregates evidence from systems someone integrated. Each control is honest about its population — and silent about everything outside it.

Scope is self-declared. The internet doesn't read your scope.

An audit examines the system you describe. The scope document lists your production environment, your corporate systems, your people. The auditor samples inside that boundary — which is the only way an audit can work — and the tooling above exists to evidence that boundary thoroughly.

Attackers run the complement of that search. The things that keep starting incidents are almost a genre:

• A staging subdomain from 2023, still resolving, still running the framework version it launched with — never in the scanner's target list because nobody remembered it exists.
• A dangling CNAME pointing at a deprovisioned cloud service, waiting to be claimed by someone else.
• A microsite a contractor or agency stood up under your domain, on their hosting, outside every integration you own.
• A certificate expiring on a hostname the uptime monitor was never pointed at.
• An SPF record that quietly got broader during a marketing-tool migration, on a domain the email team considers done.
• A lookalike domain registered last week, aimed at your customers — definitionally outside your infrastructure altogether.

None of these are failures of the enrolled-asset tooling. They are outside its population, which is the point: the riskiest assets are the ones that were never written down, and every inside-out control depends on the writing-down having happened.

"Compliant but breachable"

Here is the uncomfortable part. The frameworks do ask for this. SOC 2's CC7.1 wants monitoring for configuration changes that create vulnerabilities; ISO 27001's A.8.8 wants technical vulnerabilities managed across the organization's assets. In practice, both are routinely satisfied with evidence from the enrolled population — the internal scanner's report, the CSPM dashboard — because that is the evidence that exists. The auditor accepts it, reasonably. The letter of the control is met.

The intent of the control — know your exposure — is met only for the inventory you already had. This is how organizations end up compliant and breached in the same quarter, and why post-incident reports so often contain the sentence "the affected system was not covered by existing monitoring." It was not covered because nothing in the stack was capable of finding it, only of watching it once found.

What an outside-in control actually adds

An external scanner inverts the population problem. It starts from your domains — the one inventory you cannot forget, because it is on your business cards — and works outward from what the public internet can observe:

• Discovery, not enumeration. Certificate transparency logs surface every hostname that gets a certificate under your domains, including the ones nobody declared. The asset list stops depending on memory.
• The attacker's vantage point. Checks run from the internet with no credentials and no agent — the same view reconnaissance gets. If it is visible to the scanner, it was already visible to everyone.
• Continuity between audits. Point-in-time assessments bound drift at a year; scheduled scans bound it at days. A port that opens the week after the pen test is found that week, not at the next one.
• Coverage of the layers inside-out tools skip: DNS and email authentication, certificate lifecycles per hostname, security-header policy, lookalike registrations, your own domain's registry expiry.

Where it slots into the matrix

This is one row, not a replacement for any other. MDM still owns endpoints, CSPM still owns cloud config, the vulnerability scanner still owns CVE depth on known hosts, the pen test still owns exploitation. The external monitor owns the question the rest of the stack cannot ask: what does the internet currently see under our name, and did it change? It is typically the cheapest row on the matrix to fill — passive, no agents, no integrations to maintain — and its output doubles as audit evidence for the monitoring controls, a mapping we cover control-by-control in the audit evidence guide.

A useful test for your own program: pick a subdomain your team stood up three years ago and ask which control in your current stack would notice if it started answering on a new port tomorrow. If the honest answer is "none," that is the gap — and it is not closed by any amount of rigor applied to the assets you already know about.

Frequently asked questions