The information security policy is the shortest document in an ISO 27001 system and the one most often got wrong, because it is the one most often bought. A template policy is thirty pages long, names controls the company does not run, and once carried another company's name; an auditor recognises it on the first page. Clause 5.2 asks for something much smaller: a policy from top management that fits what the company is for, carries the security objectives or the frame for setting them, commits the company to the requirements it is under and to improving the system, and is written down, told to the people inside and shown to those outside who need it. That is seven things, and none of them is a page count. This article reads the clause for a software company, sets out the nine sections a two-page policy carries, lists what an auditor flags, and describes the free page that writes the policy from ten answers in six languages.
What the clause asks for, and what it does not
Four of the seven things are about content and three about handling. The content: the policy must be appropriate to the company's purpose, so a payroll platform's policy talks about payroll data and the customers who entrust it, not about "the organisation"; it must carry the objectives or the frame for setting them, which is why the policy names the objectives it measures; it commits the company to the requirements that apply to it, the law, the regulations and the contracts recorded in the context of the system; and it commits to continual improvement, which in practice means the internal audit, the management review and the corrective actions the rest of the standard asks for. The handling: the policy is documented information under Clause 7.5, with an owner, a version and an approval; it is communicated within the company, which an auditor checks by asking a new joiner; and it is available to interested parties where appropriate, a customer or an auditor on request. What the clause does not ask for is a length, a template, a signature ceremony or a list of controls: the controls belong to the Statement of Applicability, and the rules on each topic belong to the topic-specific policies that A.5.1 asks for underneath this one.
The nine sections of a short policy
A policy that satisfies the clause and reads well fits in nine sections. Purpose: what the company protects and why, in one paragraph that names the product. Scope: who and what the policy binds, pointing to the scope statement of Clause 4.3 rather than repeating it. Why it matters here: the honest driver, whether customers make security a condition of business, a regulator obliges it, tenders require the certificate, or the company chose it before anyone asked. Commitments: the risk process with acceptance criteria top management agreed, the requirements that apply, the awareness and training people get, the measuring, auditing, reviewing and improving of the system, and the resources it needs. Objectives: the measurable lines of Clause 6.2, three to five of them. Roles: top management, the person who runs the system, the owners of systems and information, and everyone else, each with one line of responsibility. The policies under it: the list of topic policies, so that a reader knows where the rules on access, cryptography, backup, development, suppliers and incidents live, and the rule that this policy prevails where they disagree. Compliance: how it is checked and what a breach means. Communication and review: where it is published, that it is part of onboarding, and the cycle and the triggers for review.
Objectives an auditor can measure
Clause 6.2 asks for objectives that follow from the policy, can be measured where that is practicable, are watched, told to people and kept current, each with a plan behind it. The policy is where they are stated, and the mistake is to state them as adjectives. "We take security seriously" is not an objective; "the service is available at or above the level committed to customers, measured monthly" is, and so are "no confirmed unauthorised disclosure of customer information, and every access to production data tied to a named person", "every change reviewed and tested before release, and no known critical vulnerability left in production beyond the agreed fix time", "every supplier with access assessed before onboarding and reviewed on schedule", "every incident logged, assessed and, where a duty to report applies, reported within its deadline", and "everyone completes security awareness on joining and at least yearly, and access is removed on the last day". Each of those is a line the management review of Clause 9.3 reports on, with a number beside it, which is what the auditor looks for when they open the review minutes after the policy.
The mistakes an auditor flags
The template with another company's name still in a footer, or with controls the Statement of Applicability excludes. The thirty-page policy that repeats the standard, which nobody read and which the new joiner cannot summarise. The missing approval: no name, no date, no version, or a version older than the last change to the business. Objectives written as intentions, with nothing in the management review that measures them. No communication record: the policy exists in a folder, but onboarding does not mention it and staff have not seen it, which fails the communicated part of the clause. No review since the first version, in a company that has changed products, hosting or suppliers since. And a top policy that contradicts a topic policy, such as a password rule in one and a different one in the other, with no statement of which prevails. Each is a finding at the first audit, and each is avoided by writing less and dating it.
What to do with it
Answer the ten questions on the free page: what the company delivers, why it runs the system, whether it processes customers' personal data, develops software, outsources development or has premises, who runs the system, who approves the policy, the review cycle and the objectives it will measure. The page writes the nine sections in plain words and lists the topic policies the answers call for. Edit it to sound like the company, have the approver sign and date it, publish it where every joiner reads it, and take the objectives to the management review. Then write the scope statement it refers to, the risk register the commitments promise, and the Statement of Applicability that lists the controls; StandardOS writes the policy and the topic policies under it from the same answers, versioned, and turns the review cycle into a date on the calendar.