Section 30 BSIG and your own code: the dated evidence a scan on every commit produces

What Section 30 BSIG actually requires

The wording is shorter than many vendors make it sound. Subsection 1 obliges essential and important entities to take appropriate, proportionate and effective technical and organisational measures, and closes with a sentence that sets the tone of any audit: compliance with this obligation must be documented. Subsection 2 then lists what those measures must at least cover. Number 5 reads: security measures in the acquisition, development and maintenance of IT systems, components and processes, including vulnerability handling and disclosure. Number 6 adds policies and procedures to assess how effective those measures are.

Notice what the paragraph never mentions: a tool, a vendor, a method. It tells you the state you must be able to demonstrate, that vulnerabilities are known, dealt with and disclosed, and stops there. The route is yours to choose. So when a sales deck turns this clause into a purchase obligation for scanners, the clause itself disagrees. Our code security and compliance page says the same, and this article does not soften it.

Why your own code falls under number 5

Number 5 speaks of systems, components and processes, not of software in the narrow sense. In practice, though, the vulnerabilities an attacker finds first sit exactly there: in an API key checked in three years ago that still lives in the repository history, in an open-source library with a flaw that has been public for months, or in an input that is passed unchecked to a database. All three are vulnerabilities in the sense of the act. All three arise during development or maintenance. And all three can only be managed if someone looks for them regularly.

That is precisely where an annual check fails. A finding from March says nothing about the commit from June. Number 5 does not demand a date, but the documentation duty in subsection 1 does, and an auditor reading the file asks first of all how current it is.

What a scan on every commit leaves behind as a record

A continuous scan produces four data points per finding, and those are exactly the four that belong in a file. First, the finding itself: hardcoded password, vulnerable dependency, unsafe pattern. Second, the assessment by real risk, after a person has checked whether the finding is exploitable at all in the context of the codebase. Third, the action: secret rotated, library updated, pattern defused. Fourth, the date the action was carried out.

Over weeks those four points become documentation that does not have to be assembled before the audit because it is created while the work is done. How that works for the other NIS2 duties is in our article on proving NIS2 compliance in daily operations. For code the principle is the same, only the tool differs.

What also belongs in the file is what is not in it: false positives are removed before they reach the report. An auditor who sees 400 hits of which 380 were not exploitable learns nothing about security from them, only something about the scanner.

What evidence should not look like

Three forms keep turning up in mid-sized companies, and none of them survives a follow-up question. A scanner's raw list without assessment: it proves a tool was run, not that anyone acted. The screenshot from year end: it proves one day, not a process. And the self-declaration in a questionnaire that development is secure: it proves someone ticked a box.

Number 6 of subsection 2 makes it plainer still. Anyone who has to assess the effectiveness of their measures needs data on whether the measure worked over time, which is something a one-off snapshot cannot show and a dated series can.

Where the record comes from, step by step

On day 0 the repositories are connected and the existing code is searched once for secrets, vulnerable dependencies and unsafe patterns. After 48 hours the first findings are in: what is real and critical, what can wait, what has to happen first. In the first week critical secrets are rotated, libraries updated, dangerous patterns defused, and each of those actions gets a date. From then on the check runs on every commit, and the file grows with the code instead of before the audit date.

The entry point is the free code analysis: connection, inventory scan and prioritised findings, no obligation, inside your own environment on request.

Frequently Asked Questions