ISMS in 2026 - KSC and KRI obligations versus voluntary ISO/IEC 27001

System, policy, and documentation

A management system, a security policy, and documentation should not be treated as synonyms. A management system includes people, roles, processes, resources, technology, documentation, and mechanisms for evaluation and improvement. The information security policy is the high-level document that sets direction and records management's commitments. Topic-specific policies develop those principles for particular areas.

In an ISO/IEC 27001-conformant system, establishing an information security policy is part of the standard's requirements ^[1]. KSC works differently: Article 8 requires, among other things, policies for risk assessment and information-system security, including topic-specific policies, but it does not impose a single official documentation template ^[13].

Topic-specific policies may cover access control, cryptography, backups, business continuity, remote work, supplier security, vulnerability management, or incident handling. A procedure describes how a process is carried out, an instruction describes how a particular task is performed, and a register or record captures the result. A high-level policy should set durable rules, while technical details should live in documents that can be updated without rewriting the entire policy. This topic is discussed in more detail in 4crypto's material on the Information Security Policy.

Signed documents are not the only evidence that an ISMS is operating. An auditor may also examine technical configurations, logs, incident tickets, samples of assigned privileges, vulnerability-scan results, recovery-test results, security-test reports, review minutes, and staff interviews. An IT security audit, vulnerability scanning, penetration testing, or a hardening review can provide important technical evidence, but none of them replaces an assessment of the management system as a whole.

ISO/IEC 27001:2022 - what actually changed from the 2013 edition

ISO/IEC 27001:2022 replaced the 2013 edition ^[1]. The most visible change is the structure of the reference set of controls in Annex A. The current edition contains 93 controls grouped into four themes: organizational, people, physical, and technological. Official material from ISO/IEC JTC 1/SC 27 gives the corresponding counts as 37, 8, 14, and 34 ^[3][4]. The 2013 edition organized the set differently and contained 114 entries.

The numbers alone do not show that the level of requirements has fallen. Some earlier controls were merged, reorganized, or described differently. The 2022 edition gives greater visibility to topics including threat intelligence, cloud services, configuration management, data masking, and monitoring activities ^[3][4]. ISO/IEC 27002:2022 provides guidance on information security controls and their use ^[3].

In 2024, ISO also published Amendment 1 to ISO/IEC 27001:2022, addressing climate-change considerations in the analysis of organizational context ^[2]. This does not turn an ISMS into a technical weather-response system. The point is to assess whether climate-related issues are relevant to the organization's context and the expectations of interested parties, just as other factors may affect the management system.

In practice, the number of entries in Annex A matters less than the consistency between scope, risk assessment, risk-treatment decisions, implemented controls, and evidence that those controls operate as intended.

A continuous management cycle, not an annual paperwork exercise

An ISMS should operate continuously. The organization plans the system, implements measures, monitors their operation, performs assessments and audits, responds to nonconformities, and makes improvements. A twelve-month calendar may be administratively convenient, but it does not mean that every activity should happen exactly once a year.

Frequency should follow the nature of the activity, the risk, relevant changes, and applicable legal requirements. A user's access should be revoked when the need for access ends, not at the next annual review. A critical vulnerability requires a response proportionate to the risk, not a wait for the next audit. The frequency of backup-recovery testing should reflect the importance of the system and the organization's continuity objectives.

Law may impose its own deadlines. The KRI regulation currently in force requires a periodic internal information-security audit at least once a year ^[11]. KSC requires training once per calendar year for the head of an essential or important entity and for the person entrusted with that head's cybersecurity responsibilities ^[13]. The statutory audit under Article 15 KSC, by contrast, applies to essential entities and must be performed at least once every three years, calculated from the previous audit ^[13]. These are three different mechanisms and should not be collapsed into a single calendar entry.

ISO/IEC 27004:2016 provides supplementary guidance for measurement ^[6]. It is worth noting that, as of 24 August 2026, this edition remains published, but ISO is working on its successor, and the current version was developed with reference to ISO/IEC 27001:2013 ^[6]. This is a useful example of why implementers should check not only a standard's number, but also its status and its relationship to the current edition of the base standard.

Annex A and the Statement of Applicability

Annex A of ISO/IEC 27001 contains a reference set of controls. It is not a checklist that must be mechanically marked complete in its entirety. The starting point remains the organization's risks, legal obligations, contractual and business requirements, and actual needs. ISO/IEC 27002:2022 helps interpret and implement controls ^[3], while ISO/IEC 27005:2022 provides guidance on managing information security risks ^[5].

If an organization claims that its ISMS conforms to ISO/IEC 27001, it prepares a Statement of Applicability (SoA). The document links control decisions to the risk-treatment process and shows which controls are applied and how decisions concerning the reference set were justified ^[1]. The SoA should not, however, be treated as a standalone KSC or KRI requirement. If an organization has not adopted ISO/IEC 27001 as the model for demonstrating conformity, those legal regimes do not create a separate duty to maintain a document called a Statement of Applicability.

Outsourcing does not remove a subject from the ISMS scope. If backups, email, monitoring, cloud infrastructure, or incident handling are provided by a third party, the implementation method and allocation of responsibilities change. The organization still needs to understand the risk, contractual requirements, responsibility model, oversight arrangements, and evidence of service delivery. An internal or outsourced 24/7 SOC can provide important evidence for monitoring and incident handling, but using a SOC does not by itself establish conformity of the entire ISMS.

KRI in 2026 - an ISMS obligation without a mandatory ISO certificate

As of 24 August 2026, the Regulation of the Council of Ministers of 21 May 2024 on the National Interoperability Framework (KRI) remains in force ^[11]. Section 19(1) requires an entity performing public tasks to develop, establish, implement and operate, monitor and review, maintain and improve an information security management system.

Section 19(2) lists actions that management must ensure. These include updating internal regulations, maintaining inventories of hardware and software, risk analysis, privilege management, training, information protection, the security of remote and mobile work, requirements for service and maintenance contracts, software updates, vulnerability management, incident reporting, and a periodic internal audit at least once a year ^[11].

Section 19(3) establishes an important mechanism. The requirements of paragraphs 1 and 2 are deemed satisfied if the ISMS has been developed on the basis of PN-ISO/IEC 27001 and if the establishment of controls and the management of risk are based on the specified Polish Standards related to that standard, including PN-ISO/IEC 27002 and PN-ISO/IEC 27005 ^[11]. This is not a requirement to obtain ISO/IEC 27001 certification. It is a legal route for demonstrating compliance with KRI through a defined normative model.

An organization can therefore comply with KRI without holding an ISO/IEC 27001 certificate. It must, however, actually implement the regulation's requirements and be able to demonstrate that implementation. In practice, a KRI audit should use the regulation itself as the audit criterion, even if the organization also maintains an ISO/IEC 27001-conformant system.

There is an important qualification for 2027. ELI indicates that the current KRI regulation will cease to have effect on 23 February 2027 ^[11]. In July 2026, a draft replacement KRI regulation, identified as RD313, was published ^[12]. At the reference date of this article, it is a draft, not binding law. The description of Section 19 of the 2024 regulation should therefore not be carried over automatically to the legal position after 23 February 2027.

KSC after 3 April 2026 - the ISMS as an obligation for essential and important entities

The KSC amendment implementing NIS2 entered into force on 3 April 2026 ^[14][15]. The current consolidated text of the KSC Act prepared by the Chancellery of the Sejm as of 18 August 2026 incorporates Journal of Laws 2026 items 20, 252, 815, and 1003 ^[13]. This matters when using earlier commentary that stopped at the amendment published as item 252.

Article 8(1) KSC requires an essential or important entity to implement an ISMS in the information system used in processes that affect the provision of its service ^[13]. The Act links that system to systematic risk assessment and to appropriate and proportionate technical and organizational measures.

The statutory list is extensive. It includes, among other things, security in the acquisition, development, and maintenance lifecycle of systems; physical and human-resources security; supply-chain security; business continuity and recovery; continuous monitoring of the information system; evaluation of control effectiveness; education and cyber hygiene; cryptography; secure communications; multi-factor authentication where appropriate; asset management; access control; information about cyber threats and vulnerabilities; incident management; and software updates ^[13].

This shows the difference between having a policy and meeting KSC requirements. Documentation must correspond to real organizational and technical measures. If, for example, a policy requires continuous monitoring but critical systems do not generate suitable logs, or nobody reviews the alerts, the problem is not editorial. It is a gap in how the system operates.

KSC also contains special provisions. An important entity that is a public entity, as well as certain higher-education entities identified in Article 8(3), do not apply Article 8(1) in its ordinary form; instead, they operate an ISMS that meets the requirements of Annex 4 ^[13]. A public entity should also include within its ISMS an information system supplied by another public entity to the extent required by that system's security policy or by the rules governing its operation ^[13].

Additional requirements may follow directly from EU law. Article 8b KSC identifies, among others, providers of DNS services, cloud computing services, data-centre services, content delivery networks, managed services, and managed security services that apply the cybersecurity risk-management measures specified in Commission Implementing Regulation (EU) 2024/2690 ^[13][16]. For those entities, a simple mapping from ISO/IEC 27001 to KSC is not enough, because the detailed EU requirements must also be taken into account.

Management responsibility under KSC

KSC expressly assigns responsibility to the head of an essential or important entity. Article 8c provides that responsibility remains with the head even if some or all duties have been delegated to another person ^[13]. Article 8d links the head, among other things, to decisions concerning the preparation, implementation, operation, review, and oversight of the ISMS, financial planning, and task allocation ^[13].

That has a practical consequence: an external consultant, administrator, security coordinator, or SOC provider may perform part of the operational work, but cannot take over the head's KSC responsibility. Likewise, the whole ISMS should not automatically be assigned to the data protection officer. The GDPR allows a DPO to perform other tasks, but the controller or processor must ensure that those tasks do not create a conflict of interests ^[18].

KSC also requires annual training for the head and for the person entrusted with the head's cybersecurity responsibilities, and participation must be documented ^[13]. Staff training and security awareness are a separate issue. They should follow from risk and the employee's role, rather than being reduced to a one-time signature on an attendance sheet.

KSC deadlines for entities covered by the 2026 reform

For entities that already met the criteria for classification as essential or important on 3 April 2026, Article 33 of the amending Act provides twelve months to implement the obligations in Chapter 3 KSC ^[14]. This results in a deadline of 3 April 2027.

Entities that met the criteria for classification as essential entities on the date the amendment entered into force have 24 months to complete their first audit under Article 15(1) KSC, meaning by 3 April 2028 ^[14]. The transitional provisions, however, contain rules for entities that were previously operators of essential services, so the entity's former status and audit history must be taken into account in a concrete case.

If an entity meets the criteria only later, the deadlines are calculated under the mechanism provided by KSC itself. Article 16 provides twelve months to implement the Chapter 3 obligations and, for an essential entity, 24 months to complete the first audit, calculated from the date on which the criteria are met ^[13].

For that reason, 3 April 2027 should not be treated as a universal deadline for every organization that may ever fall within the scope of KSC.

KSC audit, KRI audit, and ISO audit are different assessments

A common mistake is to use the word audit without identifying the criteria. A KRI audit examines the requirements of the relevant regulation. The statutory KSC audit under Article 15 has its own legal basis, scope, frequency, and requirements for auditors ^[13]. An internal audit of an ISO/IEC 27001-conformant system evaluates conformity and effectiveness against the criteria defined in the organization's audit programme ^[1][8].

Article 15(2a) KSC additionally prevents the statutory audit from being performed by a person who performs tasks under Article 8 and Articles 9-13 in the audited entity, or who performed those tasks during the year before the audit began ^[13]. That is a more specific restriction than the general principle of objectivity in a management-system audit.

For management-system audit programmes, the current general standard is ISO 19011:2026, published in May 2026 and replacing the 2018 edition ^[7]. ISO/IEC 27007:2020 provides additional guidance for auditing information security management systems ^[8]. As of 24 August 2026, ISO/IEC 27007:2020 remains published but is under revision ^[8].

When an organization commissions an external KRI audit, KSC and NIS2 audit, or IT security audit, the contract and the report should therefore identify the audit criteria. The service name alone should not leave doubt about whether the assessment covers legal requirements, a standard, the technical state of the infrastructure, or all of these in clearly separated scopes.

Conformity with ISO/IEC 27001 and certification

A legal obligation, conformity with a standard, and certification are separate concepts. The Polish Act on Standardization states that the use of Polish Standards is voluntary ^[17]. An organization may therefore implement an ISO/IEC 27001-based ISMS by choice, because of a customer or contractual requirement, to structure management, or with certification in mind.

Conformity without certification means that the organization has implemented the requirements and evaluates the system, but does not hold a certification decision issued by an external certification body. Certification is a separate conformity-assessment process. Accreditation concerns the competence of the conformity-assessment body, not the organization implementing the ISMS.

Neither Section 19 KRI nor Article 8 KSC establishes a general obligation to hold an ISO/IEC 27001 certificate ^[11][13]. A certificate may, however, become a requirement of a particular contract or procurement procedure. In that case, its significance follows from that specific obligation, not from the mere existence of the standard.

A certificate should also not be treated as automatic proof that every KSC or KRI obligation has been fulfilled. The scope of the certified ISMS may differ from the scope of systems covered by law. The law may also require actions that the standard does not formulate in the same way, such as statutory incident reporting, a specific KSC audit, or duties connected with the statutory list of entities.

Implementation effort for an ISMS

There is no credible universal formula such as one week per 50 employees. Headcount affects the project, but it is often not the most important variable. A small company may operate several cloud environments, its own software, a complex supply chain, and a 24/7 service. A large organization may have a comparatively simple architecture and mature processes.

The effort depends primarily on the ISMS scope, number of services and locations, system architecture, supplier dependencies, legal and contractual requirements, quality of the asset inventory, maturity of risk management, state of the documentation, and availability of process owners.

As of 24 August 2026, ISO/IEC 27003:2017 remains a published standard providing implementation guidance, but its official description relates it to ISO/IEC 27001:2013 and ISO is revising it ^[9]. It can therefore remain useful as methodological material, but it should not be presented without qualification as the current guide to every detail of an ISO/IEC 27001:2022 implementation.

For implementation projects, a sensible order is legal qualification and scope definition first, then gap analysis, and only then scheduling and pricing. This separates work required by law from voluntary certification objectives. External ISMS support can structure the methodology and provide an independent perspective, but it cannot replace management decisions or the knowledge held by process owners.

Connecting organizational requirements to technology

An ISMS should not end at the policy level. An access-management requirement should translate into processes for creating, modifying, and disabling accounts, as well as periodic privilege reviews. A vulnerability-management requirement should lead to defined sources of vulnerability information, a process for assessment and prioritization, remediation, and verification. A business-continuity requirement should connect to real backups, recovery objectives, and testing.

The same applies to monitoring. Centralized log collection is not an end in itself. The organization needs to decide which events matter, which sources should be monitored, which alerts require a response, who responds, and how evidence is retained. A 24/7 SOC service may perform part of this operational function, but it must fit into the organization's incident procedures and responsibility model.

Vulnerability scanning and penetration testing also serve different purposes. Scanning helps systematically identify defined classes of known issues. A penetration test examines whether selected weaknesses can be exploited in a defined scenario and what the consequences may be. Hardening reduces attack surface through more secure configuration. None of these mechanisms, by itself, provides compliance. Each can, however, form part of risk treatment and provide evidence about the effectiveness of specific measures.

Common mistakes

1. Reducing the system to documentation. If an employee does not know how to classify information, an administrator does not know the vulnerability-handling process, and a system owner cannot explain which risk was accepted, signed policies do not prove that a process has been implemented. At most, they show that someone declared that the process should exist.
2. Unclear responsibility. Management should identify owners for processes, risks, and controls, and define their decision-making authority. Under KSC, the responsibility of the entity's head is additionally and expressly regulated by statute ^[13].
3. Mixing assessment criteria. KSC, KRI, and ISO/IEC 27001 audits are not interchangeable. An ISO certificate does not replace the statutory KSC audit, and a technical penetration test does not replace an ISMS audit.
4. Weak links between risk and decisions. A risk register is useful when it leads to decisions: avoid the risk, reduce it, transfer it, consciously accept it, or address it in some other justified way. An assessment performed once and never updated after an architectural change quickly loses value.
5. No useful measurements. Metrics should not exist just to fill a report. A measurement should help answer whether a control or process achieves its intended objective. Examples include the time required to revoke access after a working relationship ends, the percentage of planned recovery tests completed, the time taken to handle critical vulnerabilities, or the percentage of systems covered by required monitoring. A metric is useful only when it is connected to a decision.
6. Auditing your own work. Audit objectivity requires a division of responsibilities that prevents a person from uncritically evaluating solutions they designed and implemented themselves. In the statutory KSC audit, the restriction is more specific and follows from Article 15(2a) ^[13]. ISO 19011:2026 and ISO/IEC 27007:2020 provide guidance on objectivity and audit programmes for management systems ^[7][8].
7. Turning management review into a signature. A management review should lead to decisions about changes, resources, risks, and improvement actions. Minutes without decisions, or without tracking whether those decisions were implemented, have limited value.
8. Treating a GRC tool as the system itself. Software can automate parts of evidence collection, reminders, requirements mapping, and configuration monitoring. It does not automatically determine whether the scope is correct, whether risk has been assessed properly, or whether a particular control is effective in context.
9. Using language models without verification. They can help draft a first version of a document, generate audit questions, or build an initial requirements map, but the output must be checked against real processes and primary sources. A document describing a procedure that does not exist in the organization makes the system worse, because it creates false evidence of compliance.

Integration paths

Management systems can be integrated where the organization has a good reason to do so. Information security can be linked to privacy management and business continuity. For privacy, the current edition is ISO/IEC 27701:2025, which replaced the 2019 edition ^[10]. For business continuity, ISO 22301:2019 with Amendment 1:2024 remains a reference point, although ISO is already working on the next edition ^[19].

Integration does not mean that one set of documents automatically satisfies every legal regime. The GDPR has its own legal requirements for the processing of personal data ^[18]. KSC has its own scope and obligations ^[13]. KRI has its own criteria ^[11]. Shared processes may reduce duplication, but conformity still has to be assessed against the correct criterion for each regime. See also the GDPR audit.