Blog

Vulnerability management under NIS2 and ISO 27001: what dev teams need to do

Neither NIS2 nor ISO 27001 prescribes a tool. Both require that you learn about vulnerabilities in your systems, assess them, act and can prove it. What that means for a team with GitHub repos.

Updated 25 October 2026 · Stackwatch team

What the rules require

NIS2. Article 21(2)(e) of EU Directive 2022/2555 requires security measures in the acquisition, development and maintenance of systems, “including vulnerability handling and disclosure”. In Germany, the NIS2 implementation act puts this into § 30(2) no. 5 of the BSI Act (BSIG). Under § 30(1) BSIG, compliance must be documented. Other EU member states have their own implementing laws.

ISO 27001. Annex A of ISO/IEC 27001:2022 contains control A.8.8 “Management of technical vulnerabilities”. In essence: obtain information about technical vulnerabilities of the systems in use, evaluate your exposure and take appropriate measures. The standard sets no fixed patch deadlines; they are risk-based and defined in your own policy.

Whether your company falls under NIS2 depends on the scope criteria of your national authority (in Germany, the BSI). For ISO 27001, A.8.8 applies to everyone who is certified or wants to be.

Translated into a dev team’s work

Both frameworks come down to the same cycle:

Inventory: which systems, runtimes, frameworks and packages do we use, in which versions?
Stay informed: how do we learn about new vulnerabilities affecting these components?
Assess: are we affected, and how urgent is it?
Act: patch, workaround or consciously accept, with a reason.
Verify: is the fix really rolled out?
Prove it: who knew what and did what, and when?

What auditors typically want to see

A policy with ownership and deadlines per severity, for example: critical with active exploitation immediately, critical within 72 hours, high within 14 days. You set the values yourself.
An inventory of the software in use that is kept up to date, for example derived from repos, lockfiles and Dockerfiles.
Evidence for individual cases: when did the alert arrive, who acknowledged it, when was it patched, how was it verified?
Exceptions with a reason and an expiry date, if you consciously do not close a vulnerability right away.

The most common weak spot in small teams is not the patch itself, but steps 2 and 6: you learn about a vulnerability by chance, and afterwards you can no longer prove when.

Typical gaps in the process

Runtimes are missing from the inventory. Package scanners capture lockfiles, but not the PHP or Node.js version in the Dockerfile. With PHP2Shell, that was exactly the blind spot. Which tool covers what is shown in the overview Dependabot alternatives in 2026.
Alerts without an owner. Notifications land in an inbox or tab nobody is responsible for.
No evidence of assessment. “We looked at it, it doesn’t affect us” is a valid decision, but only with a date and a reason.
No prioritization. If you treat everything the same, nothing gets done in time. How to sort is covered in the article on CVSS, EPSS and KEV.

How Stackwatch helps

Stackwatch covers the steps from inventory to proof for your GitHub repos: it maps your stack down to the runtime with evidence from file and line, matches new vulnerabilities, alerts on matches with a fix and workaround, verifies via re-scan after the patch and writes every alert, acknowledgement and status change to a tamper-evident audit log (chained checksums) with CSV export. The policy and the decision on what to do stay with you. Hosting, DPA and permissions are described on the security and privacy page.

Sources

Frequently asked questions

What does NIS2 require for handling vulnerabilities?

Article 21(2)(e) of Directive 2022/2555 requires security measures for the acquisition, development and maintenance of systems, including vulnerability handling. In Germany the obligation is in section 30(2) no. 5 of the BSI Act (BSIG), and under section 30(1) BSIG compliance must be documented.

What does ISO 27001 require for vulnerabilities?

Control A.8.8 (management of technical vulnerabilities) in Annex A of ISO/IEC 27001:2022: obtain information about technical vulnerabilities, assess your exposure and take appropriate measures. The standard names no fixed patch deadlines. They are risk-based and belong in your own policy.

Does my company fall under NIS2?

You check that using the BSI criteria for affected entities. For ISO 27001, A.8.8 applies to everyone who is certified or wants to be.

What do auditors typically want to see?

A policy with responsibilities and deadlines per severity, a software inventory that is kept up to date, evidence for individual cases (report, confirmation, patch, verification) and exceptions with a justification and an expiry date.

Where do small teams most often struggle?

Usually not with the patch itself but with being informed and with providing evidence: you hear about a vulnerability by chance, and afterwards you can no longer prove when. Runtimes missing from the inventory and alerts without an owner are also typical.

How do I prove when we knew about a vulnerability and what we did?

With a date and a justification for every decision, including the decision that a vulnerability does not affect you. Stackwatch writes every alert, confirmation and status change into a tamper-evident audit log (chained checksums) with CSV export. The policy and the decision on what you do stay with you.