ISO/IEC 27001:2022 Annex A · Control 5.1
Policies for Information Security: A Practical Implementation Guide
A useful security policy is not a document written for an auditor. It is a management decision that gives people clear direction, assigns accountability and turns information security objectives into consistent everyday behaviour.
Annex A control 5.1 concerns the organization's policies for information security. In practice, implementation means creating a policy framework that is appropriate to the organization, formally approved, available to the people who need it and kept current when risks or business conditions change.
What should the control achieve?
A well-implemented policy framework should answer four basic questions:
- What does management expect? The organization states its security principles and mandatory rules.
- Who is accountable? Policy owners, approvers and affected roles are identifiable.
- How is the direction applied? Supporting topic-specific policies, standards and procedures translate principles into practice.
- How does it stay relevant? Reviews are triggered by time, incidents, regulatory changes, new technologies and major organizational changes.
A practical implementation approach
Understand the context before writing
Start with the ISMS scope, interested parties, legal and contractual obligations, risk assessment and business objectives. A cloud software company, a hospital and a small engineering firm should not have identical policy frameworks.
List the main drivers for the policy: customer commitments, privacy obligations, critical services, regulated data, remote work, supplier dependencies and important technologies.
Choose a policy hierarchy
Keep the top-level Information Security Policy short and stable. Use supporting documents for subjects that change more often. A practical hierarchy is:
- Level 1 — Information Security Policy: management intent, principles, objectives and governance.
- Level 2 — Topic-specific policies: access control, acceptable use, incident management, supplier security, remote working, backup and similar subjects.
- Level 3 — Standards and procedures: concrete requirements and operational steps.
- Level 4 — Records: evidence that the rules were followed.
Assign ownership and approval
Give every policy a named role as owner—not merely “IT.” The owner coordinates drafting, stakeholder consultation, communication and review. The top-level policy should normally be approved by top management to demonstrate that its direction is authoritative.
Define who may approve topic-specific policies. For example, the CISO may approve technical security standards while HR and the CISO jointly approve personnel-related security rules.
Draft rules that people can apply
Write for the intended audience. Distinguish mandatory requirements (“must”) from recommendations (“should”). Avoid copying generic language that does not fit the business. Each important requirement should be realistic, owned and capable of producing evidence.
For example, “access shall be reviewed regularly” is vague. A supporting standard could state that application owners review privileged access quarterly, record the result in the ticketing system and remove unjustified access within five working days.
Consult affected stakeholders
Security policies often affect HR, Legal, Privacy, IT, Facilities, Procurement and business teams. Ask them to test whether the proposed rules are legally sound, operationally possible and consistent with existing processes. Resolve conflicts before approval.
Approve, publish and communicate
Record the approver and approval date. Publish the current version in a controlled location such as the intranet or document management system. Remove or clearly mark obsolete copies.
Communication should match the audience and the change. A new top-level policy may require an all-staff announcement and awareness module. A technical standard may require a workshop with administrators and developers. Keep evidence such as acknowledgements, attendance records or campaign statistics.
Operate a review cycle
Set a risk-based review interval—often annually for the top-level policy—and define event-driven triggers. Examples include a serious incident, a significant audit finding, acquisition, entry into a regulated market, major cloud migration or material legal change.
The review record should show what was considered, whether changes were necessary, who approved the outcome and when the next review is due.
What could this look like in practice?
Example: a 120-person SaaS company
The company maintains a six-page Information Security Policy approved by the CEO. It establishes objectives, responsibilities, risk-based decision-making, compliance expectations and the requirement to report security events. It applies to employees and contractors.
The policy is supported by topic-specific documents for access control, secure development, acceptable use, incident management, supplier security, business continuity and remote working. Technical details—such as MFA requirements, encryption parameters and logging periods—are maintained in standards so they can change without rewriting the top-level policy.
| Activity | Practical implementation | Evidence |
|---|---|---|
| Approval | CEO approves the top-level policy; CISO approves supporting standards under delegated authority. | Approval workflow and version history |
| Communication | New starters acknowledge the policy during onboarding; major changes are announced through the intranet. | Acknowledgement report and announcement |
| Access | Current policies are available in a read-only ISMS portal; obsolete versions are archived. | Portal permissions and controlled document register |
| Review | CISO reviews annually and after defined trigger events, consulting HR, Legal, Engineering and Operations. | Review minutes, tracked changes and approval record |
| Monitoring | Policy exceptions, overdue reviews and acknowledgement rates are reported quarterly. | ISMS dashboard and exception register |
A usable Information Security Policy structure
Suggested top-level outline
- Purpose and management commitment
- Scope and intended audience
- Information security objectives and principles
- Roles, responsibilities and authority
- Risk management and control selection
- Compliance with legal, regulatory and contractual requirements
- Security incident reporting
- Policy exceptions and consequences of non-compliance
- Supporting policies, standards and procedures
- Ownership, approval, review and version control
The document should reflect the organization's actual governance. Do not add sections simply because they appear in a template. Equally, do not hide operational detail in the top-level policy if it will become obsolete every few months.
Minimum implementation evidence
- Approved Information Security Policy
- Documented scope and audience
- Named policy owner and approver
- Version number and approval date
- Defined review frequency and triggers
- Register of supporting policies
- Evidence of communication
- Employee or contractor acknowledgements where appropriate
- Review and change history
- Controlled access to current versions
- Process for exceptions
- Evidence that overdue reviews are followed up
Useful metrics
Metrics should help management see whether the framework works—not merely whether documents exist. Possible indicators include:
- Percentage of policies reviewed by their due date
- Percentage of relevant personnel who completed required acknowledgement or awareness
- Number and age of approved policy exceptions
- Number of incidents or audit findings linked to unclear or missing policy requirements
- Average time needed to update affected policies after a major change
Common implementation mistakes
- Copying a template without adapting it. The policy describes an imaginary organization and cannot guide decisions.
- Creating one enormous document. Operational details make it unreadable and difficult to maintain.
- No management approval. The document appears to be an IT preference rather than organizational direction.
- Publishing without communication. Employees cannot follow rules they do not know exist.
- Using vague language. Terms such as “regularly,” “adequately” and “where possible” lack defined interpretation.
- Ignoring exceptions. Teams quietly bypass impractical rules instead of documenting and approving risk-based exceptions.
- Treating the review date as a formality. The owner changes the date without considering incidents, audits, technology or legal developments.
Questions an auditor may ask
- How did the organization determine which information security policies it needs?
- Who owns and approves the policies?
- How do employees and contractors access the current versions?
- How are important changes communicated?
- Show an example of a completed policy review.
- How are exceptions approved and monitored?
- Can employees explain the policy requirements relevant to their roles?
Continue through Annex A
Explore the complete set of organizational, people, physical and technological controls in our growing implementation library.
Open the ISO 27001 Annex A Control LibraryThis independent educational guide paraphrases the practical intent of the control and does not reproduce the ISO standard. It is not affiliated with or endorsed by ISO and does not replace the official standards, professional advice or an organization-specific risk assessment.