What a cyber insurer can see about your domain

When a company applies for cyber insurance, the insurer or the broker usually asks questions: about backups, multi-factor authentication, patching, training. Many also look at the company from the outside. Your domain, your mail setup, your websites and the services you expose to the internet are public, and anyone can read them without asking you.

This guide explains what can be seen that way, why an insurer would look, how to check your own domain before they do, and which fixes have the most effect. It describes outside-in assessment in general. It does not describe how any particular insurer works, and a better result is not a promise of better terms.

Why insurers look from the outside

An application form tells an insurer what a company says about itself. An outside-in view shows some of what is actually configured, at the moment they look. The two complement each other.

For the insurer, the outside view has practical advantages. It needs no cooperation from the applicant, it takes little time, and it can be repeated the same way for every company they assess. It also shows the conditions attackers see first: exposed services, forged mail, known-exploited software on a public server.

For you, the consequence is simple. Anything on the public internet that is misconfigured can come up in a conversation about your risk, whether or not you knew about it.

What can be seen from the outside

TrustSek groups the public evidence into six modules. They are a fair map of what anyone assessing your domain from the outside can find. Each links to a page listing every finding that module can raise.

Email security

Whether your domain publishes SPF, DMARC and DKIM, and whether they actually stop forged mail. A DMARC record set to p=none exists but asks receivers to do nothing, so invoice fraud in your name still reaches the inbox. The module also covers MTA-STS, TLS reporting, CAA, DNSSEC and nameserver redundancy. See email security.

TLS and web hygiene

Whether your websites use HTTPS, with valid certificates that are not about to expire, modern protocol versions and ciphers, a redirect from HTTP to HTTPS, and security headers such as HSTS. TLS 1.0 and 1.1 are formally deprecated (RFC 8996), so still offering them is a visible sign of old configuration. See TLS and web security.

Ransomware exposure

Whether your organisation is named in a claim on a ransomware leak site, where criminal groups publish the names of organisations they say they have attacked. TrustSek checks two independent trackers and matches names conservatively. See ransomware exposure.

Reputation

Whether your domain or the addresses it runs on appear on threat-intelligence, malware, phishing or botnet lists. A listing can mean a compromised website, a hijacked mail account, or a neighbour on shared hosting. See domain reputation.

Vulnerabilities

Which software versions your public servers advertise, and whether those versions have known vulnerabilities. Priority goes to vulnerabilities in the CISA Known Exploited Vulnerabilities catalogue, which have been seen exploited in real attacks, and to those with a high EPSS score, an estimate of how likely exploitation is in the next 30 days. This is version matching from the outside, not a penetration test. See vulnerabilities.

Attack surface

How large your estate is: the number of subdomains, hostnames that suggest admin panels, staging or remote access, non-web services open to the internet, the age of the domain, and registered lookalike domains that could be used for phishing in your name. See attack surface.

Not every tool reads every source. Some threat lists and port data need a licence, and different tools weigh the same evidence differently, so two assessments of one domain can disagree. What does not change is the evidence underneath: the records you publish and the services you expose. Fixing that evidence is what improves any outside view of your domain, whoever is looking.

Check your own domain first

It is better to find these things yourself than to hear about them in a renewal meeting. A practical order of work:

1. Run a scan of your main domain. Use the free domain check. It needs no access and nothing installed.
2. Look at coverage before the score. Each source ends as found, no match, failed or not checked. Only “no match” means clean. A source that was not checked tells you nothing either way.
3. Read each finding. Every finding says what was tested, why it matters, the impact and how to fix it. Pass them to whoever runs the system concerned: your IT provider, your web agency or your mail administrator.
4. Scan your other domains. Brand domains, old company names and country domains are often forgotten, and they are just as public.
5. Keep the evidence. Note what you fixed and when. If an insurer raises an issue you have already fixed, a dated record of the change is useful.

The score is a risk multiplier against a baseline, placed in one of four bands. The methodology explains how it is built and what its limits are.

The fixes with the most effect

Findings are ranked by severity: Critical, High, Medium and Low. Work from the top. Critical and High findings describe a real, current weakness that attackers use directly; Medium and Low findings are hardening.

Fix first: anything actively wrong.

• A known-exploited vulnerability on a public server. Update or patch the component, or take the service off the internet.
• A website served without encryption at all. Serve it over HTTPS with a valid certificate.
• A listing for phishing or malware. Find out why: a compromised site or mail account needs cleaning before the listing will clear.
• A ransomware leak-site claim. If the claim is about you, this is an incident matter for you and your insurer, not a configuration fix. If it names a different organisation with a similar name, you can explain that.

Then: controls attackers routinely exploit.

• No DMARC record, or an SPF record that authorises every sender. These let anyone send mail as you. Publish DMARC and take it to enforcement; our guide to moving DMARC from p=none to p=reject walks through it.
• Expired, expiring or self-signed certificates, and weak cipher suites.
• Remote-access, database or admin services exposed to the internet. Put them behind a VPN or restrict them by address.

Then: hardening. Old TLS versions, HSTS and other security headers, a DMARC policy still at p=none, CAA records, MTA-STS, DNSSEC and forgotten subdomains. Each is small; together they show a domain that someone looks after.

What the outside view cannot show

Some of the most important controls are invisible from the internet. A scan cannot tell whether you use multi-factor authentication, whether your backups are offline and tested, whether devices run endpoint protection, whether staff are trained, or whether you have an incident response plan. That is why insurers still ask about them on the application form, and why an outside-in score is not the whole picture of your risk.

A clean outside view also has limits. It reads what is public at one point in time, and no finding does not mean secure. Vulnerability detection reads advertised versions, so it cannot see a fix backported without a version change. The methodology lists these limits in full.

If you are on the other side of the table, assessing domains you do not own, see solutions for insurers and brokers.

See what your domain shows from the outside

Run the same kind of outside-in check on your own domain, and fix what it finds before anyone else looks.

Your domain

Check your domain

Free, no sign-up. Takes about 30 seconds.