CASRAI Dictionary

Tag: GDPR

  • GDPR Enforcement 2025: How DPAs Applied the Rules

    The EU General Data Protection Regulation (GDPR) has been in force since 2018, and its enforcement is carried out by independent national data-protection authorities (DPAs) across the EU and EEA, coordinated through the European Data Protection Board (EDPB). This article offers a neutral, aggregate recap of the themes that characterised GDPR enforcement through 2025. It deliberately discusses patterns and principles rather than naming particular organisations or framing specific outcomes as accusations, and it is not legal advice.

    How GDPR enforcement is structured

    GDPR is enforced primarily by national DPAs, each supervising organisations within its jurisdiction. For cross-border processing, the regulation uses a one-stop-shop mechanism: a lead supervisory authority, usually where the organisation has its main establishment, coordinates with other concerned authorities. Where authorities disagree, the EDPB can issue binding decisions to ensure consistent application. For the underlying framework, see our overview of the GDPR.

    This structure matters because it shapes how enforcement unfolds: many significant cross-border matters involve coordination between a lead authority and others, and EDPB consistency mechanisms help align interpretation across countries.

    Recurring themes in enforcement

    Across the body of enforcement activity, several themes recur as areas where authorities have focused. Described in aggregate, these include:

    • Lawful basis and transparency: whether organisations correctly identify and communicate the legal basis for processing, and whether privacy information is clear and accessible.
    • Consent: whether consent, where relied upon, is freely given, specific, informed and unambiguous, and as easy to withdraw as to give.
    • Data-subject rights: how organisations handle requests for access, erasure, rectification and objection within required timeframes.
    • Security and breach handling: whether appropriate technical and organisational measures are in place, and whether breaches are notified appropriately. See our explainer on data breaches.
    • International transfers: the safeguards applied when personal data move outside the EEA.

    These themes reflect the GDPR’s core principles — lawfulness, fairness and transparency; purpose limitation; data minimisation; accuracy; storage limitation; integrity and confidentiality; and accountability — and enforcement activity tends to cluster around them.

    The role of the EDPB and consistency

    A defining feature of recent years has been the EDPB’s role in promoting consistent interpretation. Through guidelines, opinions and, where necessary, binding decisions in dispute-resolution procedures, the Board has helped align how authorities approach questions such as the calculation of administrative fines and the assessment of cross-border cases. The EDPB has, for example, issued guidance intended to harmonise the methodology authorities use when determining the level of fines, supporting a more consistent approach across the bloc.

    This coordination is significant for organisations operating in multiple member states, because it reduces — though does not eliminate — divergence in how the same rules are applied in different countries.

    Tools beyond fines

    Administrative fines attract the most attention, but DPAs have a wider toolkit. Authorities can issue warnings and reprimands, order an organisation to bring processing into compliance, impose temporary or definitive limitations on processing (including bans), and order the rectification or erasure of data. In many matters, corrective orders — requiring changes to how data are handled — are as consequential as monetary penalties, because they directly alter business practices. Describing enforcement only in terms of fine totals therefore understates the range of regulatory action.

    What organisations took from it

    In aggregate, the enforcement picture through 2025 reinforced the importance of demonstrable accountability: maintaining records of processing, conducting data-protection impact assessments where required, ensuring a valid lawful basis, honouring data-subject rights promptly, and being able to evidence appropriate security measures. The accountability principle — being able to show compliance, not merely assert it — runs through the regulation and through how authorities assess organisations.

    For those seeking to understand the rules themselves rather than commentary on outcomes, the authoritative sources are the regulation’s own text, national DPA guidance, and EDPB materials published at edpb.europa.eu. Neutral definitions of related privacy terms are collected in our standards dictionary.

    Reading enforcement data carefully

    A final neutral note concerns how enforcement statistics should be read. Aggregate figures — numbers of decisions, total penalty amounts, or counts of complaints — circulate widely, but they require context. A high total in one period may reflect a small number of large matters rather than a broad pattern; a low total may reflect a focus on corrective orders rather than fines. Differences between member states can stem from caseload, the nature of the organisations established in a jurisdiction, or procedural timing rather than from differing strictness. For this reason, responsible analysis treats enforcement data as one input among several and avoids inferring conclusions about any individual organisation from aggregate trends. The constructive takeaway for organisations is forward-looking: align practices with the regulation’s principles and maintain the documentation needed to demonstrate that alignment.

    The accountability principle in focus

    If a single idea characterises how authorities approach assessment, it is accountability. The GDPR does not merely require organisations to comply; it requires them to be able to demonstrate compliance. In practice this means maintaining a record of processing activities, documenting the lawful basis for each processing purpose, conducting and recording data-protection impact assessments for higher-risk processing, and keeping evidence of the technical and organisational measures in place. When authorities examine an organisation, the ability to produce this documentation is often as important as the underlying practices themselves.

    Accountability also shapes governance. Many organisations are required to designate a data-protection officer, and the regulation encourages structured governance such as data-protection-by-design and by-default, where privacy considerations are built into systems from the outset. These structural expectations recur across enforcement themes because they underpin every other obligation — a lawful basis, honoured rights and adequate security all depend on having the governance to manage them.

    A neutral bottom line

    GDPR enforcement in 2025 is best understood not through individual headline cases but through the patterns: sustained attention to lawful basis, transparency, consent, data-subject rights, security and international transfers; growing consistency driven by the EDPB; and a corrective toolkit that extends well beyond fines. The regulation’s principles remained the constant reference point against which authorities assessed organisations.

  • GDPR and research data: lawful bases, consent and pseudonymisation

    An enormous amount of research depends on data about people — their health, their behaviour, their genetics, their opinions, their lives. Wherever such data identify or could identify individuals, they fall within data protection law, and in Europe and the United Kingdom that law is the General Data Protection Regulation (GDPR), supplemented in the UK by the UK GDPR and the Data Protection Act 2018. For researchers the GDPR is sometimes experienced as a thicket of obligations. But its core ideas are coherent, and it contains specific provisions designed to enable responsible research rather than obstruct it. Understanding lawful bases, the special rules for sensitive data, the research exemptions, and the distinction between anonymisation and pseudonymisation is part of doing data-driven research properly. This article offers an orientation, drawing on the compliance and regulatory domain of the CASRAI Dictionary. It is general guidance, not legal advice.

    You need a lawful basis

    The first principle is that processing personal data is not permitted by default; it requires a lawful basis. Article 6 of the GDPR sets out the possible bases, several of which can be relevant to research. Many researchers assume the answer is always consent, but for research by public institutions a basis such as the performance of a task carried out in the public interest is often more appropriate. The choice matters because different bases carry different consequences for the rights individuals can exercise. The key point is that a researcher must be able to identify and justify the lawful basis on which they process personal data — good intentions and scientific value do not by themselves make processing lawful.

    Special category data and Article 9

    Much research data is not merely personal but sensitive — data about health, genetics, ethnicity, sexual life, religious or political beliefs, and so on. The GDPR calls these special categories and gives them extra protection under Article 9, which prohibits their processing unless a specific additional condition is met. Among those conditions are explicit consent and, importantly for research, processing necessary for scientific research purposes subject to appropriate safeguards. This means that to process sensitive data lawfully, a researcher must satisfy both a lawful basis under Article 6 and a condition under Article 9. The heightened protection reflects the heightened risk: misuse of health or genetic data can cause serious harm, and the law accordingly demands a stronger justification and stronger safeguards before such data may be used.

    The research provisions

    The GDPR explicitly recognises the value of research and contains provisions, centred on Article 89, intended to facilitate it while protecting individuals. These measures allow certain flexibilities under conditions — for example, data collected for one purpose may in some circumstances be further processed for scientific research without that being treated as incompatible with the original purpose, and certain individual rights may be adjusted where they would seriously impair research objectives. Crucially, these provisions are not a free pass. They are conditioned on appropriate safeguards for the rights and freedoms of individuals — safeguards that the regulation specifically associates with techniques such as data minimisation and, prominently, pseudonymisation. The research exemptions, in other words, come bundled with the expectation that researchers will take concrete measures to protect the people in their data.

    Anonymisation versus pseudonymisation

    One distinction does more practical work in research than almost any other, and it is frequently misunderstood: the difference between anonymisation and pseudonymisation.

    • Anonymisation means rendering data such that individuals are no longer identifiable, by anyone, taking account of all means reasonably likely to be used. Genuinely anonymous data falls outside the scope of the GDPR altogether, because it is no longer personal data. Achieving true anonymisation is harder than it sounds, because seemingly innocuous combinations of fields can re-identify people.
    • Pseudonymisation means processing data so that it can no longer be attributed to an individual without additional information — for example, replacing names with a code, while keeping the key that links code to identity separate and secure. Pseudonymised data remains personal data and remains within the GDPR’s scope, because re-identification is still possible with the key.

    The error to avoid is treating pseudonymised data as if it were anonymous and therefore outside the law. Pseudonymisation is a valuable safeguard — indeed the GDPR commends it — but it reduces risk rather than removing the data from regulation. Knowing which one you have done determines what obligations still apply.

    Accountability and impact assessments

    The GDPR is built on accountability: it is not enough to comply, one must be able to demonstrate compliance. For research using personal data this brings practical obligations — documenting the lawful basis and Article 9 condition, being transparent with participants, applying data minimisation, and securing the data. Where processing is likely to result in a high risk to individuals — as large-scale processing of sensitive data often will — a data protection impact assessment (DPIA) may be required, identifying the risks and planning mitigations before processing begins. The DPIA is not merely a form to file; it is the moment at which a team thinks systematically about how its use of personal data could affect people and how to reduce that effect.

    A consistent vocabulary for compliance

    Data protection touches institutions, funders, ethics committees and repositories alike, and for the relevant information to be handled consistently across them, the terms involved — lawful basis, consent type, special category, pseudonymised, anonymised, retention — must mean the same thing everywhere. That consistency is what the CASRAI Dictionary provides: a shared vocabulary so that the compliance metadata describing how personal data may be used is understood identically wherever it appears, supporting the broader machinery of research administration. And because stewarding personal data responsibly is genuine contribution, that work can be described within the same framework as any other — the CRediT taxonomy and its full set of contribution roles. The GDPR is not the enemy of research; properly understood, it is the framework within which research that depends on people’s data can be done in a way that keeps faith with them.

  • What machine-actionable compliance metadata means for research administration

    Most research compliance lives in prose. An ethics approval is a letter; a data-protection assessment is a Word document; a material transfer agreement is a signed PDF in a filing system. Each is legally meaningful and administratively essential, and each is almost completely opaque to the systems that need to act on it. Machine-actionable compliance metadata is the idea that the salient facts in these documents — who approved what, under which regime, with what conditions and expiry — should also exist as structured, queryable data. This article explains what that means and why it is the next obvious step in reducing the administrative burden that CASRAI was founded to address. It draws on the vocabulary of the compliance and regulatory domain.

    What “machine-actionable” actually means

    A document is human-readable. A field is machine-actionable. The difference is whether another system can reliably extract a fact and act on it without a person reading the document first. “Ethics approval REC-2026-0481 granted by the University Research Ethics Committee on 2026-03-14, valid until 2029-03-14, covering protocol v2, conditions: annual review required” is the same information as the approval letter, but expressed so that a CRIS can check whether a project’s ethics approval is current, a repository can refuse a deposit whose approval has lapsed, and a funder report can be assembled without manual transcription.

    The model here is the machine-actionable data management plan (maDMP). The research-data community spent several years turning the DMP from a frozen narrative document into structured content that can be exchanged between systems, validated against funder requirements, and updated through the project lifecycle. Compliance metadata is the same move applied to the ethics, data-protection, and agreements layer.

    Three worked examples

    Ethics review

    An ethics approval — from an Institutional Review Board (IRB) in the US idiom, a Research Ethics Committee (REC) in the UK and Europe, or a Human Research Ethics Committee (HREC) in Australia — carries a small number of facts that systems repeatedly need: the approving body, the approval identifier, the review category (exempt, expedited, or full-board review), the date granted, the expiry or renewal date, the protocol version covered, and any conditions. Today those facts are re-keyed by hand into grant systems, CRIS records, and journal submission forms, with all the transcription error that implies. As structured metadata, the approval is recorded once and read everywhere. A journal’s submission system could, in principle, verify an approval against the issuing institution rather than trusting a typed-in reference number.

    Data protection

    Under the General Data Protection Regulation (GDPR) and its equivalents, a project handling personal data has a defined structure: a data controller, possibly a data processor, a lawful basis for processing, and — for higher-risk processing — a completed Data Protection Impact Assessment (DPIA). These are exactly the fields a research office needs to answer “are we compliant for this project, and who is accountable?” Expressed as metadata attached to the project record, the controller/processor relationship and the DPIA status become queryable across a whole portfolio, rather than being rediscovered project by project. Note that machine-actionable does not mean the personal data itself is exposed — it is the compliance facts about the processing that are structured, not the protected data.

    Material transfer agreements

    A material transfer agreement (MTA) governs the movement of physical research materials between institutions, and it typically carries conditions that have downstream consequences: permitted uses, publication restrictions, requirements to share derivatives, and obligations flowing back to the provider. When the MTA is a PDF in a drawer, those conditions are invisible to the systems where they matter — the repository that is about to publish a derivative, the technology-transfer office negotiating a licence. As structured metadata, the agreement’s key terms travel with the material and can be checked automatically before an action that the agreement restricts.

    Why this is a research-administration problem, not a paperwork problem

    The administrative burden on researchers and research offices is, to a significant degree, a metadata problem in disguise. The same compliance facts are entered repeatedly into incompatible systems because no shared, structured representation exists. Every CRIS implementation invents its own ethics-status fields; every funder portal asks for the same approvals in a different shape; every journal’s submission form re-requests information the institution already holds. The cost is the multi-billion-pound annual burden the original CASRAI set out to reduce.

    A shared, controlled vocabulary for compliance — ethics review body, ethics review outcome, review category, controller, processor, MTA condition — is the precondition for machine-actionable compliance. Without it, every system structures the facts differently and interoperability fails at the first join. With it, a compliance fact recorded once can be validated, exchanged, and acted on across the lifecycle. This is precisely the convening-and-defining role the CASRAI dictionary is built to play.

    The jurisdiction caveat

    A real risk in this work is false equivalence. An IRB, a REC, and an HREC are analogous but not identical; GDPR’s controller/processor model does not map cleanly onto every other data-protection regime; “informed consent” carries different statutory meaning in different countries. The goal of machine-actionable compliance metadata is not to flatten these differences into a single global schema that erases jurisdiction. It is to normalise the shared structure — there is an approving body, there is an outcome, there is an expiry — while preserving the jurisdictional specifics as values within that structure. A vocabulary that pretends a REC and an IRB are the same thing would be worse than no vocabulary at all.

    What to do now

    For research offices and CRIS owners: start capturing the structured facts behind compliance documents — body, identifier, category, dates, conditions — as fields, not just as attached PDFs, even before a shared standard exists. For standards and vocabulary work: prioritise the controlled vocabulary for ethics review, data-protection roles, and agreement conditions, federating to the relevant legal frameworks rather than inventing normative content. The maDMP work is the proof of concept; compliance is the natural next layer.

    Related reading

  • Research compliance as structured metadata: IRB/REC, GDPR and MTAs

    Most researchers experience compliance as a sequence of forms: an ethics application here, a data-protection assessment there, a signed agreement before a reagent can cross an institutional boundary. Each is completed under deadline pressure, filed as a PDF, and rarely consulted again. Yet the facts those documents record — that a study was approved, that personal data are processed under a defined legal basis, that a material was transferred under stated conditions — are exactly the facts that funders, regulators, repositories, and downstream researchers later need to check. This article sets out how the main compliance frameworks fit together, and why representing them as structured metadata, drawing on the compliance and regulatory domain, turns a paperwork burden into reusable infrastructure.

    Ethics review: one function, many names

    The oversight of research involving human participants is a near-universal requirement, but its institutional form varies by jurisdiction, and the vocabulary trips people up. In the United States the reviewing body is the Institutional Review Board (IRB); in the United Kingdom and much of Europe it is the Research Ethics Committee (REC); in Australia it is the Human Research Ethics Committee (HREC). These are not different things so much as the same function under different names and statutes, and a controlled vocabulary should treat them as such rather than privileging one country’s term.

    The review itself is not monolithic. Most regimes distinguish levels of scrutiny calibrated to risk: an exempt review for studies meeting defined exemption criteria, an expedited review for minimal-risk work, and a full board review for higher-risk studies considered by the whole committee. The agreement that lets a participant take part is informed consent — a documented agreement to participate after being told the nature and risks of the research — with variants such as broad consent for unspecified future use, and an ethics-approved waiver of consent where standard procedures are omitted.

    Data protection: GDPR’s defined roles

    Where research touches personal data, ethics approval is necessary but not sufficient; data-protection law applies in its own right. In the European Union and, in near-identical form, the United Kingdom, the governing instrument is the General Data Protection Regulation (GDPR), and its precision is a feature, not an obstacle. GDPR assigns defined roles: a data controller is the entity that determines the purposes and means of processing, and a data processor processes personal data on the controller’s behalf. The distinction is not pedantic — it determines who carries which legal obligation — and a study that cannot say which party is controller and which is processor has a real gap, not merely a documentation one.

    For higher-risk processing, GDPR requires a Data Protection Impact Assessment (DPIA): a structured analysis of the risks a processing activity poses to data subjects, and the measures taken to mitigate them. The DPIA is the data-protection analogue of the ethics application, and like it, it tends to be written once and shelved. Comparable regimes exist elsewhere — the United States governs protected health information under HIPAA — while the international ethical baseline for medical research remains the Declaration of Helsinki.

    Material transfer: the agreement that governs the sample

    The third pillar is contractual rather than regulatory. A Material Transfer Agreement (MTA) is a legal agreement governing the transfer of research materials — cell lines, reagents, datasets, biological samples — between institutions. The MTA sets out what the recipient may do with the material, what they may not, who owns any derivatives, and what acknowledgement or rights flow back to the provider. It is easy to treat the MTA as a one-off signature, but its terms persist for the life of the material and everything derived from it, which is precisely why its conditions need to travel as data rather than languish in a signed PDF.

    An MTA whose terms are buried in a scanned signature page is a constraint nobody can check. The same agreement, recorded as structured conditions linked to the material and the receiving project, is a constraint a system can enforce — flagging, for instance, that a derivative dataset inherits a no-redistribution clause before it is deposited openly.

    Compliance does not stop there. A conflict of interest, whether financial or personal, and export-controlled technology rules under regimes such as the EAR and ITAR, are further disclosable facts that arrive as yet more forms asking for information the institution already holds somewhere.

    Why this is, at bottom, a metadata problem

    Here is the connection to CASRAI’s mission. Almost every compliance artefact records a structured fact: a study has an approval reference and an approving committee; a processing activity has a controller, a legal basis, and a DPIA; a material moves under an MTA with stated conditions. The burden researchers feel as oppressive is largely the burden of re-entering those facts, by hand, in each system’s format — ethics portal, funder report, repository deposit form, institutional register. A regime that demands manual re-keying manufactures exactly the transcription errors it later treats as compliance failures.

    Anchoring compliance records in persistent identifiers changes this. An approval linked to its project by a RAiD, an institution identified by a ROR ID, an investigator by an ORCID iD, and a funder by its registry ID, becomes a checkable assertion rather than a typed paragraph. A repository can read that a dataset’s underlying study was approved and that its MTA permits deposit; a funder can verify that a DPIA exists for a project processing personal data — without anyone reconstructing the paperwork from memory. This is the same dividend that structured grant and disclosure data pay throughout research administration: enter each fact once, read it everywhere.

    Where shared vocabulary fits

    The terms in this area are easy to misuse and the cost of misuse is real: an IRB and an REC are the same function, not different standards; a controller is not a processor; a DPIA is a specific assessment, not a synonym for “we thought about privacy”. A shared, federated vocabulary that defines these precisely — pointing back to the relevant national regulators and to the Declaration of Helsinki for the ethical baseline rather than inventing its own meanings — is what lets a compliance assertion made in one system be understood and checked in another. Supplying that definitional layer is the role the CASRAI dictionary is designed to play.

    What to do now

    For researchers: maintain approvals, data-protection roles, and MTA conditions as structured records linked to the project, not as orphaned PDFs. For institutions: build compliance registers that generate funder and repository disclosures from authoritative, identifier-anchored facts rather than from re-keyed forms. For standards work: pin down the precise definitions that separate ethics review levels, controller from processor, and one agreement type from another, federating to the authoritative regulators for the normative content.

    Related reading