The information security policy in 2026 - a living document, not a binder

What the policy is, and what it is not

The confusion starts with the word "policy", which in technical usage covers everything from a board declaration to a setting in a domain controller. Within an information security management system the top-level policy has exactly one function: it establishes the rules and names who is responsible for them.

Its characteristics follow from that. It is the highest-ranking document, on which all the others rest. It is a statement by management rather than a paper produced by the IT department, so without the signature of the person running the organisation there is nothing to enforce. And it is a living document - reviewed at planned intervals and whenever significant changes in the organisation could affect it. An annual cycle is a common governance choice, not a frequency imposed by ISO/IEC 27001 clause 9.3.

What it is not matters just as much. It contains no specific technical settings, because those belong in procedures and instructions that change several times a year. It is not a list of prohibitions for staff - that is what the staff regulations are for. It is not an action plan with deadlines. And it is not the fulfilment of the information duties under GDPR articles 13 and 14, which require an entirely different document addressed to data subjects.

Where it sits in the document hierarchy

In a mature system the documentation falls into four levels. At the top is the overarching policy - usually five to fifteen pages, entirely declarative. Below it sit topic-specific policies for individual areas: access control, cryptography, backups, incident handling, remote working, supplier relationships. Below those are operating procedures describing how a given activity is performed, and at the bottom instructions with concrete steps. Separately there are registers and records, which are the only evidence that the rest of it works.

This split has a practical rationale: the lower the level, the more frequent the changes. A top-level policy can survive several years unchanged; a configuration instruction goes out of date with every software update. Putting everything in a single document means that every such change requires management's signature all over again. See the article on the ISMS.

What belongs in it

Clause 5.2 of ISO/IEC 27001 ^[2] sets out the requirements for an information security policy. It must be appropriate to the purpose of the organisation, include information security objectives or provide the framework for setting them, include a commitment to satisfy applicable requirements and to continual improvement of the system. It must also be available as documented information, communicated within the organisation and, where appropriate, available to interested parties.

Those are the minimum requirements. A policy that actually works contains, in our practice, a few more elements, in the following order.

It opens with purpose and scope: why it exists, and which units, locations, systems and categories of information it covers. Scope is often the single most important paragraph in the whole document, because it settles later arguments about whether a given rule applies in a particular situation.

Next comes the management commitment together with a signature, followed by the general principles: least privilege, segregation of duties, defence in depth, access strictly limited to what a task requires. Principles are worded concretely enough that a breach of them can be identified as such.

The next element is information classification - usually three or four levels, together with guidance on how to mark documents and what may be done with each category. Without it the remaining rules hang in a vacuum, because it is unclear what they apply to.

A separate and critical part covers roles and responsibilities: the head of the organisation, the data protection officer, the person responsible for the management system, administrators and users. This is where it is decided whether the policy will be enforceable. The phrase "the organisation ensures" names nobody, and therefore obliges nobody.

The document closes with: a list of the topic-specific policies, the rules for reporting incidents together with deadlines, the review and audit regime, the consequences of breaches, and a control block with version, date and signature.

The reporting deadlines deserve care, because they concern different things and different recipients. An essential or important entity submits an early warning of a significant incident within 24 hours of detecting it to the relevant sectoral CSIRT, and a full notification within 72 hours. Independently of that, a data controller notifies a personal data breach to the supervisory authority within 72 hours of becoming aware of it, where the breach is likely to result in a risk to people's rights. These are two separate obligations that can arise at the same time.

Mapping to regulations

A well-prepared policy has an annex that most documents lack: a matrix tying each rule to a specific provision or clause of a standard.

On the Polish side these are the fourteen areas in § 19(2) of the KRI regulation ^[1], which the topic-specific policies should correspond to. On the standards side - clauses 4 to 10 and the Annex A controls of ISO/IEC 27001 ^[2], whose implementation guidance is given in ISO/IEC 27002 ^[6]. On the data protection side - GDPR articles 24, 25, 30 and 32 ^[3]. On the EU side - the ten categories of measures in NIS2 article 21(2) ^[4]. Organisations that report to the board in the language of functions add a mapping to the NIST CSF ^[7].

Building such a matrix is a day or two of work, done once. It pays for itself at the first audit: a question about a specific provision is answered with "section 4.2 of the policy and the access control policy", instead of searching the documentation while the auditor waits.

The most common mistakes

The patterns below recur in audits regularly enough to be recognisable within a few minutes of reading the document.

1. A template downloaded from the internet. You recognise it by the word "Organisation" in place of the entity's name, by dates several years old and by references to provisions that no longer apply. Such a document does not merely fail to work - it misleads, because it implies conformity with a legal state that does not exist.
2. A sixty-page document. The attempt to put everything in one place ends with nobody reading it, and with every technical change requiring fresh management approval.
3. Rules with no owner. The sentence "the organisation ensures the security of backups" names no person, so when something goes wrong there is no way to establish who failed to act.
4. A document written for the auditor, not for the employee. Legal-technical language means the person who is supposed to apply the rules does not understand them. A two-level solution works well: the full policy for evidentiary purposes and a one- or two-page summary for staff.
5. No update process. A document from 2018 mentions neither the amended KSC act nor the AI Act, yet is still presented as being in force.
6. No communication. The policy exists, but staff do not know about it. An auditor checks this in the simplest way available: by asking randomly chosen people where to find the document and whom to notify about an incident.
7. No consequences. If nothing happens after a rule is broken, the document loses its force regardless of what it says - and the team will notice that before the auditor does.

Auditing the policy

An audit of the policy alone, separately from the whole management system, is short - in our practice one to three days of work in a small local authority and four to eight in a mid-sized organisation. Seven things are checked.

First, completeness: whether the document contains everything clause 5.2 requires. Second, currency: when the last review took place and whether changes in legislation were taken into account. Third, the mapping to regulations - whether the matrix exists and is up to date.

Fourth, internal consistency - whether the rules contradict one another, for instance whether a declared principle of least privilege can be reconciled with permitting shared accounts. Fifth, downward consistency: whether the topic-specific policies actually implement what the top-level document declares, or merely exist alongside it.

Sixth, communication, tested on a sample of employees. And seventh, management awareness - whether the person who signed the document knows its content and their own role in it. That last point is often decisive, because a policy signed without being understood will not survive the first situation in which it has to be applied against convenience.

A broader review covering the whole management system is described in the article on IT security audits.