Guide · 9 min read
Supplier cyber risk assessment: what continuous monitoring checks
What does it actually mean to watch a supplier's cyber risk from the outside? This is the full inventory: every category we check, why each one matters under NIS2, and how a finding turns into something you can act on, or defensibly decide to live with.
Key takeaways
- Walks through every check category and the NIS2 article each one answers to.
- All of it is passive: public sources only, no traffic to the supplier and no consent required.
- NIS2 rewards documented, managed risk, not an empty findings list: an accepted, recorded risk is evidence.
Passive intelligence: nothing ever touches the supplier
Everything here runs on passive intelligence. The data comes entirely from public sources (certificate transparency logs, DNS records, ransomware leak sites, breach datasets, sanctions registries and open intelligence feeds) so no traffic is ever sent to the supplier's systems and no permission is needed. You can assess a supplier you've signed, one you're still considering, or one who has no idea you're looking.
The full set of checks runs daily; the time-sensitive ones (ransomware and dark-web sources) re-run roughly every six hours, with an email alert the moment something critical surfaces, such as a victim-list appearance or a fresh credential leak.
Ransomware victim monitoring
Art. 21(2)(b)Several ransomware-tracking sources are re-checked about every six hours. The day your supplier turns up on a victim list (the public signature of an active or recent attack) you hear about it, which is usually the day to ask them, plainly, whether you or your data are caught up in it.
Dark-web credential leaks
Art. 21(2)(i)Credential dumps from infostealer infections and dark-web markets are searched for logins tied to the supplier's domain. Stolen credentials are still the most common way in, and a leaked password belonging to one of your supplier's staff is a password that can end up pointed at your systems.
Email security
Art. 21(2)(h)SPF, DKIM and DMARC left missing or half-configured let a supplier's domain be spoofed in email that lands looking legitimate. The check also looks at MTA-STS, the TLS-RPT reporting record and the BIMI brand indicator: the technical underpinnings behind the Article 21 cryptography measures where they apply.
TLS certificates and DNSSEC
Art. 21(2)(h)Certificate validity is tracked, with a warning two weeks before expiry. DNSSEC validation tells you whether the supplier's DNS chain is signed and intact (without it, their DNS can be spoofed) and CAA records show whether certificate issuance is fenced to approved authorities.
Web security configuration
Art. 21(2)(c)Cookie flags (Secure, HttpOnly, SameSite) are checked, since missing ones open the door to session hijacking and cross-site scripting. robots.txt is read for sensitive paths a site is quietly advertising, and security.txt for whether there is an honest channel to report a vulnerability.
Vulnerabilities and exploitation scoring
Art. 21(2)(e)Anything tied to the supplier's infrastructure that sits on the CISA Known Exploited Vulnerabilities catalogue is flagged at once. Exploitation-probability scores (EPSS) then sort the rest by how likely each is to actually be used, rather than by raw CVSS severity alone: the difference between a long list and a short, honest one.
Sanctions and mail-server reputation
Art. 21(2)(e) & Art. 21(2)(j)The supplier's organisation is checked against the EU, UN and OFAC sanctions lists. Its mail-server IP addresses are checked against four real-time blocklists: an appearance there points to email abuse, or an earlier compromise that was never cleaned up.
SAQ: self-assessment questionnaire
Art. 21(2)(a) & (b) & (d)Technical monitoring covers the surface anyone can see from outside. The process-level requirements (risk management, incident handling, supply-chain governance) are reached by sending the supplier a self-assessment questionnaire from the portal; their answers are stored and read next to the technical risk profile, so claims and evidence sit side by side.
Severity, and the risk score
Each finding lands in one of four severity bands: critical (act now), high (about seven days), medium (about thirty) and low (worth knowing). The supplier's risk score (0 to 100, where 100 is clean) is derived from the severity of whatever is currently open.
Read the score as a way to triage attention, not a verdict. A supplier with an otherwise strong posture can score low on the back of a single critical flaw, and a tidy score never excuses skipping the detail underneath it.
What happens to a finding
A finding opens the moment a check spots something off, and it stays open until the issue is actually gone: the next run confirms the fix on its own, with no manual closing. When a finding is a risk you've looked at and chosen to live with, mark it as an accepted risk with a note, and it stops generating fresh alerts unless its state changes.
Every finding is tagged to the NIS2 Art. 21(2) sub-clause it answers to as it's recorded, and shows up both in the live portal and in the monthly PDF.
How it maps to NIS2, and what the report carries
The monthly report opens with a plain-language summary, then NIS2 scores by article, a risk profile per supplier and a remediation list already sorted by priority. It's written to be read in a management meeting, not only by the people who will do the fixing.
It also carries the findings you've accepted as documented risks: the part auditors care about most. NIS2 never asked for a clean sheet; it asked you to manage risk and show your work.
Your own domain: a deeper external look
Supplier domains are assessed with passive intelligence alone: public data only. Your own domain can go a step further with a monthly external assessment (exposed ports and services, known vulnerability risks and TLS configuration) because there you have the standing to look harder. Still no integration, and still nothing reaching your internal network.