Criminal record checks for personnel under Poland’s National Cybersecurity System (KSC) are neither a universal HR screening measure nor a formality performed before an audit. Their scope must be based on a specific legal basis, the organisation’s regulatory status, and the individual’s actual duties and access rights. Starting with certificate collection rather than role qualification may leave required personnel unchecked while also resulting in the unjustified processing of criminal conviction data. The organisation should therefore first establish who may be checked and on what basis, separate responsibility for obtaining information, assessing the result and authorising access, and retain only the evidence necessary to demonstrate compliance.
Start with scope, not certificates
A decision to perform criminal record checks should not begin with requests for personnel to submit documents. Management should first confirm the organisation’s status within the KSC framework and identify the specific provision imposing an obligation in relation to defined categories of people. Referring generally to NIS2, preparing for an audit or implementing an information security management system does not, in itself, justify screening every employee, contractor and supplier.
The process boundaries must be established separately for each source of requirements. The NIS2 Directive, the Polish Act on the National Cybersecurity System in its current wording, implementing legislation, sector-specific regulations, contractual conditions and internal access rules are not equivalent sources. For each source, the organisation should determine its organisational, personal and temporal scope: who is covered, why the requirement applies, when it takes effect, whether exceptions exist, and what triggers reassessment. Designing the procedure before completing this analysis may result both in the omission of people who are subject to the requirement and in the unjustified processing of criminal conviction data.
The qualification exercise should result in a concise record approved by the compliance owner. It should identify the organisation’s status, legal basis, analysis date and version of the law considered, roles in scope, and any justified exclusions. A category such as “IT personnel” is too broad. The organisation must determine whether the requirement covers privileged administrators, incident response personnel, supplier personnel and deputies who perform these duties periodically. It should also appoint an owner for the legal analysis and set a review date, particularly following changes in legislation, the scope of operations or the access model.
Defining the boundaries of screening should form part of the programme described in “An ISMS aligned with the KSC Act: how to define scope, owners and an implementation schedule”. The management system scope, process responsibilities and privileged roles should all be derived from the same organisational map. Only then can the organisation responsibly determine whether the obligation applies under the law currently in force, which provision permits criminal record information to be obtained, and which categories of personnel may lawfully be covered.
Who should be covered by screening?
Personal scope should not be determined by job title or type of contract. The deciding factor is the applicable requirement considered alongside the person’s actual duties, permissions and influence on service security. Qualification should consider logical and physical access, the ability to modify configurations, participation in incident response, impact on business continuity, and temporary or emergency privileges. Roles unrelated to the protected service, system, facility or legally defined scope should not be screened as a precautionary measure.
The primary decision-making tool should be a role matrix maintained jointly by the process owner, information security function and HR, with the involvement of the compliance owner. The matrix should be linked to identity and access management and segregation of duties. An employee list alone is not sufficient. The organisation also needs records of privileged accounts, administrative, physical and emergency access, and external personnel with actual access to in-scope systems or processes.
| Person category | Nature of access | Basis for inclusion | Timing of screening | Decision owner | Supplier arrangements |
|---|---|---|---|---|---|
| Internal personnel | Administrative, privileged, physical or emergency access | Applicable provision mapped to the duties of the role | Before access is granted and when the role changes; repeated where required by the applicable basis | Compliance owner together with the process owner | Not applicable |
| Member of a governing body or person engaged under another arrangement | Decision-making or operational influence over the in-scope area | Only the applicable legal basis | Before appointment to the function or before access is granted | The appointing body or management | Not applicable |
| Supplier or subcontractor administrator | Remote or on-site administrative access, including temporary access | Applicable provision or a properly structured contractual requirement | Before access is granted and following a change in service scope | Service or contract owner | Define the obligation, evidence of completion, rules for refusing access, and oversight of subcontractors |
A supplier’s technical administrator may hold broader permissions than an internal manager despite not being employed by the organisation. Qualification based solely on contract type could therefore exclude a person with a material influence on security. This does not mean, however, that an external administrator is automatically subject to the same process as an employee. The scope of data, the method used to confirm that the requirement has been met, and responsibility for assessment must follow from a permissible legal basis or an appropriately structured contract. Temporary and emergency access should be evaluated according to the potential scope of activity, not the expected frequency of use.
The matrix should cover employees, members of governing bodies, people engaged under other arrangements, external administrators, and supplier and subcontractor personnel—but only within the limits of the applicable requirement. It should be reviewed following changes to the access architecture, service scope, supplier or legislation. The number of privileged roles and external personnel with actual access determines the scale of the process and provides input for the resource planning discussed in “The cost of implementing NIS2 and the Polish KSC Act: how to budget for audits, documentation, training and safeguards without costly mistakes”.
Where cost and risk arise
The principal risk does not arise from the technical act of obtaining criminal record information. It arises when screening is launched without a clear basis, defined purpose and limited scope. Data concerning criminal convictions and offences are subject to a specific processing regime. An individual’s ordinary consent or a general clause in an HR policy should not be treated as automatic justification for collecting such data. Before selecting a screening method, the organisation must establish what information the applicable provision actually requires, who is covered, and who is responsible for assessing the result.
Costs increase when an organisation requests complete documents from all personnel, retains copies without a defined retention period, sends them by ordinary email, or makes them available to HR, line managers, security personnel and auditors without segregating access rights. Every additional copy increases the effort required for data protection, access control, handling requests and secure disposal. Management should therefore monitor not only the number of checks completed, but also the number of people who can access the documents and the actual retention periods.
A second source of risk is the absence of assessment criteria. Information identified during screening must not result in an improvised management decision or an assessment unrelated to the requirement applicable to the role. HR may obtain the document correctly, yet the process will remain deficient if the organisation has not determined who evaluates its relevance, on what basis the access decision is made, and whether retaining a copy is necessary. The procedure should define an escalation route and a reaction plan within the control plan: how to define action when a process exceeds its limits.
Evidence that a check was performed should be separated from storage of the document’s contents. Depending on the applicable basis and evidentiary requirement, it may be sufficient to record the date of the check, the scope verified, the person authorised to assess it, the qualification outcome and the access decision—without retaining the complete certificate. Where a copy is necessary, the organisation must define authorised recipients, safeguards and the deletion date. This approach combines data minimisation with demonstrable compliance rather than replacing legal analysis with document collection “just in case”.
The process from role qualification to access approval
The process should begin before any criminal record information is obtained. First, the process owner qualifies the role, identifies the current legal basis and defines the required scope of screening. The organisation then informs the person about the purpose, procedure and data-processing arrangements, selects a permissible information source, and verifies the person’s identity. Subsequent control gates cover assessment of the result, the access decision, permission provisioning and creation of the control record.
Each activity should have an assigned owner, specified inputs, a deadline, and a defined response for a missing document, an overdue check or a result requiring clarification. Completion of a formal check is not the same as an operational access decision. HR may inform the employee, receive the document and confirm that the required information is complete, but it should not independently determine whether the person receives access to a system or infrastructure.
The final decision should belong to a designated business role—typically the system owner or the person accountable for the relevant operational area—with input from the security function. If the result is unclear or there is doubt about the permissible scope of data processing, the matter should be referred to the legal or data protection function. This division of responsibility prevents both automatic access provisioning upon presentation of a document and discretionary interpretation by a line manager.
Decision criteria should be approved before the first problematic case occurs. The procedure should specify who assesses ambiguity, what information may be considered, whether limiting the scope of access is permissible, and how the justification will be recorded without disclosing the underlying details to a wider audience. For example, a new employee may complete training and administrative onboarding activities but should not receive a privileged account or access to a protected environment until the decision has been made. Temporary access, if permitted at all, requires separate approval, a limited scope, an expiry date and supervision. It must not be used to bypass the control.
An adverse outcome requires a predefined response plan: permissions must be withheld, the matter escalated to designated decision-makers, cover arrangements established, the impact on business continuity assessed, and the case closed in a controlled manner. The logic should be the same as in a reaction plan: a defined event triggers an assigned response, responsibility and record. During recruitment and role changes, a useful reference is How to prepare an onboarding process for a new quality engineer or ISO management system representative, particularly regarding decision gates and confirmation of responsibilities.
The control record should make it possible to reconstruct the role qualification, basis and scope of the check, date of identity confirmation, information source, assessor, decision, access provisioning date and any escalation. The organisation should also define events that trigger reassessment—particularly changes in role or access scope—and the process for revoking permissions when a person leaves. The most useful measures of process effectiveness include the lead time from qualification to decision, the number of access rights granted before completion of the required screening, and the number of escalations caused by missing documentation or ambiguous results.
Documentation and repeat screening
Process documentation should make the rationale and consequences of decisions traceable; it should not create an archive of criminal record information. The record should explain why the role was subject to screening, when the check was performed, who made the decision, and the operational outcome: access granted, restricted or refused. This does not automatically mean that a copy of the source document must be retained. The decision to keep a copy should be separate from the retention of metadata and should be based on the current legal basis, processing purpose and storage limitation principle.
A coherent set of records should include:
- the role matrix and the rationale for its scope;
- the register of completed checks;
- data-processing authorisations and access rules;
- approved retention periods;
- the escalation protocol;
- evidence that suppliers have fulfilled their obligations.
These elements require a common owner, version control and integration with ISMS document control. Distributing them across HR, security and procurement makes it difficult to demonstrate that the process is complete. Templates, system-level decisions and the change history for the rules should be maintained in the repository, while individual records should be accessible only to authorised personnel. A useful organisational reference is How to build an internal quality knowledge repository without losing team experience.
A record may contain the dates of role qualification, screening and decision, identification of the basis applied, the date access was granted, and the planned review date. Where confirmation that the check was performed and its operational outcome is sufficient, the certificate should not be retained “just in case”. The deletion mechanism must also cover email attachments, working folders and supplier resources. The effectiveness of control can be assessed through the percentage of roles with a current rationale for inclusion in the process and the number of records retained beyond the approved period.
Repeat checks should not be scheduled according to an arbitrary calendar. Frequency may follow from the applicable provision, the nature of the role, contractual conditions or a documented risk assessment. Regardless of periodic review, the procedure should identify triggering events, particularly a change of position, extension of privileges, return to the role after a break, or a material change in legal or contractual requirements. Keeping information current does not necessarily require the repeated collection of a complete document. The process should provide a lawful and proportionate method of confirming status, each time aligned with the current legal basis and the scope of data the organisation is permitted to process.
Pre-audit readiness testing
A readiness assessment should not begin by checking whether a procedure exists. It should begin by tracing actual cases. The sample should include at least one employee in a role subject to screening, one person who has changed roles, one external administrator and one emergency-access case. For each case, the auditor should trace the sequence from the current legal basis and role qualification, through information collection and the access decision, to the permissions that are actually active.
At a minimum, testing should compare the role list with access records and examine the completeness of decisions, timeliness of checks, restriction of access to records and compliance with retention rules. The organisation should also simulate a missing document, an ambiguous result or a delayed check. It should be able to demonstrate that access can be withheld, escalation initiated and an authorised decision-maker identified. The frequency of ISMS internal audits and escalation thresholds should reflect risk and the requirements arising from the currently applicable basis, rather than the audit calendar alone.
Typical system-level nonconformities arise at process interfaces. These include the absence of a demonstrated basis, discrepancies between the list of positions and actual privileges, omission of subcontractors, access granted before the check is complete, an undefined retention period, or the absence of a documented escalation route. A correct HR record is insufficient if an external administrator retains an active account after the contract scope changes or receives extended privileges without reassessment.
Management should receive aggregated information rather than the contents of criminal conviction data. Useful measures include the percentage of active access rights requiring screening for which a current decision exists, the number of access rights granted before screening was completed, the timeliness of reviews, and the number of nonconformities by systemic cause. The indicators should support decisions on resources, corrections and escalation, in line with the approach described in How to develop process KPIs for management so the quality system does not end with spreadsheets.
Audit readiness means being able to demonstrate not only that a procedure exists, but also that its scope is proportionate, decisions are consistent and the process operates effectively. Test results should feed into the ISMS internal audit and management review, with an assigned action owner, deadline for closing the gap, and assessment of the impact on active access rights.
Masz pytania? Porozmawiajmy.
Bezpłatna konsultacja – bez zobowiązań.
