GDPR and Security Testing: Slovenian Perspective

A security assessment helps establish whether controls protecting personal data work in practice. GDPR applies directly in Slovenia; ZVOP-2 supplements it with national provisions. A penetration test supplies technical evidence for the tested scope, but does not certify an entire organisation's compliance.

GDPR Security Requirements

GDPR Articles 25, 32 and 35 connect data protection to processing design, risk and assessment. Article 32 includes regular testing, assessment and evaluation of control effectiveness among appropriate measures. It does not prescribe a universal penetration-testing frequency. Choose methods and frequency based on the processing and its risks.

• Security of processing: Assess the controls on which personal-data protection depends, including access, transmission and restoration.
• Data protection by design and by default: Include protection requirements in development. Technical testing supports verification, but does not replace analysis of lawfulness, purpose or data minimisation.
• Data protection impact assessment: Processing likely to result in high risk to individuals' rights and freedoms requires an Article 35 assessment. Test findings may support its treatment of security measures; they are not the complete DPIA.

How Testing Helps

An assessment can identify access to personal data outside an account's permissions, weaknesses in protected transfers and limitations in restoring backups. Connect each data set to its access paths and the control actually tested. For web systems, start with API authorisation and object-access testing.

A documented policy does not demonstrate that a control works. Record the test conditions, result and limitations. Use the minimum necessary sample as evidence; extracting an entire personal-data collection simply to demonstrate impact is generally unnecessary.

Slovenian Context

ZVOP-2, published by the Slovenian Information Commissioner, contains national provisions to assess against the particular processing. The Information Commissioner is the data-protection supervisory authority. A test report can support evidence of measures taken, but does not guarantee a favourable inspection outcome or immunity from liability.

For cloud services, review processing locations, contractual roles and any transfers to third countries. Encryption alone does not establish a lawful transfer. Agree authorisation, scope, evidence handling and deletion before testing; where the provider acts as a processor, also establish the appropriate contractual arrangement.

Personal Data Breach Notification

Under GDPR Article 33, the controller notifies the competent supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware, unless the breach is unlikely to create a risk to individuals' rights and freedoms. A processor informs the controller without undue delay. Communication to individuals under Article 34 has separate conditions. Discovering a vulnerability does not itself establish that a personal data breach occurred.

The Intersection with NIS2 and ZInfV-1

Slovenia transposed NIS2 through the Information Security Act (ZInfV-1), effective from 19 June 2025. Applicability must be assessed for each entity; not every healthcare organisation is automatically essential. GDPR and ZInfV-1 have different notification triggers, recipients and deadlines.

Use URSIV's guidance for entities to identify the competent CSIRT and reporting procedure. The Slovenian NIS2 and ZInfV-1 guide separates scope assessment, risk management and incident reporting.

Testing Scope and Practical Steps

Map personal-data flows and identify the systems, user roles, APIs, transfers and backups to assess. Prioritise access paths to sensitive or extensive collections. Assign an owner and a corrective action to findings, then confirm their effect through a penetration test retest. Preserve the evidence from the original finding through verified remediation.