This guide shows what ISO/IEC 27001, the IT-Grundschutz methodology of the German BSI and the NIS2 rules expect from the policy, how it differs from topic-specific policies and how to write it in five steps. It ends with an outline you can use straight away. The examples are invented.
What the policy has to do
The policy is the top document of your ISMS. It answers "why, and to what standard?", not "how exactly?". Three sources describe what goes into it.
- ISO/IEC 27001:2022, clause 5.2. Top management establishes a policy that is appropriate to the purpose of the organization, includes objectives or a framework for setting them, and makes two commitments: to satisfy applicable requirements and to continually improve the ISMS. The policy is available as documented information, communicated within the organization and available to interested parties as appropriate.
- BSI Standard 200-2, chapter 3.4. The IT-Grundschutz methodology names the importance of information security, objectives, scope and the security organization as the core. Management approves the policy, makes it known and keeps it current. For a certification based on IT-Grundschutz it is the first reference document (A.0.1). BSI Standard 200-1 describes the management framework it sits in.
- NIS2. § 30(2) no. 1 BSIG (German BSI Act) names policies on risk analysis and information system security. Under § 38(1) BSIG, management implements the risk management measures and oversees them. For certain digital providers, such as cloud, data center and managed service providers, Commission Implementing Regulation (EU) 2024/2690 gets specific: point 1.1 of its Annex lists eleven items for the policy, among them resources, roles, a list of the topic-specific policies, indicators and the date of formal approval by the management bodies. The list is a good yardstick for other entities as well.
If you work with several frameworks, write one policy that meets all three. Nobody needs separate policies for ISO 27001 and NIS2.
Policy or topic-specific policy: the difference
Many policies are too long because they contain rules on passwords, backup or remote access. Auditors expect a pyramid:
| Level | Document | Question | Example |
|---|---|---|---|
| 1 | Information security policy | Why, and to what standard? | Objectives, scope, management responsibility |
| 2 | Topic-specific policy | What applies? | Access policy, backup policy, supplier policy |
| 3 | Procedure | Who does what, and when? | Workflow for access requests |
| 4 | Work instruction | How exactly, technically? | Setting up remote access to the plant |
ISO/IEC 27001 asks for topic-specific policies in Annex A 5.1. Management approves, communicates and reviews them too, but they change more often. The top policy refers to them and stays stable as a result. Which topic-specific policies you need follows from your Statement of Applicability.
The policy in five steps
- Draft in a small group. The future CISO, IT, OT or production, HR and, where they exist, data protection and the works council. One person writes, the others review.
- Keep it to two to four pages. Anything that names a technology moves into a topic-specific policy. The text must be as clear to the production shift as to sales.
- Approval by management. Top management approves the policy with a date, by signature or as a documented approval in the document system. Again after every change of substance.
- Communicate and record acknowledgment. All employees, new ones on their first day, and service providers with access receive the policy. People without a desk get it in their safety briefing or as a notice. Record who has acknowledged it.
- Set the review. ISO/IEC 27001 asks for planned intervals and a review after significant changes (Annex A 5.1). Implementing Regulation (EU) 2024/2690 says at least annually and after significant incidents. In practice, a fixed slot in the management review works well, with a documented result even when nothing changes.
Sample outline
The outline combines the three sources. The column "Basis" shows where each section comes from; references to ISO/IEC 27001 paraphrase the standard.
| Section | Content in one sentence | Basis |
|---|---|---|
| 1. Importance | Why information security matters to your business, concrete and plain | ISO 5.2 a, BSI 200-2 ch. 3.4, IR 1.1.1 (a), (b) |
| 2. Scope | Which sites, areas, people and service providers the policy covers | BSI 200-2 ch. 3.4, ISO 4.3 |
| 3. Objectives | Overarching objectives from which yearly measurable objectives follow | ISO 5.2 b, IR 1.1.1 (c) |
| 4. Principles | A few principles, such as need-to-know and reporting without blame | Practice |
| 5. Management commitments | Meet requirements, improve continually, provide resources | ISO 5.2 c, d, IR 1.1.1 (d), (e) |
| 6. Roles and responsibilities | Top management, CISO, line managers, all employees | ISO 5.3, IR 1.1.1 (g) |
| 7. Topic-specific policies | List of the policies in force, with references | ISO A 5.1, IR 1.1.1 (i) |
| 8. Monitoring | How management tracks implementation, for example through indicators | IR 1.1.1 (j) |
| 9. Violations and reporting | Where to report incidents, consequences of violations | Practice, agree with HR |
| 10. Control and approval | Version, classification, owner, review, approval date | ISO 7.5, IR 1.1.1 (k) |
IR stands for Implementing Regulation (EU) 2024/2690. Its point 1.1.1 (h), retention of documentation, is often handled in the document control policy, with a reference in section 10.
Example from production
The example is invented. An injection molding company with two plants has a nine-page policy. It contains password rules, firewall principles and a list of approved USB sticks. Production is not mentioned, and it was signed in 2021 by a managing director who has since left.
- Shortened: The new version has three pages. Passwords, firewall and USB now sit in three topic-specific policies that section 7 refers to.
- Extended: The scope names both plants explicitly, including the control systems. One objective reads "available production and secure remote maintenance".
- Approved: Both managing directors approve the policy. The works council took part in the draft.
- Communicated: Shift leads go through it in the safety briefing, and attendance is recorded.
- Afterwards: The review is a standing item on the agenda of the management review.
Checklist
- The policy has about four pages at most and no technical details.
- Importance, scope and objectives or a framework for objectives are described.
- Management commits to requirements, improvement and resources.
- Roles of top management, CISO and employees are set out.
- The topic-specific policies are listed.
- Top management has approved it with a date.
- All employees and relevant service providers have received it, and acknowledgment is recorded.
- New employees receive it on their first day.
- A review date is set, and the result is documented.
The policy in Complass
A Word file on a shared drive and an all-staff email asking people to read it drift apart fast: which version applies, who has read it, when is the review due? In Complass it is one workflow:
- Free template. On complass.eu you download the information security policy as a Word file and PDF, with no form, under the CC BY 4.0 license. Each section comes with fill-in guidance and a suggested wording.
- Guided in the portal. In the ISO 27001 project you fill in the template's outline with guidance and sample text; indicators (section 8) go under the objectives there.
- Approval with evidence. A person with the "Approve documents" permission approves it. Complass stores an unalterable version with a checksum, with dual control if you want it.
- Policies linked automatically. The portal fills the list of topic-specific policies from the document pyramid and freezes it on approval.
- Acknowledgment without email. Employees confirm with "Read and understood". The portal reminds people of open acknowledgements by email after one week, three times at most.
- Review in view. After every approval the portal calculates the next review date and reminds the owner 30 days before.
Frequently asked questions
How long should an information security policy be?
None of the sources above gives a page count. Two to four pages have proven themselves. If it gets longer, it usually contains rules that belong in a topic-specific policy.
Does top management have to sign it?
ISO/IEC 27001 requires top management to establish the policy. A signature is not mandatory, but auditors expect an approval you can prove. Implementing Regulation (EU) 2024/2690 requires the date of formal approval by the management bodies in the document.
Do we need a separate policy for NIS2?
No. One policy can cover ISO 27001, IT-Grundschutz and NIS2 at the same time if it contains the items of all sources. Name the areas that fall under NIS2 in the scope.
May we publish the policy?
Yes, and customers often ask for it. Check first that it contains no internal details. A good policy does not anyway.
How often does the policy have to be reviewed?
ISO/IEC 27001 asks for planned intervals and a review after significant changes. Entities under Implementing Regulation (EU) 2024/2690 review at least annually. A yearly review is a sensible standard for everyone.
In a demo we show you with the demo company how the template becomes an approved policy with acknowledgements and a review date.
Request a demo Try it for 14 days
Read more
- Guide "ISO 27001 mandatory documents at a glance"
- Guide "Defining the ISMS scope: steps and example"
- Guide "Creating the ISO 27001 Statement of Applicability (SoA), with a template"
- Guide "Management and NIS2: what § 38 BSIG requires"
- Whitepaper ISO 27001
- ISO 27001 in Complass
Not legal advice. This guide gives a general overview and does not replace an assessment of the individual case. The current wording of the BSIG and of Implementing Regulation (EU) 2024/2690 and your licensed editions of the standards are authoritative. As of November 2026.