ISMS under the KSC Act – what to implement?

ISMS under KSC — what to implement

An information security management system (ISMS) under the Polish KSC Act is a working set of policies, roles, processes and technical controls. It identifies and treats risk, protects assets, supports continuity, manages incidents and gives an entity evidence that controls operate. It is not a SIEM purchase, a single policy PDF or a collection of questionnaires.

Legal status checked: 27 July 2026. This is informational material, not legal advice. For the initial group, obligations are due by 3 April 2027. A key entity must be audited at least every three years; a key entity that was not previously OUK has its first audit due by 3 April 2028. Existing OUK operators retain their three-year cycle.

Contents

• What an ISMS means in KSC
• Control areas and evidence
• Manager, training and Article 8f
• Risk, assets and suppliers
• Continuity and serious incidents
• Why SIEM is not enough
• A first 90-day plan
• FAQ

What an ISMS means in KSC

The ISMS joins governance and operations. Management approves direction and accepts residual risk where appropriate; the accountable information-security manager oversees implementation; operational teams perform controls; and documentation describes how work is actually done. The system must cover risk, assets, access, security measures, incidents, supplier relationships and business continuity in a way proportionate to the entity’s services and exposure.

Start with the applicable scope rather than a generic document library. Identify the services that matter to the KSC assessment, the systems and suppliers that support them, and the people who make security or recovery decisions. The wider framework is covered in the KSC overview and the entity categories in key entity vs important entity.

Control areas and evidence

Useful control areas include governance and review; a risk register and treatment plan; an inventory of systems, data and owners; privileged-access management; hardening and patch management; central logging and alert handling; incident playbooks; business-continuity and restore testing; supplier requirements; staff awareness; and internal-audit or corrective-action tracking.

For every control, ask for both the mechanism and the evidence. A policy needs approval and review records. MFA needs a configuration or access-review record. Backup needs a documented restore test, not only a successful scheduled job. Supplier requirements need contracts, assessment records or remediation follow-up. Auditors will test consistency between the written rule, the technical state and the operational record.

Manager, training and Article 8f

The Act requires an accountable information-security manager. Work can be performed by employees or external providers, but delegation does not remove the manager’s accountability. The manager’s training is at least annual and must be documented. Article 8f personnel requirements, including non-conviction verification, apply subject to the statutory exceptions. Establish this process with HR and legal input before treating the role as filled.

Risk, assets and suppliers

Risk management is the centre of the ISMS. Record threats to relevant services, assess likelihood and impact, select treatment and retain the decision and owner. Revisit the register after an incident, architecture change, supplier change or material change in the service. An asset inventory should identify business ownership, not only servers or software names; without it, the organisation cannot prioritise protection or explain service impact.

Supply-chain security is part of the programme. Hosting, cloud, managed service, payment, communications and other critical suppliers need proportionate requirements for security, incident notification, access, resilience and cooperation. Outsourcing does not transfer the entity’s own KSC responsibility.

Continuity and serious incidents

Business continuity requires tested recovery. Set recovery objectives that make sense for the services identified in the risk assessment and perform restore or recovery tests with records. A backup that has never been restored is not sufficient evidence of recoverability.

Incident management must integrate the serious-incident process: an early warning within 24 hours, notification within 72 hours and a final report generally within one month via S46 after register entry. The detailed steps are in serious-incident reporting. After an incident, update risk assessment, controls and the playbook rather than merely closing a ticket.

Why SIEM is not enough

SIEM, SOC and EDR can improve visibility and detection. They do not decide risk tolerance, assign asset owners, manage suppliers, test recovery, train people, approve controls or submit reports in S46. A useful monitoring programme has alert owners, response expectations, escalation to the accountable manager, evidence retention and a connection to the incident process. Technology without those decisions is a capability gap, not ISMS compliance.

A first 90-day plan

During days 1–30, confirm classification, appoint the accountable manager, plan or submit register entry, map critical services and assets, and create an initial security policy and risk register. During days 31–60, focus on priority controls: privileged access and MFA, exposed-system patching, a restore test, an incident playbook and critical-supplier requirements. During days 61–90, complete the first risk-treatment plan, run a serious-incident tabletop, obtain management review and establish audit and evidence routines.

The first 90 days do not finish the ISMS. Continue with risk reviews, annual manager training, regular recovery testing, supplier follow-up and, for key entities, audit preparation. If technical gaps need independent evidence, an IT security audit can inform the risk register.

FAQ

Does ISO 27001 replace KSC ISMS obligations?

An ISO programme can help, but it does not automatically demonstrate the KSC-specific legal and S46 requirements. Map the existing controls to the Act and keep the mapping current.

Does outsourced IT remove the ISMS obligation?

No. The regulated entity remains responsible for oversight of the supplier and for its own reporting and governance.

Does DevSentinel guarantee KSC compliance?

No. DevSentinel can support practical implementation, evidence and technical remediation but does not guarantee compliance, an audit outcome or an authority decision.