ISO 27001 A.5.1: Setting Up Information Security Policies the Right Way

TL;DR

A.5.1 requires a management-approved information security policy and topic-specific subordinate policies that set the framework for all other controls.
The overarching policy defines protection objectives, scope, roles, and responsibilities at a strategic level. Operational details belong in the subordinate policies.
For a company with around 100 employees, 8 to 12 subordinate policies in a clear hierarchy beneath the overarching policy are typically sufficient.
A documented review cycle with at least annual reviews is mandatory. Event-driven reviews after security incidents or organizational changes are additional requirements.
The best policy is useless if nobody knows about it. Communication, training, and acknowledgment by employees are essential for effectiveness.

The Mother of All Controls

When you open the Annex A of ISO 27001:2022, A.5.1 is right at the front. That is no coincidence. Information security policies are the organizational foundation on which all technical and operational measures are built. Without documented policies, there is no frame of reference: Who is allowed to do what? What is permitted, what is prohibited? What do administrators base their system configurations on, employees their data handling on, and executives their budget approvals on?

A.5.1 is titled "Policies for information security" and essentially requires two things: an overarching information security policy, approved and published by top management, as well as topic-specific subordinate policies that establish concrete rules for individual areas. Both must be regularly reviewed, updated as needed, and communicated to all relevant persons.

That sounds manageable, but in practice, surprisingly many companies fail at precisely this control. Not because the requirement is so complex, but because the policy landscape is either too thin, too bloated, or simply not maintained.

What the Standard Specifically Requires

ISO 27002:2022, the implementation guide for Annex A, describes the requirements for A.5.1 in detail. The key points can be summarized across four dimensions.

Dimension 1: Strategic Policy

Top management must approve an information security policy that sets the strategic framework for the entire ISMS. This policy contains the company's protection objectives (typically confidentiality, integrity, and availability), the scope, the commitment to continual improvement, and the fundamental responsibilities.

Important: The policy is a strategic document, not a technical manual. It describes the "what" and "why," not the "how." Technical details such as password lengths, firewall rules, or backup intervals belong in the subordinate policies.

Dimension 2: Topic-Specific Policies

Below the overarching policy, policies for specific topic areas are needed. The standard mentions as examples access control, physical security, asset management, information transfer, secure configuration, malware protection, backup, cryptography, network security, incident management, and supplier relationships.

Which policies you specifically need depends on your scope and risk landscape. There is no fixed number prescribed by the standard. What it does prescribe, however, is consistency: all subordinate policies must derive from and align with the overarching policy.

Dimension 3: Approval and Communication

Policies must be approved by the appropriate management level and communicated to all relevant internal and external parties. "Relevant" means that not everyone needs to know every policy, but every employee must know and understand the overarching policy and the subordinate policies relevant to their role.

Communication must be demonstrable. A PDF on the intranet is technically sufficient, but an auditor will ask how you ensure that employees have actually read and understood the policies.

Dimension 4: Regular Review

Policies must be reviewed at planned intervals and when significant changes occur. The standard does not prescribe a fixed interval, but an annual review cycle has established itself as best practice. In addition, policies must be reviewed on an event-driven basis when the threat landscape changes, after security incidents, during organizational changes, or when new regulatory requirements emerge.

The Policy Architecture for Around 100 Employees

A company with around 100 employees needs a policy landscape that is comprehensive enough to satisfy the standard but lean enough to be lived in practice. Too many policies lead to nobody keeping track. Too few lead to important areas remaining unregulated.

Level 1: The Information Security Policy

The overarching policy is a document of typically 3 to 5 pages. It contains the following elements:

Purpose and scope: Why does this policy exist, and who does it apply to? The scope should align with the ISMS scope, covering all locations, business processes, systems, and persons that fall under the ISMS.

Protection objectives: The definition of information security objectives at a strategic level. In addition to the classic protection objectives of confidentiality, integrity, and availability, authenticity, non-repudiation, or data privacy can also be formulated as objectives.

Management commitment: An explicit statement that top management supports information security and provides the necessary resources. This section is important because it forms the basis for budget decisions and the enforcement of measures.

Roles and responsibilities: Who is responsible for information security? Typically named here are the Information Security Officer (ISO), top management, IT management, and employees, each with their fundamental duties.

Reference to subordinate policies: The overarching policy references the topic-specific policies, making the hierarchy transparent.

Consequences for violations: A note that policy violations have consequences. The details of the disciplinary procedure belong in the subordinate policies or in the HR regulations, but the principle must be anchored in the overarching policy.

Versioning and approval: Date, version, approval notation by top management.

Level 2: Topic-Specific Policies

For a company with around 100 employees, the following policy structure has proven practical:

Access control policy: Governs authorization assignment, password requirements, multi-factor authentication, privileged access, and revocation of permissions.
Acceptable use policy: Governs how employees may use company devices, email, internet, and cloud services. Also includes rules on private use.
Information transfer policy: Governs the secure transfer of information via email, messenger, file sharing, and physical transport.
Information classification policy: Defines classification levels (e.g., public, internal, confidential, strictly confidential) and the handling of information at each level.
Physical security policy: Governs access controls, visitor management, server room security, and workplace protection.
Mobile devices and remote work policy: Governs BYOD, home office, VPN requirements, and handling of mobile storage media.
Backup and recovery policy: Governs backup intervals, retention periods, storage locations, and restore tests.
Cryptography policy: Governs approved algorithms, key lengths, key management, and transport encryption.
Incident management policy: Governs the detection, reporting, escalation, and follow-up of security incidents.
Supplier management policy: Governs security requirements for service providers and the assessment of third parties.

Depending on the industry and risk landscape, additional policies may be needed, such as for network security, patch management, software development, or cloud usage. The list above covers the essential areas that an auditor will expect from a company of this size.

Level 3: Procedures and Work Instructions

Below the policies are operational documents describing concrete steps. An example: the access control policy prescribes that new employees receive their access within two business days of joining. The procedure then describes the concrete workflow: who creates the ticket, who sets up the account, which systems are configured, who approves?

This third level is less critical for the audit than the policies themselves, but it ensures that the policies are implemented in practice.

Typical Audit Findings for A.5.1

Auditors assess A.5.1 not only for whether policies exist but also for whether they are lived. The following findings appear regularly.

Finding 1: Policy Without Approval Notation

The information security policy exists but is not formally approved by top management. A signature, an approval date, or a documented resolution is missing. The auditor will conclude that management commitment is not demonstrable.

Prevention: Every policy needs a cover page or header with version number, approval date, and who approved the policy. For digital approval, a documented workflow with timestamp and user ID is sufficient.

Finding 2: Policies Not Reviewed for Years

The policies exist, but the last review was three or more years ago. In the meantime, the company has introduced new cloud services, changed its remote work policy, and processed a security incident without updating the policies.

Prevention: Define a review calendar showing the next review date for each policy. An annual cycle is common. In addition, an event-driven review should take place after every major incident, every reorganization, and every new regulatory requirement.

Finding 3: No Evidence of Communication

The policies are created and approved, but there is no evidence that employees know about them. No training records, no acknowledgment confirmations, no documented distribution mechanism.

Prevention: Use a combination of communication channels. New policies are announced by email, published on the intranet or ISMS tool, and presented in training sessions. Each employee confirms acknowledgment, whether by digital signature, click in the ISMS tool, or documented training attendance.

Finding 4: Policies Without Reference to the Overarching Policy

Subordinate policies exist that do not demonstrably derive from the overarching policy. The overarching policy mentions "appropriate access control," but the access control policy nowhere references the overarching policy and partially contradicts it.

Prevention: Each subordinate policy should reference the overarching policy in its introduction and explain its contribution to the protection objectives defined there. This creates a visible hierarchy.

Finding 5: Policies Too Generic or Too Detailed

Some companies write policies that are so generic they have no actionable effect: "Passwords must be secure." Others drown in technical details that will no longer be accurate after the next system change: "Windows Group Policy Object XY123 is configured with the following parameters."

Prevention: Policies formulate requirements, not technical implementations. "Passwords must be at least 12 characters long and must not be among the 100 most common passwords" is a good policy requirement. How this is technically enforced belongs in the procedure.

The Review Process in Practice

A functioning review process consists of four steps that can be pragmatically implemented for a company with around 100 employees.

Step 1: Maintain the Review Calendar

Create an overview of all policies with their creation date, last review date, and next planned review date — in ISMS Lite, this review calendar is automatically maintained and reminds you in good time of upcoming reviews. With 10 to 12 policies, you can distribute the cycle so that one to two policies come up for review per month. This prevents having to overhaul all policies at once per year.

Step 2: Assign Responsibilities

Each policy needs an owner who conducts the review and an approver who signs off on the revised version. The ISO coordinates the overall process but does not need to review every policy personally. The backup policy can be owned by the IT manager, the information transfer policy by the data protection officer.

Step 3: Document Changes

Every change to a policy must be traceable. A change log at the beginning of the policy recording when which sections were changed and why is sufficient. For digital documents, versioning can happen automatically.

Step 4: Communicate After Review

After every material change, the affected employees must be informed. Minor editorial changes (typos, formatting) do not need to be actively communicated. Content changes do. If password requirements change, all employees need to know. If backup intervals change, informing the IT team is sufficient.

Communication: From Policy to Lived Standard

The most common weakness in A.5.1 is not documentation but communication. Many companies have clean policies stored in a folder, but employees know nothing about them or signed them once during onboarding and have since forgotten.

Initial Introduction

When you introduce a new policy, you should present it in a training session or at least an information event. Explain not only the content but also the context: Why does this policy exist? What are the risks it addresses? What changes for employees in their daily work?

Ongoing Reminders

Once a year, each employee should re-acknowledge the policies relevant to them. This can happen as part of the annual awareness training or as a separate process. The effect is twofold: first, employees refresh their knowledge. Second, you have documented evidence for the auditor.

Onboarding New Employees

New employees must receive and acknowledge the overarching policy and the policies relevant to their role as part of the onboarding process. Acknowledgment should occur before the first day working on systems or at least within the first week.

Accessibility

Policies must be findable at all times. A central directory on the intranet, in the ISMS tool, or in a shared file system is mandatory. If an employee searches for a policy and cannot find it within two minutes, the publication has failed.

How ISMS Lite Supports Compliance

ISMS Lite offers several features for implementing A.5.1 that significantly reduce the effort.

AI-assisted policy generation: You do not start with a blank page but use the local AI to generate a policy draft based on the A.5 controls and their implementation guidance included in the platform. You then customize the draft to your organization.

Versioning and approval: Each policy is versioned, and the approval process is documented. You can see at a glance which version is current, who approved it, and when.

Review calendar: ISMS Lite automatically reminds you when a policy is due for review. You can see on the dashboard which policies are overdue and which are coming up for review.

Acknowledgment workflow: You can assign policies to employees or groups and track who has confirmed acknowledgment. Outstanding confirmations are escalated.

Audit trail: All changes, approvals, and acknowledgments are logged and can be exported as evidence for the auditor.

Practical Example: Policy Landscape for an IT Service Provider with 80 Employees

A mid-market IT service provider with 80 employees, two locations, and ISO 27001 certification has built its policy landscape as follows:

Overarching policy: 4 pages, signed by the managing director, defines three protection objectives (confidentiality, integrity, availability), names the ISO, and references 10 subordinate policies.

Subordinate policies: Access control, acceptable use, cryptography, physical security, backup, incident management, supplier management, classification, mobile devices and remote work, network security.

Review cycle: Each policy is reviewed once per year. The calendar distributes the reviews so that two to three policies are due per quarter. Additionally, an event-driven review of affected policies takes place after every security incident.

Communication: New employees receive the overarching policy and the policies relevant to their role during onboarding. Annually, all employees confirm acknowledgment as part of the awareness training. Content changes are communicated via email.

The result: in the last surveillance audit, there were no findings for A.5.1. The auditor could verify through the documentation in ISMS Lite that all policies were current, approved, communicated, and acknowledged by employees.

Common Mistakes and How to Avoid Them

Mistake 1: Copying the policy instead of customizing it. It is tempting to take a template from the internet and just insert the company name. An experienced auditor recognizes this immediately because the policy contains generic language that does not fit the company. Use templates as a starting point but adapt them to your reality.

Mistake 2: Introducing too many policies at once. If you publish 12 policies simultaneously, employees will be overwhelmed. A phased rollout is better: first the overarching policy and the three to four most important policies, then the remainder step by step.

Mistake 3: Writing policies in legal language. Policies should be understood by all employees, not just lawyers. Short sentences, clear instructions, concrete examples. If an employee does not know what to do or avoid after reading the policy, it is ineffective.

Mistake 4: No owner for the policy. If nobody is responsible, the policy will not be maintained. Each policy needs a named owner who conducts the review and initiates changes.

Mistake 5: Review without substance. Some companies only change the date and version number at each review without actually checking the content. A good review asks: Is the content still accurate? Have processes changed? Were there incidents requiring an update? Are there new regulatory requirements?

From A.5.1 to the Remaining Controls

A.5.1 is the foundation but not an end in itself. The policies you create here form the framework for all other controls in Annex A. The access control policy sets the framework for A.5.15 through A.5.18, the cryptography policy for A.8.24, the incident management policy for A.5.24 through A.5.28.

If you build the policy landscape properly, you significantly ease the implementation and evidence of all subsequent controls. If you build it carelessly, you will have difficulties with every subsequent control because the frame of reference is missing.

Therefore, start with A.5.1 and invest the time it takes. A sound policy architecture is not a bureaucratic obligation but a genuine governance instrument that helps you in daily operations and in audits.