You submitted the application. You answered every question carefully, provided documentation, explained your controls. Two days later, the underwriter comes back with contingencies you didn't expect — problems you never mentioned on the form.

How did they know?

They didn't just read your application. They scanned your domain.

Key takeaways

  • Underwriters do not rely only on the answers on the form. They also scan your external attack surface before the quote-to-bind conversation finishes.
  • Email posture, TLS quality, subdomain sprawl, and internet-facing services shape the first impression of your risk.
  • A clean application paired with a weak public footprint creates friction fast.
  • The smartest move is to check the same public signals yourself before you send the file out.

"Google your company" is shorthand for an outside-in workflow

"Google your company" is shorthand for a larger truth: the application starts before the application. The phrase is useful because it captures what clients already sense — someone outside your company can learn a surprising amount before the first technical meeting.

That outside-in view typically includes your primary domain and email posture, discoverable subdomains, certificate and TLS signals, publicly reachable services, and any visible mismatch between how mature your company claims to be and how mature the public footprint actually looks.

That is why the first underwriting question is often unspoken: not "what do you claim?" but "what do we already see?"

The Outside-In Underwriting Reality

Cyber insurance underwriters stopped relying on applications alone years ago. Today, major carriers run automated scans against your external attack surface before, during, and after the underwriting process. Some scan monthly. Some scan continuously. Some use third-party risk scoring platforms. All of them see things you may not know are visible.

This isn't speculation. It's documented in carrier guidelines and appears explicitly in their application supplements. Coalition calls it Coalition Control. At-Bay calls it Stance. Hartford asks pointed questions about DNS posture that reveal they're checking your email authentication records. Travelers runs always-on threat monitoring during the policy period.

The gap between what you can see about your own company and what an underwriter can see is real — and it directly affects your premium, contingencies, and bindability.

Which Carriers Scan Externally (and When)

Coalition: Monthly Active Scanning

Coalition Control runs continuous scanning against your DNS, domains, and infrastructure. The scan checks:

  • SPF records — Does your domain have a Sender Policy Framework? Is it configured to avoid spoofing?
  • DKIM signing — Are outbound emails digitally signed?
  • DMARC policy — Do you have Domain-based Message Authentication, Reporting and Conformance? Is it in enforcement mode (p=reject or p=quarantine) or just monitoring (p=none)?
  • TLS certificates — Are your certificates valid, current, and using secure protocol versions?
  • Open ports and services — What's reachable from the internet?

Coalition publishes findings monthly on their portal. Unresolved findings create contingencies at renewal. A certificate that expires in 90 days isn't an urgent problem for most carriers — unless Coalition's scan flags it. Then it becomes one.

The psychological shift here matters: you're not being scored on what you can fix in time. You're being scored on what you haven't fixed yet.

At-Bay: Pre-Quote Risk Scoring

At-Bay uses its Stance platform to scan your external attack surface before issuing a quote. The scan directly influences your risk score and premium. Unlike Coalition's ongoing monitoring, At-Bay's scan is a single snapshot — but it's the one that determines your initial pricing.

If your DMARC policy is p=none, if you have open RDP ports, if your certificates are about to expire, At-Bay's algorithm sees it. Your risk score goes up. Your premium goes up.

Hartford: Forensic Application Questions

Hartford doesn't publish a scanning platform the way Coalition does. But their cyber application supplements ask extremely specific questions about email security controls:

  • Do you use external sender identification (marking external emails)?
  • What email filtering solution do you use?
  • Do you screen for malicious attachments at the gateway?

These aren't random questions. They're questions an underwriter asks when they've already looked at your SPF/DKIM/DMARC records and want you to explain the gap between your DNS posture and your stated controls.

Travelers: Always-On Monitoring

Travelers' Cyber Risk Services includes always-on threat monitoring during the policy period. Less about pre-binding scanning, more about continuous monitoring and exposure detection once you're bound. This influences renewal underwriting directly.

Third-Party Risk Scoring

Even carriers that don't run their own scans often subscribe to third-party platforms — SecurityScorecard, BitSight, Censys — that publish vulnerability and exposure data about your company. If your domain shows up on a public vulnerability list, the underwriter will know before you do.

What an Outside-In Scan Actually Reveals

Here's what a carrier's scan sees when it hits your domain:

DNS Email Authentication

SPF (Sender Policy Framework)

An SPF record tells the world which servers are authorized to send email on your behalf. A proper SPF record lists your email provider, any third-party marketing platforms, and nothing more.

A broken SPF record might:

  • Not exist (blank)
  • Contain +all (anyone can send as your domain)
  • Be misconfigured to skip authentication on some email providers

A carrier scan will flag all three.

DKIM (DomainKeys Identified Mail)

DKIM digitally signs outbound emails with a cryptographic key. If your email isn't DKIM-signed, attackers can spoof your domain and your legitimate emails are easier to intercept.

The scan checks: Do your mail servers have DKIM signing enabled? Is the public key published?

DMARC (Domain-based Message Authentication, Reporting and Conformance)

DMARC ties SPF and DKIM together and tells receiving mail servers what to do if authentication fails.

The three DMARC policies are:

  • p=reject — Reject unauthenticated emails (enforcement)
  • p=quarantine — Quarantine unauthenticated emails (enforcement)
  • p=none — Monitor only; don't reject anything (monitoring)

A p=none DMARC policy is the underwriting equivalent of a neon sign saying: "We published DMARC but we're not enforcing it." It shows intent without action. Most carriers flag it.

The scan will also check your DMARC reporting (do you receive daily reports?) and whether you're actually using the feedback to improve your authentication posture.

TLS and Certificate Posture

Certificate Validity

Is your TLS certificate valid, current, and issued by a recognized Certificate Authority? Expired certificates are an immediate red flag. Self-signed certificates are worse.

Protocol Versions

Are you still using TLS 1.0 or 1.1? Both are cryptographically broken and disabled by most modern browsers. If your scan still shows them active, carriers will flag it. TLS 1.2 minimum is expected. TLS 1.3 is increasingly standard.

Cipher Strength

Are you using weak ciphers? Carriers want to see modern, secure cipher suites only.

The scan categorizes this as either "acceptable," "weak," or "critical."

Subdomain Exposure

Forgotten development subdomains. Staging environments. Old marketing microsites. Acquisitions where you inherited domains but never fully integrated them.

A carrier scan will discover:

  • All subdomains (dev.yourcompany.com, staging.yourcompany.com, old-product.yourcompany.com)
  • What they're pointing to
  • Whether they're still active
  • Certificate status for each one

Each subdomain is an attack surface. Each one visible to the scan.

TCP/Port Exposure

Is RDP (port 3389) open to the internet? SSH (port 22)? Database ports? Forgotten VPN appliances?

Post-2023, open RDP to the internet is an automatic red flag for most carriers. It's not just a compliance issue — it's a direct indicator of compromisable access.

The scan identifies every open port, what service is listening, and whether it's supposed to be there.

Certificate Management and DNS Hygiene

  • Expired certificates
  • Self-signed certificates
  • Wildcard certificate sprawl (overly broad delegation)
  • Dangling DNS records (subdomains pointing to decommissioned infrastructure)
  • CNAME records pointing to services you no longer use

All visible. All flagged.

The red flags that create avoidable back-and-forth

Not every public issue is fatal. Many are just expensive to discover late. Based on carrier guidelines and public statements, these findings almost always create contingencies or premium adjustments:

  • No DMARC policy or DMARC at p=none — You haven't fully implemented email authentication enforcement
  • SPF with +all — You're not restricting who can send as your domain
  • Open RDP to the internet — Direct remote access vulnerability
  • Expired TLS certificates — Basic certificate hygiene failure
  • TLS 1.0 or 1.1 still active — Using deprecated, broken protocols
  • Subdomains with certificate issues — Each one is a potential attack surface you're not managing
  • Dangling DNS records — Suggests inconsistent infrastructure management
  • Weak email-authentication posture — Public, fixable, but easy to misread as someone else's problem
  • Public posture that conflicts with the application story — The file presents one maturity level; the public footprint suggests another. That mismatch invites scrutiny.
  • Signals that imply deeper operational questions — A public signal rarely proves full internal state, but it creates questions that force clients into deeper evidence work very quickly.

These aren't gotchas. They're systemic indicators that your external security posture doesn't match your application's claims.

Why this matters between renewals too

The outside-in story is not only a quoting issue. It also matters between renewals because public posture can drift. New subdomains appear. DNS changes. Services move. Temporary exceptions become long-lived. The environment the carrier saw at last renewal may no longer be the environment that exists today.

That is exactly why the best teams do not treat outside-in validation as a one-time box check. They use it as an early warning layer.

What the Scan CANNOT Tell an Underwriter

This is critical: outside-in scanning has real limits.

The scan sees:

  • DNS configuration
  • Certificate validity
  • Open ports
  • Subdomain hygiene
  • Protocol versions and cipher strength

The scan does NOT see:

  • Whether MFA is actually enforced on internal accounts
  • Whether your backups are immutable or tested
  • Whether your incident response plan has been drilled
  • Whether security awareness training is current across your organization
  • What your actual email filtering rules are (only that you have the capability)
  • Whether your vulnerability management process actually remediates findings

This is why underwriters ask detailed questions on supplements. This is why they request evidence. The scan is the outside-in verification — the proof of external hygiene. Your responses and documentation are the attestation — proof of internal controls.

You need both.

The practical way to use this insight

Do not turn this into paranoia. Turn it into sequence.

Before the broker sends the renewal application or the client signs the final version:

  1. Check the public posture — Run the free readiness check at /scan. BindLedger's Underwriter Blocker Analysis scans your external attack surface and maps findings directly to carrier requirements. You'll see which DNS email authentication controls are missing, whether your TLS posture meets carrier standards, what subdomains are visible, which open ports exist and which ones carriers flag, and an aggregate readiness score tied to specific carrier expectations. This is exactly the information underwriters collect. You get it first.

  2. Clear the obvious blockers — Fix the external issues. They're the ones the underwriter checks before reading your answers. An open RDP port isn't something you can explain away with a strong incident response plan. An expired certificate isn't something you can offset with good logging practices.

  3. Then gather the deeper internal evidence — Build your evidence packet for the controls that require internal proof — backups, incident response, MFA, training. This is where the supplement answers and documentation matter.

The order is: external verification first, then internal attestation. That sequence matters because it keeps the workflow honest. It also keeps the team from wasting time on beautiful documentation while an obvious public weakness is still visible.

If the questionnaire is already in hand, the next move is usually to combine the outside-in scan with the Carrier Decoder so the file can move from visible posture into carrier-specific evidence quickly.

The right sentence to tell clients

If you support cyber renewals, this is usually the most useful sentence in the whole conversation:

"Before we talk about what the application says, let's look at what the market can already see."

That reframes the work immediately. The client stops thinking in terms of form completion. The MSP stops thinking only in terms of screenshots. The broker stops acting like every question begins at zero.

That is the real advantage of an outside-in workflow.

The Verification Mindset

Underwriters stopped trusting applications alone because companies — good companies, careful companies — often didn't know what was visible about them.

An SPF record misconfiguration isn't intentional. A forgotten development subdomain isn't a security failure you're hiding. An expired certificate on a legacy domain isn't a red flag about your entire security program.

But it is a data point. And when underwriters can see thousands of data points at once, they're looking for consistency. Do your external controls match your application? Do your DNS records reflect your stated email security posture? Do your certificate practices suggest you have a structured asset management process?

The companies that win on cyber insurance renewals aren't the ones with perfect histories. They're the ones that see what underwriters see and fix it first.

See what underwriters see about your company: Run the free scan

Already have your supplement? Decode it with Carrier Decoder

Learn more: