Information Security Policy: What It Is, What to Include, and How to Write One

An information security policy is the foundational document of any security programme. It defines what your organization protects, how it protects it, and who is responsible. Every compliance framework — ISO 27001, SOC 2, NIS2, DORA — requires one, and every auditor asks for it first.

This guide covers what to include, how to structure it, and how to keep it useful beyond the certification shelf.

---

What Is an Information Security Policy?

An information security policy is a formal, management-approved document that establishes your organization's approach to protecting information assets. It serves as the top-level document in your security governance structure — setting principles, objectives, and boundaries that all other security controls and procedures support.

It answers three questions:

1. What do we protect? — The scope of information assets, systems, and processes covered
2. How do we protect it? — The principles, standards, and approaches the organization follows
3. Who is responsible? — The governance structure, roles, and accountability

A good information security policy is short enough to read, specific enough to be useful, and authoritative enough to drive behaviour.

---

Why It Matters

Regulatory Requirements

• ISO 27001 Clause 5.2 requires an information security policy approved by top management
• NIS2 Article 21(2)(a) mandates policies on risk analysis and information system security
• DORA Article 5 requires ICT risk management policies approved by the management body
• SOC 2 CC1.1 expects a defined organizational structure with policies and procedures

Practical Value

Beyond compliance, the policy serves practical purposes:

• Alignment — Everyone works from the same security expectations
• Decision framework — Provides principles for resolving security trade-offs
• Accountability — Clear ownership prevents responsibility gaps
• Evidence — Documented policies demonstrate governance to customers, auditors, and regulators
• Culture — Signals that security is a leadership priority, not just an IT concern

---

What to Include

1. Purpose and Scope

Define why the policy exists and what it covers:

• Which information assets are in scope (all organizational information, or specific systems)
• Which people are covered (employees, contractors, third parties with access)
• Which locations and systems are included
• Any exclusions and their justification

2. Security Objectives

State what the organization aims to achieve. ISO 27001 requires objectives to be measurable, consistent with the policy, and monitored. Common objectives:

• Protect confidentiality, integrity, and availability of information
• Comply with applicable legal, regulatory, and contractual requirements
• Maintain customer and stakeholder trust
• Enable the business to operate securely

Avoid vague objectives. "Maintain an incident response time under 4 hours for critical incidents" is better than "respond quickly to incidents."

3. Roles and Responsibilities

Assign clear accountability:

Role	Responsibility
Executive management	Approve policy, allocate resources, set risk appetite
CISO / Security Manager	Develop and maintain policy, manage ISMS, report to management
IT Operations	Implement technical controls, manage infrastructure security
Department heads	Enforce policy within their teams, report security concerns
All employees	Follow policy, complete security training, report incidents
Third parties	Comply with contractual security requirements

4. Risk Management Approach

Reference your risk management framework and methodology:

• How risks are identified and assessed
• Risk acceptance criteria and risk appetite
• Risk treatment process (reference the risk treatment plan)
• Review and monitoring frequency

5. Key Security Principles

Establish the core principles that guide security decisions:

• Information classification — How information is categorized and handled based on sensitivity
• Access control — Least privilege, need-to-know, segregation of duties
• Incident management — Detection, response, notification, and learning
• Business continuity — Resilience requirements and recovery objectives
• Change management — Controlled changes to information systems
• Supplier security — Requirements for third parties with access to information

6. Compliance Requirements

List applicable regulations and standards:

• Regulatory requirements (NIS2, DORA, GDPR)
• Industry standards (ISO 27001, SOC 2)
• Contractual obligations (customer security requirements)
• Internal standards and procedures

7. Policy Governance

Define how the policy is maintained:

• Review frequency (minimum annual)
• Approval authority (executive management)
• Communication and training requirements
• Version control and change history
• Exception process for deviations

8. Enforcement and Consequences

State the consequences of non-compliance:

• Disciplinary actions for employees
• Contract termination for third parties
• Incident escalation procedures
• Reporting channels for policy violations

---

Structure and Length

Keep It Short

The information security policy is a governance document, not a procedures manual. It should be 5-15 pages — long enough to be comprehensive, short enough to be read.

Detailed procedures belong in supporting documents:

Document	Purpose
Information security policy	High-level principles and governance (this document)
Acceptable use policy	Rules for using organizational IT resources
Access control policy	Detailed access management procedures
Incident response plan	Step-by-step incident handling procedures
Data classification policy	Classification levels and handling requirements
Business continuity plan	Continuity and recovery procedures
Vendor security policy	Third-party assessment and monitoring requirements

Write for the Audience

The primary audience is management, auditors, and employees — not security engineers. Use clear language, avoid unnecessary jargon, and explain acronyms on first use.

---

Meeting Framework Requirements

ISO 27001

ISO 27001 Clause 5.2 requires the policy to:

• Be appropriate to the purpose of the organization
• Include information security objectives or a framework for setting them
• Include a commitment to satisfy applicable requirements
• Include a commitment to continual improvement
• Be available as documented information
• Be communicated within the organization
• Be available to interested parties as appropriate

NIS2

NIS2 Article 21(2)(a) lists "policies on risk analysis and information system security" as the first required measure. Your policy framework must address all ten Article 21 domains:

1. Risk analysis and information system security policies
2. Incident handling
3. Business continuity and crisis management
4. Supply chain security
5. Security in network and information systems acquisition, development, and maintenance
6. Policies and procedures for assessing effectiveness
7. Basic cyber hygiene practices and cybersecurity training
8. Policies and procedures regarding the use of cryptography
9. Human resources security, access control policies, and asset management
10. Use of multi-factor authentication and secured communication

SOC 2

SOC 2's Common Criteria require documented policies across all Trust Services Criteria areas. The information security policy serves as the umbrella, with supporting policies for each criteria domain.

---

Common Mistakes

1. Writing a policy nobody reads. A 50-page document full of legal language gets filed and forgotten. Keep it concise and actionable.

2. Copying templates without customization. Generic templates miss your specific regulatory requirements, risk landscape, and organizational context. Templates are starting points, not finished products.

3. Treating the policy as static. An information security policy that hasn't been reviewed in two years is a compliance risk. Regular review keeps it aligned with current threats, regulations, and business changes.

4. No management endorsement. A policy without executive approval lacks authority. ISO 27001 and NIS2 both require explicit management commitment — signatures matter.

5. Disconnecting policy from practice. If the policy says one thing and the organization does another, you have an audit finding. Ensure policies reflect actual practices, or change practices to match policies.

---

From Policy to Evidence

Having a policy is the first step. Demonstrating that it's implemented, followed, and effective is what auditors and regulators actually evaluate:

• Communication evidence — Records showing the policy was distributed and acknowledged
• Training records — Evidence that employees understand their responsibilities
• Review history — Documented reviews with management approval
• Compliance monitoring — Evidence that policy requirements are being met
• Incident records — Showing the policy is applied during security events

A Trust Center makes this evidence accessible to external stakeholders — publishing your policy framework, compliance status, and certification evidence so buyers and auditors can verify your security governance.

---

How Orbiq Supports Information Security Policies

• Trust Center: Publish your security governance framework, certifications, and policy summaries for buyer due diligence
• Evidence Management: Automated collection of compliance evidence showing policy implementation
• Continuous Monitoring: Track control effectiveness to ensure policies are followed in practice
• AI-Powered Questionnaires: Respond to buyer security questions about your policies automatically

---

Further Reading

• Risk Management Frameworks — Choosing the right framework for your ISMS
• Compliance Automation — Automating the evidence collection that proves policy implementation
• NIS2 Compliance: The Complete Guide — NIS2 policy requirements in detail

---

This guide is maintained by the Orbiq team. Last updated: March 2026.