How Senserity checks cyber risk

The Cyber category assesses the external-facing digital security posture of a company. It does not perform penetration testing or scan internal networks. Instead, it examines publicly visible signals: how well a company has configured its email defences, whether its website follows security best practices, and whether it holds recognised cybersecurity certifications.

For procurement and compliance teams, a supplier's cyber posture matters because a breach at a supplier can expose your own data, disrupt your operations, or create regulatory liability. The Cyber category gives you a structured, automated assessment without requiring the supplier to fill in a security questionnaire.

To see the raw scan results these tests were derived from, rather than the scored assessment of them, open the Cyber tab on the company profile. See Exploring the company evidence tabs.

What it checks

The Cyber category runs around 70 tests, grouped into several areas.

Email security

Email is the most common attack vector for business fraud, phishing, and impersonation. Senserity checks three key email authentication standards:

SPF (Sender Policy Framework). SPF tells receiving mail servers which servers are authorised to send email on behalf of the company's domain. Without SPF, anyone can send email that appears to come from the company. Senserity checks whether an SPF record exists and whether it is correctly configured.

DKIM (DomainKeys Identified Mail). DKIM adds a cryptographic signature to outgoing emails, allowing the recipient's server to verify that the message has not been altered in transit. Senserity checks for the presence of DKIM records.

DMARC (Domain-based Message Authentication, Reporting and Conformance). DMARC ties SPF and DKIM together and tells receiving servers what to do when an email fails authentication: accept it, quarantine it, or reject it. A strong DMARC policy (reject) means the company has taken steps to prevent its domain being used for phishing. Senserity checks the DMARC record, its policy strength, and whether reporting is configured.

A company with all three correctly configured has a significantly stronger email security posture than one with none. The combination of SPF, DKIM, and DMARC is tested as an "email authentication triad" with its own dedicated assessment.

Website security

Senserity checks a range of web security indicators:

SSL/TLS certificates. Whether the website uses HTTPS, whether the certificate is valid and not expired, and what type of certificate is in use. An expired or missing SSL certificate is a visible sign of poor maintenance.

Security headers. Modern web security relies on HTTP headers that instruct browsers to enforce security policies. Senserity checks for HSTS (forcing HTTPS connections), Content Security Policy (preventing code injection), clickjacking protection, MIME sniffing protection, and referrer policy. Each missing header represents a defence that has not been configured.

Threat intelligence. Senserity checks the company's domain against known threat databases, including Spamhaus (email blacklists), URLhaus (malware distribution), and Google Safe Browsing. A listing on any of these indicates the domain has been associated with malicious activity.

Sensitive path exposure. Senserity checks for common administrative and configuration paths (such as login pages, backup files, or debug endpoints) that should not be publicly accessible. Exposed paths can give attackers a foothold.

CMS and technology detection. Senserity identifies the content management system and key technologies used by the website. Outdated or unpatched systems are a known risk.

Public hostnames

A company's website is rarely its only presence on the internet. There are usually other named addresses too: a mail server, a VPN gateway, a customer portal, a staging copy of the site, sometimes the web interface of a firewall or a NAS. Each one is a way in, and each is invisible if you only look at the main website.

Senserity finds these through Certificate Transparency. Every certificate authority is required to publish a public log entry for each TLS certificate it issues, recording the hostnames the certificate covers. Those logs are open to anyone. Senserity reads them for the company's domain, then resolves each name it finds and attempts a TLS connection to establish four things:

Where the name leads. Whether it is reachable from the internet, sits behind a firewall, resolves only to an internal address, has no site configured, or no longer resolves at all. Only the reachable ones represent exposure.

Whether the certificate is sound. For each reachable name, whether the certificate is valid, expired, self-signed, or cannot be verified against a trusted authority. A single expired certificate on a forgotten subdomain is a maintenance signal; a low proportion of valid certificates across an estate is a systemic one.

What kind of system it is. Development and test environments, remote access gateways, and equipment management interfaces are identified where the name or the certificate makes it clear. These often carry weaker security than the main site while being reachable from the same internet.

Whether the estate is changing. New names appearing over a ninety-day window are tracked, so a sudden expansion in a supplier's footprint is visible.

Internal hostnames disclosed in the public log are reported for information only. They tell you something about how a company names its infrastructure, but they are not reachable and are not scored as a weakness.

Two limits are worth understanding. The sample is capped, so for a company with a very large estate Senserity examines a subset rather than every name, and the report and the Cyber tab both say so where that applies. And the size of an estate is not itself a risk signal: a managed service provider hosting systems for its customers will have far more hostnames than a professional services firm of the same headcount, without being any less secure. Estate size is reported as context and is deliberately not scored. What is scored is the proportion of certificates that are sound, which compares fairly across estates of any size.

Cyber Essentials certification

Cyber Essentials is a UK government-backed certification scheme that covers five basic security controls: firewalls, secure configuration, access control, malware protection, and patch management. There are two levels: Cyber Essentials (self-assessed) and Cyber Essentials Plus (independently verified).

Senserity checks whether the company holds a valid Cyber Essentials certificate, what level it has achieved, and when the certificate expires. Certification is not mandatory for most companies, so its absence is not treated as a failure. However, holding a valid certificate is a positive signal, and an expired certificate that has not been renewed is flagged.

Cyber Essentials checks are part of the full data set included on every paid tier and run automatically as part of monitoring, at no credit cost.

How scores work

Each Cyber test produces a pass, warning, or fail result with an associated severity. The individual results are aggregated into the Cyber category score using the same weighted approach as all other categories, where Critical and High severity failures have a larger impact than Low or Info findings.

A company with no website or no domain will have limited Cyber test coverage. In these cases, the category score is based on whatever data is available, and the absence of a web presence is noted but not penalised.

What it does not check

The Cyber category assesses external-facing configuration only. It does not test internal network security, endpoint protection, staff training, incident response procedures, or data handling practices. These are important aspects of cybersecurity, but they require direct access or supplier cooperation to assess. For those areas, Senserity's attestation system allows you to ask suppliers directly about their internal security practices.

It is also worth being clear about what hostname discovery is not. Senserity reads a public log of issued certificates and then makes an ordinary connection to the names it finds, in the same way any browser would. It does not scan ports, probe for vulnerabilities, guess at names that were never published, or attempt to reach anything a certificate authority has not already made public.

Last updated 2 September 2026.