How to Write an Information Security Policy Under ISO/IEC 27001 (Structure and Example) (2026)

When a company first runs into ISO/IEC 27001, one of the first documents it's asked for is an information security policy. And this is where many people make the same mistake: they google someone else's policy, copy the PDF, swap the company name in the header, and consider the job done. An auditor sees through documents like that in a couple of minutes.

An information security policy is a short document in which the company's leadership states what it protects and how, and sets the ground rules for every employee. It isn't a password manual or a technical procedure, but a top-level statement of intent: which data matters most to us, who is responsible for it, and what principles we follow. The whole information security management system starts from it, so how honestly and precisely it's written shapes everything that comes after.

In the standard ISO/IEC 27001, the requirements for this document are gathered in clause 5.2, "Policy." Below we break down what it actually demands, what structure works in practice, and we show a section-by-section skeleton you can adapt to your own company instead of copying someone else's. And if you need the wider context, our complete guide to ISO/IEC 27001 walks through the whole path to certification.

Clause 5.2 of the standard isn't a recommendation but a mandatory requirement from the main body of ISO/IEC 27001 (clauses 4 to 10). You can't exclude it or justifiably skip it the way you can individual Annex A controls. And the responsibility here is personal: the policy is established by top management, not the IT department and not an outside consultant. This is a matter of principle. The director's signature under the policy means security has support from the top, without which it simply doesn't work.

The standard frames its requirements in two parts. The first four points (a to d) concern the content of the document; the last three (e to g) concern whether it's actually alive: you can word the principles perfectly, but if nobody has seen the policy, the requirement isn't met. Points e to g are exactly where companies that treated the policy as a formality tend to fall down. Here's the full list in plain terms.

The question "why do we even need this policy" comes up almost every time, and the answer decides whether the document ends up alive or dead. The purpose of an information security policy is to set a single direction for every decision about protecting information in the company, and to show that leadership backs that direction. Put simply, it's a compass: when an employee or a manager isn't sure how to act in an ambiguous situation, they check against the policy.

Broken down further, the purpose of an information security policy is to:

• set direction and principles: what protecting information means for the company and which rules it follows;
• anchor management responsibility: the policy is approved by top management, so security stops being "the IT department's problem";
• provide a framework for objectives: concrete, measurable security objectives flow from the policy;
• tie security to laws and contracts: through the commitment to meet applicable requirements;
• start the improvement mechanism: the policy records that the system is reviewed and evolves.

Notice that none of these goals is about technology. The policy doesn't say "install antivirus X." It sets the floor a company won't drop below, while the specific measures are chosen to fit the risks.

Here's a confusion almost every newcomer trips over. In the standard the word "policy" appears in two different places, and they aren't the same thing.

Clause 5.2 requires one top-level information security policy, the same short document from management that this article is about. Annex A control 5.1 ("Policies for information security," in the plural) is a set of topic-specific, detailed policies for particular subjects: an access control policy, a password use policy, a supplier relationships policy, a clear desk policy.

The relationship is simple: the top-level policy (5.2) sets the overall direction, while the topic-specific policies (Annex A 5.1) spell it out in detail for individual areas. One umbrella, and many concrete documents beneath it. Don't confuse them: an auditor expects both levels, but the top-level policy is single, and it should stay concise.

Now for the most practical part: what the document physically consists of. The standard doesn't dictate a rigid template. It says what the policy must contain (points a to g), but not how to format it. Over years of practice a structure has settled that covers every clause 5.2 requirement while staying readable.

Here's a skeleton you can take as a base and fill with your own content. It isn't a file to download, but a structure: you simply recreate these sections in your own document and write about your company, not about an abstract "organization."

Eight sections is a guide, not dogma. A small IT company will fit it all on two pages; a large financial institution will expand to five or six. The main rule: every section must carry meaning. If you can't explain why a given paragraph is in the policy, it shouldn't be there.

And the reverse is true: some things have no place in a top-level policy. Specific password settings, lists of approved software, step-by-step response procedures all live in topic-specific policies and standards. Stuff them into the main document and it swells to an unusable size, and you'll have to revise it every time some minor technical detail changes. The policy should be stable; let the details change below it.

The policy doesn't hang in the air. It rests on information security risk management, and this is a link auditors check especially closely. The logic goes like this: first you assess what could go wrong with your data, then you decide what to do about it, and only then does the policy anchor the general principles behind those decisions.

So the policy needs a section that references the risk management process: who runs it, how often, by what method. Not the risk analysis itself, which lives in separate documents, but a mention that the company handles it systematically. This is the practical embodiment of requirement 5.2(b): the policy sets the framework, while concrete objectives and measures flow from the risk assessment.

The chain looks like this: the policy declares an intent to manage risks, the risk assessment shows where the threats are, risk treatment picks controls from Annex A, and the Statement of Applicability records the choice. If the policy doesn't even mention risks, it's detached from the real system, and that shows immediately. For more on how this whole system is built, see our ISMS certification guide.

Let's put it all in order. Here's what writing a policy looks like from a blank page to a signed document.

1. Gather the context. Before writing, work out what data the company handles, what clients and laws require, and where the boundaries of the future system lie. Without this the policy comes out abstract.
2. Run a preliminary risk assessment. Even a rough picture of the threats will tell you which principles are worth anchoring in the policy.
3. Draft it from the skeleton above. Eight sections, each a few paragraphs in plain language. Write so that not only a security specialist but also an accountant can follow it.
4. Agree it with management. This isn't a formality: top management has to not just sign but understand and back what they're signing.
5. Approve, date, and version it. A policy without a date and version is a draft. Add a version number, an approval date, and who approved it.
6. Communicate it to staff. Send it out, post it in an internal system, add it to new-hire onboarding. Requirement 5.2(f) counts as met when people actually know about the policy.
7. Schedule a review. Once a year, or after significant changes, so the policy doesn't age along with the company.

In practice the biggest time sink isn't the wording but agreeing it with management and honestly assessing what the company really does rather than what it declares. If you're doing this for the first time, a preliminary readiness assessment saves weeks: it shows which principles you can honestly anchor in the policy right now, and which would still be fiction.

Policy mistakes repeat from company to company, and almost all of them come down to a formal approach. Here are the ones that turn up most often.

The first and crudest is copying someone else's policy. The policies of banks and large companies sit out in the open, so the temptation to grab something ready-made is strong. But another company's document describes another company's risks, structure, and systems, and during an audit that surfaces from the first questions. The second is a policy detached from reality: it says "access is granted on a least-privilege basis" while in fact everyone has admin rights. An auditor checks not the text but whether the text matches life.

The third mistake is over-detailing, when people try to stuff passwords, settings, and procedures into a top-level policy. That's what topic-specific policies are for. The fourth is a missing signature and date: a document without management approval formally fails requirement 5.2. And the fifth is "written and forgotten": the policy was approved three years ago, the company has changed beyond recognition, and the document is still the same.

In practice a policy is rarely an end in itself: a company comes for it because it's preparing for certification or answering a client's request. So we don't write the policy apart from the system. Ekontrol supports ISMS implementation as a single practice, and the policy emerges naturally from an assessment of your context and risks, not from a template.

We start by reviewing the situation: what data you handle, what contracts require, and where your main risk lies. Then comes a preliminary diagnostic that shows the gap between what you have and what the standard wants, and only after that the policy and the rest of the documents get built around your real processes. Our certification preparation services cover the whole path, from the first diagnostic to the certification audit. For IT and SaaS companies working with EU and US clients, we separately prepare tender documentation, where the policy is only one element.

If you're not sure where to start, there are two simple options: read the complete guide to ISO/IEC 27001 to see the whole picture, or write to the Ekontrol team right away to discuss your situation. We have worked as a Bureau Veritas partner in Ukraine since 2014.