Guide · 10 min read
Supplier cyber risk assessment — what automated NIS2 monitoring checks
A complete breakdown of all check categories, their relevance to NIS2, and how findings translate into actions.
Passive intelligence — no traffic to the supplier
Automated monitoring is based on passive intelligence: all data is collected from public sources — certificate registries, DNS records, ransomware databases, HIBP breach databases, sanctions registries, and open OSINT feeds. No traffic is sent to the supplier's network, and no consent from the supplier is required.
The full check suite runs daily, with ransomware and dark-web feeds checked approximately every 6 hours. Critical findings — such as a ransomware victim listing or an active dark web credential leak — trigger an immediate email alert.
Ransomware victim monitoring
Art. 21(2)(b)Multiple ransomware intelligence feeds are checked approximately every 6 hours. If your supplier appears on a victim list — a sign of an active or recent ransomware attack — you receive an alert the same day. This may warrant an urgent conversation with the supplier about whether you or your data are at risk.
Dark web credential leaks
Art. 21(2)(i)Infostealer malware databases and dark web markets are scanned for email-password pairs tied to the supplier's domain. Compromised credentials are the most common attack entry point — leaked logins from your supplier's employees can end up targeting your systems.
Email security
Art. 21(2)(h)Missing or misconfigured SPF, DKIM or DMARC allows the supplier's domain to be abused for email spoofing. Also checks MTA-STS (transport-layer email protection), TLS-RPT reporting record, and BIMI brand indicator. All are cryptographic requirements under NIS2 Art. 21(2)(h).
TLS certificates and DNSSEC
Art. 21(2)(h)TLS certificate validity is checked with alerts 14 days before expiry. DNSSEC validation checks whether the DNS chain is signed and intact — missing DNSSEC exposes the supplier to DNS spoofing. CAA records indicate whether certificate issuance is restricted to approved CAs.
Web security configuration
Art. 21(2)(c)Cookie security attributes (Secure, HttpOnly, SameSite) are checked — missing attributes enable session hijacking or XSS attacks. robots.txt is analysed for sensitive path disclosure. security.txt is checked to confirm the existence of a responsible vulnerability disclosure channel.
Vulnerabilities and CVE/EPSS scores
Art. 21(2)(e)CISA KEV (Known Exploited Vulnerabilities) listings tied to CVEs associated with the supplier's infrastructure are identified immediately. EPSS scores (Exploit Prediction Scoring System) prioritise vulnerabilities by exploitability likelihood — not just CVSS severity rating alone.
Sanctions and MX blacklist checks
Art. 21(2)(e) & Art. 21(2)(j)EU, UN and OFAC sanctions lists are checked against the supplier's organisation. The supplier's mail server (MX record) IP addresses are checked against four real-time blackhole lists (RBLs) — blacklisting indicates email abuse or prior compromise.
SAQ — self-assessment questionnaire
Art. 21(2)(a) & (b) & (d)Technical monitoring covers the externally visible attack surface. Process-level requirements — risk management, incident handling, supply chain governance — are covered by sending the supplier a SAQ self-assessment questionnaire from the norppa.io portal. Responses are stored and combined with the technical risk profile.
Risk scoring and severity levels
Every finding is classified into one of four severity levels: critical (immediate action), high (remediate within 7 days), medium (remediate within 30 days) and low (informational). The risk score (0–100, 100 = clean) is calculated based on the severity of open findings.
The risk score is intended as a prioritisation tool, not an absolute truth. A supplier may receive a low score due to a single critical vulnerability even when their overall security posture is strong.
Finding lifecycle
A finding is created when a check detects an anomaly. It remains open until the issue is resolved — the checker confirms the fix automatically on the next run. If a finding represents a known, accepted risk, it can be marked as "accepted risk" with a comment. The same finding will not trigger new alerts unless the status changes.
All findings are automatically mapped to the corresponding NIS2 Art. 21(2) sub-clause — they appear both in the real-time portal view and in the monthly PDF report.
NIS2 mapping and reporting
The monthly report includes an AI executive summary, NIS2 scores by article, per-supplier risk profiles, and a prioritised remediation action list. The report is designed for executive-level presentation — not just for technical teams.
The report also includes findings that have been accepted as documented risks. This matters for audit purposes: NIS2 does not require zero findings — it requires documented risk management.
Your own domain — comprehensive external assessment
Supplier domains are assessed using passive OSINT — publicly available data only. Your own domain can additionally receive a monthly external security assessment: exposed ports and services, known vulnerability risks, and SSL/TLS configuration. No integration, no access to your internal network.