A KSC audit should not be treated as a box-ticking exercise, but as a tool that verifies whether an organization truly has control over its security. During the audit, the actual level of safeguards is assessed, along with their effectiveness and alignment with KSC requirements. The analysis covers both IT and OT environments, as well as organizational aspects such as roles and responsibilities, risk management, business continuity, and supply chain oversight.
The outcome of the audit is not just a report, but a clear map of risks and a set of actionable recommendations—often structured over time and tailored to the organization’s capabilities. For key entities, the audit is mandatory and must be conducted periodically. Its real value, however, lies in enabling a shift from declarative security to genuine control over the environment and conscious, structured risk management.
A security audit preparing an organization to meet the requirements of the National Cybersecurity System Act should not be treated solely as a formal obligation. Its primary objective is to determine how resilient the organization is to security incidents, where its weaknesses lie, and what actions need to be implemented to mitigate risks related to breaches of confidentiality, integrity, availability, and authenticity of information.
In practice, the audit should answer several key questions:
- what is the actual level of the organization’s security,
- whether the implemented safeguards are effective,
- which areas require improvement,
- whether the organization complies with KSC requirements,
- what actions should be taken to address these requirements in an appropriate and proportionate manner.
The audit obligation under KSC vs. its real value for the organization
For essential entities, a security audit is a mandatory requirement that should be conducted periodically, i.e., once every three years. Important entities are not subject to this obligation unless required by a decision of the competent authority or a sectoral CSIRT, for example in response to an incident.
A well-conducted audit should clearly identify the organization’s actual weaknesses. Its purpose is not merely to meet formal requirements, but to identify vulnerabilities and areas that could be exploited as attack vectors. Therefore, the audit should cover not only the IT environment, but also processes, organizational structure, documentation, risk management, incident monitoring, business continuity, physical security, the supply chain, and OT environment security.
Who should conduct the audit?
The Regulation of the Minister of Digital Affairs of October 12, 2018, on the list of certificates authorizing audit performance and related executive acts indicate that the audit should be carried out by individuals with appropriate, verified competencies. In practice, this includes certifications such as CISA, CISM, CRISC, CISSP, CIA, Lead Auditor ISO/IEC 27001 or ISO 22301, as well as certifications related to industrial cybersecurity, such as ISA/IEC 62443 Cybersecurity Expert.
The audit may be conducted internally if the organization has the necessary competencies. In practice, however, involving an independent external entity provides significant value. This perspective reduces the risk of self-assessment bias, increases objectivity, and allows the environment to be evaluated without organizational blind spots.
What areas does a KSC audit cover?
The audit scope should include three main perspectives:
- organizational,
- process-related,
- technical.
Omitting any of these may result in an incomplete security picture and leave the environment vulnerable to attacks.
Security governance structure
From an organizational perspective, the audit verifies, among other things, the information security governance structure, roles and responsibilities, top management involvement, and whether designated individuals are responsible for cybersecurity within the organization.
Risk management
Another key area is risk management. The audit should verify whether the organization identifies risks, assesses their impact, defines acceptable risk levels, and implements measures to reduce the likelihood or impact of incidents. Not every risk must be eliminated, but each should be consciously assessed, documented, and accepted by the appropriate stakeholders.
Incident monitoring and response
KSC requires organizations to be capable of detecting and responding to security events in a timely manner. In practice, this means implementing detection solutions such as EDR, NDR, IDS, IPS, and other monitoring systems. Having tools alone is not sufficient.
The statutory requirement for continuous monitoring implies either building an internal 24/7 response team or leveraging a professional SOC service, where analysts respond to alerts within defined SLAs, distinguish false positives from real incidents, and initiate response procedures.
Business continuity management
The audit should also cover business continuity management. This includes verifying whether the organization knows how to maintain or restore critical processes in the event of an incident, failure, or attack. This involves crisis procedures, incident response teams, communication plans, backups, recovery testing, and the actual ability to restore system operations.
From a technical perspective, the audit includes, among others, network perimeter security, firewall configurations, network segmentation, service separation, LAN and Wi-Fi security, cloud environments, servers, endpoints, mobile devices, email systems, communication channels, data security, AI usage, backups, and access and privileged user management.
Supply chain
KSC requires organizations to consider not only their own systems, but also suppliers that are critical to service delivery or business operations. Supply chain verification may include security questionnaires, contractual clauses, declarations of applied safeguards, and assessment of whether suppliers meet requirements aligned with best practices, ISO standards, or KSC.
How does the audit process look step by step?
Kick-off meeting
This is a crucial stage, as it defines the scope, timeline, stakeholders, expectations, and documentation required for analysis. The meeting should involve not only IT, but also management representatives and business owners from key areas such as compliance, legal, HR, and security.
The auditor then provides a maturity assessment questionnaire, survey, and a list of documents for review. The responses help identify areas requiring deeper analysis and prepare more targeted questions for subsequent stages. This ensures the audit is not a generic discussion, but focused on real elements of the environment.
Documentation review
The auditor verifies whether the organization has policies, procedures, and instructions forming an information security management system. A common issue is when security documentation is limited to personal data protection policies, which is insufficient to be considered a mature system aligned with KSC requirements.
Technical verification
At this stage, auditors and engineers review configurations of systems, security controls, firewalls, email, servers, endpoints, backups, network segmentation, and privileged access. In practice, security improvements can already be implemented at this stage. If a risky configuration is identified, such as an overly permissive firewall rule, it can be corrected immediately and documented in the report.
Final report
The final report should include an executive summary written in clear, non-technical language, a list of vulnerabilities, a description of the current state, recommendations, and a remediation roadmap. The roadmap may divide actions into 0–3 months, 3–6 months, and 6–12 months.
Common mistakes organizations make when preparing for an audit
Lack of management involvement
Cybersecurity is often delegated to IT, but without management support it is difficult to implement real changes, secure budget, and enforce policies across the organization. Ultimately, top management is responsible for ensuring the organizational, procedural, and financial resources needed for security.
Documentation misaligned with practice
Another common issue is documentation that does not reflect reality. Organizations may have policies and procedures, but they are often not aligned with actual operations, unknown to employees, or impractical in day-to-day work.
Ignoring OT environments
Manufacturing companies often focus on traditional IT while overlooking industrial automation systems, even though they may be critical to operations. Lack of IT/OT separation, unsupported systems, uncontrolled service access, and lack of third-party oversight can become significant risk sources.
Unaddressed supply chain security
Organizations often lack visibility into the security measures used by key suppliers, even though their operations directly impact business continuity. This is particularly relevant for ICT providers, cloud services, SOC services, infrastructure maintenance, and production systems.
Assuming information security is only an IT responsibility
In reality, every business owner is responsible for information within their domain, and every user impacts organizational security. This also includes employees who do not work daily with IT systems but may notice unusual behavior or physical access anomalies.
Frequently asked questions about KSC
Is a serious vulnerability a security incident?
A vulnerability itself is not a security incident. It is an attack vector and should be addressed within risk management processes, but until it causes a negative impact, it should not be recorded as an incident. A vulnerability register should be maintained separately from an incident register.
Does continuous monitoring mean SOC 24/7?
Continuous monitoring means the need for ongoing oversight of alerts generated by detection systems. In practice, this is often handled by a Security Operations Center operating 24/7, analyzing alerts, distinguishing false positives from real incidents, and initiating response procedures.
Are security questionnaires sufficient for supply chain oversight?
Questionnaires are a useful component of supply chain security oversight, but should not be the only mechanism. Their results can inform contractual clauses, security requirements, supplier declarations, and cooperation decisions. If a key supplier avoids transparency, the associated risk should be carefully evaluated.
What is a major incident?
A major incident is one that may result in degradation or disruption of a critical service. The definition is provided in the KSC Act, while specific thresholds are defined in implementing regulations.
Should risk analysis include social and business impact?
Yes, especially in sectors with direct societal impact. Organizations in areas such as energy, healthcare, or public infrastructure should assess not only internal impact but also consequences for service users.
When must incidents be reported to CSIRT?
The obligation arises once the organization is classified as an essential or important entity. From that point, it must comply with KSC requirements, including incident reporting to the appropriate CSIRT.
What documents and procedures are required for KSC compliance?
A single document is not sufficient. A full information security management system is required, including policies, incident response procedures, backup policies, business continuity plans, privileged access management rules, risk management procedures, and user guidelines.
How to verify if an organization must register in S46?
It is necessary to assess the sector defined in the Act, employment thresholds, revenue, and actual business activity. PKD classification may help, but should not replace a real assessment.
Does every supplier need to be verified?
No. Verification should focus on suppliers critical to operations or service delivery. Minor suppliers without significant impact do not require the same level of control.
Is the S46 system paid?
No. The S46 system is managed by NASK and is free of charge. Organizations are added after being classified as essential or important entities.
A KSC readiness audit quickly reveals whether an organization truly controls its security.
Text autors:
