ISO 27001 policies list: shorter than the standard, longer than a tweet
The Acceptable Use Policy is forty-one pages. It was adapted from a template that was adapted from a template, it covers the use of fax machines, and every member of staff has clicked to acknowledge it. At Stage 2 the auditor will ask one of them what it says.
That interview is the reason an iso 27001 policies list should be shorter than instinct suggests. Not because the standard asks for brevity, but because a policy nobody has read is a control that does not operate, and the auditor finds that out by asking rather than by reading.
The iso 27001 policies list you actually need
Grouped by what they do, which is more useful than the order they appear in the standard.
Governance. Information Security Policy, the ISMS scope statement, and a roles and responsibilities document. The Information Security Policy is the only one the standard names explicitly as a requirement.
Risk. Risk assessment methodology, the risk register, the Statement of Applicability, the risk treatment plan. These are the four risk documents and they are documents rather than policies, which matters because they change more often.
People. Acceptable Use Policy, a screening procedure, a disciplinary reference which can point at existing HR material rather than duplicating it, and a remote or home working policy.
Access. Access Control Policy and a password or authentication standard.
Operations. Backup Policy, change management procedure, vulnerability management procedure, logging and monitoring procedure.
Incident and continuity. Incident Response Plan and a business continuity plan scaled to the size of the company.
Third party. Supplier Security Policy and a supplier risk assessment procedure.
Physical. Physical Security Policy, which can be brief for a remote-first company and should still exist to explain why.
Ongoing governance. Internal audit procedure and management review procedure.
That is around twenty documents. Fewer than most templates sell you and more than most people expect, because the procedures are where the work is and templates tend to supply policies without them.
Why long policies fail
Three reasons, and the third is the one that actually costs you.
Nobody reads them, so the awareness control does not operate. Clause 7.3 requires personnel to be aware of the policy and its implications. Awareness is tested by asking somebody, not by checking an acknowledgement log.
They contain claims you cannot evidence. A forty-page policy adapted from a template will state that you do things you do not do. Every such sentence is a finding waiting for somebody to sample it, and you wrote it yourself.
They are never reviewed properly. Reviewing a one-page policy annually takes ten minutes. Reviewing forty pages takes an afternoon nobody has, so the review becomes a date change in the version history, which an auditor can see.
One page plus a linked procedure
The structure that survives.
The policy states intent, scope, who it applies to, the principles, and who owns it. It is deliberately free of specifics that change, so it can go a year without amendment. One page, occasionally two.
The procedure states how, and can be as long as it needs to be. It carries the specifics: the tool names, the thresholds, the step-by-step. It changes whenever the implementation changes, without triggering a policy re-approval and re-acknowledgement cycle.
So the Access Control Policy says access is granted on the principle of least privilege, reviewed quarterly, approved by the system owner, and removed on leaving. The joiner, mover and leaver procedure says which portal, which sequence, and which script, and it is the automation note made official.
That split means staff read one page, the auditor reads both, and you amend the procedure without asking forty people to re-acknowledge anything.
The evidence that makes a policy real
A policy on its own is a Word document. Three things turn it into a control that operated.
Approval by the right person, dated. Not "approved by management". A named individual with the authority, on a date, recorded somewhere other than inside the document itself. Minutes of a management meeting work well because they double as clause 5 evidence.
Acknowledgement by staff, dated. Whatever mechanism you use, the output has to be a list of names and dates you can produce on request, including for joiners since the last review.
Review on a stated cycle. Annually is the usual answer. The evidence is a record that a review happened and what came of it, including "no changes required", which is a legitimate outcome that many people fail to record and therefore fail to evidence.
One small thing worth getting right: keep the approval status in a register rather than only on the document's face. A file whose cover page says DRAFT while it is the version everyone follows creates an argument at audit that takes longer to resolve than it should.
The awareness question
At Stage 2 the auditor may ask a member of staff what the acceptable use policy requires, or what they would do if they lost a laptop, or who to tell about a suspected phishing email.
They are not testing recall of the document. They are testing whether the control operates, and the answer they want is roughly right and confident. "I would tell [name] straight away and there is a form" passes. "I think there is a policy somewhere" does not, and no amount of policy quality fixes it.
That is an argument for short policies and for a brief induction conversation rather than for a longer document. Ten minutes explaining three things people must do beats forty pages nobody opens, and the ten minutes is also easier to evidence.
Getting the first draft
Templates are a reasonable starting point and a poor finishing point. The failure mode is adopting one wholesale, because you inherit claims about practices you do not have and language that does not match how your company works.
Two rules that make templates safe. Delete anything you cannot evidence today or commit to a date for. And rewrite every sentence that describes a practice, in your own words, because a policy written in somebody else's voice reads as borrowed and prompts sampling.
The book includes two complete policies, the Information Security Policy and the Acceptable Use Policy, written for a company of this size, along with the document control conventions that make the set auditable. The NCSC's guidance on policy and process is a useful sanity check on whether yours says anything a board would recognise.