NIS2 for Software Suppliers: What It Means for Your Web App

NIS2 rarely applies to small software suppliers directly, but if you build, host or sell a web app to an organization that falls under it, that customer has to manage the security of its supply chain, and those requirements end up in your contract. In practice that means secure development, timely security patches, fast incident notification, multi-factor authentication and documentation you can produce on request. As a rule, you're only in scope yourself if your company operates in one of the listed sectors and has at least 50 staff, or more than €10 million in both annual turnover and balance sheet total.

I'm a developer based in Denmark, not a lawyer. This guide is written from the supplier's side of the table, with the directive and the Danish authority's guidance as reference points.

The short answer: does NIS2 affect you as a supplier?

Find the row that matches your situation. Most software suppliers sit in the first one.

My rule of thumb: the closer your app sits to the customer's core service, and the more access you have to their systems and data, the more you'll be asked for. A room booking tool for the office canteen and a system that runs a water utility won't be assessed the same way.

NIS2 is only one part of keeping a web app healthy in production. Updates, backups, monitoring and who owns what are covered in my complete guide to web application maintenance.

What NIS2 is, and why it reaches software suppliers

NIS2 (Directive (EU) 2022/2555) is the EU's updated cybersecurity law for organizations that keep society and the economy running. According to the European Commission's NIS2 overview, member states had until 17 October 2024 to turn it into national law, and it makes top management accountable for cybersecurity risk management. Not every country hit the deadline. Denmark, where I'm based, only had its national law in force from 1 July 2025, so check which country your customer is regulated in.

The directive covers medium-sized and large organizations in sectors such as energy, transport, banking, health, drinking water, wastewater, digital infrastructure, public administration, waste management, food, chemicals and parts of manufacturing. Some types of entity are in scope regardless of size.

Suppliers come in through Article 21 of the directive text. It lists ten areas of cybersecurity measures every covered entity must have, and one of them is supply chain security, including the security aspects of its relationships with direct suppliers and service providers. The same article says covered entities should take into account the overall quality of their suppliers' products and security practices, including their secure development procedures. If you write or run the code behind one of their systems, that's you.

One group of suppliers may be directly in scope: medium-sized and larger managed service providers, cloud providers and similar digital businesses. They also fall under Implementing Regulation (EU) 2024/2690, which sets more detailed technical requirements, and ENISA has published technical implementation guidance for it. A freelancer or small studio is far below the size threshold.

What your customers will ask for

The Danish NIS2 authority's guidance on security measures (in Danish) lists the kind of clauses a covered entity can put in supplier contracts. Translated to a web app, they look like this:

Secure development and patching

Expect questions about your process, not just the result. How does code get from your laptop to production? Is it tested and reviewed? Can you see who changed what, and when? A Git repository with pull requests, automated tests and a staging environment answers most of them.

Vulnerability handling is the other half. The customer must be able to show that known vulnerabilities in its systems get found and fixed, and if you own the code, your process is effectively theirs. Some customers will also ask for regular vulnerability scans or a full penetration test of the web app.

Incident notification

Article 23 gives covered entities three reporting deadlines for significant incidents: an early warning within 24 hours, an incident notification within 72 hours and a final report no later than one month after that notification. Those deadlines are your customer's, not yours. But your customer can only meet them if you speak up fast, so expect a clause requiring you to notify them as soon as you become aware of an incident and to help with the details for the report. That assumes you'll notice. Without error tracking and uptime monitoring, you'll hear about it when the customer calls.

Access, MFA and people

The list in Article 21 also covers access control, human resources security and multi-factor authentication where appropriate. MFA is the most concrete ask: plan on using it everywhere that gives access to the customer's system, meaning your hosting account, code repository, database and admin panel. For the most critical systems, contracts can also require background checks or specific training for the people with access.

How to get your web app ready: 7 steps

None of these steps needs a certification. Most of them are about tidying up things you probably already do, and being able to show them.

1. Find out which customers are in scope. Ask them directly: which country's rules apply, what they want to see from you, and by when.
2. Map your system. Where is the app hosted, which third-party services does it use (email, payments, error tracking, AI APIs) and who has access to what? Your list of subcontractors is one of the first things a customer asks for.
3. Update, then put updates on a schedule. Run composer audit and npm audit (commands that check your packages against known vulnerabilities), fix what they find and agree on a fixed rhythm. I've written about why you shouldn't let dependencies drift.
4. Lock down access. Turn on MFA everywhere, replace shared logins with personal accounts, limit who can read production data and have a routine for revoking access when someone leaves.
5. Write a one-page incident procedure. Who notices the problem, who contacts the customer within how many hours, and what goes in the message: what happened, when, which users and data are affected and what you've done so far. Walk through it at least once a year.
6. Prove your backups restore. A backup you've never restored is an assumption, not a plan. My web app backup strategy guide covers what to test.
7. Write a security overview. Two to four pages on hosting, subcontractors, update schedule, access and MFA, backups, incident procedure and your contact person. Send it with your proposal and it answers most questionnaires before they arrive.

What NIS2 doesn't oblige your customer to demand

Small suppliers sometimes receive a security annex that reads as if it were written for a global IT provider. It helps to know that Denmark's NIS2 authority states plainly in its scope guidance (in Danish) that covered entities don't have to impose the same requirements on suppliers that apply to themselves, and don't have to demand a particular certification or audit report. Requirements should be proportionate to the risk your delivery poses.

That doesn't mean your customer can't ask. A buyer can make ISO 27001 or a SOC 2 report a condition of the deal, but then it's a commercial requirement rather than a legal one, and you can negotiate it. My advice is to answer the risk: show what you do and propose a level that fits what the app actually does for them.

When a small supplier isn't the right fit

Some situations call for a bigger supplier than a freelancer like me, and it's better to say so upfront:

• The customer requires an ISO 27001 certificate or a SOC 2 Type II report from the supplier, with no exceptions.
• The system needs round-the-clock monitoring with guaranteed response times at night and on weekends.
• The customer wants named deputies and background checks for everyone with access.

In those cases a larger supplier with a certification and an on-call rotation fits better. Sometimes the answer is a split: one party develops the app, and a certified hosting partner runs it.

Reading the contract: clauses to push back on

When the security annex arrives, read it with three questions in mind. Can I comply? What will it cost? And who carries the risk if something goes wrong?

• Notification window. "Without undue delay" is realistic for most suppliers. "Within one hour, 24/7" needs an on-call setup. Agree on what counts as an incident, too.
• Audit rights. Who pays, how often and with how much notice? A yearly written review is very different from on-site visits at short notice.
• Liability. Check that your liability cap also covers the security annex, so a clause you skimmed doesn't open the door to unlimited damages.
• Subcontractors. Does the customer need to approve new ones? Make sure switching hosting or email providers doesn't require a fresh negotiation.
• Exit. Agree on the format for returning data and the deadline for deleting it.
• Cost. Security work takes time. Updates, documentation and incident support belong in an ongoing agreement, not in unpaid extras.

Many of these points fit naturally into a software maintenance agreement with response times and update terms. For a large contract or a critical customer, have a lawyer read the annex.

Next steps: your NIS2 supplier checklist

Run through this before your next meeting with a covered customer. If you can tick every box, the questionnaire won't catch you off guard.

If you want help with the technical side, see how I handle maintenance and ongoing development for existing web apps. The legal question of who is in scope, you or your customer, is still one for an adviser.

Frequently asked questions

Does NIS2 apply to UK or US software companies?+

Usually not directly, but it reaches you through your EU customers. If they're covered, they have to assess their suppliers wherever those suppliers are based, so you'll get the same questionnaires and contract clauses as an EU company. A few types of digital provider, such as cloud and managed service providers, that serve the EU without being established there may need an EU representative. The UK has its own, separate NIS regulations.

Is the Cyber Resilience Act the same as NIS2?+

No. NIS2 regulates organizations and how they manage cybersecurity risk, while the Cyber Resilience Act (Regulation (EU) 2024/2847) sets requirements for products with digital elements, such as installable software and connected devices. It's being phased in through December 2027. A web app delivered purely as a service in the browser generally falls outside it, but if you sell software customers install, check the rules with an adviser.

How does NIS2 relate to the GDPR?+

The GDPR protects personal data, while NIS2 covers the security and availability of the whole system, even when no personal data is involved. In practice they overlap heavily, and customers often put both sets of requirements in the same annex as the data processing agreement. The reporting rules differ, though, so keep them apart in your incident procedure. I've collected the technical GDPR points in a GDPR checklist for SaaS.

Who pays for the extra security work?+

It's a negotiation, but ongoing security work usually belongs in your maintenance price. Updates, MFA and an incident procedure should be standard for any serious supplier. Requirements driven by one customer's needs, such as custom reports, audit visits or faster response times at night, are fair to price separately. Settle this before the contract is signed, not when the first audit is on the calendar.