How we classify severity

By the zmam.ai team · 29 May 2026

On this page

A severity rating is a prioritization tool, not a grade. It answers one question: if you only have time to fix a few things, which should they be? A zmam.ai report sorts findings into five levels, based on what is visible from the outside and how much an attacker could do with it.

Two factors drive every rating: impact (how bad is it if this is abused?) and exposure (how reachable and reliable is the abuse from the public internet?). A serious weakness that is hard to reach can rank below a moderate one that is trivially exposed.

The levels

Critical

A finding that appears to enable immediate compromise, account or domain takeover, serious data exposure, or abuse of a known, actively-exploited vulnerability. These are rare in a purely external, non-intrusive check, because confirming them usually requires intrusive testing we do not perform — but a strong external signal (for example, an exposed admin interface on end-of-life software with a known exploited flaw) can warrant it.

High

A finding that creates meaningful risk and should be addressed quickly, especially on internet-facing production systems. An exposed administrative login, a publicly reachable service that should be internal, or a clearly weak TLS configuration on a primary host fall here.

Medium

A weakness that increases the likelihood or impact of an attack but usually needs other conditions to become severe. A DMARC policy left at p=none is a good example: it does not breach anything by itself, but it leaves your domain open to convincing spoofing. A missing HSTS header on a site that otherwise uses HTTPS is also typically medium — it widens a real but conditional attack window.

Low

A hardening opportunity or minor information exposure. Stale DNS records you no longer use, a missing X-Content-Type-Options header, or verbose version banners usually sit here: worth tidying, rarely urgent on their own.

Informational

Useful context that is not, by itself, a weakness — for example, noting which mail provider or CDN a domain uses. It helps you understand your footprint without implying something is wrong.

Why two similar findings can differ

Severity is contextual, so the same kind of finding can land differently:

A missing security header on a static marketing page is lower than the same header missing on an application that handles logins.
An exposed service is higher when its software is end-of-life, because no patch is coming — see How to tell if your website is exposed .
An expired TLS certificate is high because every visitor sees a browser warning; a soon-to-expire one is a timed medium.

How to use the ratings

Work top-down: fix Critical and High first, then Medium, then Low when you have room. Re-run the check after each change — most findings should drop or disappear once the underlying configuration is fixed. A report with few findings does not prove a domain is secure, and one with many does not prove it is breached; the ratings simply tell you where to start.