A customer sends you a security questionnaire. They want to know how you protect their data, handle incidents and manage the suppliers behind your service. You have answers. The harder part is finding evidence you can confidently send with them.

That is the problem behind the NIS2 Supplier Check we have built for ScanComb: a focused starting point for smaller suppliers preparing for customer security reviews. It brings external technical observations, organisational answers and a practical action plan into one dated report.

Product preview, September 2026: the implementation described here is being prepared for public rollout. The self-service check is not publicly available yet. Contact ScanComb about the preview.

Why NIS2 questions reach smaller suppliers

NIS2 makes supply-chain security part of cybersecurity risk management for entities within its scope. Article 21(2)(d) addresses relationships with direct suppliers and service providers; Article 21(3) calls for considering their vulnerabilities and cybersecurity practices, including secure development. See the NIS2 Directive, Article 21.

A practical consequence is that a customer may ask for evidence about your security even when your own company is not directly regulated under NIS2. That commercial request does not, by itself, establish that you fall within the directive's scope. Applicability depends on your circumstances and relevant national law; the European Commission's NIS2 overview explains the wider framework.

For a small SaaS business, consultancy or IT service provider, the immediate task is concrete: explain the controls relevant to the service you deliver, show what you can substantiate and be clear about the work still open.

What the NIS2 Supplier Check examines

The current implementation combines a catalogue of 23 external technical indicators with 15 questions about organisational measures. These cover different kinds of evidence, and the report keeps that distinction visible.

Technical indicators visible from outside

A catalogue entry is not a guarantee that an indicator can be assessed on every domain. Network restrictions, provider behaviour or missing information can leave a result uncheckable. For example, DKIM discovery depends on knowing a selector; the implementation lets a domain owner supply selectors and rerun that check. It does not infer that every outgoing message is correctly signed from a DNS record alone.

Organisational measures that need your input

A public website cannot demonstrate that your team tests backup restoration or removes access when an employee leaves. The questionnaire asks about policies, risk assessment, incident response, continuity, supplier management, patching, development practices, training, encryption, inventories and access controls.

Those answers are self-declarations unless supported by a separate verification path. The report does not turn a checked box into an independently verified fact. A cloud backup configuration, for example, still leaves the question of whether the business has successfully tested a restore.

Domain verification comes before the fuller check

The preview workflow starts with a domain and a work email associated with it. The user confirms that they are authorised to request the check for the business. A limited preview uses public DNS and narrowly bounded web and TLS observations.

Before the fuller check runs, the user must demonstrate control of the domain by adding a DNS TXT record. This is an ownership check, not a request for a cloud administrator account, a repository token or a production password.

The scanner makes bounded, read-only requests. It does not submit forms, attempt logins, run a port scan or exploit vulnerabilities. HTTP checks are restricted to the main domain and its www host; subdomain observations use DNS. This makes it a focused external assessment, not a penetration test.

What goes into the supplier evidence report

The PDF is designed to accompany a customer questionnaire. It brings the results into a format a reviewer can read without access to your account:

  1. A dated cover and report identity. A QR code supports an authenticity check for the report's identity, domain and date.
  2. A summary and priorities. An A–F grade is paired with the top actions, so the number is not the whole story.
  3. An Article 21(2) mapping. Technical observations and declared measures are organised against the ten measure groups, with their evidence basis visible.
  4. A practical action plan. Findings include explanations and remediation guidance, with configuration examples where appropriate.

The authenticity check identifies the report; it does not endorse the supplier's security. Likewise, the grade summarises the tool's scoring method. It is not a percentage of legal compliance, a certification or a promise that the customer will accept the report.

How to use it in a customer security review

Imagine a small software supplier with a public website, hosted email and an application running in the cloud. An external check can help document the website and domain configuration. It cannot inspect the application's internal permissions or establish how the team responds to an incident.

A useful response package therefore has three parts: the dated technical report, evidence for the organisational answers, and a short list of open actions. A missing header might become a configuration task. A declared backup policy might need a recent restore-test record. An incomplete incident process needs an owner and a documented workflow.

Before sharing, confirm that the assessed domain and services match the customer's question. Review the findings, attach only relevant supporting material, and agree who owns each gap. After a fix, rerun the relevant check instead of treating a ticket marked “done” as fresh technical evidence.

Where WardBee adds deeper evidence

The external check is an entry point. Where customers need evidence from inside cloud accounts or repositories, WardBee provides a separate connection and assessment workflow. The Supplier Check implementation can link eligible WardBee AWS and GitHub results to selected questionnaire answers, retaining partial coverage where the evidence proves only part of the answer.

That follows the same approach we described in our introduction to WardBee: show what the evidence supports and make the remaining questions visible. A well-configured public domain is useful evidence. It cannot stand in for the controls inside the service your customer actually uses.

NIS2 supplier check: common questions

Does this certify my company as NIS2 compliant?

No. It documents technical indicators and declared information at a point in time. It is not an audit, certification or legal assessment.

Can it replace my customer's questionnaire?

Treat it as supporting material. Your customer determines what evidence they need for the service, contract and risks under review.

Do I need to connect AWS or GitHub first?

The external domain check does not require those connections. Deeper WardBee evidence uses a separate, explicitly authorised integration.

Is the NIS2 Supplier Check available now?

This article previews the implementation ahead of public rollout. The domain check and supplier PDF are planned as a free starting point; separate WardBee services have their own scope and pricing. Contact ScanComb for current preview availability rather than assuming immediate self-service access.

Prepare evidence before the next questionnaire arrives

The aim is to make the first response easier to assemble and easier to review: here is what was checked, here is what we declare, here is the supporting material, and here is what we are fixing. That is a more useful conversation than sending a score without its evidence.

Ask ScanComb about the NIS2 Supplier Check preview → You can also review WardBee's connection and security model before considering deeper evidence collection.