Policies for information security

Plain-language summary

Setting out what your organisation expects on information security in a short top-level policy and a set of topic-specific policies — signed off by management, made available and explained to the people they bind, accepted by them, and kept up to date as things change.

What the clause is really asking

This control is the backbone the rest of Annex A hangs from. It asks for two layers: a top-level information security policy that states management's direction and commitment (the same document clause 5.2 requires), and topic-specific policies wherever the organisation needs more detail — access control, acceptable use, cloud services, backup, cryptography, supplier security, remote working and so on. Each policy needs sign-off at the right level of management, has to reach the employees and outside parties it binds, needs evidence they have taken it on board, and must be revisited on a schedule and whenever the business, the risks or the law shifts. The common misunderstanding is that more pages mean more compliance: a 60-page manual nobody reads fails the communication test, while short policies with an owner and a review date pass. ISO 9001 users already have the mechanics — document control, approval, periodic review — so reuse them. In South Africa the policy set is also the first evidence of the 'organisational measures' POPIA section 19 requires.

What auditors look for

Auditors ask for the policy set and check each document's approval, version, owner and last review date against the review interval you set yourself. They pick two or three topic-specific policies and test whether practice matches — if the access control policy promises quarterly reviews, they ask for the last two. They interview a handful of staff and a contractor, ask where the policies are and which apply to them, then ask for the acknowledgement records. They compare the policy set with the Statement of Applicability, looking for controls that cite a policy that does not exist. The hard question: what changed in the business or the law since the last review, and why did the policy not change with it?

Typical evidence

Top-level information security policy signed by top management; topic-specific policies with owner, version, approval and review dates; policy register or document master list; communication records such as intranet posts, induction packs and emails; signed or electronic acknowledgements from employees and contractors; review records showing changes made; cross-reference from the Statement of Applicability to each policy.

How to comply — recommendations

Start with a policy register: list the topic-specific policies your risk assessment and Statement of Applicability actually call for, name an owner for each and set a review date. The free Qlause ISO 27001 Gap Analysis Checklist will show which are missing. Keep the top-level policy to two pages and each topic policy as short as it can be while still stating clear rules. Route every policy through your existing document control for approval. Publish them in one place, push the ones relevant to each role at induction, and collect electronic acknowledgements. Review the set annually and also after a significant incident, a restructure or a change in law, recording what changed and why.

Common nonconformities

Topic-specific policies cited in the Statement of Applicability but never written; policies unapproved or approved at the wrong level; review dates passed with no review recorded; staff and contractors unaware of policies that apply to them; no acknowledgement records; policy rules contradicted by practice, such as promised access reviews never performed; template policies naming systems the organisation does not use.

Resources for this clause

• ArticleISO/IEC 27001:2022 Annex A explained: the 93 controls in plain English, theme by theme, with the 114-to-93 map and the attribute tags
• ArticleThe Statement of Applicability, explained — what ISO/IEC 27001 clause 6.1.3 requires, the four ways an SoA fails Stage 1, and how to build one from the risk register
• ArticleISO/IEC 27001:2022 explained for people who already run ISO 9001: what is the same, what is new, and how to get certified
• Free downloadInformation Security Policy templateThe clause 5.2 policy on one page: what you commit to, the objectives framework, who does what, the rules in brief, communication and review — with «fields» to fill and a box on how to keep it true.
• Toolkit · $39Risk & SoA ToolkitScore your information security risks on a documented method, pick the Annex A controls that treat them, and the Statement of Applicability writes its own first draft — every justification citing the risks behind it.
• Toolkit · $29ISMS Metrics & Evidence TrackerThe three things an ISMS has to show after certification, in one workbook: measures with a live Green / Amber / Red status, management review minutes that cover every required input, and an evidence register that gives every control an owner, a rhythm and a due date.
• Free downloadAnnex A 93 Controls Quick ReferenceOne A3 page: all 93 Annex A controls in their four themes, the eleven new in 2022 flagged, and the ISO/IEC 27002:2022 attribute legend — the poster for the wall beside the Statement of Applicability.
• Free downloadISO 27001 Gap Analysis ChecklistWhere you stand against ISO/IEC 27001:2022 in one afternoon — the 30 management-system requirements and all 93 Annex A controls, scored, with owners, dates and a readiness figure that calculates itself.
• Free masterclass · ~27 minISO 27001 MasterclassYou already know four fifths of ISO 27001. Here is the other fifth — the risk method, the SoA, the 93 controls, the evidence rhythm, POPIA, and a 44-week path.
• Free appAudit ManagerPlan the programme, anchor each finding to its clause and drive the NC to closure.