The ISMS in 2026 - information security management without the paralysis

The system, the top-level policy and topic-specific policies

Three terms are often used interchangeably although they denote things of different orders, and confusing them is the source of most misunderstandings in a conversation with an auditor.

The management system covers everything: documents, processes, people, technology and the improvement cycle that ties it together. The information security policy is one document within that system - the highest, declarative, signed by management. Topic-specific policies sit a level below and address particular areas: access control, cryptography, backups, incident handling.

Below those come procedures describing how an activity is performed, and instructions with concrete steps. Separately there are registers and records, which are the only evidence that the rest actually works. The top-level document is covered in more depth in the article on the information security policy.

The practical consequence of this hierarchy is simple: a system without records is a description of intent, not a statement of fact. An audit starts with documents but is decided on records.

What the 2022 edition changed

The 2022 edition replaced the 2013 one after nine years, but the change concerns almost exclusively Annex A. The management requirements in clauses 4 to 10 remained essentially the same.

Annex A moved from a thematic arrangement - 114 controls in fourteen categories - to an arrangement by who implements them: 93 controls in four groups. There are 37 organisational, 8 people, 14 physical and 34 technological controls. The number fell because some items were merged, not because anything was dropped.

Eleven new controls were added, of which four usually require the most work: threat intelligence (A.5.7), configuration management (A.8.9), data masking (A.8.11) and monitoring activities (A.8.16). Each of them presupposes a process that no entry in a policy can substitute for.

The third novelty is the set of attributes assigned to every control across five dimensions. They make the catalogue easier to filter and to map onto other models, including the NIST CSF and CIS Controls. The attributes are described in detail in ISO/IEC 27002 ^[5].

The transition period for certificates based on the 2013 edition ended on 31 October 2025, so every certificate valid today relates to the 2022 edition.

The annual improvement cycle

The standard rests on a cycle of planning, doing, checking and acting, and the clauses correspond to its successive phases. In a typical organisation the cycle runs twelve months.

In the planning phase, covering clauses 4 to 7, the context of the organisation and the interested parties are established, the scope of the system is set, the policy approved, roles assigned, the risk assessment carried out and the risk treatment plan built. In the doing phase, clause 8, the plan is implemented and the risk assessment repeated after significant changes.

The checking phase is clause 9: monitoring and measurement - guidance for which is given in ISO/IEC 27004 ^[4] - internal audit and management review. The acting phase, clause 10, covers the handling of nonconformities and improvement.

The cycle only makes sense once it is closed. The next year should begin with the results of the last one: what worked, what did not, which risks changed character. A system in which every cycle starts from zero is in substance an annual documentation project.

Annex A and the statement of applicability

Annex A lists 93 controls in a single sentence each. The guidance on how to implement them is in ISO/IEC 27002 ^[5].

The organisational group is the largest and covers policies and roles, information classification, identity and access management, supplier relationships, incident handling, business continuity and compliance with legal requirements. The people group deals with the whole employment lifecycle, from candidate screening to obligations that survive departure; training belongs here, and is covered in the article on security awareness. The physical group covers zones, entry control, environmental resilience and the protection of equipment. The technological group is the closest to the daily work of IT teams: endpoints, entitlements, cryptography, backups, logging and monitoring, network security and the software development lifecycle.

The key document is the statement of applicability. For each of the 93 controls it states whether it applies and justifies that decision. A certification audit begins there, because it determines what the auditor will look for afterwards. A statement in which everything is marked as applicable therefore does not simplify the audit; it enlarges it.

Certification or conformity alone

Implementing the system and obtaining a certificate are two different decisions, and they are worth taking separately.

Conformity without certification means building the system to the standard and checking it by internal or external audit, but without an accredited certification body. It is considerably cheaper and is enough wherever nobody demands the paper.

Certification adds a two-stage audit - first documentation, then verification of actual implementation - a certificate valid for three years, and surveillance audits in the first and second years.

Which route to take depends mainly on who is asking. In the public sector conformity is usually enough: the KRI regulation ^[2] does not require the system to be based on ISO/IEC 27001, still less to be certified. § 19(3) works differently: if the system was developed on the basis of PN-ISO/IEC 27001, with controls established under PN-ISO/IEC 27002 and risk managed under PN-ISO/IEC 27005, the requirements of the regulation are treated as met. That is a presumption of conformity, an evidentiary convenience, not an obligation.

For essential and important entities under the Polish KSC act, which transposes the NIS2 directive ^[3], certification is likewise not compulsory. For essential entities it can be useful evidence during the periodic article 15 audit; important entities do not have that general periodic audit duty, although certification can still support evidence in supervision. In commercial relationships the customer usually decides: in sales to large organisations, particularly in financial services and healthcare, a certificate is often a formal condition, and among software-as-a-service providers it is effectively standard.

The cost of certification for an organisation of fifty to a hundred people runs, in our experience, from PLN 30,000 to 80,000 for the first audit and from PLN 15,000 to 30,000 a year for surveillance audits. These are ranges from our own projects, not a price list.

What it costs in hours

The claim that an ISMS consumes most of the administrative capacity is not borne out in our projects - provided the documentation is not being used in place of a process.

Guidance on implementation itself is given in ISO/IEC 27003 ^[7]. A first implementation, from nothing to a working system, usually takes six to twelve months and absorbs 200 to 500 hours of internal effort plus 80 to 200 consultant hours. Maintenance in later years, in a mid-sized local authority, runs to 8 to 20 hours a month for the coordinating person, plus periodic audits, reviews and training. The distribution is very uneven - most of the effort falls in the period just before and just after an audit.

On the benefit side, the easiest to point to are those observable without a study. The system reduces the likelihood of events whose cause is the absence of a process: the backup that was not taken, the entitlement not revoked when someone left, the update nobody remembered. It does not stop an attack, but it removes the reasons attacks succeed.

The system's documentation is also evidence in the event of an incident - both towards the data protection authority and towards the competent cybersecurity authority. It eases sales to customers who assess their suppliers, and the conversation with an insurer, because the risk questionnaire asks precisely about what the system documents. The effect on the premium itself, however, depends on the offer and the risk profile too much to be reduced to a single figure.

The most common mistakes

Six patterns that recur regardless of the size of the organisation.

1. The system reduced to documentation. The simplest test is to ask a randomly chosen employee which information is confidential in this organisation. If they do not know, the classification exists only in a file.
2. No owner. Without a person who has the system in their job description, nobody maintains it. In smaller organisations the role usually falls to the data protection officer or a department head, but it has to be named explicitly.
3. A statement of applicability with no justifications. Controls marked in or out with no reason given. It is the first thing an auditor checks and the first thing they stop at.
4. No metrics. Clause 9.1 requires monitoring, measurement, analysis and evaluation. Without indicators - the number of incidents, response time, training coverage, the proportion of systems matching a baseline - there is nothing to evaluate. Guidance is given in ISO/IEC 27004 ^[4].
5. An internal audit run by the head of the area being audited. A breach of the independence principle set out in ISO 19011 ^[6] and, for information security management systems, refined in ISO/IEC 27007 ^[8]. In smaller organisations the answer is often an auditor from another unit, or a reciprocal exchange of auditors.
6. A management review reduced to a signature. Clause 9.3 requires a review involving top management whose output is decisions and a plan, not a presentation merely noted.

Where things are heading

Three developments are changing how a system is run today.

Integration of management systems. The common structure of the standards makes it possible to combine information security, privacy under ISO/IEC 27701 and business continuity under ISO 22301 into one set of documents with a combined audit. The saving is mainly in management time, because the review happens once instead of three times.

Compliance management tooling. Software that collects evidence automatically and monitors conformity continuously replaces part of the manual work. It is worth remembering, though, that a tool gathers evidence that a control exists, not that it is effective - that still requires human judgement.

Language models in documentation work. Drafting a first version of a policy, an initial gap analysis or a set of audit questions are tasks where such tools genuinely shorten the work. The output needs verification, however: a document describing processes that do not exist is worse than no document, because it creates a false picture of conformity.