This page is a legal-technical research profile of the General Data Protection Regulation. It is maintained for research, governance and educational purposes, with emphasis on cybersecurity, accountability, technical and organisational measures, breach handling, privacy engineering and audit evidence.

It is not legal advice. Legal interpretation, authority communication, contractual decisions and enforcement questions require qualified legal review and current supervisory guidance.

Evidence labels used on this page:

  • Official legal source — based on EUR-Lex or another official legal publication source.
  • National legal source — based on national legislation or a national authority source.
  • Supervisory guidance — based on EDPB or supervisory authority material.
  • Research publication — based on a publication or bibliographic record.
  • Historical publication — useful research context, but not necessarily current legal guidance.
  • Author analysis — technical, governance or cybersecurity interpretation on this site.
  • Current relevance review required — the item needs fresh legal/technical review before being used as current guidance.

Regulatory snapshot

FieldValue
CategoryRegulatory framework for personal data protection
Research typeRegulation
JurisdictionEuropean Union / EEA context
National contextSlovak Republic
Primary legal actRegulation (EU) 2016/679
Common nameGeneral Data Protection Regulation, GDPR
Slovak legal frameworkAct No. 18/2018 Coll. on personal data protection
EU guidance sourceEuropean Data Protection Board
Slovak supervisory authorityOffice for Personal Data Protection of the Slovak Republic
Reviewed1 August 2026
Content statusLegal sources referenced; selected publications partially normalized; not legal advice

What GDPR is

The General Data Protection Regulation establishes a legal framework for protecting natural persons in relation to the processing of personal data and for the free movement of such data within the European Union legal framework. Evidence: Official legal source.

It defines principles, lawful bases, rights of data subjects, accountability obligations, controller and processor responsibilities, security of processing, breach handling, data protection impact assessments, international transfer rules and enforcement mechanisms. Evidence: Official legal source; Author analysis.

For this Research site, GDPR is especially relevant at the boundary between privacy, cybersecurity, governance, audit evidence, identity management, logging, incident response, monitoring and IT asset/service management systems. Evidence: Author analysis.

What GDPR is not

GDPR is not:

  • a cybersecurity standard by itself,
  • a single technical checklist,
  • a product certification requirement for every system,
  • a consent form template,
  • a privacy notice alone,
  • a guarantee that data processing is lawful,
  • a replacement for risk assessment, records, governance and evidence.

Compliance cannot be achieved by installing one security tool, publishing a generic notice or collecting consent for everything. Organisations must understand their processing activities, identify lawful bases, manage risks to individuals and demonstrate appropriate measures. Evidence: Official legal source; Author analysis.

Core definitions

The GDPR vocabulary should be handled carefully. This page uses simplified explanations and does not replace the wording of the regulation.

TermTechnical research explanation
Personal dataInformation relating to an identified or identifiable natural person.
ProcessingOperations performed on personal data, such as collection, storage, use, disclosure, modification or deletion.
Data subjectThe natural person to whom the personal data relates.
ControllerThe party deciding purposes and means of processing.
ProcessorThe party processing personal data on behalf of a controller.
RecipientA party to whom personal data is disclosed.
ProfilingAutomated processing used to evaluate personal aspects of a natural person.
PseudonymisationProcessing so data cannot be attributed to a specific person without additional information kept separately.
Special categoriesSensitive categories such as health, biometric, genetic, political, religious or similar protected data categories.

The safe practice is to cite the relevant GDPR article when a precise legal definition is required. Evidence: Official legal source; Author analysis.

Processing principles

The GDPR principles are a strong bridge between legal governance and technical system design.

PrincipleTechnical and governance relevance
Lawfulness, fairness and transparencyProcessing must have a lawful basis and be understandable to the affected individuals.
Purpose limitationData should be collected for specified purposes and not silently reused for incompatible ones.
Data minimisationSystems should not collect or retain unnecessary data just because storage is cheap.
AccuracyIdentity, asset, ticket and customer records require correction and lifecycle processes.
Storage limitationRetention, archival and deletion must be designed, not improvised later.
Integrity and confidentialitySecurity controls, access control and resilience are part of lawful processing.
AccountabilityThe organisation must be able to demonstrate compliance and operating controls.

Evidence: Official legal source; Author analysis.

Lawful bases

Consent is one possible legal basis. It is not the default legal basis for every processing operation.

The GDPR lawful bases include:

  • consent,
  • performance of a contract,
  • legal obligation,
  • vital interests,
  • task carried out in the public interest or official authority,
  • legitimate interests, where applicable and balanced.

A technical system should not hard-code the assumption that consent is always required or always sufficient. Processing purpose, legal basis, retention and evidence should be documented per processing activity. Evidence: Official legal source; Author analysis.

Data subject rights

GDPR rights influence application design, identity workflows, logs, exports and records management.

Relevant rights include:

  • right to information,
  • right of access,
  • right to rectification,
  • right to erasure,
  • right to restriction of processing,
  • right to data portability,
  • right to object,
  • rights related to automated decision-making and profiling,
  • right to lodge a complaint with a supervisory authority.

Technical systems need evidence of requests, response workflow, scope assessment, identity verification and exceptions. Evidence: Official legal source; Author analysis.

Controllers, processors and accountability

The controller/processor model is central to system governance.

Key points:

  • controllers decide purposes and means of processing,
  • processors process personal data on behalf of controllers,
  • processor agreements matter,
  • sub-processors must be controlled,
  • joint controller situations require documented allocation of responsibilities,
  • accountability requires evidence, not only policy documents.

For technology operations, this affects SaaS tools, hosting, monitoring systems, ticketing, endpoint agents, backups, managed services and external support providers. Evidence: Official legal source; Author analysis.

Security of processing

Security is one of the strongest GDPR intersections with cybersecurity research.

AreaGDPR relevance
AccountabilityArticle 24
Data protection by design and by defaultArticle 25
Processor obligationsArticle 28
Records of processing activitiesArticle 30
Security of processingArticle 32
Notification to supervisory authorityArticle 33
Communication to affected individualsArticle 34
Data protection impact assessmentArticle 35
Data Protection OfficerArticles 37–39

GDPR does not prescribe one universal product or one fixed control list. Appropriate measures depend on risk, state of the art, implementation cost, nature, scope, context and purposes of processing, and risks to rights and freedoms of natural persons. Evidence: Official legal source; Author analysis.

Examples of technical and organisational measures relevant to research and operations:

  • identity and access management,
  • least privilege and role separation,
  • encryption,
  • pseudonymisation,
  • backups,
  • restoration of availability,
  • logging and audit trails,
  • monitoring,
  • vulnerability management,
  • security testing,
  • incident management,
  • secure deletion,
  • regular testing and evaluation of measures.

Personal data breach handling

A personal data breach analysis starts with whether a security event affects personal data. Not every security incident automatically becomes a notifiable personal data breach.

Security event
      ↓
Does it affect personal data?
      ↓
Personal data breach assessment
      ↓
Document the assessment and breach facts internally
where a personal data breach exists (Art. 33(5))
      ↓
Is it likely to result in a risk to rights and freedoms?
      ↓
┌──────────────────────────────┬──────────────────────────────┐
│ Keep internal breach record  │ Notify supervisory authority │
│ and remediation evidence     │ where required               │
└──────────────────────────────┴──────────────┬───────────────┘
                                              ↓
                                 High risk to individuals?
                                              ↓
                                 Communicate to individuals
                                 where required

The often-mentioned 72-hour rule should not be simplified into “report every security incident within 72 hours.” Organisations need a documented assessment process, internal evidence, risk evaluation and authority/individual communication decision path. Where a personal data breach exists, the controller should keep internal documentation of the facts, effects and remedial action; notification to the supervisory authority and communication to individuals are separate decisions based on the level of risk. Evidence: Official legal source; Supervisory guidance; Author analysis.

Data protection by design and by default

Data protection by design and by default should be treated as a lifecycle obligation, not as a one-time pre-launch checklist. It affects requirements, architecture, data minimisation, access control, defaults, logging, retention, testing, release review and decommissioning. Evidence: Official legal source; Supervisory guidance; Author analysis.

Engineering questions:

  • What personal data is truly necessary?
  • Can identifiers be pseudonymised or separated?
  • Are defaults privacy-preserving?
  • Who can access personal data and why?
  • Are exports and reports scoped?
  • Are logs necessary, proportional and protected?
  • Is retention implemented technically?
  • Can deletion or restriction requests be executed safely?

DPIA and risk assessment

A data protection impact assessment is relevant where processing is likely to result in high risk to rights and freedoms of natural persons. The DPIA concept connects legal risk with technical architecture and operational controls. Evidence: Official legal source; Author analysis.

A useful DPIA-oriented technical review should ask:

  • What is the processing purpose?
  • Which data subjects and categories of personal data are affected?
  • What systems, vendors and processors are involved?
  • What risks exist for individuals, not only for the organisation?
  • What technical and organisational measures reduce those risks?
  • What residual risk remains?
  • What evidence shows that controls are operating?

Profiling and automated decisions

Profiling and automated decision-making require special care because automation can affect individuals at scale. Technical teams should avoid treating scoring, classification, fraud detection, HR analytics, monitoring or AI-assisted decisions as purely internal engineering features. Evidence: Official legal source; Author analysis.

Research questions:

  • Is the system evaluating a person or only infrastructure?
  • Can output affect access, service, employment, pricing or legal position?
  • Is human review meaningful?
  • Are explanations, objections and corrections possible?
  • Is training or inference data personal data?

International transfers

International data transfers require specific legal mechanisms and risk assessment. From a technical perspective, this affects cloud hosting, SaaS tools, support access, telemetry, backups, logs, analytics, email providers and remote administration. Evidence: Official legal source; Author analysis.

The practical inventory question is simple but often missed:

Where can personal data be accessed, processed, stored, logged, backed up or supported from?

Documentation and audit evidence

GDPR accountability depends on evidence. Policies are not enough if the organisation cannot demonstrate what is actually implemented and operating.

Useful evidence types include:

  • records of processing activities,
  • data-flow maps,
  • system inventories,
  • access-control reviews,
  • processor agreements,
  • DPIA records,
  • incident and breach assessments,
  • backup and restore tests,
  • security testing records,
  • retention/deletion evidence,
  • change-management records,
  • training and awareness records,
  • audit logs and review notes.

Cybersecurity relevance

GDPR and cybersecurity overlap most strongly where personal data is processed by real systems.

Important intersections:

  • identity and access control,
  • endpoint and server monitoring,
  • ticketing and incident response,
  • SIEM/logging and retention,
  • asset inventory and CMDB records,
  • vulnerability management,
  • backup and recovery,
  • secure development,
  • supplier and processor management,
  • evidence and audit trails,
  • privacy impact of monitoring itself.

Good cybersecurity can support GDPR compliance, but cybersecurity tooling can also create additional processing of personal data through logs, user identifiers, alerts, telemetry and investigations. Evidence: Author analysis.

Relationship with GLPI, NetXMS and operational systems

GDPR relevance is practical, not abstract, when applied to operational systems.

SystemGDPR-relevant angle
GLPIUsers, tickets, service records, assets, contracts, documents, history and workflow evidence may contain personal data.
NetXMSMonitoring data, device names, interface labels, events, alarms or logs may indirectly identify people or locations.
SBOMSoftware supply-chain documentation supports accountability but may also reference systems processing personal data.
Zero TrustAccess control, segmentation, continuous verification and least privilege can support security of processing.

The important architectural principle is purpose awareness: a system built for operations can still process personal data, and therefore needs privacy-aware configuration and retention decisions. Evidence: Author analysis.

This section intentionally lists only selected publications. A complete bibliography should be normalized separately before it is presented as an authoritative archive.

PublicationStatusNote
GDPR Issues from a Marketing PerspectiveFeatured research publicationPublication relevant to marketing, GDPR and data protection.
Options to Improve the General Model of Security Management in Private Bank with GDPR ComplianceFeatured research publicationConnects GDPR compliance with security management in private banking.
Pseudonymizácia a anonymizácia osobných údajov ako požiadavka GDPRHistorical research publicationOriginal Slovak title; relevant to pseudonymisation and anonymisation as historical GDPR-transition context.

Publication and citation metadata are time-dependent. Google Scholar metrics should only be displayed as a dated snapshot, not as automatically current data. Evidence: Research publication; Author analysis.

Additional GDPR-related publications exist in the author’s historical bibliography. They should be deduplicated, bibliographically verified and separated from current legal guidance before they are presented as a curated public archive. Evidence: Author analysis.

Historical publication context

Many GDPR-related professional publications from 2017 and 2018 were written during the transition into GDPR applicability. That does not make them useless; it means they must be labelled correctly.

Recommended labels:

  • publication date,
  • historical context,
  • bibliographic verification status,
  • current legal relevance review status,
  • full-text availability,
  • duplicate-candidate status,
  • relation to current EDPB or national guidance.

Historical articles should not be presented as current legal guidance unless they have been reviewed against current law, guidance and practice. Evidence: Author analysis.

Current guidance watch

A maintained GDPR research page should track current guidance, but draft or consultation material must be labelled clearly.

Useful watch topics:

  • anonymisation,
  • pseudonymisation,
  • web scraping and generative AI,
  • personal data breach notification,
  • AI/data protection overlap,
  • international transfer practice,
  • security of processing expectations,
  • data protection by design and by default.

Draft or public consultation material should be described as draft/consultation material, not final guidance. Evidence: Supervisory guidance; Author analysis.

Limitations and interpretation risks

  • This page is not legal advice.
  • GDPR applicability can depend on context, role, jurisdiction, processing purpose and data-flow details.
  • National law and sector-specific law can add obligations.
  • Supervisory guidance and case law evolve.
  • Technical controls do not automatically prove legal compliance.
  • Consent is not always the right lawful basis.
  • Security incidents and personal data breaches are related but not identical.
  • Citation metrics and publication metadata change over time.
  • Historical publications need current relevance review.
  • Operational systems can process personal data even if privacy is not their primary purpose.

The main /research/gdpr/ page should remain a readable legal-technical profile. Deeper pages can follow later as flat Research entries or after a routing expansion:

  • GDPR publications archive,
  • GDPR security and personal data breaches,
  • GDPR DPIA and risk assessment,
  • GDPR privacy by design,
  • GDPR data subject rights,
  • GDPR controllers and processors,
  • GDPR international transfers,
  • GDPR and cybersecurity operations,
  • GDPR and GLPI,
  • GDPR and monitoring/logging systems.

Further research directions

Future extensions should keep the main /research/gdpr/ page readable while moving deeper material into separately curated Research entries when the supporting evidence is ready.

Useful directions include:

  • a normalized GDPR publications archive with deduplicated bibliographic metadata,
  • a historical-publications section that separates transition-period articles from current legal guidance,
  • a reviewed comparison of current EDPB guidance on anonymisation, pseudonymisation and breach handling,
  • a mapping of GLPI and NetXMS operational data to GDPR-relevant processing categories,
  • reusable evidence templates for DPIA, personal data breach assessment and security-of-processing reviews,
  • a privacy-aware monitoring/logging profile for operational and cybersecurity systems.