Information Security Policy in 2026: a management document that must steer the system

What a policy is and what it is not

This distinction prevents a common mistake: writing one document intended to "satisfy KRI, KSC, NIS2, GDPR, and ISO". These regimes have different scopes and legal character. One well-designed policy may be a shared component of the management system, but compliance must still be demonstrated against each applicable criterion separately.

In security practice, the word "policy" may refer both to a management statement and to a technical system setting. Within an ISMS, the top-level policy should remain strategic. It defines direction, principles, accountability, and the framework for more detailed documents.

It should not contain every technical setting. TLS parameters, retention periods for a specific log, EDR configuration, firewall rules, or a server-restore procedure change more frequently and belong in standards, procedures, work instructions, and operating records.

It is also not an employee rulebook, project plan, incident-response playbook, or the transparency notice required by GDPR Articles 13 and 14. Those documents may connect to the policy but have different functions and different life cycles.

The key test is simpler: after reading the policy, it should be clear what principles the organisation has adopted and who is accountable for implementing them. A sentence such as "the organisation ensures information security" without an accountability mechanism does not answer that question.

Where the policy sits in the documentation

There is no legally mandatory number of documentation levels. A practical structure can separate documents by stability and detail:

• top-level policy - direction, objectives, principles, and accountability;
• topic-specific policies or standards - for example access control, cryptography, backups, suppliers, remote work, vulnerability management;
• procedures - how a process is carried out and which operational roles perform it;
• technical instructions - concrete steps for a particular system or technology;
• registers and records - evidence that procedures were actually performed.

This separation avoids sending minor technical changes back to top management for approval every time. If a configuration instruction changes after a product update, the top-level policy does not necessarily need to change.

The policy should be stable but not static. It should be reviewed at planned intervals and whenever organisational context, law, risk, accountability, or the system's governing principles change. ISO/IEC 27001 does not impose a universal requirement to amend the policy every year. The organisation must instead keep it suitable and under control as documented information.^[2]

What ISO/IEC 27001:2022 requires

Clause 5.2 of ISO/IEC 27001 requires top management to establish an information security policy appropriate to the purpose of the organisation. The policy must include information-security objectives or provide a framework for setting them, a commitment to satisfy applicable requirements, and a commitment to continual improvement of the ISMS. It must be available as documented information, communicated within the organisation, and made available to interested parties as appropriate.^[2]

The standard does not prescribe one template, a page count, or one form of signature. Top management must nevertheless genuinely establish the policy and remain accountable for ISMS direction. A signature, board resolution, management order, or another approved mechanism may serve as evidence depending on the organisation's governance structure.

Annex A and ISO/IEC 27002 expand the control areas, but this does not mean that all 93 controls should be copied into the top-level policy. Applicability is assessed in the context of risk and ISMS requirements and is documented, among other things, in the Statement of Applicability.^[2][6]

What follows from KRI

The KRI Regulation of 21 May 2024 requires management of entities in scope to establish, implement, operate, monitor, review, maintain, and improve an information security management system. Section 19(2) lists 14 groups of requirements, including updating internal rules, risk analysis, inventory, access management, training, protection against vulnerabilities, incident handling, compliance checks, and an annual internal audit.^[1]

KRI does not say that all these requirements must be contained in one document called an information security policy. A KRI audit should examine the complete system of regulations, responsibilities, and records. The policy can be the highest layer while detailed requirements are distributed across standards and procedures.

Section 19(3) provides a mechanism under which the requirements are deemed satisfied where the ISMS is developed on the basis of applicable Polish Standards, including PN-ISO/IEC 27001, and related standards are used for controls and risk management.^[1] This is not a certification mandate.

As of 29 August 2026, the 2024 KRI Regulation remains in force. Draft RD313 for a new regulation is being developed in parallel.^[7] Current organisational documentation should therefore not be written as though draft requirements were already binding law.

KSC and NIS2: policy as part of risk management

Following the amendment effective from 3 April 2026, the KSC requires essential and important entities to implement an ISMS in the information systems used in processes that affect service delivery and to manage cybersecurity risk systematically. Article 8 includes, among other matters, security policies, secure acquisition and maintenance of systems, supply-chain security, continuity, monitoring, effectiveness assessment, education, cryptography, and the management of assets, vulnerabilities, and incidents.^[3]

NIS2 Article 21(2) includes policies on risk analysis and information-system security among the cybersecurity risk-management measures.^[4] For an organisation in Poland, however, the principal compliance criterion is the KSC as currently in force, while NIS2 provides the common EU context.

Management has a real role in this system: it should approve appropriate measures and oversee their implementation. This should not be confused with a legal requirement to sign one specific file named "Information Security Policy". The documentation method must fit the organisation's governance structure and permit management decisions to be demonstrated, which is one of the areas examined in a KSC/NIS2 audit.

GDPR: policies, but not always a document with that name

GDPR Article 24(2) states that, where proportionate in relation to processing activities, controller measures include implementation of appropriate data-protection policies. Article 32 requires risk-appropriate security measures, and Article 25 requires data protection by design and by default.^[5]

GDPR does not impose a universal document called "Information Security Policy" in a prescribed format. An organisation may combine part of its privacy principles with the security policy or maintain separate documents. The roles must remain clear: an information security policy does not replace the record of processing activities, privacy notices, DPIAs, processing agreements, or the personal-data breach procedure, all of which are examined in a GDPR audit.

What a good policy should contain

The content should be proportionate to the organisation. In practice, the following elements are useful.

Purpose and scope. The policy should state which units, locations, systems, information types, and people it covers. An overly vague scope creates later disputes about whether a rule applies to a particular environment.

Management commitment. The document should make clear that information security is part of organisational governance, not a stand-alone IT project.

Objectives and principles. Examples include least privilege, separation of duties, security in change management, defence in depth, risk management, and documented exceptions. Principles should be concrete enough that a breach of them can be recognised.

Roles and responsibilities. The policy should explain the roles of management, information and system owners, security personnel, administrators, users, the DPO where applicable, and suppliers. The statement "IT is responsible for security" is usually too broad and inaccurate.

Information classification and handling. The organisation should define categories appropriate to its real working practices. There is no universal legal rule requiring three or four levels.

References to topic policies. The top-level policy may point to more detailed rules on access, cryptography, backup, suppliers, vulnerabilities, incidents, continuity, remote work, and physical security.

Reporting security events and breaches. The policy should define a channel and the principle of rapid escalation. Detailed legal clocks and classification logic are better kept in response procedures because they differ between KSC, GDPR, DORA, and other regimes.

Review and control. The owner of the document, review triggers, approval method, publication of the current version, and withdrawal of obsolete versions should be defined.

Classification is only useful if it changes behaviour

A table containing labels such as public, internal, confidential, and strictly confidential protects nothing by itself. Each category should lead to actionable rules: who may access it, whether external email is allowed, what encryption is required, where data may be stored, how it should be marked, and how it should be deleted.

Classification should be based on the impact of unauthorised disclosure, alteration, or loss of availability rather than the intuition of the document author. Public organisations also need to consider special legal regimes for specific types of information. Internal classification does not change a status that is defined by law.

Compliance mapping: useful, but not magic

The policy or the ISMS documentation can include a mapping showing which documents and processes support specific KRI, KSC, GDPR, ISO/IEC 27001, or other applicable requirements. This prevents every audit from starting with manual searching across dozens of files.

The mapping should not imply equivalence between documents of different legal character. One control may support several requirements, but satisfying an ISO clause does not automatically satisfy a legal provision. Every mapping has to be read within its scope, and ISO 19011:2026 provides the methodology for examining it.^[9]

Policy versus practice

The most valuable audit of a policy checks whether its principles leave traces in systems and decisions.

• If the policy requires least privilege, test a sample of privileged accounts.
• If it requires supplier-risk management, examine the contract and risk assessment for a critical cloud service.
• If it declares service restoration capability, inspect evidence of the last restore test.
• If it requires incident reporting, trace a recent incident from detection to decision.
• If it requires classification, inspect real documents and how they are shared.

A policy that cannot support such tests is probably too abstract. Audits by the Polish Supreme Audit Office in public entities show that the problem is often not a missing document but the absence of evidence that it is applied.^[10] Risk assessment conducted in line with ISO/IEC 27005 is the natural reference point here, because it links a principle to a decision about a safeguard.^[8]

Common mistakes

1. Downloading a template from the internet. It is often recognisable by roles that do not exist, outdated laws, technologies the organisation does not use, and placeholders such as "Organisation" that were never replaced.
2. Putting everything into one document. When the policy contains every technical instruction, it becomes too expensive to maintain and nobody updates it.
3. Rules without owners. Accountability must be assigned to a role, and the role must exist in the real structure.
4. Presenting an arbitrary review frequency as an ISO requirement. An annual review may be a sensible organisational choice, but ISO/IEC 27001 does not require the policy text to be amended every year.
5. Embedding detailed legal deadlines without a maintenance process. When legislation changes, the policy becomes a source of incorrect instructions. It is usually better to keep the principle of immediate escalation at policy level and maintain regulatory clocks in response procedures.
6. Equating signature with implementation. A signature proves approval, not operation of controls.
7. Lack of communication. A policy that exists only on the ISMS owner's disk cannot fulfil an organisational function.

How to implement the policy

After approval, the organisation should decide which groups need the whole document and which need selected rules. An administrator needs different information from a finance employee. An external supplier does not necessarily need the entire internal policy, but applicable obligations should appear in contracts, security annexes, or access instructions.

Training should translate principles into decisions: how to report an incident, what not to send, how to protect access, where to store information, and who approves an exception. A knowledge quiz after reading the document does not prove that staff can execute the process.

In 4crypto policy-design work, it is usually more effective to start with ISMS scope, the risk map, and existing processes, and write the policy afterwards. Reversing the order often creates a document describing an imagined organisation rather than the real one.

When the policy should change

A change is needed when the policy no longer reflects the current direction and principles. Typical triggers include:

• a material change in structure or accountability;
• entry into a new legal regime or a material regulatory change;
• adoption of cloud, outsourcing, or a new technology class that changes risk;
• a serious incident exposing a flawed principle;
• an audit or management-review result;
• a change in risk appetite or security objectives.

A review may legitimately conclude "no change required". That conclusion is still worth recording. Changing only the date and version number to create the appearance of freshness adds no value: an auditor reads the content, not the footer.