Category: GDPR DPO

A Practical Guide for DPOs and In-House Legal Teams

Artificial intelligence has quietly become part of everyday work. From productivity assistants to document summaries and email suggestions, most organisations already use AI without realising it. These technologies bring efficiency, but they also raise important questions for data protection and compliance professionals: how do you manage accountability, explainability, and transparency without overburdening your governance processes?

The EU AI Act offers a clear framework for doing exactly that. It classifies AI systems according to the level of risk they pose to people’s rights or safety. The EU AI Act distinguishes between unacceptable, high, and certain limited-risk systems. The term ‘minimal or no risk’ is commonly used to describe AI systems that fall outside the specific obligations of the Act. For most organisations, the focus will be on the last two categories. They cover the vast majority of AI systems in day-to-day use, tools that enhance productivity rather than make high-stakes decisions.

This article explains what minimal and limited risk systems are, what the EU AI Act expects of organisations that use them, and how DPOs and legal teams can embed proportionate AI governance into existing compliance frameworks.

Understanding the EU AI Act’s Risk Approach

The Act’s design is rooted in proportionality. It does not impose heavy regulation on every AI tool. Instead, it scales obligations according to the potential impact on people.

• Unacceptable risk systems are banned altogether. These include manipulative or exploitative AI such as social scoring or subliminal techniques.
• High risk systems are strictly regulated and typically found in sectors such as health, employment, education, credit scoring, or law enforcement.
• Limited risk systems require transparency measures so that users know when they are engaging with AI.
• Minimal risk systems carry no specific legal obligations beyond general laws such as the GDPR and consumer protection rules.

This tiered approach is important because it allows innovation to continue while protecting fundamental rights. For most DPOs and legal teams, the challenge is to translate those tiers into practical governance actions that fit within existing processes rather than duplicating them.

Why Minimal and Limited Risk Matter Strategically

It would be easy to treat these categories as purely technical or compliance-driven. In reality, they sit at the heart of strategic governance.

Accurately classifying AI systems defines how organisations can innovate safely. It helps determine when a full risk assessment is required, when lighter documentation will suffice, and how to prioritise oversight. More importantly, it demonstrates to regulators, partners, and customers that the organisation understands its responsibilities and has a defensible approach to accountability.

This is not simply about avoiding fines. Clear classification also builds trust and confidence among staff and clients. When people know how and why AI is being used, the organisation’s reputation for transparency and ethical practice grows stronger. That is particularly valuable in markets where trust is a differentiator, such as healthcare, finance, and technology.

Minimal Risk AI: Low Impact, High Accountability

Minimal risk AI refers to systems that present little or no potential to affect individuals’ rights or safety. They typically automate small, low-stakes tasks, often in the background, and do not involve profiling or decision-making.

Common examples include:

• Grammar and spelling assistants.
• Autocomplete and predictive text.
• Search or document retrieval tools.
• Spam filters and simple categorisation algorithms.

The EU AI Act imposes no direct obligations on these systems, but good governance remains essential. Accountability underpins both the Act and the GDPR. DPOs should ensure that minimal risk systems are visible in governance registers and can be explained if questions arise.

Practical steps for managing minimal risk AI:

• Keep a short internal note in your DPIA or processing record identifying the system, its function, and your rationale for minimal risk classification.
• Record the supplier, model version, and location of any data processed.
• Periodically review the system to ensure that its functionality has not evolved into areas such as profiling or analytics that might alter the risk level.

Minimal risk does not mean no oversight. A one-page record of your reasoning is often enough to show accountability, but it is also a valuable signal of organisational maturity.

The difference between minimal and limited risk is not about technical complexity but about human impact. Once AI begins interacting with people or generating information that could shape perceptions or decisions, transparency becomes the key dividing line.

Limited Risk AI: Where Transparency Becomes the Safeguard

Limited risk systems are those that interact with users directly or generate synthetic content but are not used in sensitive or high-risk contexts. Their primary risk lies in misunderstanding, in that people may not realise they are engaging with AI or may over-rely on outputs.

Examples include:

• Chatbots and virtual assistants.
• Tools that generate text, audio, or images.
• Meeting transcription or summarisation services.
• Productivity assistants that draft, summarise, or recommend actions.

For limited risk AI, the EU AI Act focuses on transparency obligations. Transparency obligations for certain AI systems, such as chatbots, emotion recognition, and systems generating synthetic content, are set out in Article 50 of the AI Act. Users must:

• Be clearly informed that they are interacting with AI.
• Users must be informed that content has been generated or manipulated by AI.
• Be able to identify AI-generated or synthetic content from notifications.
• Understand the capabilities and limitations of the system.

The goal is not to stop organisations using these tools, but to make sure people know when AI is at work and can interpret its outputs appropriately.

Practical steps include:

• Maintain a register of all limited risk AI systems with notes on their transparency measures.
• Confirm that user interfaces display clear AI notices or indicators.
• Keep vendor documentation that demonstrates compliance with the EU AI Act’s transparency articles.
• Incorporate transparency records into your DPIA or a dedicated AI governance appendix.

Transparency is the safeguard for limited risk AI. When users understand when AI is involved, how it works, and what it cannot do, most of the compliance risk disappears.

A Practical Example: Microsoft 365 Copilot

Microsoft 365 Copilot illustrates limited risk AI in action. Microsoft 365 Copilot would typically fall within the limited-risk category when used for general productivity tasks, but classification may change depending on context (for example, HR decision-making could raise the risk level). It operates inside familiar tools such as Word, Outlook, Excel, and Teams, using the organisation’s existing data. Copilot is not creating a new dataset, but it changes how that data is accessed and used.

DPOs can approach Copilot systematically:

1. Map the data flow. Identify what sources Copilot draws from. Most will already be governed under GDPR.
2. Determine the risk tier. Copilot’s summarisation and drafting features fall within the limited risk category.
3. Ensure transparency. Provide staff training and internal guidance making it clear that Copilot uses AI and that outputs require human review.
4. Verify supplier compliance. Keep copies of Microsoft’s documentation on Copilot’s AI model, transparency commitments, and security measures.
5. Reassess periodically. If Copilot is later used in HR or decision-making contexts, reclassify it as high risk, if applicable, and expand governance accordingly.

Copilot is a good example of how limited risk AI sits inside existing compliance frameworks. The AI layer does not replace GDPR obligations; it adds a transparency layer on top.

Managing Vendors and Third-Party AI

AI governance does not end with in-house systems. Third-party vendors and cloud providers are increasingly embedding AI functionality into standard software packages. DPOs need to know what these systems are doing and how they fit into the organisation’s risk profile.

Practical supplier governance steps include:

• Updating vendor due diligence questionnaires to include AI-specific questions.
• Requiring suppliers to disclose whether their systems use AI and, if so, how they classify it under the EU AI Act.
• Ensuring contracts contain obligations for transparency and notification of material changes in functionality.
• Reviewing third-party privacy notices to check alignment with your organisation’s transparency commitments.

This supplier awareness is critical because many limited risk systems will enter the organisation indirectly through updates or integrated features. A question as simple as “Does this system now use AI?” should become part of routine vendor management.

Combining AI Risk Assessment with DPIAs

AI risk assessments and GDPR DPIAs often apply to the same technology. Running them separately wastes time and risks inconsistency. A combined assessment provides a single, coherent record of compliance.

A practical two-in-one approach looks like this:

1. Begin with your existing DPIA template.
2. Add an AI section that determines the system’s risk tier under the EU AI Act.
3. Cross-reference overlapping controls, such as fairness, accuracy, and human oversight.
4. Record your rationale for classification and any transparency measures applied.

This combined model makes your documentation more efficient and defensible. It also shows regulators that the organisation is integrating AI governance within established privacy processes rather than treating it as a siloed exercise.

You do not need separate compliance tracks for AI and data protection. A single integrated DPIA with an AI addendum provides a clear, practical, and efficient approach to governance.

Building a Culture of Transparency and Awareness

AI compliance is not just a technical task. It depends on awareness across the organisation. Many risks arise not from deliberate misuse but from lack of understanding about where AI is operating.

DPOs can help by:

• Training staff to recognise when systems might use AI and how to disclose it.
• Including AI awareness in induction and refresher compliance training.
• Providing a clear reporting route for staff who introduce new AI tools or discover them within existing systems.
• Encouraging open discussion about AI ethics and bias without creating a culture of fear.

A culture of awareness ensures that AI deployments are surfaced early, documented properly, and reviewed for transparency obligations before they create regulatory problems.

The Case for Public AI Transparency Policies

Every organisation using AI should have a concise AI Transparency Policy available to the public. While not required by the EU AI Act, publishing a short AI transparency statement is a good practice for accountability and public trust. This policy communicates the organisation’s position, shows leadership, and demonstrates accountability in a visible way.

A strong policy should:

• Outline what types of AI systems are used and for what purpose.
• Describe how each category is governed and classified under the EU AI Act.
• Explain how transparency and fairness are maintained.
• Provide a contact route for questions or concerns.

For user-facing services, an AI indicator icon or short disclosure note linking directly to the policy can make transparency tangible. This approach mirrors cookie banners and privacy notices, ideally short, accessible, and visible.

Transparency builds confidence. A clear policy and visible AI indicator show that the organisation is proud of its responsible practices rather than hiding them in small print.

Questions to Ask in Governance and Board Meetings

Board and compliance meetings are where accountability becomes visible. Directors and senior managers do not need to be AI experts, but they should know how to ask the right questions. These conversations build oversight and reinforce the organisation’s duty to monitor risk.

Useful questions include:

• Do we have a current and published AI Transparency Policy?
• Is there an AI systems register, and who maintains it?
• What models or third-party tools are currently in use across our environment?
• Do we ask suppliers to confirm whether their products include AI components or use third-party models?
• Have our DPIA templates been updated to include AI classification and transparency checks?
• Who reviews risk classifications and re-evaluates systems as they evolve?
• How do we communicate AI use internally to staff and externally to clients or regulators?

Governance is not about knowing every detail of how AI works. It is about asking questions that reveal whether proper control and understanding are in place.

Regularly reviewing these questions in board meetings keeps AI governance aligned with other corporate risks. It also creates an audit trail showing active oversight which is a powerful indicator of accountability.

Roles and Accountability in AI Oversight

AI governance often sits across several functions. DPOs manage data protection, CISOs handle security, legal teams address contractual risk, and IT manages deployment. For many organisations, the best approach is to establish a cross-functional AI governance group.

This group should:

• Meet periodically to review the AI systems register and any new implementations.
• Ensure consistent interpretation of risk classification.
• Align AI oversight with broader risk frameworks such as ISO 27001, NIST AI RMF, or internal ethics committees.
• Report key findings to senior management and the board.

A shared model of accountability prevents gaps and ensures that AI risks are addressed from both ethical and operational perspectives.

Looking Ahead: The Future of AI Governance

The EU AI Act is the first comprehensive AI regulation, but it will not be the last. Global frameworks are converging. The NIST AI Risk Management Framework, OECD principles, and upcoming UK AI Assurance Guidance all reinforce similar ideas: risk-based classification, transparency, human oversight, and accountability.

Organisations that build governance structures now, even for minimal and limited risk AI, will be well positioned as new standards evolve. The European Commission’s AI Office, expected to oversee implementation, will likely emphasise documentation and transparency as core indicators of compliance maturity.

Future audits may ask to see your AI systems register, transparency policy, and evidence of staff awareness. Starting small, with minimal and limited risk systems, ensures that governance habits are already in place when oversight becomes more formal.

Bringing It All Together

The EU AI Act provides an opportunity, not a burden. For most organisations, compliance will not mean complex technical changes, but thoughtful governance and clear communication. The EU AI Act entered into force on 1 August 2024, with most obligations, including transparency rules for limited-risk AI, becoming applicable from 2 August 2026.

By classifying systems accurately, integrating AI risk assessment into DPIAs, maintaining a public transparency policy, managing supplier disclosures, and embedding awareness at all levels, DPOs and legal teams can meet the requirements confidently.

Minimal and limited risk AI may seem low on the regulatory ladder, but they represent the foundation of responsible AI use. Transparent documentation, consistent oversight, and honest communication will not only meet compliance expectations but also strengthen trust, with clients, employees, and regulators alike.

Compliance done the right way is not about doing everything; it is about doing the right things properly, documenting them clearly, and being open about how technology is used. That is how ethical organisations turn regulation into a mark of integrity.

Safeguarding Data Protection and Privacy in Research: Data Protection Impact Assessments and the Clinical Trials Landscape

Clinical trials form the cornerstone of biomedical progress. They provide the evidence base for new therapies, diagnostics, and medical devices, all while involving some of the most sensitive categories of personal data. In an era of increasingly decentralised studies, complex data flows, and cross-border collaboration, the governance of personal data in clinical research has become as vital as the scientific protocols themselves. This reality places data protection and in particular, the requirement to conduct Data Protection Impact Assessments (DPIAs) at the heart of ethically and legally robust trials.

Across the European Union and European Economic Area, the General Data Protection Regulation (GDPR) sets a clear expectation: where processing is likely to result in a high risk to individuals’ rights and freedoms, a DPIA is not merely advisable — it is mandatory. The processing of special category data, such as health-related information, triggers heightened scrutiny. In clinical trials, this scrutiny is more than procedural. It touches on participant autonomy, data sovereignty, and the fundamental trust between the research community and society.

This article explores the DPIA obligation in the context of clinical trials, drawing from authoritative guidance developed by Ireland’s National Clinical Trials Oversight Group (NCTOG) and supported by the Irish Data Protection Commission (DPC). It situates these responsibilities within the broader framework of EU data protection law, while also reflecting the operational realities faced by sponsors, investigators, ethics committees, and Data Protection Officers (DPOs).

A Regulatory Imperative, Not a Formality

At its core, a DPIA is a structured process that enables organisations to identify, assess, and mitigate risks associated with personal data processing. It embodies the GDPR’s principle of accountability and operationalises the concept of privacy by design. While DPIAs may take different formats depending on the nature and scale of processing, their objective remains consistent: to anticipate data protection risks before they materialise, and to document the rationale behind the chosen safeguards.

Clinical trials typically involve the systematic collection and analysis of data concerning participants’ health, genetic information, lifestyle, and sometimes even biometric or behavioural data. The processing often occurs over extended periods, involves multiple entities across jurisdictions, and uses advanced technologies such as electronic data capture systems, cloud-based trial management platforms, and artificial intelligence tools for statistical analysis or remote monitoring. Each of these dimensions amplifies the potential risk to data subjects.

Under Article 35(3) of the GDPR, a DPIA is required in situations involving the large-scale processing of special category data or systematic monitoring of individuals. These criteria are routinely met in the design and conduct of clinical trials. It is therefore essential for sponsors and sites to treat the DPIA not as a tick-box requirement, but as an embedded part of the trial planning process.

Defining Roles: Controllers, Processors and Joint Arrangements

A fundamental step in assigning DPIA responsibility is determining the role of each participating organisation. The GDPR distinguishes between data controllers, who determine the purposes and means of processing, and data processors, who act on a controller’s documented instructions.

In the clinical trial domain, the sponsor is frequently the entity that defines the protocol, determines the data that will be collected, and decides how it will be analysed. In such cases, the sponsor is clearly acting as a data controller. If the trial site which is typically a hospital or academic institution, simply follows the sponsor’s protocol and manages data on the sponsor’s behalf, it functions as a processor.

However, not all arrangements are so straightforward. Increasingly, trial sites participate in protocol design, select subsets of data to retain locally, or use the data for secondary research. Where decision-making around data processing is shared, the sponsor and site may be deemed joint controllers under GDPR (Art. 26). This designation carries specific obligations, including the need for a transparent joint controller agreement and a clear delineation of responsibilities toward data subjects.

In both the controller–processor and joint controller scenarios, the responsibility for conducting a DPIA lies with those determining the purposes and means of processing. Where roles are shared, the parties must reach a practical and lawful arrangement for completing the DPIA. The NCTOG guidance confirms that local hospital DPOs and ethics committees are not responsible for the DPIA, although they may have supporting roles or be consulted during the process.

 

Responsibility / Factor	Sponsor as Controller	Trial Site as Processor	Joint Controllers (Sponsor & Site)	Independent Controllers
Determines purposes and means of processing	✔️	❌	✔️ (jointly)	✔️ (separately)
Initiates and conducts DPIA	✔️	❌	✔️ (collaborative or delegated)	✔️ (each independently)
Primary accountability under GDPR	✔️	❌	✔️ (shared)	✔️ (individual)
Requires joint controller or processor agreement	✔️ (Processor Agreement)	✔️	✔️ (Joint Controller Agreement)	❌
Consults with DPO before trial begins	✔️	❌	✔️ (both)	✔️ (each separately)
Handles data subject rights	✔️	❌ (unless instructed)	✔️ (must coordinate)	✔️ (each controller)
Provides data protection notice	✔️	❌	✔️ (joint or coordinated)	✔️ (individually)
Defines legal basis and mitigates risk	✔️	❌	✔️ (shared or divided)	✔️ (each independently)

 

The Ethics Committee Is Not the DPO

One of the more persistent misconceptions in the clinical trial landscape is the belief that ethics committee approval substitutes for a DPIA. This confusion stems from the fact that both processes occur early in the study lifecycle and are designed to safeguard participants’ interests. However, they are fundamentally distinct.

An ethics committee evaluates the clinical rationale, safety considerations, and integrity of the informed consent process. It assesses whether the proposed research design is proportionate, scientifically valid, and ethically sound. Data protection may be mentioned, but it is not the central focus. In contrast, a DPIA scrutinises the data processing elements of the project. It examines the lawfulness of processing, the compatibility of purposes, data minimisation strategies, storage limitations, security measures, and the extent to which data subjects can exercise their rights.

The GDPR is explicit on this point. DPIA obligations exist independently of other sector-specific approvals. Ethics committees are not tasked with reviewing DPIAs, and a trial may require additional safeguards beyond those imposed by ethics boards. The distinction must be respected to ensure that data protection responsibilities are not overlooked or fragmented.

DPIAs in Practice: Timing, Consultation, and Iteration

A well-conducted DPIA begins well before the first participant is enrolled. It should form part of the initial feasibility and risk assessment stages of the trial, when data flows are being designed and operational partners are being selected. Delaying the DPIA until after key decisions are made diminishes its value and can expose the sponsor to unnecessary regulatory risk.

The GDPR encourages the consultation of a DPO where one has been appointed. In clinical research, this consultation is not only legally prudent but practically beneficial. DPOs can bring critical insights regarding data retention schedules, international transfers, lawful bases for processing under both Articles 6 and 9, and mechanisms for handling data subject rights. Where multiple jurisdictions are involved, local DPOs or legal experts may be consulted to address national derogations or ethics frameworks.

The DPIA should not be treated as a static document. Clinical trials often evolve through protocol amendments, new study arms, or technology upgrades. Each of these changes may affect the data processing landscape. Sponsors should revisit and, where necessary, revise their DPIAs in response to these developments. This iterative approach aligns with the accountability principle and positions the DPIA as a living instrument rather than a bureaucratic artefact.

Distinguishing Medical Consent from GDPR Consent

In the context of clinical trials, the concept of “consent” carries distinct legal and ethical meanings depending on the framework in which it is applied. One of the most frequent sources of confusion, both among research professionals and participants, is the assumption that informed medical consent automatically satisfies the requirements for valid consent under data protection law. However, this is not the case.

Medical or clinical consent relates to a person’s agreement to participate in a clinical trial or medical intervention. It is governed by ethical and clinical standards, typically overseen by ethics committees and national legislation. This form of consent ensures that participants understand the purpose, procedures, potential risks, and benefits of the study, and that their decision to participate is voluntary, informed, and free from coercion.

By contrast, GDPR consent is one of several legal bases available for processing personal data under Article 6 of the General Data Protection Regulation. When special category data such as health information is involved, as it nearly always is in clinical trials, Article 9 also applies, requiring a separate condition to legitimise processing. GDPR consent is defined by a strict set of criteria: it must be freely given, specific, informed, unambiguous, and capable of being withdrawn at any time, without detriment.

These differences have practical consequences. While informed consent is ethically indispensable for trial participation, it may not always be the appropriate or reliable legal basis for processing personal data under GDPR. This is especially true in scenarios where the data processing is essential to comply with legal obligations, to perform a task in the public interest, or to fulfil the sponsor’s legitimate interests, provided that such interests are not overridden by the rights and freedoms of the participant.

Moreover, GDPR consent must be separable from clinical consent. Participants must be able to decline or withdraw their data processing consent without necessarily withdrawing from the trial itself, which is not always feasible in practice. As a result, many sponsors and ethics boards prefer to rely on alternative lawful bases such as public interest in the area of public health or scientific research purposes under Article 9(2)(j), supported by appropriate safeguards such as pseudonymisation, data minimisation, and robust governance controls.

Ultimately, it is crucial to treat medical and data protection consents as distinct instruments serving different legal and ethical purposes. DPIAs offer a valuable opportunity to document this distinction, justify the choice of lawful basis for data processing, and ensure that participant-facing materials clearly explain the difference. This approach not only enhances compliance but also reinforces transparency and respect for the individuals at the heart of the research.

Documentation, Transparency and Responding to Challenges

The value of a DPIA lies not only in its risk analysis but also in its documentation. Regulatory authorities may request evidence that the DPIA was completed and that appropriate mitigation measures were implemented. In high-risk cases where the DPIA indicates that the processing would still result in significant residual risks, the controller must consult the relevant supervisory authority before proceeding. While such consultations are rare in clinical trials, sponsors must be prepared to demonstrate that they considered the option if applicable.

Transparency is equally important. While the DPIA itself is not typically published, its outcomes may be summarised in participant information leaflets or data protection notices. These summaries should strike a balance between accessibility and accuracy, enabling participants to understand how their data will be used, protected, and governed.

Responding to data subject requests whether for access, rectification, or objection is another area where the DPIA can prove useful. It should outline the procedures for managing such requests, especially where joint controller arrangements are in place. Clarity on responsibilities can help avoid delays and ensure consistent communication with participants.

Supervisory Oversight: Ireland’s DPC and Broader EU Implications

The NCTOG guidance, reviewed and approved by Ireland’s Data Protection Commission, offers a structured and practical interpretation of DPIA responsibilities in clinical trials. While it reflects the Irish regulatory environment, its core principles are aligned with guidance from the European Data Protection Board (EDPB) and are applicable across the EU.

Sponsors operating multinational trials should be alert to national variations in ethics oversight, data protection enforcement, and health legislation. Some Member States impose additional conditions on processing health data, particularly in the context of public health or scientific research. These conditions may affect the DPIA content or consultation processes. Engaging with local DPOs and legal counsel is therefore essential in cross-border settings.

From a regulatory risk perspective, supervisory authorities increasingly expect organisations to demonstrate not only formal compliance but substantive accountability. A DPIA that is generic, outdated, or disconnected from operational practice will not withstand scrutiny. Conversely, a well-reasoned and evidence-based DPIA can serve as a shield in the event of complaints or inspections.

Looking Ahead: Embedding DPIAs in Research Culture

The ultimate goal of data protection law is not to obstruct research but to enable it in a way that respects the dignity and autonomy of individuals. In this sense, DPIAs are not a burden but a tool of empowerment. They prompt researchers to consider the ethical and legal dimensions of data use at every stage of the trial. They foster interdisciplinary collaboration between scientific, legal, and technical teams. They provide transparency and reassurance to participants who entrust their data to the research enterprise.

For sponsors and investigators, this means moving beyond minimal compliance and toward a culture of proactive privacy management. For DPOs, it means engaging with research teams early and often, providing pragmatic advice that supports both innovation and data protection. For oversight bodies and ethics committees, it means clarifying their respective roles and encouraging alignment across governance processes.

As the clinical trials landscape becomes more digital, decentralised, and data-driven, the importance of DPIAs will only grow. By investing in robust, context-sensitive DPIAs, the research community can strengthen its social license, mitigate legal risks, and uphold the foundational values of trust, transparency, and respect.

At XpertDPO, we partner with organisations across a diverse range of industries to help them achieve resilient compliance, protect personal data, and build operational resilience in line with GDPR, EU AI Act, NIS2, DORA, and evolving cybersecurity frameworks. Our sector-specific knowledge ensures practical, risk-based solutions, whether you’re a small charity, a fintech scale-up, or a public body under regulatory scrutiny.

From financial services and healthcare to education, technology, and public sector organisations, we tailor our solutions to address industry-specific risks, data protection requirements, and cybersecurity threats. Our experience spans highly regulated sectors, ensuring businesses remain resilient, compliant, and well-prepared for evolving data protection laws.

Whether you need outsourced DPO support, regulatory audit assistance, or data security guidance, XpertDPO delivers pragmatic, effective solutions through qualified seasoned data protection officers to help you navigate compliance with confidence.

Healthcare

• Key Focus: Patient data security, GDPR compliance, handling sensitive health records.
• Challenges: AI innovation implementations and ensuring compliance with GDPR for patient records, managing Subject Access Requests (SARs), mitigating data breaches.
• How We Help: XpertDPO provides AI and GDPR consultancy, SAR support, and outsourced DPO services for healthcare providers.

Why Data Protection Matters in Healthcare:

The healthcare sector processes highly sensitive patient data, making compliance with jurisdictional regulations such as GDPR, HIPAA (for US-linked entities), and NIS2 crucial for data security, patient confidentiality, and regulatory oversight.

Key Data Protection challenges in Healthcare:

• Strict Regulatory Requirements: Compliance with GDPR, national health data laws, and cybersecurity directives.
• Cybersecurity Threats: Increased risk of ransomware attacks and data breaches affecting patient records.
• Data Sharing & Consent Management: Handling electronic health records (EHRs) and cross-border data transfers.
• Incident Response & Reporting: Managing breach notification obligations within tight regulatory timeframes.

How We Help Healthcare Organisations with Data Protection:

XpertDPO supports healthcare organisations with GDPR and AI compliance frameworks, DPIAs, cybersecurity risk management, and breach response strategies. Our expertise ensures secure patient data handling, regulatory adherence, and enhanced resilience against cyber threats.

Public Sector

• Key Focus: Compliance with GDPR and NIS2 for government and public institutions.
• Challenges: Protecting citizen data, managing regulatory reporting requirements, handling Subject Access Requests (SARs).
• How We Help: Outsourced DPO services, GDPR audits, and compliance support for government bodies.

Why Data Protection Matters:

Government agencies process citizen data, making compliance with GDPR, NIS2, and national cybersecurity laws essential to prevent data breaches and ensure public trust.

Key Challenges:

• Strict Data Security Requirements: Meeting GDPR and national security regulations.
• Cyber Threats & Ransomware Attacks: Government agencies face increasing cyber risks.
• Handling Public Data Requests: Managing DSARs and Freedom of Information (FOI) requests securely.
• Cross-Agency Data Sharing Risks: Ensuring lawful, secure data exchanges between departments.

How We Help:

XpertDPO provides public sector data protection audits, regulatory compliance guidance, DSAR and FOI request management, and cybersecurity risk assessments. Our solutions help government bodies enhance data security and public trust.

Financial Services

• Key Focus: Compliance with GDPR, DORA, and cybersecurity frameworks.
• Challenges: Protecting financial data, maintaining compliance with evolving regulations, preventing fraud and breaches.
• How We Help: Advisory services for GDPR, DORA compliance, and supervisory authority engagement.

Why Data Protection Matters in Financial Services:

The financial sector handles highly sensitive customer data, making it a prime target for cyberattacks, fraud, and regulatory scrutiny. Compliance with GDPR, DORA, NIS2, and PCI-DSS is essential to ensure data security, operational resilience, and regulatory adherence.

Key Data Protection Challenges in Financial Services:

• Regulatory Compliance: Meeting strict GDPR, DORA, and anti-money laundering (AML) obligations.
• Cybersecurity Risks: Financial institutions are top targets for data breaches, phishing attacks, and ransomware.
• Third-Party Risk Management: Ensuring vendor and cloud service provider compliance with financial regulations.
• Incident Response & Reporting: Managing real-time breach response and regulatory notifications.

How We Help Financial Services Organisations with Data Protection:

XpertDPO provides specialist advisory services to help financial institutions navigate DORA, GDPR, and NIS2 compliance, manage third-party risks, and develop resilient cybersecurity frameworks. We offer GDPR audits, incident response planning, DPO support, and vendor risk assessments, ensuring financial organisations meet regulatory expectations while safeguarding sensitive data.

Med Tech

• Key Focus: Securing medical technology and digital health data under GDPR and NIS2.
• Challenges: Ensuring data privacy in connected health devices, managing patient data security risks.
• How We Help: Data protection gap analysis, compliance audits, and risk assessments for MedTech firms.

Why Data Protection Matters in Med Tech:

The MedTech sector is revolutionising healthcare with connected medical devices, digital health solutions, and AI-driven diagnostics. However, these innovations come with strict regulatory requirements, including GDPR, NIS2, MDR (Medical Device Regulation), IVDR (In Vitro Diagnostic Regulation), and HIPAA (for US-linked entities). Ensuring patient data security, regulatory compliance, and ethical AI use is critical for protecting individuals and maintaining trust in medical technology.

Key Data Protection Challenges in Med Tech:

• Compliance with GDPR, MDR, & NIS2: Managing complex data protection, cybersecurity, and regulatory approval requirements.
• Securing Patient & Health Data: Protecting electronic health records (EHRs), wearables, and IoT medical devices from cyber threats.
• Cross-Border Data Transfers & Cloud Security: Ensuring lawful global data processing and third-party compliance.
• AI & Algorithmic Transparency: Addressing risks in AI-powered diagnostics, automated decision-making, and patient profiling.
• Incident Response & Regulatory Reporting: Meeting data breach notification obligations within strict timeframes.

How We Help Med Tech Organisations with Data Protection:

XpertDPO provides specialist compliance support for MedTech companies, ensuring GDPR, MDR, and cybersecurity compliance. We assist with DPIAs, AI risk assessments, third-party vendor audits, cybersecurity frameworks, and incident response planning. Our expertise helps MedTech firms secure patient data, meet regulatory requirements, and build trust in digital health solutions.

Ensure compliance and data security in MedTech, contact XpertDPO today.

AI Regulation

• Key Focus: Ethical and legal compliance for AI-driven data processing.
• Challenges: Navigating GDPR in AI-based decision-making, transparency requirements, ensuring data security in machine learning models.
• How We Help: Advisory on AI governance, GDPR compliance for AI systems, and regulatory engagement.

Why Data Protection Matters in AI Regulation

As artificial intelligence (AI) becomes increasingly integrated into business operations, compliance with emerging AI regulations is essential to ensure transparency, fairness, and data protection. The EU AI Act, GDPR, and sector-specific regulations impose strict obligations on organisations developing or deploying AI-driven systems, particularly those handling personal data, automated decision-making, and high-risk applications.

Key Challenges in AI Regulation

• Compliance with the EU AI Act & GDPR: Ensuring AI systems meet risk classification, transparency, and data protection requirements.
• Bias, Fairness & Automated Decision-Making: Implementing safeguards to prevent discrimination and ensure lawful AI use.
• Data Security & Privacy Risks: Protecting training datasets, AI outputs, and personal data from misuse or breaches.
• Explainability & Accountability: Demonstrating how AI models make decisions, particularly in high-risk applications.
• Cross-Border AI Deployment: Navigating global regulatory landscapes for AI compliance.

How We Help Organisations comply with AI Regulation

XpertDPO provides AI governance and regulatory compliance services, ensuring businesses align with the EU AI Act, GDPR, and ethical AI principles. We assist with AI risk assessments, bias audits, data protection impact assessments (DPIAs), and regulatory reporting. Our experts help organisations develop responsible AI frameworks, enhance transparency, and mitigate legal risks associated with AI deployment.

Prepare for AI regulation, contact XpertDPO today.

Insurance

• Key Focus: Data security in policy management and claims processing.
• Challenges: Managing large volumes of personal data, preventing unauthorised access, ensuring compliance with GDPR.
• How We Help: GDPR consultancy, data processing audits, and compliance monitoring for insurers.

Why Data Protection Matters in Insurance

The insurance sector processes vast amounts of highly sensitive personal data, including financial, health, and biometric information. Compliance with GDPR, NIS2, DORA, Solvency II, and industry-specific data security regulations is critical to ensuring customer trust, regulatory adherence, and resilience against cyber threats.

Key Data Protection Challenges in the Insurance Sector

• Handling & Securing Sensitive Customer Data – Processing policyholder, claimant, and medical data while ensuring lawful, secure storage and transfers.
• Regulatory Compliance & Cross-Border Data Transfers – Meeting GDPR requirements for global operations, including Schrems II and Standard Contractual Clauses (SCCs).
• Cybersecurity & Fraud Prevention – Protecting against data breaches, ransomware, and fraudulent claims manipulation.
• Incident Response & Regulatory Reporting – Managing breach notification requirements under GDPR and NIS2.
• Automated Decision-Making & AI Risks – Ensuring fair, transparent use of AI and automated underwriting systems.

How We Help Insurance Organisations with Data Protection and Artifical Intelligence Compliance

XpertDPO supports insurance providers, brokers, and underwriters with GDPR compliance, data security audits, DORA resilience strategies, and regulatory reporting frameworks. Our outsourced DPO services, DSAR management, incident response planning, and AI governance expertise help insurers meet legal obligations, strengthen cybersecurity, and protect policyholder data.

Need expert data protection support for your insurance firm? Contact XpertDPO today.

Why Sector-Specific Expertise Matters

Compliance is never one-size-fits-all. Each sector faces unique challenges—from safeguarding and social work protocols in care settings to regulatory sandboxes in fintech. At XpertDPO, we blend legal expertise, technical audits, and operational know-how to offer tailored solutions that reflect the real risks and obligations in your field.

Our team includes lawyers, data protection officers, security engineers, and educators—all focused on building trust and reducing risk through pragmatic, compliant practices.

Let’s Talk

Are you looking for outsourced DPO services, DSAR support, AI governance, or regulatory response guidance? Get in touch for a tailored conversation about your sector’s needs.

Email us at info@xpertdpo.com
Visit xpertdpo.com

What is the GDPR?

The General Data Protection Regulation (GDPR) applies from 25 May 2018. It has general application to the processing of personal data in the EU, setting out more extensive obligations on data controllers and processors, and providing strengthened protections for data subjects. Although the GDPR is directly applicable as a law in all Member States, it allows for certain issues to be given further effect in national law. In Ireland, the national law, which, amongst other things, gives further effect to the GDPR, is the Data Protection Act 2018.

What is personal data?

The GDPR defines ‘personal data’ as any information relating to an identifiable person who can be directly or indirectly identified, in particular by reference to an identifier. This definition provides for a wide range of personal identifiers to constitute personal data, including name, identification number, location data or online identifier, reflecting changes in technology and the way organisations collect information about people.

Who must comply with the GDPR?

Any organisation that processes the personal data of people in the EU must comply with the GDPR. “Processing” is a broad term that covers just about anything you can do with data: collection, storage, transmission, analysis, etc. “Personal data” is any information that relates to a person, such as names, email addresses, IP addresses, eye colour, political affiliation, and so on. Even if an organisation is not connected to the EU itself, if it processes the personal data of people in the EU (via tracking on its website, for instance), it must comply. The GDPR is also not limited to for-profit companies.

What is a data controller and who is the data controller?

Data controllers are a person or organisation who (alone or with others) determines the purposes for which and the manner in which any personal data are, or are to be, processed. A data controller can be the sole data controller or a joint data controller with another person or organisation. However, when services are provided directly by private hospital, voluntary hospitals, agencies or private contractors, the private hospital, voluntary hospital, agency or private contractor may be the data controller.

What is a data processor?

Data processors are those that processes personal data on behalf of the controller. This does not include an employee of the controller who processes data during the course of their employment. A data processor can be held liable if they are responsible for a data protection breach.

What is data processing?

Processing in relation to personal data is any operation or set of operations performed on personal data including – collecting, recording, organising, structuring, erasing, destroying, altering, combining, disclosing or sharing the data.

What are the main GDPR principles?

• Lawful, Fair and Transparent: Personal Data processed lawfully, fairly and in a transparent manner in relation to individuals;
• Purpose Limitation: Personal data must be collected for specified, explicit and legitimate purposes and not further processed in a manner that is incompatible with those purposes; further processing for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes shall not be considered to be incompatible with the initial purposes.
• Data Minimisation: Personal data collected must be adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed
• Accuracy: Personal data must be kept accurate and, where necessary, kept up to date; every reasonable step must be taken to ensure that personal data that are inaccurate, having regard to the purposes for which they are processed, are erased or rectified without delay.
• Storage Limitation: Personal Data must be kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed; personal data may be stored for longer periods insofar as the personal data will be processed solely for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes subject to implementation of the appropriate technical and organisational measures required by the GDPR in order to safeguard the rights and freedoms of individuals
• Confidentiality and Integrity: Personal Data must be processed in a manner that ensures appropriate security of the personal data, including protection against unauthorised or unlawful processing and against accidental loss, destruction or damage, using appropriate technical or organisational measures.
• Accountability: The Data Controller shall be responsible for, and be able to demonstrate compliance with the data protection principles

Can I send marketing emails using Legitimate Interests as the Lawful Basis for processing if I cannot prove consent?

“Most of our database is made up of historical quotations or previous customers but under GDPR, just because they have gotten a quote from us or bought from us doesn’t actually give us the right to use their data for marketing purposes. Is this correct?”.

Answer: When you originally sold, quoted or marketed products or services did you offer an opt-out at point of sale?

If the answer is yes, you may be able to rely on ‘soft opt-in’.

If you did not offer an ‘opt-out’ then you will need consent. If you cannot reference an affirmative opt-in or consent then you do not have the data subject’s permission, therefore you cannot send marketing emails.

Fig 1: Legitimate Interests Assessment

Remember, it’s PECR (Privacy and Electronic Communications Regulations) that regulates e-marketing NOT GDPR. Legitimate Interests IS NOT a lawful basis for electronic marketing under PECR.

Opt-in has to be specific, informed and freely given and if you are relying on the ‘soft opt-in’ you can only use it for marketing/promotion of your OWN products/services. So an opt-in is the cleanest way to start a new list.

See here some useful links in relation to PECR: Statutory Instrument 336 of 2011 (Ireland) and ICO (UK) Guide to PECR

I have heard that Processing Contracts must be updated for GDPR. What must be included?

The GDPR introduces direct obligations and potential liabilities on the Controller AND Processor. The GDPR requires a legally binding contract between the Data Controller and the Data Processor(s).

There are Compulsory details that must be included:

• The subject matter and duration of the processing;
• The nature and purpose of the processing;
• The type of personal data and the categories of data subject; and
• The obligations and rights of the controller

Compulsory terms:

• The processor must only act on the written instructions of the controller (unless required by law to act without such instructions);
• The processor must ensure that people processing the data are subject to a duty of confidence;
• The processor must take appropriate measure to ensure the security of processing;
• The processor must only engage a sub-processor with the prior consent of the data controller and a written contract;
• The processor must assist the data controller in providing subject access and allowing data subjects to exercise their rights under the GDPR;
• The processor must assist the data controller in meeting its GDPR obligations in relation to the security of processing, the notification of personal data breaches and data protection impact assessments;
• The processor must delete or return all personal data to the controller as requested at the end of the contract; and
• The processor must submit to audits and inspections, provide the controller with whatever information it needs to ensure that they are both meeting their Article 28 obligations, and tell the controller immediately if it is asked to do something infringing the GDPR or other data protection law of the EU or a member state.

What do you we need to document under Article 30 of the GDPR?

• The name and contact details of your organisation (and where applicable, of other controllers, your representative and your data protection officer)
• The purposes of your processing
• A description of the categories of individuals and categories of personal data
• The categories of recipients of personal data
• Details of your transfers to third countries including documenting the transfer mechanism safeguards in place
• Retention schedules
• A description of your technical and organisational security measures

Should we document anything else?

As part of your record of processing activities, it can be useful to document (or link to documentation of) other aspects of your compliance with the GDPR and the UK’s Data Protection Act. Such documentation may include:

Information required for privacy notices, such as:

• The lawful basis for the processing
• The legitimate interests for the processing
• Individuals’ rights
• The existence of automated decision-making, including profiling
• The source of the personal data
• Records of consent
• Controller-processor contracts
• The location of personal data
• Data Protection Impact Assessment reports;
• Records of personal data breaches

Information required for processing special category data or criminal conviction and offence data under the Data Protection Act, covering:

• The condition for processing in the Data Protection Act
• The lawful basis for the processing in the GDPR
• Your retention and erasure policy document

XpertDPO has provided feedback to the European Data Protection Board (EDPB) on Recommendations 1/2022 on the Application for Approval and on the elements and principles to be found in Controller Binding Corporate Rules (Art. 47 GDPR).

The EDPB recommendations build upon the agreements reached by data protection authorities during approval procedures on concrete BCR applications since the GDPR came into force. They also bring the existing guidance in line with the requirements in the Court of Justice of the European Union’s Schrems II ruling, providing clarity for controllers relying on Binding Corporate Rules for international data transfers.

XpertDPO welcomes the EDPB’s recommendations and its efforts to ensure a level playing field for all BCR applicants. While the recommendations provide a standard form for the application for approval of BCR for controllers (BCR-C) and clarify the necessary content of a BCR-C, there is still scope for more standardisation to simplify the process for companies considering BCRs as an appropriate safeguard for transfers of personal data to third countries.

XpertDPO’s detailed submission to the public consultation has been published on the EDPB website and can be read here. If you wish to find out more about the approval process for Binding Corporate Rules you can contact XpertDPO at info@xpertdpo.com or on +353 1 678 8997.

The A to Z of GDPR: Glossary of Key Data Protection Terms and Concepts

Welcome to XpertDPO’s definitive GDPR A to Z glossary – your expert guide to the most important terms and principles under the General Data Protection Regulation (GDPR). Whether you’re a Data Protection Officer (DPO), compliance lead, business owner or privacy enthusiast, this glossary breaks down complex data protection terms into clear, practical explanations. Use this page to understand your obligations, educate your team, or support your GDPR training efforts.

Each entry is designed to help you comply with GDPR, respond to regulatory requirements, and embed a culture of data protection in your organisation. From Accountability to Zero Trust, explore the A–Z now.

Looking to go beyond the basics? XpertAcademy offers practical GDPR training and certification for teams of all sizes. Or, if you need hands-on help with compliance, explore our Outsourced DPO support or DPO Support services. At XpertDPO, we don’t just define data protection – we deliver it.

Bookmark this page and check back as we expand this glossary with new terms and updates in line with evolving privacy regulations like the AI Act, NIS2 and DORA. For real-time compliance advice, contact our team of data protection specialists today.

When we are working with prospective or new clients, we are often asked this question. There isn’t a short answer but we will highlight some steps you can take to begin to demonstrate that you are complying with the GDPR. This is not an exhaustive list by any means, but is intended to be a set of proactive steps.

The General Data Protection Regulation (GDPR) relates to the processing of ‘Personal Data’. Unfortunately, and this is where there is lots of confusion, the GDPR does not provide a definitive list of items that are considered Personal Data. The GDPR, in Article 4(1) states

‘personal data’ means any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person;

So, to break that down, the GDPR relates to data that either on its own (directly), or in conjunction with other data (indirectly) that can be used to identify a living human being.

The GDPR also describes the concepts of Data Controllers and Data Processors. A data controller could either be an organisation (e.g. bank, retailer) or an individual (e.g. general practitioner) that collects and processes information about customers, patients, etc. Under the GDPR, the data controller is responsible for ensuring that data is processed in compliance with the principles of lawfulness, fairness, transparency, data minimisation, accuracy, storage limitation, integrity, and confidentiality. A Data Controller generally makes the decisions around the what, why, who, when and how personal data will be processed.

So, if you are running a business and employing staff, you are a data controller for that processing. You must keep in mind here that the GDPR does NOT just apply to large organisations. Individuals, SMEs, community groups and not for profit organisations who process personal data are all responsible for complying with the GDPR. There is no differentiator in the application of the principles of the GDPR in terms of the organisation size.

One of the most important obligations that organisations have is preparing Records of Processing Activity (RoPA). Article 30 of the GDPR details the requirements and responsibilities of Data Controllers in relation to these records.

In our experience, many organisations have inadequate RoPA and there are organisations that are not aware that this is a requirement.

So, if you are a Data Controller, you will need to maintain documentation that details the following:

1. the name and contact details of the [Data] controller and, where applicable, the joint controller, the controller’s representative and the data protection officer;
2. the purposes of the processing;
3. a description of the categories of data subjects and of the categories of personal data;
4. the categories of recipients to whom the personal data have been or will be disclosed including recipients in third countries or international organisations;
5. where applicable, transfers of personal data to a third country or an international organisation, including the identification of that third country or international organisation and, in the case of transfers referred to in the second subparagraph of Article 49(1), the documentation of suitable safeguards;
6. where possible, the envisaged time limits for erasure of the different categories of data;
7. where possible, a general description of the technical and organisational security measures referred to in Article 32(1).

Many organisations believe that they are not responsible for maintaining these records as they are only small entities. This is, in many cases, incorrect.

There are some exemptions to maintaining these records. Article 30(5) states:

The obligations … shall not apply to an enterprise or an organisation employing fewer than 250 persons unless the processing it carries out is likely to result in a risk to the rights and freedoms of data subjects, the processing is not occasional, or the processing includes special categories of data as referred to in Article 9(1) or personal data relating to criminal convictions and offences referred to in Article 10.

Your organisation may not process data that results in a risk, let alone high risk, to the data subjects. Likewise, you may not process special category data or data relating to criminal convictions or offences but, you will be processing more frequently than occasionally. There is guidance form the European data Protection Board (EDPB) to this effect, they state:

‘To take account of the specific situation of micro, small and medium-sized enterprises, this Regulation includes a derogation for organisations with fewer than 250 employees with regard to record – keeping’…

Therefore, although endowed with less than 250 employees, data controllers or processors who find themselves in the position of either carrying out processing likely to result in a risk (not just a high risk) to the rights of the data subjects, or processing personal data on a non-occasional basis, or processing special categories of data under Article 9(1) or data relating to criminal convictions under Article 10 are obliged to maintain the record of processing activities.

However, such organisations need only maintain records of processing activities for the types of processing mentioned by Article 30(5).

For example, a small organisation is likely to regularly process data regarding its employees. As a result, such processing cannot be considered “occasional” and must therefore be included in the record of processing activities.

Finally, In addition to the RoPA, it would be recommended that your organisation drafts and maintains a library of supporting documentation in support of your GDPR compliance program. Again, the GDPR does not provide us with a definitive list but, we have seen Data Processing Agreements, Data Protection Policy, ICT Policy, Password Policy, Retention Policy amongst others specifically requested by the Data Protection Commissioner.

We do not advocate that documents are copied from the internet, or even templates being used. These documents will have little or no context in relation to your organisation and how it processes personal data.

Your supporting documentation must give an accurate description of who you are and how your organisation processes data including how long you retain data and who you might share that data with.