NIS2 Evidence and Audits: How to Prove to the BSI That Your Measures Work

If you fall under NIS2, you have to do more than implement measures: you have to be able to prove them, in a way that an outside auditor understands without you in the room. The BSI will not inspect everyone at the same time, but the duty to document has applied for months. This article covers who has to provide evidence and when, what the law allows the BSI to demand, and how to build an evidence pack that survives an inspection.

Who has to prove what to the BSI? Three groups, three regimes

The German NIS2 Implementation Act was promulgated on December 5, 2025 and entered into force on December 6, 2025. It rewrote the BSI Act (BSIG). For evidence, what matters is which group your entity belongs to. The law distinguishes three, and they are supervised very differently.

A note up front: this is not legal advice. Clarify borderline cases with your legal department or law firm.

Operators of critical facilities: evidence without being asked

§ 39 BSIG applies to operators of critical facilities. They must prove the implementation of their measures "at a point in time set by the Federal Office" and every three years after that, through security audits, inspections or certifications. The cycle used to be two years. The results go to the BSI together with any security deficiencies found. The BSI can request the underlying documentation, a remediation plan, and later proof that the deficiencies were fixed.

Transitional rules apply to existing KRITIS operators: the new date falls at the earliest three years after the last proof under the old law, and according to its FAQ the BSI informed operators individually about their dates. If you are unsure whether you operate a critical facility, the article on the obligations under the KRITIS Umbrella Act explains how to classify yourself.

Essential entities: evidence on order, at the earliest December 2028

For the other essential entities, for example companies in the Annex 1 sectors with 250 or more employees (or with high turnover and balance sheet total), the law works in two steps. § 61 (1) allows the BSI to order individual entities to have audits, inspections or certifications carried out by independent bodies. § 61 (3) covers the submission of evidence: the BSI can order it "at the earliest three years after this Act enters into force". Counted from December 6, 2025, that is December 6, 2028. For approved hospitals under § 108 SGB V a period of five years applies, unless an ordinance sets an earlier date.

Two things you should not read into this. First, the three-year period appears in the wording only in paragraph 3. The inspection power in paragraph 5, which covers checking compliance, entering premises, and requesting documents and information, names no period. Whether the BSI uses it before December 2028 is open, and you should not rule it out. Second, "can order" does not mean "will order for everyone". When selecting entities, the BSI considers risk exposure, the size of the entity, the likelihood and severity of possible incidents, and their societal and economic impact (§ 61 (4)).

Important entities: reactive, but not unprotected

For important entities, § 62 is short and clear. If facts justify the assumption that they fail to implement their duties under § 30 (1) sentence 1, § 32 (1) to (3) or § 38 (3), or implement them incorrectly, the Federal Office can check compliance and take measures under § 61. So the BSI needs a reason. The law does not define what counts as one. A reported incident or a tip from outside are conceivable. The duty to document applies from day one, though, and once there is a reason, the same toolbox applies as for essential entities.

Our example company in this article is a machinery manufacturer with 100 employees. If it belongs to an entity type in Annex 1 or 2 and has at least 50 employees, it counts as an important entity under § 28 (2). If you have not yet registered with the BSI, catch up on the missed NIS2 registration first. Without registration you violate § 33, and under paragraph 3 the BSI can even register you itself.

What can the BSI demand? Audits, inspections and documents

The law gives the BSI a tiered toolbox. For essential entities, and via § 62 for important entities when there is a reason, § 61 provides essentially these powers:

• Order audits, inspections or certifications by independent bodies (paragraph 1). They cover the duties under § 30 (risk management), § 32 (1) to (3) (reporting) and § 38 (3) (management training).
• Demand evidence and results (paragraph 3). This includes audit results including security deficiencies, the underlying documentation, a remediation plan, and proof that the deficiencies were fixed.
• Inspect itself (paragraph 5). The BSI may use a qualified independent third party. The entity must allow access to business premises during normal business hours, produce documents, provide information and give support.
• Issue orders (paragraphs 6 and 7). The BSI can order measures, remediation plans, and the implementation of specific recommendations from an inspection.

Who pays for the inspection? For an inspection under paragraph 5, the BSI charges fees and expenses only if it acted on indications that give rise to justified doubt about compliance with § 30 (1). § 61 contains no rule on the cost of an audit ordered under paragraph 1.

Documentation is a duty in itself

The most important sentence for this topic is not in the supervision provisions but in § 30 (1) sentence 3: "The entities must document compliance with the obligation under sentence 1." That has two consequences. You do not have to wait for an order to start building your evidence. And anyone who fails to document, documents incorrectly or incompletely commits an administrative offense under § 65 (2) no. 3.

The fine range is substantial. For missing or defective measures, documentation and reports it is up to EUR 10 million for essential entities and up to EUR 7 million for important entities. Only above a total turnover of EUR 500 million do the percentage caps of 2 and 1.4 percent come into play (§ 65 (5) to (7)). Refusing the BSI documents or access risks up to EUR 100,000, and ignoring an enforceable order under § 61 (3) sentence 1 up to EUR 500,000. Details on liability and penalties are in the article on NIS2 fines. An evidence pack is therefore not a nice-to-have but the fulfillment of a duty.

Does an ISO 27001 certificate or IT-Grundschutz count as evidence?

This question comes up in almost every project. The BSI's answer is clear. In its information package "ISO/IEC 27001 in the context of NIS-2/BSIG", the BSI writes that an ISO 27001 certification does not automatically mean a company is NIS2-compliant. It can answer the requirements of §§ 30, 31, 32 and 38 only incompletely or not at all and "cannot be regarded as proof of NIS-2 conformity". At the same time it forms "a good foundation" on which the duties under the BSIG can be built. And a certification is not a prerequisite for meeting the requirements of the BSIG.

Why the gap? The BSI names three reasons:

1. Scope. With ISO 27001 you define the scope yourself, and it can be limited to one site or business unit. The BSIG requires the measures for the entire relevant operation of the entity.
2. Risk treatment. The standard allows risk acceptance and risk transfer. The BSIG requires appropriate, effective and proportionate measures. Blanket risk transfer or general risk acceptance is ruled out, and you may only accept risks that are insignificant for the entity's services.
3. Additional duties. Reporting obligations (§ 32), registration (§ 33), and the responsibility, liability and training of management (§ 38) are not in the standard.

How the two frameworks overlap in detail is covered in the comparison NIS2 vs. ISO 27001. What counts here is the consequence for evidence: the certificate is one building block in your pack, not the pack. The BSI FAQ says the same: a company certificate alone is not enough, but it can be a building block for the measures under § 30.

For operators of critical facilities it looks somewhat different. The BSI's guidance on evidence under § 39 allows other standards, such as ISO 27001 certification schemes, as a basis for the audit, but requires an audit that is aligned with the critical facility, its documented scope and the requirements of the BSIG. How such a certification project runs is described in the article on the ISO 27001 certification process.

The ten minimum measures as an evidence table

The core of the evidence pack is the mapping of requirement, evidence and storage location. § 30 (2) sentence 2 BSIG lists ten areas that the measures must "at least" cover. They follow the letters a to j of Article 21 (2) of the NIS2 Directive. The ISO references in the table come from the BSI's mapping and serve only as orientation. The BSI itself stresses that implementing these controls does not automatically meet the requirements of the BSIG.

Row six is where most packs get thin. According to § 30 (2) sentence 2 no. 6, the effectiveness of measures requires "concepts and procedures for assessment". A set of policies only says what you intend to do. Only the internal audit, the metrics and the decision in the management review show that it works. How to set this up is covered in the articles on the internal ISMS audit and the management review under ISO 27001.

Building the evidence pack: how documents become evidence

An evidence pack is not a folder you throw everything into. It is an index with a cut-off date that shows, for each requirement, which evidence applies, who owns it, and when it was last reviewed. An auditor should be able to read it without follow-up questions.

When a document is evidence

A document becomes evidence when five things are true:

1. Dated and versioned. You can see which version applied at which point in time.
2. Approved. A named person put it into effect. Drafts do not count.
3. Assigned. It is assigned to a requirement, ideally through a link rather than a file name.
4. Repeated. For ongoing duties there is a time series: not one restore test, but one per cycle.
5. Unchanged. A report that can be overwritten afterwards proves little.

The BSIG names no retention period for the documentation under § 30 (1) sentence 3. As a recommendation: at least one audit cycle, so three years, plus one year as a buffer. Which documents you need to keep permanently beyond that is shown in the overview of ISMS documentation.

A folder structure for the pack

Organize the pack by requirements, not by departments. An auditor works through the list in the law, not your org chart.

00_Index (cut-off date, owners, version state)
01_Scope_and_Applicability (classification, registration)
02_Governance (policy, roles, management review minutes)
03_Risk_Analysis (methodology, register, treatment decisions)
04_Measure_Status (open and completed measures)
05_Policies (approved, with acknowledgements)
06_Incidents_and_Reports (records, report evidence, exercises)
07_Business_Continuity (BIA, emergency plans, test records)
08_Supply_Chain (supplier list, assessments, contracts)
09_Training_and_Awareness (employees)
10_Management (training evidence, resolutions)
11_Effectiveness (internal audits, metrics, findings)
12_Technical_Evidence (MFA, cryptography, patch status)

If you use an ISMS tool, you do not need the folder as a copy. Then the pack is an export or a frozen snapshot of the live data. In ISMS Lite, measures, risks, policies and training stay linked to their evidence, and with SoA snapshots you capture the state that the auditor and management review refer to before an audit. An audit log records status changes and business write operations. It complements the functional evidence but does not replace it.

Risk analysis and measure status: make decisions visible

In its information package, the BSI requires that decisions for or against measures be documented traceably and that the reasons be recorded in an audit-ready way. For the pack this means: besides the risk register, every risk that you do not treat with a measure needs a reason why it is insignificant for your entity's services. "Accepted" without a reason is not enough.

The measure status belongs in the pack as a dated snapshot: what is implemented, what is in progress, what is open, who is responsible, by when. Also show completed measures with their effectiveness check. Open items are no flaw if a plan stands behind them. The law even explicitly provides for a remediation plan.

Management: proving training and oversight

Under § 38 (1), management must implement the risk management measures and monitor their implementation. Under paragraph 3 they must take part in training regularly. The BSI has published a guidance document on this, "Training for management boards", currently in version 1.0 of April 17, 2026. Its most important points for the pack:

• Who must be trained. All persons who are authorized by law, articles of association or partnership agreement to manage the business and represent the entity. The BSI assumes that in most entities this affects several people.
• How often. The law says only "regularly". The BSI recommends a thorough initial training with regular follow-ups and names as triggers a change in management and significant changes in processes, risk exposure or measures.
• Which content. Recognizing and assessing risks, risk management measures, and judging their impact. According to the BSI, training that covers only measures falls short of the law and would be rated as insufficient in a supervisory action.
• Which formats. They do not have to be multi-hour lectures. The BSI mentions, among others, a quarterly risk management meeting with the information security officer (ISB), tabletop games and an audit simulation.
• What the documentation contains. Provider or internal unit, participants with their role, date, time and duration, and the content covered with reference to § 38 (3). A knowledge test is not required by law or by the BSI.

The most interesting point in the guidance: attendance documentation proves only attendance. That management has acquired "sufficient knowledge" shows, in the BSI's reading, in that it takes part in risk management decisions in a traceable way. So the resolutions belong in the pack too: approval of the policy and risk treatment, budget decisions, management review minutes.

Incidents and reports: the timeline counts

For significant security incidents, § 32 (1) requires an early initial report within 24 hours of becoming aware, a report with a first assessment within 72 hours, an interim report on request, and a final report at the latest one month after the 72-hour report. The evidence here is the timeline: when was the incident detected, when assessed, when reported, through which channel, with which reference?

Also put incidents into the pack that were not reportable, together with the assessment of why not. An auditor who sees twelve assessed incidents without a single report will ask about your threshold. If you documented it, you answer in a minute. For this, ISMS Lite separates report type, actual sending time, channel, reference and evidence, so the timeline sits in the incident itself.

Timeline 2026 to 2028 for a company with 100 employees

First the legal position: the duties under § 30, § 32, § 33 and § 38 have applied since entry into force, and the earliest date for an order under § 61 (3) is December 6, 2028. The timeline below is not a statutory deadline but a planning recommendation. It assumes that the example company, as an important entity, starts from zero with its evidence work and that customers will ask for evidence earlier than the BSI. For suppliers to the automotive industry, the requirements of TISAX under VDA ISA 2027 come on top with the new assessments. The pack can be reused for that.

As a planning assumption for the example company, count on one responsible person who spends a few days per quarter maintaining the pack, and on a fixed quarterly management slot for risk management, a format the BSI itself names for training. The biggest time sink is not collecting but chasing missing approvals and links. The earlier you start, the less piles up at the end.

Take the dry run seriously too. Play it through once: the BSI demands documents on short notice. Who delivers, who approves, where is the pack, who may see it? The answer must not be "Only the ISB knows."

Checklist: Evidence pack for the BSI

Foundation

• Classification as essential or important entity (or operator of critical facilities) documented, with date and reasoning
• Registration with the BSI confirmed, change notices within two weeks organized
• ISMS scope covers the entire relevant operation of the entity (not only the IT department)
• Index of the evidence pack created with cut-off date, owner and version state

The ten minimum measures

• Risk analysis with methodology, register and approved treatment
• Reasoning for every risk that stays without a measure
• Incident response policy and incident records in place
• BIA, emergency plan and at least one test record in place
• Supplier list with assessment of critical suppliers
• Patch and vulnerability process with reports
• Cryptography policy and key inventory
• Access control concept, joiner and leaver process, asset inventory
• MFA coverage shown as an export

Governance and management

• All members of management identified and enrolled in training
• Training documentation with provider, participants, date, duration and content
• Approval of policy and measures by management, with date
• Management review minutes with decisions and follow-up measures

Reporting

• Reporting process for 24 hours, 72 hours and one month described
• Contact list and deputy arrangement for reporting
• Exercise record, for example from a tabletop exercise
• Assessment of non-reportable incidents documented

Effectiveness and maintenance

• Internal audit carried out, report and findings available
• Remediation plan for open findings with deadlines
• Effectiveness metrics defined and collected at least twice
• Retention defined (recommendation: at least four years)
• Dry run "BSI demands documents" played through once
• Cut-off state frozen and access regulated

Common mistakes with NIS2 evidence

Treating the certificate as a free pass. An ISO 27001 certificate whose scope covers only the IT department does not cover the duties of an entity. The BSI states explicitly that certification does not mean NIS2 conformity. Check scope, risk acceptance, reporting, registration and management against the BSIG.

Documents without date, approval and version. The policy sits on a file share, but nobody can say who put it into effect when and what applied before. To an auditor that is a draft. Approve policies formally and archive old versions instead of deleting them.

Accepting risks wholesale. "Accepted" in a column replaces no reasoning. The BSI rules out general risk acceptance and blanket transfer. For every decision, write down why the risk is insignificant for your services or the measure disproportionate, and use the criteria in § 30 (1) sentence 2 as your yardstick.

Treating management as a side issue. The pack holds a training certificate for one person although management has three members. Or the certificate names no content. The BSI expects attendance documentation for everyone subject to the training duty and looks for learning in decisions. Plan resolutions as evidence.

Assembling the pack only when the order arrives. If you only start collecting when the BSI's letter lands, you find gaps that can no longer be closed: a restore test that never happened, an audit that did not take place. Evidence is created in operation, not afterwards. Time series cannot be produced retroactively.

Conclusion: the pack grows with operations

The law has required documentation since December 2025 and submission at the earliest from December 2028. The time in between is not a grace period but the window in which time series can emerge: two audit cycles, two management reviews, two training rounds. Start this week with the index, assign the ten measures to evidence, and mark where nothing exists yet. Once the gaps are in the index, you know what to do next.

Further reading

• NIS2 Checklist: All Requirements at a Glance
• Evaluating Audit Findings and Deriving Actions
• Training Records in the ISMS: What Must Be Documented
• NIS2 Initial Report to the BSI: Content, Deadlines, and Template
• Risk Assessment in the ISMS: Methodology, Matrix, and Practical Example