The minimal NIS2 policy stack for small organisations

The guide has given you the building blocks: IS-Policy with minimum content, seven sub-policies mapped to Section 30 BSIG, owners, validity dates, management approval, annual review. What it does not explain: why most first drafts still contain four weaknesses, which single formulation in each sub-policy most often produces audit findings, and how a management approval must be structured to hold up after a BSI auditor visit. That is what this article covers.

Step 1: The IS-Policy – Four Places Where First Drafts Fail

The IS-Policy is the first document a BSI auditor requests. Its existence is not enough. Its content determines whether Section 30(2)(1) BSIG is considered satisfied. Four errors appear in most first drafts – often simultaneously.

Error 1: No risk acceptance criteria

Risk acceptance criteria – also called risk appetite – define the level up to which your organisation tolerates risks without actively mitigating them. Without this section, all sub-policies are logically unmoored: an access control policy requiring least privilege cannot be rationally justified without a defined acceptance threshold. A BSI auditor asking about the rationale for your security decisions needs this definition as the foundation.

The minimum for a small entity is three acceptance levels with clear criteria. Example: "Risks with low probability and limited impact on business operations are accepted. Risks with medium probability or significant impact are mitigated through measures from the security plan. Risks with high probability or critical impact are reduced to the medium level or lead to the discontinuation of the affected process." Reference your risk analysis for operationalisation.

Error 2: Management commitment as a statement of intent

"Management is committed to information security and supports all related measures." This sentence appears in many IS-Policies and gives a BSI auditor no actionable information. Section 38 BSIG does not require a statement of intent – it requires the governing body to actively approve measures under Section 30 BSIG and oversee their implementation.

A sufficient management commitment contains three concrete elements: the named appointment of the ISB with their role, a resource commitment (as a budget line or percentage of time allocation), and the explicit statement that sub-policies are binding for the entire organisation and violations carry consequences. The sentence "Ms Müller is appointed as ISB and allocated 20% of her working time plus an annual budget for security measures" satisfies the criterion. "The sub-policies are binding" alone does not.

Error 3: Scope that excludes cloud

"This policy applies to all IT systems of the company" sounds complete – but frequently excludes cloud services, SaaS applications, and external service providers with system access, because users do not perceive these as "IT systems of the company." Write the scope explicitly: "This policy applies to all information systems, networks, and data of [the entity], including all cloud-based services, SaaS applications, external service providers with access to company systems or data, and personal devices used under BYOD arrangements."

If exceptions exist – systems of a subsidiary, separate regulatory environments – name them explicitly as excluded. What is not explicitly excluded falls under the policy. Not the other way around.

Error 4: No datable approval act

The date of management signature is the legal anchor point: from this date, the policy is considered introduced. If an auditor asks "since when have you operated a documented information security policy?", the answer is the management signature date – not the file creation date or the internal completion date. The approval must therefore be a real, traceable event: a signature at a meeting, a recorded session, an email with explicit reference to document name and version. This date appears in the document and matches the actual approval act.

Output of this step: IS-Policy with explicit scope (including cloud), risk acceptance criteria, management commitment naming the ISB with resource allocation, reference to all sub-policies, and a signature field with a real management date.

Step 2: The Seven Core Policies – What "Minimal" Means and the Critical Pitfall Per Policy

Each of the seven sub-policies is documentary evidence that a concrete measure under Section 30(2) BSIG is anchored in your organisation. Without the policy, you cannot demonstrate an implemented measure – not because the measure does not exist, but because there is no rulebook for an auditor to reference.

The Section 30 mapping at a glance:

• Access Control Policy → Section 30(2)(9) BSIG
• Patch Management Policy → Section 30(2)(6) BSIG
• Cryptography Policy → Section 30(2)(8) BSIG
• Incident Response Policy → Section 30(2)(2) BSIG
• Backup and Recovery Policy → Section 30(2)(3) BSIG
• Supplier Security Policy → Section 30(2)(4) BSIG
• Acceptable Use Policy (incl. BYOD and password rules) → Section 30(2)(7) BSIG

"Minimal sufficient" does not mean few pages – it means: the policy defines a concrete rule, a named responsible owner, and a consequence for non-compliance. A two-page policy that does this is more audit-relevant than a 15-page document that does not. The following identifies the pitfall that most often produces audit findings in each policy.

1. Access Control Policy (Section 30(2)(9) BSIG)

The most common pitfall: "MFA is mandatory for all critical systems." What are critical systems? Without a list or classification criterion in the document, each administrator decides for themselves – which effectively nullifies the MFA requirement. Write system-specifically: "MFA is mandatory for all admin accounts, all remote access systems (VPN, RDP), all cloud services accessing internal data, and all email accounts." Equally essential: a measurable offboarding deadline. "Accounts of departing employees are deactivated within 24 hours of their last day" is auditable. "Promptly" is not.

2. Patch Management Policy (Section 30(2)(6) BSIG)

The most common pitfall: patch deadlines are defined as targets for the IT service provider – not as binding requirements in your own policy. If your external IT provider manages patching, their SLA deadlines must appear explicitly in your policy and be contractually secured. "Critical patches are applied within 72 hours of availability – unless an approved exception document exists" is the correct formulation. Without this ownership in your own policy, you lack the Section 30 audit trail even if the provider patches on time.

3. Cryptography Policy (Section 30(2)(8) BSIG)

The most common pitfall: approved algorithms are listed – AES-256, RSA-3072+, TLS 1.2 minimum – but no one is named as responsible for key management. When a key is lost or compromised, there is no escalation line. Name explicitly: who manages certificates, who approves exceptions to the algorithm list, who is the first point of contact for key compromise. "Key loss = security incident" must appear in the policy as an explicit statement.

4. Incident Response Policy (Section 30(2)(2) BSIG)

The most common pitfall: the escalation chain ends at "notify the ISB" without contact details in the document itself. During a ransomware attack at 3am, no employee will search the intranet for the ISB's phone number. Primary and fallback contacts (phone, email) must be in the policy. The same applies to external contacts: BSI notification platform MELDIS, external forensics firm if under contract, legal contact. The 24-hour initial notification obligation under Section 35 BSIG must appear explicitly as a deadline in the policy – not buried in an IR plan that staff may not know.

5. Backup and Recovery Policy (Section 30(2)(3) BSIG)

The most common pitfall: backup frequency and retention periods are defined, but no testing obligation. The BSI considers a backup without a restore test an incomplete measure. Write explicitly: "Quarterly restore test of a defined dataset; annual full recovery test. Test results are documented. If a test fails, a re-test is mandatory within 14 days." Without this testing obligation in the policy, your backup implementation is not demonstrable in an audit.

6. Supplier Security Policy (Section 30(2)(4) BSIG)

The most common pitfall: the policy applies to "important suppliers" without defining what that means. When an auditor asks "which of your suppliers fall under this policy?", the answer should be derivable from the document. Define Tier-1 criteria: suppliers with direct access to production-critical systems or sensitive data, without which business operations cannot be maintained within 24 hours. These suppliers are subject to annual security assessments and a contractual incident notification obligation. The classification itself does not need to be in the policy – it must reference a documented classification logic.

7. Acceptable Use Policy (Section 30(2)(7) BSIG, incl. BYOD and password rules)

Two pitfalls in one policy. First, BYOD: "personal devices are permitted under certain conditions" without defining those conditions is unenforceable. Either BYOD is not permitted – stated clearly in the document – or BYOD is permitted with mandatory MDM, data separation (container approach), IT remote-wipe authorisation, and screen lock after a maximum of 5 minutes. Any middle position without these technical requirements is a policy with no enforcement mechanism.

Second, password rules: forcing password changes every 90 days contradicts BSI guidance since 2021. The BSI no longer recommends periodic forced changes – except on concrete suspicion of compromise. A policy based on outdated security knowledge signals to an auditor that no current review has taken place. Current formulation: "Password changes are required immediately upon suspected compromise or at ISB request – no periodic forced changes."

Output of this step: seven policies of one to four pages each, each containing a concrete rule, a named owner, and a consequence for non-compliance.

Step 3: The Policy Register – the Document That Saves Audits

The guide instructs you to assign an owner and review date to each policy. A policy register holds that on a single page – as your working tool and as the first answer when an auditor asks "show me your policy governance." The register contains five fields per policy: policy name, owner (name, not function), current version, last approval date, next review date.

Ownership: ISB as owner of all policies is a warning sign

If the ISB owns all eight policies, it signals to an auditor that no line management accountability for security exists. A more defensible distribution: the IT manager owns the access control and patch management policies, because they make the operational decisions and can answer substantive questions during an audit. The ISB owns cryptography, IR, and backup policies. Supplier security is shared between ISB and procurement. The acceptable use policy is shared between ISB and HR. This distribution is not a formality – it determines who can answer substantively when audited.

Overdue reviews: worse than no register

A policy register with a past-due review date is actively worse than no register – it documents a missed obligation. If you create the register and a review date has already passed, there are two acceptable responses: either complete the review immediately, or document the reason for the delay and set a new, binding date. Leaving the old date unchanged is not defensible in any audit context.

The four triggers for immediate ad-hoc review

Beyond the annual cycle, four events require immediate review of the affected policy: a regulatory change that directly affects the policy area; a security incident that has exposed a gap in an existing policy; a material system change that makes a policy rule technically unenforceable; and an audit finding that references a specific policy. When these four triggers occur, the annual calendar date is not sufficient.

Output of this step: policy register – one page, eight rows, five columns. Every policy, every owner, every version at a glance.

Step 4: Getting Management Approval – Preparing the Conversation and Choosing the Right Form

The most common problem: the ISB sends all eight documents to the managing director by email with a note to "please review and approve." Result: a reply email saying "looks good, go ahead" – without document reference, version number, or date. This is not an audit-proof approval.

What a valid approval requires: an unambiguous reference to the document (name and version), a date, and a signature or a digitally traceable equivalent. Email approval is possible if it reads explicitly: "I approve IS-Policy Version 1.0 and the seven sub-policies in Version 1.0 dated [date]." This email is archived and constitutes the approval record. An undated email or one without a document reference is insufficient.

For the first approval, a 30-minute meeting is recommended – not because of the time required, but because of the questions. When the managing director sees the IS-Policy for the first time, questions are normal and expected. These questions are evidence that management understands the content – which is what Section 38 BSIG means by "active approval." Future annual reviews can be conducted by email with the correct formulation once the framework is established.

The three sentences for the management conversation: "This document package is the written proof that you are actively governing our organisation's information security – Section 38 BSIG makes you personally accountable as a governing body member. It changes nothing in daily operations, which remain with the ISB. What it does change: in the event of an audit, you have a dated approval record rather than a verbal assertion."

When sub-policies require renewed management approval: for minor changes – typo corrections, updated contact details, refined formulations without rule changes – ISB approval is sufficient, documented with a new version number. For major changes – expanded scope, new rules, changed responsibilities – management approval is required. If every small change triggers management sign-off, the managing director will stop reading the documents. That is the end of a functioning policy process.

Step 5: Version Control Without a DMS – What the BSI Actually Examines

Most small entities do not have a document management system. A SharePoint folder or file server directory is sufficient – under four conditions that together ensure immutability and traceability.

• Write-protect for all except ISB and IT administrator: If any employee can edit policies, you cannot prove that the approved version is unchanged. The "Policies/Current" folder is readable by all but writable only by the ISB and a defined administrator.
• Filenames with version number and date: "IS-Policy_v1.0_2026-03-03_approved.pdf" – not "IS-Policy-final.pdf" or "IS-Policy-new.pdf". The filename is an auditor's first reference point and must unambiguously express the approval status.
• Change history within the document itself: A three-column section at the end of each policy: Date | Version | Change. This table belongs in the document – not in a separate file that may not be shared when someone requests "the current policy".
• Archive folder for older versions: Old versions are not deleted but moved to an "Archive" subfolder. A BSI auditor can ask how a policy has evolved over time – the answer must be retrievable from the archive.

The MAJOR.MINOR rule determines which version is triggered. Minor versions (1.0 → 1.1) are corrections without rule changes – no management approval needed. Major versions (1.x → 2.0) mean changed rules, changed scope, or changed responsibilities – management approval always required. This threshold definition must be written down so it is not decided ad hoc each time.

The recommended folder structure – building on the archiving system from Step 5-4 (Management Security Reporting): NIS2-Governance/Policies/Current/ for all eight approved documents; NIS2-Governance/Policies/Archive/ for older versions with the date in the filename; NIS2-Governance/Policy-Register.pdf for the current register.

What the BSI actually examines in an audit: an auditor opens the folder, finds eight PDF files with readable names and version dates, opens one and finds the change history at the end of the document. That is sufficient. No sophisticated DMS, no blockchain signature – active management that can be demonstrated from the documents themselves.

What You Have After This Step

After these five steps you have five concrete artefacts:

1. IS-Policy (2–4 pages, management-approved) with explicit scope, risk acceptance criteria, named ISB and resource commitment in the management statement
2. Seven sub-policies (1–4 pages each), each with a concrete rule, a named owner, and a consequence for non-compliance
3. Policy register (1 page) with owner, version, approval date, and next review date per policy
4. Management approval record – signatures on cover pages or an email record with document reference, version number, and date
5. MAJOR.MINOR versioning rule and folder structure that guides a BSI auditor through the documents without explanation

This policy stack is your primary evidence under Section 30(2)(1) BSIG. For regular management reporting on the status of this stack – demonstrating quarterly that the policies are actively followed – see Step 5-4 (Management Security Reporting for NIS2).

This article does not constitute legal advice. The guidance reflects a practice-oriented interpretation of NIS2 requirements from an IT security consulting perspective and does not establish a legal advisory relationship. Consult a qualified attorney for legal questions specific to your situation.