NIS2 and your software supplier: what to require from your development partner and put in the contract

DESAmedia · 2026-10-20

Short answer

If your organisation has been added to Lithuania's register of cybersecurity entities, NIS2 obligations do not stop at your own walls: they have to be carried into your contracts with the companies that build, maintain or host your systems. The responsibility stays with you. The Lithuanian Law on Cybersecurity and the government-approved Description of Cybersecurity Requirements (KSRA in Lithuanian) require supplier contracts to cover the supplier's compliance with the requirements, a duty to report incidents, your right to audit, vulnerability management, an SLA, access levels and several other points (KSRA point 34). Organisational requirements, including supply chain security, must be in place within 12 months of registration, and technical requirements within 24 months. For organisations that NKSC registered in the first identification round (notifications were sent by 17 April 2025), this means contracts should already have been updated, and the technical requirements must be implemented by 17 April 2027 at the latest. In practice, your development partner will implement most of those technical requirements in your system, so below we cover what to put in the contract, what to require technically and how to review existing suppliers.

Who this applies to and the deadlines

The amended Law on Cybersecurity, which transposes the NIS2 Directive (EU) 2022/2555 into Lithuanian law, entered into force on 18 October 2024. It applies to medium-sized and large companies and public-sector bodies operating in the sectors listed in Annexes 1 and 2 of the law. Some entities, such as central and regional government bodies, are classed as essential regardless of size. Small and micro companies are generally out of scope, apart from the exceptions set out in the law.

Entities are split into essential and important. Essential entities are subject to stricter supervision by NKSC (the National Cyber Security Centre), and some technical requirements apply only to them. Obligations start from the date of registration in the Cybersecurity Information System (KSIS). According to the Ministry of National Defence (KAM), the register includes 1,443 organisations from 11 sectors of high criticality and 7 other critical sectors, and it is reviewed at least once a year, so new entities are still being added.

The deadlines are set in KSRA points 71 and 72:

If your organisation was registered later, the deadlines run from your own registration date, which you will find in the NKSC notification and in KSIS.

One important detail: the requirements do not apply to every system the organisation runs. They apply to the network and information systems that support the activity for which the organisation was added to the register. So the first step is not supplier contracts but a list of your systems and which of them support that activity.

Why this involves your development partner

Article 14(5) of the law lists supply chain security, including relationships with direct suppliers and service providers, and security in the acquisition, development and maintenance of network and information systems, including vulnerability handling, among the mandatory elements of cybersecurity. Article 21(3) of the NIS2 Directive goes further: when choosing supply chain measures, entities must take into account the vulnerabilities specific to each direct supplier, the overall quality of its products and its cybersecurity practices, including secure development procedures.

A supplier that is not itself in the register has no direct obligations under the law. NKSC calls this an indirect effect: the requirements reach the supplier through your contract and your oversight. KAM puts it plainly: entities must require and verify that suppliers meet cybersecurity requirements, have incident response plans and relevant certifications, and will cooperate if an incident occurs. Responsibility for choosing and overseeing suppliers stays with the organisation, however many suppliers it uses.

There is one exception worth knowing about. Managed service providers, cloud providers and data centre providers can be cybersecurity entities in their own right, subject to Commission Implementing Regulation (EU) 2024/2690. If your hosting or IT support partner is one of them, ask which requirements it already implements itself.

What the KSRA says your contract must cover

Section six of the KSRA deals with the supply chain. It requires a supply chain security procedure (point 32), supplier selection criteria (point 33), specific contract terms (point 34), supplier risk assessment (point 35), monitoring of the security requirements set in the contract (point 38) and an up-to-date list of suppliers (point 39).

For the buyer, point 34 is the key one. It lists what a contract with a supplier, including subcontractors, must cover to the extent it relates to the services provided. Below, each sub-point is translated into what it means in a software development, maintenance or hosting contract.

Point 34 overlaps with things your contract should cover even without NIS2: ownership of the code, the code kept in your own repository, a data processing agreement under the GDPR, warranty and exit terms. We covered those in detail in How to choose a software development partner: 12 questions before you sign. From a cybersecurity perspective they matter for business continuity: if the supplier walks away, you need to be able to take the system over.

In the public sector, these requirements need to appear in the procurement documents. NKSC advises defining the third party's logical and physical access levels and conditions in the procurement documents, and suggests that supplier compliance can be assessed, for example, by asking bidders to fill in a table of cybersecurity requirements. We explained how to write security requirements that can actually be verified in Technical specification for a software project.

Technical requirements your developer will implement

The technical KSRA requirements are set out in seven tables. Some of them concern office infrastructure (workstations, Wi-Fi, printers), but a good number apply directly to a custom-built system, its servers and its hosting. These are the ones to discuss with your development partner now, so they are in place before the 24-month deadline.

Identity and access management

• Users and administrators confirm their identity with a password and an additional factor, in other words multi-factor authentication (KSRA table 7, point 61).
• Every user is uniquely identifiable, and administrator tasks are performed from a separate account that is not used for everyday work (points 58 and 60).
• An administrator's rights are suspended after more than 2 months of inactivity, and a user's after more than 3 months (points 62 and 63).
• On publicly accessible websites, credentials, API keys and tokens must not be stored in the source code (point 76.1). For a developer, that means a secrets store and a check that nothing has been committed to the repository.
• Third-party access, including your supplier's, is limited to the resources that party needs, goes through a secure VPN, uses multi-factor authentication where possible, and is logged (table 3, point 32.2).

Logging

KSRA table 1 sets out what must be logged where the system supports it: user and administrator authentication events, account creation and access changes, administrator actions, and the viewing, deletion or modification of logs. Each entry must include the date and exact time, the user or device involved and a description. Logs must be kept for at least 90 calendar days, must not be deleted or altered before that period ends, and must be analysed at least once a month.

For a custom system this calls for a clear decision: which events go into the application audit log, where the log is sent (ideally outside the system itself) and who may read it. If the system does not do this today, that is a concrete piece of development work to estimate and schedule.

Protecting internet-facing systems

Table 3 includes several requirements that are part of a developer's daily job:

• a web application firewall (WAF) for internet-facing systems (point 36);
• protection against the main attacks following OWASP Top 10 good practice (point 37);
• input validation in web forms (point 38);
• error messages that reveal nothing about the system, the code or the server (point 39);
• only the HTTP methods the functionality needs (point 40).

For essential entities, table 4 also requires TLS 1.3 or newer on websites (point 48.4).

Updates, changes and vulnerabilities

• Updates recommended by software vendors are installed (table 3, point 30). Systems that, for objective reasons, run unsupported versions must sit in a separate network segment (point 31).
• Security patches are tested before they go to production (point 44), and changes that could disrupt operations are approved and tested in a test environment (point 43). In practice, you cannot meet this without a test environment.
• The vulnerability management procedure must require critical vulnerabilities to be fixed without delay and a full vulnerability scan of the system at least every 6 months (points 45.7 and 45.8). NKSC also cites as good practice assessing new systems for vulnerabilities before they are formally put into use.

The patch, change and vulnerability management procedures (KSRA points 43-45) are organisational requirements, so the 12-month deadline applies to them.

Backups and availability

• Backups are made at a set frequency and kept in a geographically separate location (table 2, point 17).
• Backups are tested regularly, or software is used that automatically checks whether fully working data can be restored from them (point 18).
• Backup data is encrypted, with the keys kept separately from the backups (table 4, point 49).
• Systems identified as critical for business continuity must be available at least 99% of the time for essential entities and 96% for important ones (point 16).
• The business continuity plan sets a recovery time objective (RTO) and a recovery point objective (RPO), and both must be tested (points 27.9 and 27.10).

These figures should be reflected in the hosting and maintenance contract. If the SLA promises 99% availability but nobody has ever tested a restore from backup, the requirement is met only on paper.

Incidents: what the supplier must do in the first hours

For a significant incident, the entity must send NKSC an early warning within 24 hours, an incident notification with an initial assessment within 72 hours and a final report within one month (Article 18 of the Law on Cybersecurity, Article 23 of the NIS2 Directive). Other incidents are reported to NKSC within 72 hours.

The clock starts when you become aware of the incident, and with a system run by a supplier, the supplier is often the first to know. So the contract should spell out:

• within how many hours and through which channel the supplier reports an incident (KSRA point 34.3 requires reporting as soon as the supplier becomes aware);
• who is on call on both sides outside business hours;
• what information the supplier provides in the first hours so you can meet the 24- and 72-hour notifications;
• preservation of evidence and logs (KSRA point 24.6 requires the incident response plan to cover how evidence is collected and preserved);
• the content and deadline of the investigation report.

If the supplier provides services related to incident handling, your incident response plan must be agreed with that supplier (KSRA point 23).

Existing systems and existing contracts

For most organisations, the real work is not new procurement but systems already in production and contracts signed years ago. A practical order of work:

1. List your systems. An asset inventory is a KSRA requirement. For each system, note whether it supports the activity for which you are registered, who built it, who maintains it and where it is hosted.
2. List your suppliers. KSRA point 39 requires a list of suppliers, reviewed when contracts change or significant incidents occur.
3. Check each contract against point 34. Note which sub-points are missing. The usual gaps are the audit right, an incident notification deadline and a vulnerability management duty. Missing terms can be added through an annex or an amendment. In the public sector, any contract modification has to be assessed against Article 89 of the Law on Public Procurement.
4. Run a technical gap analysis. Compare the system with the technical requirements: multi-factor authentication, logging, WAF, backups, a test environment. You end up with an estimated list of work that can be scheduled before the 24-month deadline.
5. Deal with legacy systems. If a system runs on an unsupported operating system or framework version and cannot be upgraded quickly, it must be isolated in a separate network segment (table 3, point 31) and its modernisation planned.

KAM also answers a common question about off-the-shelf products: if software was bought as a product and there is no ongoing contact with the vendor, assessing the vendor and the product at the time of purchase is enough. If support is purchased, the organisation providing it counts as a third party and its risk has to be assessed on an ongoing basis. KAM also lists a change of the supplier providing critical maintenance or development services as grounds for an extraordinary risk assessment.

When a contract ends, NKSC recommends making sure that data is securely returned or destroyed with proof of destruction, that all access granted to the supplier is revoked, that the supplier's last logged actions are reviewed, and that confidentiality obligations continue after the contract.

Supplier assessment checklist

You can send these questions to a current or prospective supplier and ask for written answers. The answers will also feed into the supplier risk assessment (KSRA point 35).

• Who has administrator access to our system, servers and database? Is that access personal, protected by multi-factor authentication and time-limited?
• Is the code kept in our repository, and is the code free of passwords and API keys?
• How do you track vulnerabilities in the libraries and dependencies you use? How quickly do you deploy a fix for a critical vulnerability?
• Is there a test environment where changes and patches are tested before production?
• Which actions does the system log, where are the logs kept and for how long?
• Where and how often are backups made, are they encrypted, and when was a restore last tested?
• Is the internet-facing system behind a WAF, and has it been tested against the OWASP Top 10?
• When was the last vulnerability scan or penetration test, and what did it find?
• Within how many hours, and to whom, do you report an incident? Will you put that in the contract?
• Will you accept an audit carried out by us or by an auditor we appoint?
• Do you use subcontractors or cloud services that have access to our data?
• Do you have an incident response plan, and security certifications or an independent audit report?
• What do we receive if the contract ends: code, documentation, access, a copy of the data? How will you confirm that data has been destroyed?

If a supplier will not provide the information needed to assess it, KAM recommends asking for an independent auditor's assessment report that covers the requirements you care about.

Example: what this looks like in practice

This example is fictional; the organisation and figures are made up for illustration.

UAB Pavyzdys is a medium-sized company that NKSC has registered as an important entity. It runs a customer self-service portal built four years ago and maintained by an external developer, with servers rented from a hosting provider. The contract with the developer includes an SLA and handover of the code, but no audit right, no incident notification deadline and no vulnerability management duty.

The review found that administrators log in to the portal with a password only, the application audit log records only orders, and backups are kept in the same data centre. The resulting plan: a contract annex with the KSRA point 34 requirements (incident reported within a few hours, audit right, patches by severity), multi-factor authentication for administrators, an audit log covering logins and permission changes kept separately for at least 90 days, backups in a second location with encryption and a quarterly restore test, a WAF in front of the portal, and a vulnerability scan every six months. The work was phased to fit the 24-month deadline, with the contract changes done first.

Common mistakes

• Treating NIS2 as an IT department task. The law makes the head of the organisation responsible for compliance, and supplier requirements have to appear in procurement and contracts.
• A contract that just says "the supplier complies with applicable law". That phrase does not replace the specific point 34 terms: deadlines, the audit right, a description of access.
• Forgetting subcontractors. Point 34 covers contracts with suppliers, including subcontractors. If your developer uses another company for servers or testing, you need to know.
• Backups nobody has ever restored. The KSRA requires backups to be tested, not just taken.
• No test environment. Without one, patches and changes cannot be tested before production.
• Shared accounts. An "admin" account used by the whole supplier team breaks the requirement that every user be uniquely identifiable.
• Leaving the technical work to the last few months. Adding multi-factor authentication or an audit log to an older system is a development project that needs budget and time. We explained how to think about the cost of that kind of work in How much does custom software development cost.

FAQ

Does the Law on Cybersecurity apply to my IT supplier?

Directly, only if the supplier is itself in the register (for example, as a managed service provider or cloud provider). Otherwise, the requirements reach the supplier through your contract: you must include them and monitor compliance (KSRA points 34 and 38).

Does an ISO 27001 certificate mean the supplier meets the requirements?

Certifications are among the things you can require of a supplier's staff and organisation (KSRA point 34.2), and they make the assessment easier. However, NKSC states that the mandatory cybersecurity audit must follow the NKSC methodology, so an ISO 27001 assessment does not replace it on its own. The contract still needs the point 34 terms.

What are the fines?

Article 30 of the Law on Cybersecurity sets the maximum fines: for an essential entity, up to EUR 10,000,000 or up to 2% of worldwide annual turnover, and for an important entity, up to EUR 7,000,000 or up to 1.4%, whichever is higher. Lower caps apply to budgetary institutions: up to 1% of the budget and income but no more than EUR 60,000 for an essential entity, and up to 0.5% but no more than EUR 30,000 for an important one. The actual amount depends on how serious the breach is.

Do all contracts need to be changed at once?

NKSC recommends including the point 34 requirements in new contracts, in line with the services being purchased. For existing contracts, it makes sense to prioritise by how critical the system is, starting with suppliers that have access to systems supporting the registered activity.

Can we audit the supplier ourselves?

Yes, if the contract gives you that right. KSRA point 34.4 requires the contract to give you, or a service provider you authorise, the right to audit the supplier's compliance, including unplanned audits. This is not the same as the cybersecurity audit every 3 years under Article 14(8) of the law, which is carried out by independent certified auditors.

Do the requirements apply to our company website?

They apply to systems that support the activity for which you are registered. If a website or portal is such a system (a customer self-service portal, for example), the specific requirements for internet-facing systems also apply: a WAF, protection based on the OWASP Top 10, and no credentials in the code. A purely informational website unrelated to that activity is not covered by them, although they are still good practice.

Next steps

Start with three things: draw up a list of systems and suppliers, mark the systems that support the registered activity, and compare each contract with KSRA point 34. Then go through the technical requirements with your developer and build a plan of work that fits your 24-month deadline.

DESAmedia builds and maintains custom systems, so we can help from the developer's side: assess an existing system against the technical requirements, prepare a plan of work with an estimate, and implement the changes, from multi-factor authentication to the audit log and backup restore tests. That is what our IT consulting and system design service is for, and for new systems, web application development. Public-sector organisations may also want to see our public sector page. This does not replace the cybersecurity audit required by law, which is carried out by independent certified auditors. You can send us your questions via the contact page.

Sources

• Law No. XIV-2902 amending the Law on Cybersecurity No. XII-1428 (e-tar.lt, in Lithuanian)
• Law on Cybersecurity, Article 14. Cybersecurity risk-management measures (infolex.lt, current version, in Lithuanian)
• Law on Cybersecurity, Article 18. Incident notifications (infolex.lt, in Lithuanian)
• Law on Cybersecurity, Article 30. Fines (infolex.lt, in Lithuanian)
• Government Resolution No. 818 of 13 August 2018 on implementing the Law on Cybersecurity (e-tar.lt, consolidated version, in Lithuanian)
• Government Resolution No. 945 of 6 November 2024 approving the current Description of Cybersecurity Requirements (e-seimas.lrs.lt, in Lithuanian)
• Ministry of National Defence. Law on Cybersecurity (in Lithuanian)
• NKSC. Law on Cybersecurity: frequently asked questions (in Lithuanian)
• NKSC. Description of Cybersecurity Requirements: frequently asked questions (in Lithuanian)
• Directive (EU) 2022/2555 (NIS2), EUR-Lex
• OWASP Top 10