ISO 27001 A.5.1 - Policies for Information Security

Requirement

Information security policy and topic-specific policies should be defined, approved by management, published, communicated to and acknowledged by relevant personnel and relevant interested parties, and reviewed at planned intervals and when significant changes occur.

Plain-language meaning

The organization needs a formal information security policy structure, not random documents sitting in a shared folder.

A policy is useful only if it is:

1. written;
2. approved;
3. controlled;
4. published;
5. communicated;
6. acknowledged by relevant audiences;
7. maintained;
8. reviewed regularly and after significant changes;
9. linked to risk and business requirements.

A policy that nobody knows exists is not an effective control.

Top-level policy vs topic-specific policies

Top-level information security policy

The top-level policy is the high-level management statement of intent.

It should explain:

• why information security matters;
• what the organization is trying to protect;
• the general ISMS scope;
• management commitment;
• high-level security objectives;
• key responsibilities;
• the risk-based control approach;
• compliance expectations;
• exception and non-compliance handling;
• references to supporting policies.

The top-level policy should normally be short and understandable. A one-page policy is often stronger than a long policy nobody reads.

Topic-specific policies

Topic-specific policies provide detailed rules for specific security areas.

Examples:

The top-level policy says what the organization commits to.

The topic-specific policies say how specific security areas are governed.

Procedures and standards then explain how the policies are executed.

Policy hierarchy

Implementation guidance

1. Keep policies simple and usable

Policies should be clear enough that people understand their responsibilities.

Bad pattern:

Users shall protect information according to business requirements and applicable laws.

This is too generic to be useful.

Better pattern:

Users must protect company information according to its classification, use approved storage locations, report suspected incidents immediately, and comply with access control, acceptable use, and data handling requirements.

2. Obtain management approval

Management approval matters because the policy represents organizational authority.

A draft policy written by the security team is weak evidence if it was never approved.

Good evidence includes:

• signed policy;
• workflow approval;
• board or executive committee minutes;
• GRC approval record;
• policy register showing approved status;
• version history showing approver.

3. Publish and communicate policies

Publication and communication are different.

A policy hidden in a folder may exist, but it may still fail the communication and awareness test.

4. Require acknowledgement where relevant

Relevant personnel and interested parties should acknowledge relevant policies.

“Relevant” is important. Not every person needs every topic-specific policy.

5. Control external distribution

External parties may need policy information, but internal policies can contain sensitive details.

Use:

• redacted policies;
• supplier security schedules;
• contractual security requirements;
• third-party code of conduct;
• confidentiality agreements;
• controlled access to current versions.

6. Protect policies from tampering

Policies are controlled documents.

Expected controls include:

• version control;
• named document owner;
• restricted edit permissions;
• approval workflow;
• review history;
• read-only publication copy;
• archived previous versions;
• change log.

7. Review policies

Policies should be reviewed:

• at planned intervals; and
• when significant changes occur.

Review triggers include:

A policy review that only checks grammar is weak. The review should confirm that the policy remains suitable, accurate, risk-aligned, and implementable.

Audit guidance

An auditor should not only check whether a policy document exists.

A good audit asks:

Does the policy support the ISMS, and can the organization prove it is approved, communicated, understood, maintained, and reviewed?

Audit tests

Strong evidence

• Top-level policy signed by an appropriate executive.
• Document has owner, version, approval date, and next review date.
• Policy is published on intranet or a GRC platform.
• Employees complete annual acknowledgement.
• New hires acknowledge policy during onboarding.
• Topic-specific policies are linked from the top-level policy.
• Policy changes are controlled and tracked.
• Review records show planned and event-driven reviews.
• Exception process exists and has real examples.

Weak evidence

• Policy is marked draft.
• No management approval.
• No named owner.
• No review date.
• Outdated references to old systems or teams.
• Employees do not know where to find it.
• No communication evidence.
• No acknowledgement records.
• Topic-specific policies contradict each other.
• Policies exist but are not followed.
• External parties are expected to comply with policies they were never given.

Common failures

Exam traps

• Having a policy document is not enough.
• Top-level policy should not contain every operational detail.
• Relevant external parties may need access to policy requirements.
• Not all policies should be public.
• Reviews are both scheduled and triggered by significant changes.
• The auditor checks communication, acknowledgement, ownership, version control, and review, not just the document.

KB-ready summary

A.5.1 requires a formal information security policy structure. The top-level policy should express management commitment and link to detailed topic-specific policies. Policies must be approved, published, communicated, acknowledged by relevant audiences, controlled, protected from unauthorized modification, and reviewed periodically and when significant changes occur.

Templates and checklists

• Top-Level Information Security Policy
• Policy Register
• Policy Review Checklist
• A.5.1 Audit Checklist
• Policy Communication and Acknowledgement Tracker