Preparation for a mandatory KSC audit does not begin with appointing an auditor or compiling procedures. The first steps are to confirm the legal status of the specific entity, define which regulated services are in scope, and assign accountability for risks, controls and evidence of their operation. Without these decisions, an organisation may invest in the wrong areas, overlook critical dependencies or enter the audit with documentation that does not reflect how its services are actually delivered. Readiness for the first compliance assessment therefore depends not on the number of procedures, but on alignment between legal qualification, operational scope, risk management and day-to-day practice.
Which entities will be subject to the first audit?
The first decision is to establish whether the legal entity falls within the scope of the KSC, which category applies to it, and which audit requirements and deadlines are relevant. This assessment must consider the sector, the activities actually performed, the organisation’s size and any specific criteria set out in the legislation currently in force. Essential entities should not be treated as equivalent to the former operators of essential services, nor should their status be determined solely by reference to a Polish Classification of Activities (PKD) code. A PKD code may provide an initial indication, but it cannot replace an analysis of the services delivered, their recipients and the organisation’s role within the sector.
The first working document should be an approved applicability assessment. It should identify the activities covered by the legislation, the organisational units that perform them, the services delivered, the information systems supporting those services and the basis for the conclusion reached. Ownership of the KSC compliance process may be assigned to a legal, compliance or cybersecurity function. The applicability decision itself, however, should be formally approved by the body authorised to make decisions on behalf of the entity. Where the position is unclear, obtaining legal advice is more appropriate than building the preparation programme around an undocumented assumption.
| Assessment factor | Working evidence | Responsibility for confirmation |
|---|---|---|
| Sector and type of activity | Service descriptions, contracts, permits and operating model | Legal or compliance function together with the business owner |
| Entity size | Employment and financial data presented on the required basis | Finance and HR |
| Specific criteria | Decisions, registrations, scope of services and the entity’s significance | Legal or compliance function |
| Organisational and technical scope | Map of organisational units, services, systems and supplier dependencies | Process owners and the cybersecurity function |
Within a corporate group, one company’s status does not automatically extend to the others. Each legal entity, its activities, scale and any specific qualifying criteria must be assessed separately. Only then should shared service centres, infrastructure, systems and suppliers be identified. This separation is necessary when assigning risk accountability, defining audit boundaries and planning how to prepare for a second-party audit of a key supplier.
Detailed thresholds, exemptions, identification, registration or notification procedures, and audit deadlines must be checked against the current wording of the Polish Act on the National Cybersecurity System and the relevant implementing legislation. The absence of formal notification from an authority should not, in itself, delay the analysis where the organisation’s business profile indicates that the legislation may apply. Only a confirmed status provides a sound basis for defining the scope and timetable of the first audit.
Scope determines the outcome
The most serious preparation error is to equate the scope of a KSC audit with the IT department. The assessment concerns how the security of services and systems is managed. Audit boundaries must therefore also cover operations, maintenance, procurement, HR, business continuity, incident management and management oversight. A scope that is too narrow excludes dependencies that are material to service resilience. Conversely, including the entire organisation without justification increases workload and makes it more difficult to distinguish significant findings from secondary issues.
The scope should be designed by starting with the services covered by the legislation. From there, the organisation should trace the supporting processes and information through to applications, infrastructure, locations, personnel and external providers. An asset inventory alone does not explain which resources are essential to service delivery or who is accountable for the associated risks. Each service should therefore have an identified owner, dependent processes, key information assets, systems, suppliers and evidence that relevant controls operate. The dependency map should make it possible to trace the impact of an outage or breach without documenting relationships that have no bearing on the service under assessment.
Backups illustrate the practical importance of this approach. They may be completed on schedule, monitored and operated in accordance with a procedure. However, if the operational process owner has not specified the required recovery time, the organisation cannot demonstrate that the technical control meets the business need. Similarly, a system shared by several companies should be included in the scope of each entity whose regulated service depends on it. The allocation of responsibility for administration, risk, incidents and the provision of evidence must nevertheless be clearly documented.
Organisational and technical boundaries should be confirmed during a workshop involving service and process owners, together with those responsible for business continuity, cybersecurity and critical suppliers. The scope cannot be established solely through discussions with the infrastructure administrator. The workshop should produce a list of the services assessed, their supporting systems, locations and suppliers, shared dependencies and justified exclusions. Each exclusion requires a documented basis, an assessment of its impact on the service and an identified decision owner.
This map also provides the starting point for estimating the investment discussed in How much does NIS2 and the amended KSC implementation cost? Building a realistic budget for audits, documentation, training and controls.
The distinction between internal and external audits may help when defining roles, assessment independence and the handling of findings. It does not change the fundamental principle: a KSC audit has its own legal basis, criteria and scope arising from the obligations of the audited entity. It is not an ordinary management system certification audit, even if it applies similar methods for collecting evidence and evaluating control effectiveness.
Costs increase where responsibilities overlap
The highest preparation costs usually arise not where a document is missing, but where accountability is fragmented. Typical interfaces include IT and operations, a company and its corporate group, a customer and its supplier, or a process owner and a system owner. If no party is clearly accountable for risk, incidents, business continuity and the provision of evidence, the gap remains open even where roles have been assigned on paper.
The budget should be based on the impact of gaps on the service and the risk that control effectiveness cannot be demonstrated—not on the number of missing procedures. It is useful to budget separately for the gap assessment, organisational changes, technical controls, testing, competence development, supplier management and the audit itself. Three measures support effective expenditure management:
- the number of critical gaps requiring investment or contractual change;
- the expected implementation time for controls that require testing;
- the proportion of infrastructure modernisation costs that would arise independently of the compliance obligation.
The most difficult deficiencies to resolve usually require technical changes, contract renegotiation, recovery testing, stronger privileged-access management, or redesign of incident reporting and escalation. They cannot be credibly closed merely by approving a procedure. A cloud service provider may, for example, claim to operate extensive security controls while the organisation remains unable to demonstrate the division of responsibilities, its right to receive incident information or its ability to obtain the evidence required by the auditor. The issue then affects the contract, supplier oversight, service architecture and evidence readiness at the same time.
Before the audit, the organisation must close any gaps that undermine its ability to deliver the service, respond to incidents or demonstrate the operation of a key control. Other gaps may be managed through a controlled action plan, provided it defines an owner, deadline, resources, interim risk treatment and approval of the residual risk at the appropriate management level. Priority should not be given to tasks simply because they are easy to mark as completed. The choice between purchasing a tool and improving a process must also be driven by the root cause of the gap, not by the availability of capital expenditure.
The same discipline in assigning accountability is important in the area covered by How to prepare a team for a customer audit involving APQP, PPAP and root cause analysis, although the assessment criteria and underlying basis remain different.
The auditor will assess operation, not the document folder
A document is only the beginning of the audit trail. The auditor should be able to move from a requirement and identified risk to the process owner, the control applied, the record confirming its execution, the monitoring result and the response to any deviation. A policy, procedure or instruction alone does not demonstrate effectiveness. Objective evidence from normal operations is required, including tickets, event logs, approvals, test records, review results, risk decisions and completed corrective actions.
The preparation programme should define how samples of actual cases will be selected, rather than merely listing documents to be presented. The sample should include, among other matters, the granting and withdrawal of access, vulnerability management, an incident, data recovery, a system change, employee training, supplier qualification and management review. For each sample, the source record, responsible person and effectiveness criterion should be established.
It is useful to compare the number of conforming cases, deviations and instances where evidence is unavailable. Where measurements are maintained, they should also cover incident response and closure times, together with the results of recovery tests, exercises and access reviews. Evidence retention periods should allow the consistency of the process to be evaluated and should cover events material to risk. They should not be set solely around the planned audit date.
An access-removal procedure will not constitute sufficient evidence if a sample of former employees’ accounts reveals delays, active accounts or no confirmation that the request was completed. The auditor may compare HR data, service desk tickets, directory records and activity logs. Evidence generated automatically by tools is valuable where its completeness, reliable timestamping and link to a specific case can be demonstrated. Decisions on risk acceptance, exemptions, incident closure or supplier qualification require an approved record with traceable accountability.
An internal audit sample should reproduce the external auditor’s line of enquiry: from the criterion, through the sample, to an assessment of implementation and effectiveness. Individuals must not, however, audit their own work. When assessing third-party oversight, useful context is provided by Supplier audits in the nuclear energy sector: what is assessed and how to prepare before qualification, while recognising that the applicable assessment criteria are different.
An existing management system may already provide mechanisms for document control, internal audits, corrective action and management review. These should be used rather than creating a parallel workflow. An existing certificate does not, however, replace the need to demonstrate conformity with the applicable KSC criteria. The outcome depends on whether controls operate within the defined scope and whether the organisation can present consistent, reliable evidence of their application.
Suppliers form part of the scope
Outsourcing system maintenance, data processing or security monitoring does not transfer an essential entity’s accountability to the provider. A supplier may operate controls and manage incidents, but the organisation must still understand the associated risk, set requirements and demonstrate effective oversight. Audit preparation should therefore include external services on which business continuity, information confidentiality or system availability depend.
The depth of assessment should reflect supplier criticality. Relevant factors include the effect of a failure on the service, the supplier’s access to information and systems, its replaceability, the use of subcontractors, processing locations and the organisation’s practical ability to obtain evidence. Suppliers with limited impact may be assessed through a questionnaire and document review. For strategic partners, interviews, continuity tests, examination of operational records or a second-party audit may be justified.
If a supplier does not permit a right to audit, the organisation should identify alternative evidence, assess the residual risk and decide whether additional controls, contract renegotiation or an exit plan are required. A supplier declaration or certificate may be insufficient if it does not cover the relevant service, location or operational scope.
A common gap arises when a contract defines service availability but does not specify the deadline for incident notification, cooperation requirements for root cause analysis or the right to verify the supplier’s actions. This is not merely a formal omission. Without such provisions, the organisation may not receive the information needed in time to assess the impact, make decisions and present the auditor with a coherent record of the response. An internal procedure cannot remedy a contractual gap.
Reviews of contracts and security schedules should address information protection obligations, incident notification, business continuity, subcontracting, termination, data return or deletion, access to evidence and verification arrangements. Progress can be monitored through the number of critical suppliers, the proportion of partners with a current risk assessment and evidence of oversight, the number of contracts requiring amendment, and the number of services without a confirmed continuity or exit plan. A more detailed verification approach is presented in How to prepare for a second-party audit of a key supplier.
A plan for the first assessment
The preparation programme should follow a defined sequence: confirm the entity’s status and the applicable legal criteria, establish the boundaries of the environment being assessed, assign accountability, perform risk and gap assessments, and approve a remediation plan. A mock audit is justified only after actions have been implemented and records of their operation have been collected. Its findings should lead to the removal of nonconformity root causes, not merely their symptoms, followed by a final management readiness review.
The timetable should be built backwards from the deadline arising from the legislation currently in force or from a formal decision concerning the entity. There is no single safe starting date for every organisation. The lead time depends on legal status, technical scope, control maturity, the number of external dependencies and the time required to generate records demonstrating operation. Management should approve priorities according to risk significance and task dependencies—not according to how easily items can be closed on the project plan.
A task marked as complete when a procedure is published remains open in practice until the procedure has been implemented, tested on a representative sample and supported by a record. The same applies to technical controls, incident management, continuity plans and supplier oversight. Audit readiness requires evidence of the full operating cycle: decision, execution, verification of the result and response to any deviation. Where a deficiency concerns arrangements with an external party, useful context is provided by Supplier audits before contract signature: reducing quality and delivery risk.
Management reporting should not be limited to the percentage completion of the plan. Management information should identify:
- the number of gaps by severity, together with the owner and closure date;
- the proportion of controls supported by operating records;
- open risks accepted at the appropriate management level;
- obstacles such as the absence of an owner, a control not yet implemented, an untested plan, an unresolved contract or a gap without credible closure evidence.
The process of selecting the audit provider should begin sufficiently early, but only after checking the current KSC requirements concerning the provider and the documentation of results. Price must not be the sole criterion. The organisation should assess the required authorisations, independence, sector competence, methodology and ability to examine the actual technical environment. Appointing the provider does not replace a mock audit or management review. It completes only the organisational element of preparation for the formal assessment.
The first KSC audit should be treated as an assessment of the organisation’s ability to manage service security—not as a one-off document review. An entity is ready only when it can justify its status and scope, identify risk owners, demonstrate that controls operate and provide reliable evidence of oversight across both internal processes and suppliers.
Masz pytania? Porozmawiajmy.
Bezpłatna konsultacja – bez zobowiązań.