Most organisations have two to five times more suppliers connected to them than they've documented. NIS2 makes supply chain security a legal obligation under Article 21. Compliance starts with a living inventory, not the one in your contracts folder.
Our discovery data feeds your NIS2 compliance programme by giving visibility across assets, suppliers, and external exposures that inform Article 21 risk-management measures. See how ThingsRecon supports each requirement.
Article 21(2)(a): Policies on risk analysis and information system security.
Article 21(2)(i): Asset management and access control policies.
Automated Asset Discovery and Supply Chain Mapping continuously identify domains, IPs, APIs, certificates, and connections, including shadow IT and forgotten infrastructure your asset inventory doesn't capture.
Article 21(1): Measures must be appropriate, proportionate, and based on the state of the art.
Article 21(2)(f): Policies and procedures to assess the effectiveness of risk-management measures.
Continuous external discovery with test-over-time comparison shows whether risk actually decreased between assessments, not just whether a policy exists on paper.
Article 21(2)(d): Supply chain security, including the relationship between an entity and its direct suppliers or service providers.
Article 21(3): Take into account supplier-specific vulnerabilities and the overall quality of their cybersecurity practices.
Supply chain discovery and Digital Proximity scoring show which suppliers are deeply integrated into your environment, not just which ones exist on a vendor list, so a medium finding on a critical supplier gets prioritised as what it actually is.
Article 22(1): Coordinated security risk assessments of critical ICT supply chains at Union level.
Concentration and dependency mapping across your supplier base gives the evidence needed to participate in sector-wide, coordinated risk assessments instead of assessing each supplier in isolation.
Article 21(2)(e): Security in network and information systems acquisition, development, and maintenance, including vulnerability handling and disclosure.
A risk scoring engine with 100+ cyber hygiene indicators, including end-of-life software, exploited CVEs, and misconfigured TLS, flags which vulnerabilities sit on infrastructure that actually matters.
Article 21(2)(b): Incident handling.
Article 24: Notification of significant cyber threats to affected service recipients without undue delay.
Contextual risk reports and remediation recommendations identify which exposures would meet the threshold for a significant incident or threat before they're exploited.
Article 23: Reporting of significant incidents within 24 hours, 72 hours, and one month.
Article 32: Management bodies must approve and oversee risk-management measures and can be held personally liable for negligent breaches of duty.
Reporting insights plug into GRC, SIEM, or board-reporting workflows, giving management the visibility Article 32 requires them to oversee, and shortening the clock between detection and the 24-hour early warning.
EASM can support NIS2 by helping organisations identify and monitor internet-facing assets, vulnerabilities, misconfigurations and external dependencies. This strengthens the asset visibility needed for risk analysis, vulnerability handling, incident preparedness and supply chain security measures. NIS2 requires appropriate and proportionate risk management rather than the purchase of a specific tool. External discovery should therefore connect findings to ownership, critical services and remediation processes. ThingsRecon adds supplier relationships, evidence and Digital Proximity to the external attack surface, helping teams show which assets and dependencies matter to essential operations and maintain a defensible record of continuous oversight. In practice, teams should record the supporting evidence, confirm ownership and business criticality, and connect the finding to an accountable workflow. This prevents a useful observation from becoming another isolated score or dashboard alert.
Audit-ready cyber evidence is documented, traceable information that demonstrates what was assessed, what was observed, when it was observed and how the organisation responded. Useful evidence includes scope, timestamps, technical findings, supporting records, ownership, remediation status and trend history. It should be reproducible and understandable to reviewers beyond the security team. ThingsRecon produces evidence-backed findings and continuous monitoring records that can support audits and regulatory reporting, while organisations add their control decisions, approvals and internal documentation. In practice, teams should record the supporting evidence, confirm ownership and business criticality, and connect the finding to an accountable workflow. This prevents a useful observation from becoming another isolated score or dashboard alert. The strongest implementation combines external intelligence with internal knowledge, supplier engagement and documented risk decisions, creating a view that remains useful as the digital ecosystem changes.
NIS2 does not prescribe a specific security questionnaire. It requires essential and important entities to implement appropriate and proportionate cybersecurity risk-management measures, including supply chain security. A questionnaire can support supplier due diligence, while the wider programme still needs risk-based oversight, evidence, monitoring and documented action appropriate to the organisation and its suppliers.
A SIG questionnaire can provide structured supplier assurance and help collect detailed information about controls, governance and security practices. It does not by itself demonstrate continuous oversight. Regulatory programmes still need to connect the answers to supplier criticality, supporting evidence, monitoring, remediation and current risk decisions.
Useful supplier-oversight evidence is traceable, dated, and connected to a documented control or risk decision. Depending on the programme, this can include questionnaires, contracts, certifications, review records, technical findings, monitoring history, remediation tickets, exceptions, approvals and evidence of reassessment. The strongest record shows what was reviewed, who owned the decision and what happened when the supplier risk changed.
Some questionnaire answers can be checked against external evidence. Examples include internet-facing assets, certificates, DNS configuration, exposed services, software fingerprints, security headers and observable supplier relationships. Internal controls such as access governance, network segmentation and recovery procedures usually require supplier evidence or internal validation. External monitoring is therefore most useful as an independent layer of assurance around claims that can be observed from outside.
A security rating gives a supplier a single score, often a letter grade, based on scan data alone. A DORA or NIS2-ready tool goes further: it maps how deeply that supplier's systems touch your critical operations and ties specific findings to the regulatory article they affect, so the output functions as evidence, not just a grade.
No. Both regulations ask for the same underlying capability: continuous, evidence-based visibility into third-party and supply chain risk. A tool that maps findings to specific articles across both frameworks, rather than treating them as separate checklists, can serve a financial entity under DORA and a broader NIS2-scoped organization at the same time.
Continuously, not annually. ENISA's technical implementation guidance for NIS2 requires a live, updated register of suppliers reflecting ongoing risk management activity. DORA's oversight provisions expect the same standard. A once-a-year questionnaire cannot produce evidence for the other 364 days of the year.
No single tool does. Compliance is a governance and operational outcome involving procurement, legal, and executive sign-off, not just software. What a tool can do is provide the visibility, prioritization, and evidence trail that make the rest of that governance work possible.
