ISO 27001:2022 in 2026: the ISMS, the 93 Annex A controls and certification

What ISO 27001 is: history and status

The full title is Information security, cybersecurity and privacy protection - Information security management systems - Requirements ^[1]. The last word matters most: this is a requirements standard rather than a guidance one, so every provision in it is verifiable during an audit.

The standard grew from the British BS 7799, published in 1995. Its first part reached ISO in 2000 as ISO/IEC 17799, and in 2005 the first edition numbered 27001 appeared. The 2013 edition established the shape most organisations know: 114 controls in fourteen categories. The present edition, from 2022, rebuilt Annex A and added attributes.

Several characteristics are worth setting straight, because they are often confused. It is international, developed jointly by ISO and IEC. It is voluntary - no Polish rule mandates either its application or certification. It is certifiable, unlike most of the 27000 series, which contain guidance. And it uses the harmonised structure common to all management system standards, which allows it to be integrated with ISO 9001, ISO 22301 or ISO/IEC 42001 without building a second parallel system.

Why organisations implement it

The commonest reason is an external requirement. In some tenders and business-to-business contracts the absence of a certificate disqualifies a bid at the formal stage, regardless of the actual level of security.

The second is evidential convenience before regulators. The Polish KRI regulation, in § 19(3), grants a presumption of compliance to a management system based on PN-ISO/IEC 27001 - the only place in Polish law where the standard has that effect. Beware of a common shortcut: neither the KSC act nor the NIS2 directive contains a similar provision. An implemented standard is strong evidential material during an inspection there, but it discharges no obligation.

The third reason is the process itself. The asset inventory, risk analysis and assignment of responsibility that the standard forces usually reveal things the organisation did not know - and that holds regardless of whether a certificate appears at the end.

Changes in the 2022 edition

The 2022 edition did not materially change the management requirements in clauses 4 to 10. The whole change concerns Annex A.

Previously it held 114 controls grouped thematically into fourteen categories from A.5 to A.18: access control separately, cryptography separately, physical security separately. Now there are 93 controls in four groups: organisational (37), people (8), physical (14) and technological (34). The basis of the division changed from subject matter to who or what delivers the control.

The drop from 114 to 93 does not mean anything was abandoned - no control disappeared; some were merged and some reworded.

Eleven new controls

The new items answer changes between 2013 and 2022: A.5.7 threat intelligence, A.5.23 security in the use of cloud services, A.5.30 ICT readiness for business continuity, A.7.4 physical security monitoring, A.8.9 configuration management, A.8.10 information deletion, A.8.11 data masking, A.8.12 data leakage prevention, A.8.16 monitoring activities, A.8.23 web filtering and A.8.28 secure coding.

Four of them - threat intelligence, monitoring activities, leakage prevention and secure coding - are the most often skipped in audits, because they require a working process rather than a document.

Control attributes

Every control now carries attributes across five dimensions: type (preventive, detective, corrective), the information property protected, the function in the sense of the NIST CSF ^[15], the operational capability and the security domain. Attributes are not mandatory, but they make filtering the catalogue and reporting coverage easier. The detail is in ISO/IEC 27002 ^[3].

Migration from the 2013 edition

The International Accreditation Forum determined that certification against the 2022 edition became possible on 31 October 2022, and that certificates based on the 2013 edition ceased to be valid on 31 October 2025. Migration usually happened alongside a surveillance or recertification audit, so for most organisations it did not mean a separate exercise.

The 2024 amendment on climate

In February 2024 ISO introduced the same change into several dozen management system standards at once, designated in ISO/IEC 27001 as ISO/IEC 27001:2022/Amd 1:2024 ^[1]. It concerns clauses 4.1 and 4.2: the organisation is to consider whether climate change is relevant to its context, and interested parties may raise related requirements.

It is a change of small implementation weight but it is auditable. In practice it comes down to adding one considered question with its reasoning to the context analysis - including where the conclusion is that climate change is not a relevant factor for that organisation. The absence of any trace of that analysis is a nonconformity, if a minor one. The Polish equivalent appeared as PN-EN ISO/IEC 27001:2023-08/A1:2025-02. The standard itself remains the 2022 edition and holds published status in the ISO catalogue, so no further migration is in prospect.

The structure of the standard: ten clauses

The standard uses the layout common to all management system standards. The first three clauses are informative: scope, normative references, and terms and definitions, the last of which refers to ISO/IEC 27000 ^[9]. Clauses four to ten are audited, and it is those that contain the requirements.

Clause 4, context of the organisation, requires understanding internal and external circumstances, identifying interested parties and their expectations and - most important in practice - setting the scope of the system. Scope is often the source of the greatest later trouble: too wide raises the audit cost, too narrow means the certificate does not cover what clients ask about.

Clause 5, leadership, requires top management commitment, an approved information security policy and unambiguous assignment of roles and authorities. It is the clause where nonconformities most often appear in organisations that treat the system as an IT department project.

Clause 6, planning, is the core of the system. It covers actions to address risks and opportunities, information security risk assessment (6.1.2), risk treatment (6.1.3), security objectives (6.2) and planning of changes (6.3). Hidden in point 6.1.3(d) is the requirement to produce a statement of applicability, discussed below.

Clause 7, support, concerns resources, competence, awareness, communication and documented information. Clause 8, operation, requires planning and control of operational activity and repetition of the risk assessment and implementation of the treatment plan.

Clause 9, performance evaluation, covers monitoring and measurement - guidance on which comes from ISO/IEC 27004 ^[11] - internal audit and management review. The standard requires these at planned intervals and gives no specific frequency; in practice certification bodies expect an annual cycle. How to run an internal audit is set out in ISO 19011 ^[17], and its information-security-specific version in ISO/IEC 27007 ^[12].

Clause 10, improvement, requires continual improvement and the handling of nonconformities and corrective actions.

The PDCA cycle in practice

Clauses 4 to 10 arrange themselves into a cycle of planning, doing, checking and acting. That is not methodological decoration but the answer to why the system does not end when the certificate is issued.

In the plan phase the scope, policy, risk assessment, risk treatment plan and objectives are produced, and resources and competence are assigned. In the do phase the risk treatment plan, operating procedures, the Annex A controls and training are implemented. The check phase is monitoring and measurement, internal audit and management review. The act phase covers improvement and corrective action for the nonconformities found.

The last arrow is the crucial one: every corrective action returns to planning and brings an update of the risk assessment, the policies or the statement of applicability. A system in which that return never happens stops matching reality within a year, even though formally it still exists.

Annex A: 93 controls

Annex A is the most discussed part of the standard and simultaneously the most misunderstood. It contains 93 controls, each described in a single sentence. It is not a mandatory list - it serves to check that nothing was overlooked during risk treatment. Detailed implementation guidance is in ISO/IEC 27002 ^[3].

Group A.5, organisational, holds 37 controls and covers policies and roles, asset management and information classification, access control and identity management, supplier relationships, incident handling - for which ISO/IEC 27035-1 ^[13] gives guidance - business continuity and compliance with legal requirements. The last item, A.5.34, concerns protection of personal data and is the natural point of contact with the GDPR and with ISO/IEC 27701 ^[14].

Group A.6, people, holds 8 controls and covers the whole employment cycle: candidate screening, contractual terms, training, disciplinary process, duties after the relationship ends, confidentiality agreements, remote work and event reporting.

Group A.7, physical, holds 14 controls on security perimeters and entry control, the environmental resilience of premises, clear desk and clear screen rules, and protection of equipment and media, including off site.

Group A.8, technological, holds 34 controls and is closest to the daily work of IT teams: endpoints and privileged accounts, malware protection and vulnerability management, backups and redundancy, logging and monitoring, cryptography, network security and the whole software development lifecycle.

The statement of applicability

The statement of applicability is the only document whose content the standard requires outright (6.1.3(d)). For each of the 93 controls it has to state whether the control applies, justify that decision, describe how it is implemented and refer to the evidence.

The commonest mistake is marking all 93 items as applicable, to avoid explaining exclusions. The effect is the opposite of the one intended: the organisation declares controls it does not have, and those are exactly the ones the auditor checks.

Exclusion is permitted and normal, provided it follows from risk analysis or from context rather than from inconvenience. An organisation with no server room of its own will reasonably exclude some physical controls, noting that the provider delivers them; an organisation that does not develop software will exclude the development lifecycle controls. Justifications along the lines of "expensive" or "awkward" do not pass.

The statement is a living document - it is updated after every significant change of scope, after a new risk analysis and after an audit. It is also sometimes shared with counterparties, which is why many organisations maintain an abbreviated version without configuration detail.

Certification in a three-year cycle

The certificate is issued for three years, but that does not mean three years without contact with the certification body.

The certification audit has two stages. The first is a documentation review: the policy, the statement of applicability, the risk analysis, the treatment plan and the reports from internal audit and management review. It ends with a readiness assessment and a list of things to fix. The second, usually one to three months later, verifies actual implementation: conversations with staff, sampling of evidence, examination of clauses 4 to 10 and of the controls declared as applied.

In the first and second years after certification come surveillance audits, shorter and sample-based. They check that the system is maintained and improved and that corrective actions were carried out. After three years comes recertification covering the whole system and ending with a certificate for the next period.

Nonconformities fall into three categories. A major one is a serious departure and holds up issue of the certificate until it is fixed, usually confirmed by an additional audit. A minor one requires a corrective action plan with a deadline and does not block the certificate. An observation is a suggestion for improvement and does not affect the outcome.

Choosing a certification body

Certificates are issued by bodies meeting PN-EN ISO/IEC 17021-1 ^[7]. In Poland accreditation is granted by the Polish Centre for Accreditation ^[8], and its recognition abroad follows from multilateral agreements at European and international level.

The first question when choosing is therefore whether the body is accredited for ISO/IEC 27001. Accreditation alone is not enough, because it covers specific scopes - the accreditation body maintains the current list, and it is that list, rather than marketing material, that is worth checking.

Beyond that, three practical things matter. Whether the certificate is recognised by the people it is being obtained for - if a particular foreign client requires it, ask outright which bodies they honour. The auditors' experience in the sector, because an auditor who understands the industry asks more sensible questions. And availability of dates, which towards the end of the year becomes a real constraint.

Price varies between bodies and it is worth gathering several offers, but compare the number of person-days rather than the sum - proposals can assume different effort for the same scope.

Implementation and certification costs

The ranges below come from our implementation practice and from negotiations with certification bodies in Poland. They are not a price list or the result of market research - treat them as an order of magnitude for an initial budget.

The cost falls into three parts. Implementation, meaning consulting and preparing documentation, usually runs PLN 30,000 to 80,000 in a small organisation of up to fifty people, PLN 80,000 to 250,000 in a mid-sized one, and upwards of PLN 250,000 in a large one. The audit is usually PLN 15,000 to 50,000 for both stages, PLN 10,000 to 30,000 for each surveillance audit and PLN 15,000 to 40,000 for recertification.

The third item is often the largest and the most often left out of the budget. If the organisation has no multi-factor authentication, no endpoint protection, no event monitoring and no working backup process, the cost of the tools and services themselves is added - with our clients usually in the order of PLN 100,000 to 500,000. It is worth noting, though, that this is spending on security rather than on a certificate: an organisation that plans no certification will incur it just the same.

For a mid-sized organisation with no prior implementation, the first year usually closes in the range of PLN 200,000 to 500,000, and maintenance in later years at PLN 50,000 to 100,000 a year.

On the benefit side, the easiest to point to is access to procedures where the certificate is a formal condition - there the arithmetic is simple and unambiguous. The certificate also shortens supplier assessment by corporate clients and due diligence in transactions. An effect on cyber insurance premiums is often mentioned, but it depends on the offer and the risk profile enough that no single figure describes it.

The rest of the 27000 series

ISO/IEC 27001 is the only standard in the series that is certified. The others contain guidance and supplement it in specific areas.

ISO/IEC 27002:2022 ^[3] expands every Annex A control into a full implementation guide. Without it what remains is a one-sentence description, from which little can be designed.

ISO/IEC 27005:2022 ^[4] structures information security risk management, which is what clause 6.1.2 requires. ISO/IEC 27003 ^[10] gives guidance on implementation itself.

Two standards address the cloud. ISO/IEC 27017:2026 ^[5] supplements the controls with matters specific to cloud services, including the split of responsibility between provider and customer. ISO/IEC 27018:2025 ^[6] concerns protection of personal data in public clouds and is addressed above all to providers acting as processors.

It is also worth knowing ISO/IEC 27701:2025 ^[14], which since the 2025 edition is a standalone standard - certifying a privacy information management system no longer requires holding an ISO/IEC 27001 certificate.

Relationships with legislation and other models

An ISO 27001 certificate replaces no legal obligation, but it makes demonstrating one considerably easier. It is worth understanding exactly where that line runs.

The Polish KSC act ^[16] requires essential and important entities to implement an information security management system (article 8(1)), but it refers to no standard and provides no presumption of conformity based on a certificate. An implemented ISO 27001 therefore discharges nothing - but it is very good evidential material during an article 15 audit, because it covers most of the areas listed in article 8(1)(2). See the KSC article and the NIS2 article.

The KRI regulation works differently and is the only Polish instrument that gives the standard legal effect: § 19(3) treats the requirements as met where the system is based on PN-ISO/IEC 27001, controls are established under PN-ISO/IEC 27002 and risk is managed under PN-ISO/IEC 27005.

For the GDPR, the technical and organisational measures of article 32 overlap substantially with Annex A, but the standard does not cover the purely legal obligations: the bases for processing, handling data subject requests, or the records of processing activities. Nor is the certificate a certification within the meaning of article 42 of the GDPR.

Against DORA the standard is useful as documentary groundwork for the ICT risk management requirements, but it does not cover the register of contracts with providers, incident reporting or threat-led testing.

Among models that are not regulation, the standard is most often set against the NIST CSF ^[15], which works at a higher level of generality and lends itself better to a conversation with the board, and against NIST SP 800-53, a far larger control catalogue. Both map onto Annex A and neither replaces it.

The commonest implementation mistakes

The problems below appear in audits regardless of the size of the organisation or the industry.

1. Scope chosen for the convenience of the audit. A narrow scope lowers the cost, but a certificate covering one department will not answer a client's question about the security of the service they are buying.
2. All 93 controls marked as applicable. The statement of applicability then becomes a list of commitments the organisation does not meet, and those are exactly what the auditor checks.
3. Risk analysis written to a predetermined conclusion. A register in which every risk comes out acceptable given the current controls is not an analysis but a justification of the status quo.
4. The system as an IT department project. Without management involvement clause 5 stays unmet, and management review comes down to a signature on a document somebody else prepared.
5. Internal audit conducted by the person responsible for the area audited. A breach of independence that an external auditor catches almost every time.
6. Documentation current only before the audit. A cyclical documentation push a month before the auditor's visit is easy to spot from file modification dates.
7. Skipping the controls added in 2022. Threat intelligence, monitoring activities, leakage prevention and secure coding require a process, not a line in a policy.
8. The certificate as an end in itself. A system built purely for the audit stops working the week after it ends, and at the first incident turns out to be unknown to the people meant to operate it.