NIS2 and KSC Compliance Inspections: Documents, Registers and Tests That Must Form a Coherent Evidence Trail

A NIS2 and KSC compliance inspection is not limited to presenting policies and procedures. The supervisory authority may examine whether the organisation has correctly defined the scope of its obligations, assigned accountability, implemented safeguards and retained current records, test results and management decisions demonstrating that those safeguards operate effectively. Preparation should therefore follow a clear evidence trail: from the applicable obligation and identified risk, through the control applied, to evidence of performance, effectiveness evaluation and the response to any deviation.

An inspection examines the system, not the filing cabinet

The starting point is not the number of policies and procedures, but an accurate determination of the organisation’s obligations. The organisation should be able to identify which services, processes, information systems, locations and supplier dependencies fall within the KSC requirements, and explain the basis for that determination. Before reorganising its documentation, senior management should therefore confirm the entity’s status and the scope of services provided, then appoint a person responsible for coordinating inspection readiness.

The greatest evidential risk arises when documentation describes arrangements that the organisation does not actually operate or cannot substantiate with records. This is particularly relevant to access reviews, risk assessments, backups, supplier oversight and business continuity testing. The evidence should form a coherent chain: requirement or risk, decision, control applied, accountability, record of performance, effectiveness evaluation and response to any identified deviation.

The authority may begin with a governing document and then select an operational sample. If the incident management procedure defines how events are classified and escalated, the organisation should expect the authority to examine reports, response times, decisions, communications, case closure and post-incident lessons. System scope is demonstrated not only through a written description, but also through service and dependency maps, asset inventories, assigned owners and consistency between this information and operational registers.

NIS2 and KSC documentation before an inspection: the policies, registers and evidence you actually need should reflect an operating management mechanism rather than a catalogue of templates. A supervisory inspection should also be distinguished from a management system audit. Both may use similar evidence, but an inspection assesses fulfilment of obligations arising from the applicable legislation and supervisory remit, whereas an audit evaluates the conformity and effectiveness of a system against defined criteria. A positive outcome from one does not replace the other.

Scope and accountability under scrutiny

The first group of evidence should explain why the organisation is subject to particular obligations and where the boundaries of the supervised environment lie. The authority may expect a documented rationale for the entity’s classification, identification of regulated services and a clear view of the related processes, information assets, systems, locations and suppliers. Scope should not be described solely by naming the organisation’s business activity. It must allow a service to be traced from the business process, through the supporting assets, to external dependencies.

The foundation of readiness is a current, management-approved scope statement supported by a service and process map, an inventory of critical assets and a defined accountability structure. Documents establishing roles should specify not only job titles, but also authority to accept risk, activate contingency arrangements, escalate incidents and make supplier-related decisions. Service, asset and risk owners must be assigned in line with the organisation’s actual allocation of authority.

A common inconsistency occurs when the register names a formal risk owner, but another person accepts the risk without the necessary authority or documented decision. The same issue arises with control exceptions, business continuity decisions and supplier approvals. Meeting minutes, resolutions, risk assessment approvals, budget decisions and management reviews should demonstrate that senior management understands material risks, resolves matters beyond operational authority and monitors implementation of its decisions.

The method of classification, entry in the relevant register and the authority’s powers must always be determined by reference to the current legal framework and the entity’s specific circumstances. A practical extension of this topic is NIS2 self-assessment and entry in the KSC register: what must a manufacturing company do? If the organisation is classified as an essential entity, the scope assessment should also be considered alongside Mandatory KSC audit: which essential entities must prepare for their first conformity assessment? Entity status alone does not demonstrate that management has approved the boundaries of accountability or arranged for their periodic review.

Registers reveal how the system works in practice

A register provides evidence of continual management only when it reflects decisions and activities performed within processes. It should not be an appendix to a procedure that is updated only from time to time. Before selecting a tool, the organisation should define the required fields, data sources, record owners and rules for approving changes. A spreadsheet may be sufficient if it provides access control, change history, unambiguous accountability and protection against unauthorised modification. A sophisticated application will not make data reliable if no one knows who updates the register, when it is updated or which event triggers the update.

The risk register should link threat scenarios to services and assets, identify the owner and existing controls, record the assessment result and treatment decision, and show the status of related actions. The authority may check whether a risk designated for mitigation has an assigned action, due date and evidence of completion, and whether an accepted risk was approved by a person with the appropriate authority. Useful management measures include the number of open risks, overdue or incomplete actions, and decisions awaiting reassessment. These are organisation-defined indicators, not statutory thresholds.

The incident and event register should enable the organisation to reconstruct each stage: detection, incident classification, escalation, the reporting decision, communication, service restoration and formal closure, including lessons learned. Related evidence may include vulnerability, patch and approved-exception registers, access reviews, backup and restoration records, configuration changes, administrator activity, training and exercises.

A deferred patch should be traceable from the identified vulnerability, through impact assessment and the exception decision, to compensating controls, a reassessment date and confirmation of closure. A list of overdue patches alone does not explain whether the delay remains controlled.

The same consistency is required for supply-chain oversight. A list of contracts does not replace supplier classification, assessment of service and asset dependencies on third parties, defined security requirements, review records or decisions concerning unacceptable gaps. The register should show who approved the supplier, which exceptions were authorised and when reassessment is due. Particular attention should be paid to suppliers without a current assessment and actions from reviews that remain incomplete. This remains relevant when implementing the programme described in Implementing NIS2 after entry in the KSC register: action plan to 3 April 2027.

Retention, access and change-approval rules should be differentiated according to the type of record, its evidential significance, legal and contractual requirements, and incident-analysis needs. A single retention period should not be applied to every register without such an assessment. Incident reporting deadlines and arrangements for preserving evidence must always be verified against the legislation in force and guidance issued by the competent authority. A broader catalogue is provided in NIS2 and KSC documentation before an inspection: the policies, registers and evidence you actually need. Operational maturity, however, is demonstrated by records generated through day-to-day work and by a visible trail from the requirement to the control outcome and corrective action.

Every test must result in a decision

The supervisory authority may ask for more than a business continuity plan, an incident response procedure or confirmation that backups are performed. It may also require evidence that these arrangements have been tested under conditions reflecting the organisation’s actual services, technologies and supplier dependencies. The test programme should be driven by risk assessment, service criticality, environmental changes, and legal and contractual requirements. There is no single correct frequency for every control. Areas with high potential impact, rapid change or material findings from previous tests should be examined more frequently.

Before each test begins, its subject and pass criteria should be defined. The record should cover the scope, scenario, participants, environment, pass criteria and permitted tolerances. Once the test has been completed, it should document the result, deviations and actual or potential impact on the service. Where gaps are identified, the evidence should specify corrective actions, owners, deadlines and the date of follow-up verification.

Useful measures include the actual recovery time, achieved recovery point, escalation time and percentage of post-test actions closed. One of the most serious organisational weaknesses is repeated testing without success criteria or without closing the nonconformities identified.

Key tests include restoring data from backups, failover to contingency solutions, incident response exercises, crisis communication tests, access reviews, configuration restoration and technical vulnerability testing, including scanning and—where appropriate to the risk—penetration testing. A supplier’s test result may form part of the evidence, but it does not replace testing by the organisation where it does not cover the organisation’s processes, integrations, responsibilities and operating conditions.

After every test, the service owner should make a documented decision: accept the result, implement a correction, establish a compensating control, repeat the test or accept the risk within the limits of the authority granted.

A successful database backup does not by itself demonstrate that a service can be restored. Testing may reveal that the application requires an undocumented configuration version, the identity mechanism does not work in the recovery environment, keys are unavailable, or the only person who knows the component start-up sequence is not involved in the recovery. Only an end-to-end test of the dependency chain allows the organisation to compare actual recovery time and recovery point with the approved criteria, assess service impact and decide whether readiness is adequate or improvement is required.

This approach to documenting tests is relevant across sectors, including when considering NIS2 for manufacturing companies: who is covered, what obligations apply and how to prepare the organisation without treating it solely as an IT issue. The expected evidence must be aligned with the obligations applicable to the organisation, its services and the current legal framework. The essential sequence remains the same: identified risk, planned test, measurable criterion, documented result, owner’s decision and confirmation that resulting actions have been effectively closed.

Inconsistencies increase the cost of an inspection

Formally complete documentation loses its value when it does not reflect actual practice. The authority may compare statements in policies with system configurations, ticket records, contracts, access lists, scan results, test reports and explanations from process owners. The issue is not editorial consistency, but whether a decision can be traced from the identified obligation and risk through to the implemented control, evidence of its operation and the response to any deviation.

A pre-inspection review should use a deliberately selected sample of services, incidents, suppliers and access rights, then trace each item through the documentation to the source data. This can reveal outdated asset inventories, inconsistent names for the same service across documents, risks without owners, incidents omitted from the register, suppliers without documented assessments and corrective actions closed without effectiveness verification. Discrepancies should be resolved by establishing the facts and identifying the record owner, not by making superficial changes to align documents.

In a manufacturing organisation, the review should not stop at the office IT environment. For a selected service, it may cover maintenance, industrial automation, remote service access, configuration management and dependencies between production systems. An access register may, for example, omit an account used by a service technician even though the contract, connection log and device configuration confirm that it exists. These dependencies are discussed in greater detail in NIS2 for manufacturing companies: who is covered, what obligations apply and how to prepare the organisation without treating it solely as an IT issue.

A management system certificate can support structured risk management, document control, audits and corrective action, but it does not replace analysis of the applicable legal scope or evidence that KSC-specific obligations have been fulfilled. This distinction is explained in NIS2 and ISO 27001: what certification provides and what is still required for KSC compliance. The absence of a single record does not necessarily establish noncompliance, but it does require an assessment of the evidence’s significance, the reason for the gap and whether operation of the control can be demonstrated through other reliable records.

Inspection costs rise most sharply when evidence is dispersed, delegated authorities are unclear and no one coordinates responses or approves the material being disclosed. Teams then begin manually reconciling conflicting data while the inspection is already under way. Appointing a coordinator in advance, assigning owners to each category of evidence and defining how discrepancies will be resolved reduces both workload and the risk of presenting inconsistent explanations to the authority.

Readiness is built through a mock inspection

An internal mock inspection should begin by confirming the entity’s status, the scope of services subject to the obligations, and the accountability of senior management and process owners. The person coordinating contact with the authority should then prepare a compliance matrix linking each obligation to its owner and supporting evidence. Only then should the organisation sample records, interview responsible personnel and reconstruct the course of a selected incident or test. The coordinator should have access to senior management and sufficient authority to resolve discrepancies, while not replacing the subject-matter owners of the evidence.

Each obligation owner should be able to identify:

• the governing document defining how the activity is performed,
• a record confirming that the obligation was fulfilled,
• a measure of the control’s effectiveness,
• the most recent decision arising from a review.

If any of these elements is missing, there is a break in the evidence trail. An incident response procedure is insufficient if the organisation cannot produce the event record, response time, impact assessment, root-cause analysis and decision to modify controls. Reconstructing a case also shows whether employees’ explanations are consistent with the records and the actions actually taken.

The mock inspection should also cover inspection logistics: receipt and registration of a request, assignment of a response deadline and owner, approval of materials, protection of sensitive information, version identification for disclosed documents and documentation of arrangements agreed with the authority. It is useful to rehearse a situation in which a requested record contains data outside the scope of the inspection or requires contextual explanation. This establishes who decides the extent of disclosure and how the organisation retains a record of the materials provided.

The remediation plan should prioritise gaps according to service impact, legal exposure, likelihood of detection and the time required to obtain credible evidence of effectiveness—not according to how easy it is to draft another procedure. Senior management approves priorities, resources and the acceptable level of risk. An action should be closed only after the control has been retested.

The timetable should be derived from the entity’s actual status, correspondence with the authority and the current legislation. Once status has been established, the analysis may be supplemented by NIS2 self-assessment and entry in the KSC register: what must a manufacturing company do? and Implementing NIS2 after entry in the KSC register: action plan to 3 April 2027. The dates and obligations presented in those materials must always be confirmed against the legal framework currently in force.