Article partially generated by artificial intelligence.
TL;DR: Third-party risk management is now a legal duty for companies covered by NIS2. Supply chain security is one of the minimum risk-management measures in the directive, and it reaches the companies that write, maintain and host your software. In practice that means assessing vendors by criticality, putting security terms in contracts and reviewing critical vendors regularly. In Poland, this sits inside the information security management system required by the KSC Act by 3 April 2027. This article shows how to do it for software houses and freelancers without producing paperwork nobody reads.
This post is part of our NIS2 and CRA guide for companies that own applications.
Key facts:
NIS2 requires essential and important entities to manage cybersecurity risk, and supply chain security is one of the minimum measures. The directive also requires companies to consider the vulnerabilities specific to each direct supplier, the overall quality of suppliers’ products and their cybersecurity practices, including secure development. Each Member State writes this into national law; in Poland it falls under the information security management system (ISMS) required by the KSC Act. For the Polish timeline, see Poland’s KSC deadlines for company applications.
An ISMS is often built on ISO/IEC 27001, but certification is not required by NIS2 and does not replace meeting the law.
A software vendor often has access nobody else has: source code, production servers, databases and admin accounts. If their security fails, yours does too. So supply chain security covers not only hardware and cloud providers, but also software houses, freelancers and agencies that maintain your websites and applications.
ENISA’s technical guidance on the NIS2 measures expects a supply chain security policy that sets requirements for suppliers, shapes how they are selected and flows into contract terms.
An assessment without a contract achieves little. A contract with a critical software vendor should cover security requirements for development and maintenance, response times for vulnerabilities and incidents, a duty to report incidents, the right to audit or to receive test reports, rules on subcontracting, handover of source code and documentation, and an exit plan for moving the system to another vendor. The last point is often skipped, and it decides whether you end up with an application nobody can maintain.
An auditor will ask for evidence, not just a policy: a vendor list with criticality ratings, completed questionnaires, review reports, contracts with security terms and a record of actions taken on findings. The strongest evidence is an independent technical review of an application a vendor delivered, because it shows how things really are rather than how the vendor described them. An OWASP Top 10-based checklist is a practical starting point for that review.
Not every vendor needs the same attention. Splitting vendors into three tiers focuses effort where the risk is highest.
The tier depends on access and business impact, not contract value. A small freelancer with the admin password to the customer database is a critical vendor, even if their invoice is a few thousand euros a month.
Good third-party risk management does not have to be heavy. It starts with a list and a tiering exercise, and deep work is reserved for the few most important relationships. For many mid-sized companies that means a handful of vendors, not dozens, and that is where preparation should begin.
A good software vendor does not treat a security questionnaire as an obstacle. Companies that take security seriously have answers ready: a description of their development process, a vulnerability handling policy, a sample test report, an example SBOM and a list of subcontractors. If a vendor needs weeks to answer basic questions or replies in generalities, that is information too.
Also watch how the vendor reacts to a request for source code and documentation. A refusal, or a clause saying the code stays with the vendor and cannot be handed over, means that when the relationship ends you will be left with a system nobody else can maintain. Under NIS2 that is a business continuity risk and belongs in your ISMS risk analysis.
Sanddev is a software house, so we know these questions from both sides. We help companies assess vendors technically: we review the code and infrastructure of delivered applications, evaluate the development process and prepare findings for your ISMS. See how we provide an independent technical view on your software vendors.
Third-party risk management under NIS2 is the duty of essential and important entities to manage the cybersecurity risks posed by their direct suppliers and service providers, including software vendors, as part of supply chain security under Article 21 of the directive.
Yes. NIS2 supply chain security covers direct suppliers and service providers, which includes software houses, freelancers and hosting providers that build, maintain or host a company’s software.
No. NIS2 does not require ISO/IEC 27001 certification. The standard helps build an information security management system, but a certificate does not replace meeting the legal duties or checking how vendors actually work.
Critical software vendors should be reviewed at least once a year and after any serious incident on their side. For other vendors, frequency depends on their importance to the business and the results of the risk analysis.
A contract with a critical software vendor should set security requirements, response times for vulnerabilities and incidents, an incident reporting duty, audit rights, subcontracting rules, access to source code and an exit plan for handing the system to another vendor.
OWASP Top 10 is the list of the most serious risk categories in web applications. AI-built apps, for example in Lovable on a Supabase database, usually fail exactly where it says – above all in access control. Here is a 12-point checklist to run before an auditor asks.
An SBOM (software bill of materials) is a list of the libraries, modules and versions a product is built from. From 11 December 2027, the Cyber Resilience Act requires manufacturers of products with digital elements to draw up an SBOM in a commonly used, machine-readable format covering at least top-level dependencies.
The Cyber Resilience Act (CRA) has required, since 11 September 2026, manufacturers of products with digital elements to report actively exploited vulnerabilities and severe incidents. An early warning is due within 24 hours of becoming aware, a full notification within 72 hours and a final report later.
