Writing an Information Security Policy: Structure, Content, and Example

Why the Information Security Policy Is Your Most Important ISMS Document

Every information security management system needs a document that sets the strategic direction. The information security policy takes on exactly this role. It is the foundation on which all further policies, processes, and measures are built. Anyone who wants to build an ISMS should therefore start with this document.

ISO 27001 explicitly requires this document in clause 5.2. Without a documented and communicated information security policy, no ISMS can be certified. But even if you are not pursuing certification, the document is worthwhile. It answers the central question: how does our organization handle information security, and why do we do it?

The policy is not aimed at the IT department alone. It addresses the entire organization — from top management through specialist departments to external service providers who have access to your systems or data. This is precisely why it should be written in an understandable manner and not sound like a technical manual.

What ISO 27001 Specifically Requires

Clause 5.2 of ISO 27001:2022 defines several requirements for the information security policy. You must cover these mandatory elements:

• Appropriateness to the organization's purpose: The policy must fit your organization. A software company has different priorities than a manufacturing business.
• Information security objectives: Either the policy contains specific objectives or it provides the framework from which objectives can be derived.
• Commitment to fulfilling applicable requirements: This includes legal, regulatory, and contractual obligations, such as DSGVO (GDPR), NIS2, or industry-specific requirements.
• Commitment to continual improvement: The ISMS is not a one-time project. The policy must anchor the continuous improvement approach.
• Availability as documented information: The policy must be documented, accessible, and maintained.
• Communication within the organization: All relevant persons must be aware of it.
• Availability for interested parties: Depending on the context, this may include customers, partners, or regulatory authorities.

Additionally, the standard requires the policy to be approved by top management. This is not a formality but demonstrates that information security is a leadership priority.

Structure and Format: How to Organize the Policy

A good information security policy follows a clear structure. You can use the following outline as a template and adapt it to your organization:

1. Document Information

The metadata of the document comes first. It enables proper version control and makes transparent who is responsible for the document.

• Document title
• Version number and date
• Document owner (typically the ISM)
• Approved by (top management)
• Confidentiality level (usually "Internal")
• Next scheduled review

2. Purpose and Objectives

Here you describe why the policy exists and what goal it pursues. Keep this section short and concise.

Sample wording:

This information security policy defines the fundamental principles, objectives, and responsibilities for information security at [Organization Name]. It provides the framework for protecting all information assets and serves as the basis for all further security policies and measures.

3. Scope

The scope defines who and what the policy applies to. Be precise here, as the policy scope directly corresponds to the scope of your ISMS.

Clearly define:

• Which locations, departments, and business processes are covered
• Which groups of people are affected (employees, managers, external parties)
• Which IT systems, networks, and data are included
• Whether there are explicit exclusions and why

Sample wording:

This policy applies to all employees of [Organization Name], including managers, temporary staff, interns, and external service providers with access to the organization's information systems or data. It covers all locations as well as all physical and digital information assets.

4. Top Management Commitment

This section is crucial. ISO 27001 requires that top management demonstrate their leadership role and commitment to information security. A specific, signed statement carries more weight than general platitudes.

Sample wording:

The management of [Organization Name] is committed to information security as an integral part of corporate governance. We commit to providing the necessary resources, continually improving the ISMS, and fulfilling all applicable legal, regulatory, and contractual requirements. Information security is a leadership responsibility carried by all levels of the organization.

5. Information Security Objectives

Formulate three to five overarching objectives that your organization pursues with the ISMS. These objectives bridge the policy and the concrete measures.

Typical objectives include:

• Confidentiality: Information is accessible only to authorized persons.
• Integrity: Information is complete and unaltered.
• Availability: Information and systems are available when needed.
• Compliance: All legal and contractual requirements are met.
• Awareness: All employees are sensitized to information security.

Avoid objectives that you cannot measure. "We want to be secure" is not an objective. "We reduce the number of security-relevant incidents through training measures by 30% within 12 months" is. However, the overarching objectives in the policy may be somewhat more abstract than the detailed ISMS objectives that you document separately.

6. Information Security Principles

In this section, you establish the principles by which your organization implements information security. These can be five to ten principles that serve as guardrails for all further decisions.

Examples of such principles:

• Need-to-know principle: Access to information is granted only when necessary for task fulfillment.
• Accountability: Every information asset has a defined owner.
• Proportionality: Protective measures are proportionate to the protection requirement.
• Defense in depth: Security is achieved through multiple, layered measures.
• Reporting obligation: Security incidents are reported and addressed without delay.

7. Roles and Responsibilities

Describe the central ISMS roles and their responsibilities. This section clarifies who is responsible for what.

Ensure you do not describe responsibilities that nobody actually assumes. If there is no dedicated ISM in your organization but the IT manager fills the role in a dual capacity, then write that honestly.

8. Applicable Requirements and Regulatory Framework

List the most important legal, regulatory, and contractual requirements relevant to your ISMS. This shows the auditor that you have engaged with the context of your organization.

Typical requirements:

• DSGVO (GDPR)
• NIS2 directive (if applicable)
• Industry-specific requirements (e.g., KRITIS, BAIT, VAIT)
• Contractual obligations to customers and partners
• ISO 27001 as the chosen standard

9. Reference to Subordinate Policies

The information security policy is deliberately high-level. Operational details belong in specific policies that you reference here. This creates a clean document hierarchy and prevents the IS policy from becoming a monolith that nobody wants to maintain.

List the subordinate policies by name and reference their current version. This way, every reader immediately sees which documents belong together.

Sample wording:

The following policies specify the principles set out in this information security policy for specific topic areas:

• Password Policy (POL-IS-002)
• Mobile Device Usage Policy (POL-IS-003)
• Access Control Policy (POL-IS-004)
• Backup and Recovery Policy (POL-IS-005)
• Security Incident Management Policy (POL-IS-006)

A uniform numbering scheme for all policies significantly simplifies management. Assign a sequential document ID and maintain a central policy register containing the title, ID, version, approval date, and responsible person for each document.

10. Training and Awareness

This section anchors the obligation for regular training of all employees. Describe which training formats are planned (in-person, e-learning, brief instructions), the frequency, and how attendance is documented.

Sample wording:

All employees are required to participate in annual information security training. New employees receive an introduction to information security as part of onboarding within the first two weeks. Attendance is documented and evaluated by the ISM.

11. Violations and Consequences

Describe what happens when the policy is violated. This does not need to be a doomsday scenario, but clear consequences are necessary.

Sample wording:

Violations of this policy or the subordinate security policies may result in disciplinary action up to and including termination. For external service providers, violations may lead to termination of the engagement. All violations are documented and handled through the incident management process.

12. Effective Date, Review, and Versioning

Record when the policy takes effect, how often it is reviewed, and how changes are documented.

Dos and Don'ts: Avoiding Common Mistakes

When writing the information security policy, there are some typical pitfalls. Here are the most important dos and don'ts:

Dos

Write clearly. The policy will be read by the entire organization, not just security experts. Avoid jargon wherever possible. If you must use technical terms, explain them.

Keep the policy lean. Five to ten pages is a good benchmark. Anything beyond that belongs in subordinate policies. A lean IS policy is more likely to be read, understood, and accepted than a 40-page document.

Make it specific to your organization. The policy must fit you. Do not copy a generic template from the internet and just change the company name. The auditor will notice, and your employees will not see themselves in the document.

Anchor measurable objectives. Even though the overarching objectives may be somewhat more abstract: they should be formulated so that you can derive specific, measurable ISMS objectives from them.

Plan the review from the start. A clearly defined policy lifecycle ensures that you establish from the outset when the policy will next be reviewed. Put the date in the calendar.

Don'ts

Too abstract. "We protect our information" is not a policy but a wish. Specify what you mean by protection and which principles apply.

Too detailed. The IS policy is not an operations manual. Technical configurations, specific password rules, or firewall settings belong in operational policies or work instructions.

Making unrealistic promises. Do not write anything in the policy that you cannot deliver. "All systems are available around the clock" sounds good but is simply not true in most organizations. Be honest.

Leaving out top management. The policy must be supported from the top. If top management does not know the document, has not signed it, or does not identify with it, that is a serious problem.

Writing once and then forgetting. A policy that has not been reviewed in three years is an audit finding. Organizations change, laws change, threats change. The policy must keep pace.

The Approval Process: Who Approves, Who Signs

The approval of the information security policy is a formal act. ISO 27001 requires that top management approve the policy. In practice, the process typically looks like this:

Step 1: Draft the document. The ISM or responsible person creates the draft, taking into account the organization's context, the standard's requirements, and existing documentation.

Step 2: Stakeholder alignment. The draft is shared with relevant stakeholders. These may include IT management, the data protection officer, HR, and selected managers. Obtain their feedback before presenting the document for approval.

Step 3: Final approval. Top management reviews and approves the policy. This should be documented, ideally through a signature on the document itself or in a separate approval record.

Step 4: Publication and communication. After approval, the policy is published and made accessible to all relevant persons. This can happen via the intranet, a document management system, or an ISMS platform.

Important: approval is not the same as acknowledgment. Top management approves; everyone else acknowledges. These are two different processes.

A practical tip on the approval process: allow sufficient time for the alignment round. Experience shows that it takes two to four weeks for all stakeholders to provide their feedback. Set clear deadlines and send reminders. If you don't, the approval can drag on for months, and the underlying conditions may have already changed in the meantime.

Ensuring Acknowledgment: How to Reach All Employees

The best policy is useless if nobody knows about it. ISO 27001 requires that the policy be communicated within the organization. You therefore need a verifiable process to demonstrate that all relevant persons have acknowledged the policy.

There are several proven approaches:

Digital acknowledgment via an ISMS tool. The most elegant solution: you publish the policy in your ISMS platform, and each employee confirms acknowledgment with a click. Tools like ISMS Lite offer exactly this workflow with automatic logging of timestamp and person, so you always have the evidence.

Signature list. The classic approach: each employee signs that they have read and understood the policy. It works but is cumbersome to manage in larger organizations.

E-learning with quiz. You package the key content of the policy into a short e-learning module with comprehension questions. The advantage: you verify not only that the policy was read but also that it was understood.

Training with attendance list. You present the policy in an in-person training session or webinar and document attendance.

Which approach suits you? For organizations under 50 employees, a combination of training and signature list often suffices. From 50 employees onward, using an ISMS tool with digital acknowledgment pays off because manual management becomes too labor-intensive. E-learning is particularly suited for organizations with distributed locations or high turnover.

Regardless of which path you choose: document acknowledgment completely. You will be asked about it in an audit. And remember that new employees must also acknowledge the policy during the onboarding process. Define within what timeframe after joining the acknowledgment must occur — typically within the first two weeks.

Versioning and Review Cycles

An information security policy is a living document. You must ensure that the current version always applies and that changes are traceable.

Versioning Scheme

Use a simple, understandable scheme:

• Major versions (1.0, 2.0, 3.0): Fundamental content changes, e.g., new scope, new regulatory requirements, or a complete overhaul.
• Minor versions (1.1, 1.2, 1.3): Smaller adjustments, corrections, additions to individual sections.

Each version is documented with date, author, and a brief description of the changes in a change history at the beginning of the document.

Review Cycle

Managing all policy versions and review cycles is significantly easier in an ISMS tool like ISMS Lite than via file systems and Excel. Plan a fixed review cycle:

• At least annually, a complete review of the policy.
• Event-driven for significant changes: new laws (such as the NIS2 implementation act), organizational restructuring, major security incidents, findings from internal or external audits.

The review should be structured. Check each section: Is the scope still correct? Have responsibilities changed? Have new regulatory requirements been added? Do the security objectives still match the current risk landscape?

After the review, the updated policy goes through the same approval process as the initial version. And you must also obtain acknowledgment again for material changes.

Handling Obsolete Versions

Ensure that outdated versions of the policy are no longer in circulation. In digital systems, this is straightforward: you replace the old version with the new one. With physical copies, it becomes more difficult. It is best to forgo printed copies entirely and instead point to the central digital storage location. If you need printed versions, label them as "controlled copy" and maintain a register of who has received which copy.

Other Important Policies for Your ISMS

The information security policy sits at the top of the document hierarchy. Below it, you need operational policies that govern specific topics. Which ones these are depends on your organization. The following are required in most cases:

Password Policy

The password policy governs password length, complexity, change intervals, and the use of password managers. Per current BSI recommendations: long passwords instead of frequent changes. Also define that passwords may never be shared via email or chat.

Mobile Device Usage Policy

Defines which devices may be used for business purposes, whether BYOD is permitted, which security measures apply to mobile devices (encryption, screen lock, remote wipe), and how to handle a lost device.

Access Control Policy

Describes the principles of rights assignment, especially the need-to-know principle and the least privilege principle. Governs how access rights are requested, approved, provisioned, and revoked. Also includes requirements for privileged accounts and regular access reviews.

Backup and Recovery Policy

Defines backup strategies (full, incremental, differential), retention periods, storage locations, and regular verification of recoverability. A backup that has never been tested is not a backup.

Security Incident Management Policy

Describes the process from detection through reporting to handling and post-incident review of security incidents. Defines escalation paths, reporting deadlines, and responsibilities in the incident response process.

Clean Desk and Clear Screen Policy

Simple to implement, often underestimated: governs that confidential documents are not left in the open and screens are locked when leaving the workstation. An important building block, especially in open-plan offices or with visitor traffic.

Supplier and Service Provider Policy

Defines the security requirements for external partners. This includes contractual arrangements, verification of security measures, and the procedure for security incidents on the service provider's side.

Classification Policy

The classification policy defines your organization's confidentiality levels (e.g., Public, Internal, Confidential, Strictly Confidential) and sets out how information at each level must be handled. Without clear classification, nobody knows which emails need to be encrypted and which documents must not end up on a private USB drive.

You do not need to create all policies at once. Start with the most important ones and build up the policy catalog step by step. Prioritize based on your risk analysis: which topics have the highest protection needs? Where are the biggest gaps? Typically, the password policy, access control policy, and the security incident management policy are the three documents you should tackle right after the IS policy.

From Template to Finished Policy: Practical Tips

Finally, some practical pointers to help with creation:

Don't start from scratch. Use the outline from this article as a starting point and adapt it. A good template saves you hours of work. But never copy blindly — make every word your own.

Talk to top management before you write. Get the management's commitment upfront. Clarify which strategic objectives the policy should support and what resources are available. If top management only learns what you wrote when it's time to sign, you risk having to start over.

Use a consistent document template. All ISMS documents should follow a uniform layout. Define a header with logo, a footer with version number and page number, consistent fonts, and a cover page with document metadata.

Write iteratively. The first version does not need to be perfect. Write a draft, collect feedback, revise, and then approve. Perfectionism is the enemy of progress, especially during ISMS build-up.

Link the policy to your other ISMS documents. The IS policy does not stand alone. It references the risk analysis, the ISMS objectives, the Statement of Applicability, and the subordinate policies. Ensure these cross-references are accurate and current.

Test readability. Give the policy to someone who does not work in the security field to read. If they understand the content and know what they need to do, you have done a good job.

Further Reading

• Building an ISMS: The Complete Guide for Companies with 50 to 500 Employees
• Key ISMS Roles: ISM, CISO, Risk Owner – Who Does What?
• Creating a Password Policy: Requirements, Example, and Enforcement
• Policy Lifecycle: From Creation to Retirement
• Access Control Policy: Physical and Logical

The information security policy is the cornerstone of your ISMS. It sets the direction, creates accountability, and demonstrates both internally and externally that information security is taken seriously in your organization. Invest the time in a solid document. It will pay off in every audit, every training session, and every security incident.