Write the security policy for the person who joined this morning

1. Which information here is sensitive, and how do I recognise it?
2. What am I allowed to install, store or share, and where?
3. Who do I tell when something looks wrong, and how fast?
4. Who in leadership stands behind these rules?
5. Where do I find the detailed rule for a specific situation?

If any answer is missing, the gap is rarely about security knowledge. It is usually a policy written for a committee, full of intent and short on instruction. The fix is to keep the top document brief and point to topic-specific policies for the detail.

Fit for your purpose

It reflects what your organisation does, not a template from another industry.

Objectives

It either states security objectives or explains how they get set (Clause 6.2 covers the setting).

Meeting obligations

It commits the organisation to satisfy the security requirements that apply to it, such as contracts and law.

Getting better

It commits to continual improvement of the ISMS.

Written down

It exists as documented information under version control.

Shared inside

Staff have been told about it, in a way you can prove.

Shared outside when sensible

Customers, regulators or partners can see it where that is appropriate.

That is the whole requirement, in our words. Nothing in Clause 5.2 asks for a long document. Clause 7.3 adds that people doing work in scope must be aware of the policy, which is why the day-one test above matters.

1. A..1
   5.10 Acceptable use of information and other associated assetsUsually the first topic policy a new hire signs.
2. A..2
   5.15 Access controlHow access is requested, approved and taken away.
3. A..3
   5.12 Classification of informationThe labels and what each one means for handling.
4. A..4
   6.7 Remote workingHome networks, shared spaces and travel.
5. A..5
   8.24 Use of cryptographyWhere encryption is required and who holds keys.
6. A..6
   5.24 Information security incident management planning and preparationHow to report and who responds.

Which topic policies you need follows from your risk assessment and your Statement of Applicability, not from a fixed list.

• Approval trail. A dated sign-off by a member of top management, on the current version.
• Proof people know it. Onboarding acknowledgements and awareness sessions that reference it.
• Interviews. A randomly chosen engineer can say where the policy lives and what it asks of them.
• Consistency. Topic policies and procedures do not contradict the top document.
• Review history. Evidence it was looked at on the schedule you set, and again when the business changed.

• One giant document. Every small rule change forces a full re-approval, so nobody updates it.
• Borrowed language. A downloaded template names systems and roles you do not have.
• No named owner. Each topic policy needs a person who keeps it current.
• Silent on consequences. Staff should know that breaking the rules leads to a defined disciplinary process (Annex A 6.4).

Version control, approval and retention rules for the policy set belong to your documented information process; the guide on that topic covers them.

• Documented informationWhat to write, how to control it, and how little is enough.

Sources: ISO/IEC 27001:2022, Clauses 5.2, 6.2, 7.3 and 7.5 and Annex A control titles (public); ISO/IEC 27002:2022 control titles. Requirements are summarised in our own words; the standards' text is not reproduced.