ISO 27001 Annex A 5.1 is one of the foundational organizational controls in an Information Security Management System (ISMS). It establishes how an organization sets management direction for information security through documented policies.

But A.5.1 is not simply a requirement to “create an Information Security Policy.”

An organization needs to demonstrate that its policies are:

Defined
Appropriate to the organization
Approved by management
Published
Communicated to relevant people
Acknowledged where applicable
Reviewed periodically
Updated when significant changes occur

The control also covers topic-specific information security policies, which provide more detailed direction for particular security areas.

The official ISO/IEC 27001:2022 control requires information security and topic-specific policies to be defined, approved by management, published, communicated and acknowledged by relevant personnel and interested parties, and reviewed at planned intervals and when significant changes occur.

What Is ISO 27001 Annex A 5.1?

Control: Policies for Information Security

The purpose of A.5.1 is to provide management direction and support for information security in accordance with the organization’s business requirements and applicable legal, regulatory and contractual requirements.

In simple terms:

Management must establish clear rules and direction for how the organization protects information, communicate those rules to the people who need to follow them, and periodically verify that the policies remain suitable.

A policy should not simply exist as a document in a folder.

The organization should be able to demonstrate the complete policy lifecycle:

Identify → Develop → Approve → Publish → Communicate → Acknowledge → Review → Update

What Does Annex A 5.1 Require?

There are several distinct requirements within A.5.1.

Requirement	What the organization needs to do
Define policies	Establish an overall Information Security Policy and appropriate topic-specific policies
Management approval	Obtain approval from authorized management
Publish	Make policies available to relevant personnel and interested parties
Communicate	Ensure applicable people know about the policies and requirements
Acknowledgment	Obtain acknowledgment where applicable
Planned review	Review policies at defined intervals
Change-triggered review	Review policies when significant changes occur
Maintain records	Keep evidence of approvals, versions, reviews and communication

The requirement is therefore broader than writing a policy document.

1. What Policies Do You Need for ISO 27001?

There is no requirement that every organization use exactly the same list of policies.

The policies should reflect the organization’s:

Business activities
Information security risks
Technology environment
Legal and regulatory obligations
Customer requirements
Contractual requirements
Applicable Annex A controls
Organizational structure

A small SaaS company may require a different policy framework from a bank, hospital, manufacturing company or government organization.

Typical ISO 27001 policy framework

An organization may have:

Core policy

Information Security Policy

This is the high-level policy that establishes management’s overall direction and commitment to information security.

Topic-specific policies

Depending on the organization’s risks and environment, these may include:

Access Control Policy
Password and Authentication Policy
Information Classification Policy
Acceptable Use Policy
Asset Management Policy
Cryptography Policy
Data Protection/Privacy Policy
Information Security Incident Management Policy
Backup Policy
Business Continuity Policy
Remote Working Policy
Mobile Device Policy
Supplier Security Policy
Vulnerability Management Policy
Secure Development Policy
Logging and Monitoring Policy
Physical Security Policy
Change Management Policy
Cloud Security Policy
Data Retention and Disposal Policy

Important: Do not create 20 policies simply because a template lists 20 policies.

The organization should determine which policies are relevant based on its business, risks, controls and obligations.

2. What Should the Information Security Policy Contain?

The top-level Information Security Policy should establish the organization’s overall security direction.

Typical content includes:

1. Purpose

Why the policy exists.

Example:

The purpose of this policy is to establish the organization’s commitment and direction for protecting information assets and maintaining the confidentiality, integrity and availability of information.

2. Scope

Identify what the policy applies to.

For example:

Employees
Contractors
Temporary staff
Systems
Applications
Information assets
Cloud environments
Offices
Suppliers where applicable

3. Management commitment

The policy should demonstrate management’s commitment to information security.

4. Security objectives

The organization can reference its information security objectives and ISMS goals.

5. Legal and contractual requirements

The policy should recognize applicable:

Laws
Regulations
Customer requirements
Contractual obligations
Industry requirements

6. Responsibilities

Define who is responsible for implementing and maintaining information security.

7. Risk management

The policy should align with the organization’s information security risk management approach.

8. Compliance

State the organization’s expectation that applicable information security requirements will be followed.

9. Policy review

Define how and when the policy will be reviewed.

3. What Activities Are Required to Implement A.5.1?

A practical implementation can be divided into eight activities.

Activity 1: Understand the Organization

Before writing policies, understand the organization.

Review:

Business model
Products and services
Employees
Customers
IT infrastructure
Cloud services
Applications
Data processed
Suppliers
Regulatory requirements
Customer contractual requirements

Example

A SaaS startup serving US healthcare customers may need policies addressing:

Access control
Data protection
Incident management
Supplier security
Encryption
Secure development
Backup
Privacy

A small consulting company with no customer-hosted production environment may have a much smaller policy framework.

Activity 2: Identify Information Security Risks

Policies should support the organization’s risk management approach.

Consider risks such as:

Unauthorized access
Data leakage
Malware
Phishing
Ransomware
Insider threats
Loss of availability
Supplier compromise
Weak passwords
Insecure software development
Cloud misconfiguration

The results of risk assessment can help determine which topic-specific policies are required.

Activity 3: Identify Applicable Annex A Controls

Review the Statement of Applicability (SoA).

Determine which Annex A controls apply to the organization and what policies, procedures or other documented information support those controls.

For example:

Annex A Control	Possible Supporting Policy
A.5.1	Information Security Policy
A.5.15	Access Control Policy
A.5.23	Cloud Services Security Policy
A.5.24	Incident Management Policy
A.5.30	ICT Readiness for Business Continuity Policy
A.8.8	Vulnerability Management Policy
A.8.25	Secure Development Policy

The SoA should explain how applicable controls are implemented and identify relevant supporting documentation.

Activity 4: Develop the Policies

Create the required policies.

A practical policy template can contain:

Document Information

Policy name
Document ID
Version
Policy owner
Approved by
Effective date
Review date

Policy Content

Purpose
Scope
Policy statements
Roles and responsibilities
Requirements
Exceptions
Compliance
Review requirements

Document Control

Version history
Approval history
Review history

Activity 5: Obtain Management Approval

A policy should not simply be uploaded by the IT team.

It needs appropriate management approval.

For example:

Prepared by: Information Security Manager

Reviewed by: CISO / ISMS Manager

Approved by: CEO / Managing Director / Authorized Management

The exact approval authority depends on the organization’s governance structure.

Evidence

Maintain:

Approval email
Electronic approval
Digital workflow
Signed policy
Management meeting minutes
Document management approval record

Activity 6: Publish and Communicate

After approval, policies need to be made available to the people to whom they apply.

Possible communication channels include:

Employee portal
HR platform
SharePoint
Document management system
Email
Security awareness platform
Employee onboarding system
Security training sessions

Simply storing a PDF in a folder is not sufficient evidence that employees were actually informed.

Activity 7: Obtain Acknowledgment

Where applicable, obtain evidence that relevant personnel and interested parties have acknowledged the policy.

Examples include:

Employee electronic acknowledgment
HR onboarding checklist
Security awareness platform record
Signed acknowledgment
Training completion record
Supplier acknowledgment

Example

An employee receives:

“Please review the Information Security Policy and confirm that you have read and understood the requirements.”

The system records:

Employee: John Smith
Policy: Information Security Policy
Version: 2.0
Acknowledged: 15 September 2026

This can become useful audit evidence.

Activity 8: Review and Update the Policies

A.5.1 requires policies to be reviewed at planned intervals and when significant changes occur.

A company might establish:

Annual policy review

plus event-driven reviews.

For example:

New law or regulation
Major organizational change
New product
New technology
Major cloud migration
Acquisition or merger
Significant security incident
Major audit finding
Change in customer requirements
Change in risk profile
Major change to the ISMS scope

What Events Should Trigger a Policy Review?

This is one of the most important practical aspects of A.5.1.

Do not rely only on an annual calendar reminder.

Create event-based policy review triggers.

Event	Example	Possible Policy Review
New regulation	New privacy requirement	Privacy/Data Protection Policy
New technology	Company moves to AWS	Cloud Security Policy
Security incident	Ransomware incident	Incident Management Policy
New product	Launch of SaaS platform	Information Security / Secure Development Policy
Organizational change	Acquisition	Multiple policies
New customer requirement	SOC 2 requirement	Security policies
Major risk change	Critical new threat	Relevant security policies
Audit finding	Weak access management	Access Control Policy
Business model change	B2B → B2C	Privacy / Security policies
Annual review	Scheduled review	All applicable policies

This creates a living policy management process rather than a once-a-year documentation exercise.

How to Implement ISO 27001 A.5.1 in a Startup

A startup does not necessarily need a huge policy library.

A practical approach is:

Step 1 — Define the ISMS scope

Understand what part of the business is covered by the ISMS.

Step 2 — Identify information assets

Examples:

Customer data
Source code
Production systems
Employee information
Financial information
Cloud infrastructure

Step 3 — Perform risk assessment

Identify major information security risks.

Step 4 — Determine applicable controls

Use the risk assessment, business requirements and other obligations to determine applicable Annex A controls.

Step 5 — Create the policy framework

Start with:

Information Security Policy

Then add topic-specific policies required by the organization’s risks and applicable controls.

Step 6 — Assign policy owners

For example:

Policy	Owner
Information Security Policy	CISO / ISMS Manager
Access Control Policy	IT/Security
Secure Development Policy	Engineering
Supplier Security Policy	Procurement/Security
Incident Management Policy	Security
Business Continuity Policy	Business Continuity Manager

Step 7 — Obtain approval

Management formally approves the policies.

Step 8 — Publish and communicate

Make policies available to relevant employees and interested parties.

Step 9 — Collect acknowledgment

Record applicable acknowledgments.

Step 10 — Monitor review dates

Maintain a central Policy Register.

Example: ISO 27001 A.5.1 for a SaaS Startup

Consider a SaaS company called ABC Cloud Technologies.

The company:

Has 45 employees
Hosts its application in AWS
Processes customer business information
Has remote employees
Uses third-party SaaS providers
Serves customers in the US and Europe

The company decides that A.5.1 applies.

Policy framework

ABC Cloud creates:

Information Security Policy
Access Control Policy
Acceptable Use Policy
Asset Management Policy
Data Classification Policy
Incident Management Policy
Supplier Security Policy
Cloud Security Policy
Secure Development Policy
Business Continuity Policy

Approval

The policies are reviewed by the ISMS Manager and approved by the CEO.

Publication

The policies are published in the company’s employee portal.

Communication

New employees receive the policies during onboarding.

Existing employees receive an annual security awareness communication.

Acknowledgment

Employees acknowledge applicable policies electronically.

Review

The company performs an annual policy review.

Additionally, the company triggers a review when:

A major security incident occurs
A new regulation becomes applicable
The company changes its cloud architecture
A major new customer requirement is introduced

This demonstrates a functioning policy management process rather than merely having policy documents.

What Evidence Will an ISO 27001 Auditor Look For?

An auditor may want to see evidence across the complete lifecycle.

Policy documents

Information Security Policy
Topic-specific policies
Current versions

Approval evidence

Management approval
Approval dates
Approver information

Publication evidence

Document management system
Employee portal
Policy repository

Communication evidence

Emails
Training records
Awareness sessions
Onboarding records

Acknowledgment evidence

Employee acknowledgments
Training completion
Electronic acceptance records

Review evidence

Policy review records
Version history
Management review records
Updated policies

Change evidence

If a significant change occurred:

Change → Review → Policy Update → Approval → Communication → Acknowledgment

This chain is particularly useful for demonstrating that the control operates in practice.

ISO 27001 A.5.1 Audit Checklist

Use the following checklist as a practical readiness test.

Question	Yes/No
Is an Information Security Policy defined?	☐
Are relevant topic-specific policies defined?	☐
Are policies aligned with business requirements?	☐
Have applicable legal requirements been considered?	☐
Have contractual requirements been considered?	☐
Are policies approved by authorized management?	☐
Is approval evidence retained?	☐
Are current policies published?	☐
Are relevant employees aware of the policies?	☐
Are relevant interested parties informed where applicable?	☐
Is acknowledgment obtained where applicable?	☐
Are policy owners defined?	☐
Are review dates defined?	☐
Are policies reviewed at planned intervals?	☐
Are event-driven reviews performed?	☐
Is version history maintained?	☐
Are changes approved before release?	☐
Is evidence retained?	☐

Common A.5.1 Mistakes

1. Downloading generic policy templates

A template is not automatically evidence of implementation.

The policy should reflect the organization’s actual:

Business
Technology
Risks
Responsibilities
Regulatory environment

2. Creating policies but never communicating them

A policy sitting in Google Drive or SharePoint does not demonstrate that relevant employees have been informed.

3. No management approval

The policy should have evidence of appropriate management approval.

4. No acknowledgment

Where acknowledgment is applicable, the organization should maintain evidence that relevant people acknowledged the policy.

5. Reviewing only before the certification audit

Policies should be maintained throughout the ISMS lifecycle.

6. No event-driven review

Organizations sometimes have an annual review date but fail to review policies after major changes.

A significant change should trigger consideration of whether policies remain suitable.

7. Too many policies

More policies do not automatically mean better security.

A startup may be better served by a manageable policy framework that employees can understand and actually follow.

Policy vs Procedure: What Is the Difference?

This distinction is important.

Policy

A policy defines what the organization requires or expects.

Example:

Access to company systems shall be granted based on business need and authorized job responsibilities.

Procedure

A procedure explains how the requirement is implemented.

Example:

The IT administrator shall create user accounts only after receiving an approved access request from the employee’s manager.

Evidence

Evidence demonstrates that the process actually happened.

Example:

Access request
Manager approval
User account creation record
Access review report

Therefore:

Policy = What

Procedure = How

Evidence = Show me that you did it

A.5.1 Implementation Model

A simple implementation model is:

1. Identify Requirements

↓

2. Identify Risks

↓

3. Determine Applicable Policies

↓

4. Draft Policies

↓

5. Assign Policy Owners

↓

6. Management Approval

↓

7. Publish

↓

8. Communicate

↓

9. Obtain Acknowledgment

↓

10. Review

↓

11. Update

↓

12. Repeat

This creates a continuous policy management lifecycle within the ISMS.

What Does “Good Implementation” Look Like?

A mature organization should be able to answer five questions quickly:

1. What is your policy?

Here is the current approved policy.

2. Who approved it?

Here is the management approval record.

3. Who has been informed?

Here are our communication and acknowledgment records.

4. When was it reviewed?

Here is the review history and version record.

5. What happens when something changes?

Our policy review process includes event-driven review triggers.

If an organization can demonstrate this complete chain, A.5.1 becomes an operational process rather than simply a documentation exercise.

Useful Resources & Draft Policy Document

To help you implement ISO 27001 Annex A 5.1 – Policies for Information Security, we have prepared a draft Information Security Policy and additional practical resources.

📄 Draft Information Security Policy

Download / View the Draft Policy Document:
https://drive.google.com/file/d/1Dg5XWruHKKiXjLpyjrOUnpC1WVng5CbG/view?usp=drive_link

You can use this document as a starting point and customize it based on your organization’s:

Business activities
ISMS scope
Information security risks
Technology environment
Legal and regulatory requirements
Customer and contractual requirements

Important: A policy template should not be adopted without review. Customize it to reflect your organization’s actual processes, responsibilities and security requirements.

🔗 Other Useful Resources

You may also find these resources helpful:

ISO 27001 Risk Assessment Guide – Understand how risks influence the selection and implementation of controls with example
ISO 27001 Statement of Applicability (SoA) Guide – Understand how applicable controls are documented and justified.
How to Prepare an ISO 27001 Statement of Applicability – Example
ISO 27001 Internal Audit Checklist – Use a practical checklist to assess ISMS readiness.
ISO 27001 Policy & Procedure Templates – Reference documents for developing your organization’s ISMS documentation.
ISO 27001 Implementation Guide for Startups – A practical approach to building an ISMS without unnecessary documentation.

Tip: Use these resources as implementation aids, but always ensure that your final ISMS documentation reflects your organization’s actual risks, processes and operating environment.

Final Takeaway

ISO 27001 Annex A 5.1 is not simply “create an Information Security Policy.”

The real requirement is to establish a controlled policy lifecycle.

Your organization needs to:

Define → Approve → Publish → Communicate → Obtain Acknowledgment → Review → Update

The policy framework should be proportionate to the organization’s business, risks, technology, legal requirements and applicable controls.

For startups, the objective should not be to create hundreds of pages of documentation. The objective is to establish clear, relevant and usable security direction that management supports and employees actually follow.

ISO/IEC 27001:2022 is the standard specifying requirements for an ISMS, while Annex A provides the reference information security controls to be considered in the context of the organization’s risk treatment and Statement of Applicability.

In short:

A.5.1 = Security policies that are defined, approved, communicated, acknowledged, reviewed and kept relevant.

For an audit-ready ISMS, don’t just create the policy. Create the evidence trail showing that the policy is actually governed and used.