Vendor assessment for universities: a complete guide to GDPR, security and AI Act reviews

A practical, source-backed walkthrough of how a European university can assess a software vendor: who should be involved, which documents to ask for, what the GDPR and the EU AI Act actually require, and how to keep the assessment current after the contract is signed.

Published 7 October 2026 · Sources checked 7 October 2026

1. When a vendor assessment is needed

Universities buy and adopt software in many ways: central procurement, departmental purchases, free tools a lecturer starts using in a course, and services written into a research grant. The legal trigger for a GDPR assessment is not the purchase route but the processing. Where a supplier processes personal data on the university's behalf, Article 28(1) GDPR says the controller "shall use only processors providing sufficient guarantees" to implement appropriate technical and organisational measures. Free tools are not exempt: the obligation follows the data.

In practice, a review should be triggered when any of the following is true:

• The service will receive personal data of students, staff, applicants, alumni or research participants.
• It will connect to university systems (single sign-on, the learning platform, student records, HR).
• It includes AI features that generate content, assess students or make recommendations about people.
• Data will be processed or accessed from outside the European Economic Area.
• The vendor changes something material: new owner, new hosting region, new subprocessors, new AI features.

Other regimes may add their own triggers. Public universities are generally public sector bodies for web accessibility purposes, and Directive (EU) 2016/2102 requires public sector bodies' websites and mobile applications to be accessible. The NIS2 Directive allows Member States to extend its scope to "education institutions, in particular where they carry out critical research activities" (Art. 2(5)(b)), so whether NIS2 supply chain duties apply depends on national transposition. Check your own country's law.

2. Who is involved

Vendor assessment fails most often when one team assumes another has looked at something. A clear split of responsibilities helps. Universities that are public authorities or bodies must designate a data protection officer (GDPR Art. 37(1)(a)), and Article 35(2) requires the controller to seek the DPO's advice when carrying out a DPIA.

Validemic's analysis The single most useful governance decision is naming one owner per vendor who is responsible for keeping the file current. Without that, approvals are given once and never revisited.

3. The process, step by step

Step 1: Intake

Start with a short request form completed by the person who wants the tool. Ask for: the purpose, who will use it, what data will go in (with examples), whether it replaces an existing approved tool, integrations needed, the number of users, and the expected start date. A good intake form also asks whether the tool has AI features and whether research participants' data is involved. This is also the moment to check whether the university already has an approved alternative.

Step 2: Triage by risk

Not every tool needs the same depth. A simple three-tier model works for most institutions:

Our free DPIA screening tool applies the WP248 criteria to help with this step, and the AI Act checker for education helps classify AI features.

Step 3: Questionnaire

Send a structured questionnaire so answers are comparable across vendors. Many vendors already hold a completed HECVAT, the EDUCAUSE questionnaire widely used in US higher education. It is useful evidence, but European institutions usually need more on GDPR roles, transfers and the AI Act. Our guide HECVAT for European universities explains the gap and offers a free European questionnaire as a Word file.

Step 4: Document review

Questionnaire answers are claims; documents are evidence. Compare answers with the DPA, the subprocessor list, the privacy notice and the security reports. Where they disagree, the signed contract and independent reports carry more weight than marketing pages. The EDPB notes that the guarantees that count are those the processor "is able to demonstrate to the satisfaction of the controller", which often requires exchanging documents such as security policies, audit reports and recognised certifications (Guidelines 07/2020, para. 95).

Reviewing a vendor right now? Validemic checks the vendor's documents against GDPR and the EU AI Act and cites every finding. Try the demo workspace

Step 5: Contract

Negotiate the Art. 28 terms, transfer clauses, security annex, audit rights, breach notification timing, liability and exit. Check that the version you sign is the version you reviewed. Our DPA checker maps a draft agreement against each point of Article 28(3).

Step 6: Decision and conditions

Record the decision, the residual risks the business owner accepted, and any conditions of use, for example "no special category data", "SSO only", "AI features switched off" or "approved for course X only". Add the processing to your record of processing activities (Art. 30); see our ROPA template for universities.

Step 7: Monitoring until exit

Track subprocessor notices, policy changes, certification expiry and incidents, and reassess at renewal. This step is covered in section 11.

4. Documents to request

The table below is the core evidence pack. Not every item applies to every tool; the right column explains when you need it.

5. Controller, processor or joint controller?

The GDPR defines the controller as the body that "determines the purposes and means" of processing (Art. 4(7)) and the processor as one that processes personal data "on behalf of the controller" (Art. 4(8)). The EDPB's Guidelines 07/2020 explain that purposes are always for the controller, while "non-essential means", such as the choice of software or detailed security measures, can be left to a processor. "Essential means", such as which data, for how long, and who has access, stay with the controller.

For universities, three patterns come up repeatedly:

• Classic processor. A survey platform or learning tool that stores data only to provide the service to the university. Art. 28 applies.
• Vendor acting partly as a controller. Terms often reserve uses such as product improvement, analytics or model training for the vendor's own purposes. For those uses the vendor is likely to be a controller, and Art. 28(10) says a processor that determines purposes and means is treated as a controller for that processing. Read the terms for these clauses, and check whether the education or enterprise plan differs from the free plan.
• Joint controllers. Research consortia and shared services often jointly determine purposes and means. Art. 26 requires an arrangement setting out each party's responsibilities, with its essence made available to data subjects.

Role analysis matters because it decides which contract you need and who answers data subject requests. Get it wrong and the DPA may cover only part of what the vendor actually does.

6. The Article 28 data processing agreement

Article 28(3) requires a contract or other legal act, binding on the processor, that sets out the subject matter, duration, nature and purpose of processing, the type of personal data, the categories of data subjects, and the controller's obligations and rights. It must also stipulate that the processor:

The agreement must be in writing, which includes electronic form (Art. 28(9)). The Commission has adopted standard contractual clauses for controller-processor contracts under Art. 28(7) in Implementing Decision (EU) 2021/915; these can be used as the whole agreement or as a benchmark when reviewing a vendor's own DPA.

On subprocessors, the EDPB's Opinion 22/2024 concludes that controllers should have information on the identity (name, address, contact person) of all processors and subprocessors "readily available at all times", regardless of risk, and that the processor should proactively keep that information up to date. The opinion also says the controller does not have a duty to systematically request every sub-processing contract, but should decide case by case whether reviewing them is necessary.

For agreement templates in other languages, see our national guides: Swedish personuppgiftsbiträdesavtal, Dutch verwerkersovereenkomst, Norwegian databehandleravtale and Finnish käsittelysopimus.

7. International transfers (Chapter V)

Article 44 GDPR allows transfers to third countries only if the conditions in Chapter V are met, including for onward transfers. The EDPB's Recommendations 01/2020 add a point that vendor reviews often miss: remote access from a third country, for example in support situations, is also considered a transfer. A service hosted in Frankfurt can still involve transfers if support staff in another country can access the data.

The transfer tools, in order

1. Adequacy decision (Art. 45). On 7 October 2026 the Commission's list includes, among others, the United Kingdom (renewed in December 2025), Switzerland, Japan, the Republic of Korea, Canada (commercial organisations), Brazil (adopted January 2026) and the United States for organisations in the EU-US Data Privacy Framework. Check the Commission's adequacy page for the current list.
2. EU-US Data Privacy Framework. Under Implementing Decision (EU) 2023/1795, adequacy covers transfers to US organisations included in the "Data Privacy Framework List" kept by the US Department of Commerce. Check the vendor's entry, not just its privacy notice. The General Court dismissed a challenge to the decision on 3 September 2025 (Case T-553/23); an appeal was lodged on 31 October 2025 (Case C-703/25 P). Follow that case, because the outcome could affect US transfers.
3. Appropriate safeguards (Art. 46). Most often the Commission's standard contractual clauses (Implementing Decision (EU) 2021/914), which have four modules: controller to controller, controller to processor, processor to processor and processor to controller. Under Clause 14 the parties warrant that they have assessed the destination country's laws and practices, and must document that assessment and make it available to the supervisory authority on request. This is what is usually called a transfer impact assessment (TIA).
4. Derogations (Art. 49). Narrow and meant for specific situations. Article 49(3) also says consent and the contract-based derogations do not apply to activities carried out by public authorities in the exercise of their public powers, which limits their use by public universities.

The EDPB's six steps for SCC-based transfers are: know your transfers, identify the transfer tool, assess whether it is effective in the destination country, adopt supplementary measures, take procedural steps, and re-evaluate at appropriate intervals. Our free transfer mechanism tool walks through this order.

Pending: the Commission says it is developing additional SCCs for transfers to importers whose processing is directly subject to the GDPR. We found no adopted text on 7 October 2026; check the Commission's SCC page before relying on the current set for such importers.

8. DPIAs and high-risk processing

Article 35(1) requires a data protection impact assessment, before processing starts, where a type of processing "is likely to result in a high risk" to individuals, in particular when using new technologies. Article 35(3) lists three cases where a DPIA is always required, including large-scale processing of special category data. Each supervisory authority also publishes a list of processing types that require a DPIA (Art. 35(4)); check your national list.

The Article 29 Working Party's DPIA guidelines (WP248 rev.01), endorsed by the EDPB, set out nine criteria:

1. Evaluation or scoring, including profiling and predicting.
2. Automated decision-making with legal or similarly significant effect.
3. Systematic monitoring.
4. Sensitive data or data of a highly personal nature.
5. Data processed on a large scale.
6. Matching or combining datasets.
7. Data concerning vulnerable data subjects.
8. Innovative use or applying new technological or organisational solutions.
9. Processing that prevents data subjects from exercising a right or using a service or contract.

The guidelines say that "in most cases" processing meeting two criteria requires a DPIA, and that sometimes one is enough. They also note that employees can be vulnerable data subjects because of the power imbalance with the controller, and the same reasoning is often applied to students.

Validemic's analysis In higher education the criteria stack up quickly. An AI tool that grades or flags student work is plausibly evaluation or scoring, innovative technology, and processing of data about people in an unequal relationship with the institution. Online proctoring adds systematic monitoring. Tools that look minor on paper can therefore need a DPIA.

The DPIA must contain at least a description of the processing, an assessment of necessity and proportionality, an assessment of risks, and the measures to address them (Art. 35(7)). If residual risk stays high, Art. 36 requires prior consultation with the supervisory authority. Vendors are required to help (Art. 28(3)(f)); ask for their DPIA input early.

9. EU AI Act duties for universities as deployers

The AI Act (Regulation (EU) 2024/1689) calls an organisation that uses an AI system under its authority a "deployer" (Art. 3(4)). When a university licenses an AI tool, it is normally a deployer and the vendor is the provider. The Act was amended by the Digital Omnibus on AI (Regulation (EU) 2026/1744), which entered into force on 27 July 2026. On 7 October 2026 the position is:

When the high-risk rules apply, Article 26 will require deployers to use the system according to the instructions for use, assign competent human oversight, monitor operation, keep logs under their control for at least six months, and use the provider's information when carrying out a GDPR DPIA. Deployers that are public authorities must also check registration in the EU database (Art. 26(8)). Article 27 requires bodies governed by public law to carry out a fundamental rights impact assessment before deploying most Annex III systems; after the Omnibus, it can cross-reference an existing DPIA where that already meets the obligations.

For vendor review this means asking now, even before December 2027: what is the intended purpose, does the vendor classify the tool as high-risk, will it provide instructions for use, and which general-purpose AI models does the tool rely on? Our AI Act guide for universities covers this in more depth, and the AI Act checker helps classify a tool.

For AI tools specifically, also ask whether university data is used to train the vendor's or a third party's models, whether that differs between free and institutional plans, and which AI model providers appear in the subprocessor list. Our fact sheets on tools such as ChatGPT, Microsoft Copilot, Gemini and NotebookLM set out what each vendor documents publicly. For research use, see GDPR and AI tools in research.

10. Security standards and evidence

Article 32(1) GDPR requires security appropriate to the risk, including, as appropriate, pseudonymisation and encryption, ongoing confidentiality, integrity, availability and resilience, the ability to restore data in a timely manner, and regular testing of the measures. Independent assurance helps you check these claims without auditing every vendor yourself.

Treat certifications as evidence, not proof. Article 28(5) GDPR says adherence to an approved code of conduct or certification mechanism "may be used as an element" to demonstrate sufficient guarantees. The AICPA itself has published a notice that it is looking into allegations about a compliance vendor's SOC services and stresses that SOC services should be thoroughly evaluated, which is a reason to check who issued a report, not only that one exists.

11. Renewal and monitoring

The EDPB states that the obligation to use processors with sufficient guarantees "is a continuous obligation" and that the controller should verify those guarantees at appropriate intervals, including through audits where appropriate (Guidelines 07/2020, para. 99). Recommendations 01/2020 likewise end with "re-evaluate at appropriate intervals" for transfers. A practical monitoring routine:

• Subscribe to subprocessor change notices and check them against your conditions. Our free subprocessor alerts tool can help.
• Track expiry dates of certificates and the period covered by SOC reports.
• Watch the vendor's privacy notice, terms and AI policy for changes, especially to training use.
• Check the vendor's DPF List status yearly if you rely on the Data Privacy Framework.
• Reassess before renewal, and whenever the use case expands (new faculty, new data types, AI features enabled).
• Update the DPIA where the risk changes (Art. 35(11)) and the record of processing activities.

12. Common pitfalls

1. Reviewing the free plan, contracting the institutional plan, or the reverse. DPAs, training opt-outs and data residency often differ by plan.
2. Hosting location confused with transfers. EU hosting does not rule out transfers through support access or non-EEA subprocessors.
3. Accepting "GDPR compliant" as an answer. Ask for the documents behind the claim. No tool is compliant on its own; compliance depends on contract, configuration and use.
4. Missing vendor-as-controller clauses. Analytics, product improvement and model training clauses can sit outside the DPA.
5. No owner after approval. Approved once, never reviewed again.
6. Researchers outside the process. Grant-funded tools bought on a project card may never reach the DPO. Link the vendor process to the data management plan.
7. Treating AI features as a product detail. A vendor switching on an AI assistant can change the role analysis, the subprocessor list and the AI Act position.
8. Certificates with the wrong scope. A certificate for the vendor's head office does not cover the hosted product.

13. Vendor assessment checklist

Copy this into your own process documentation. Each item should leave a document or a decision in the vendor file.

For a picture of which AI tools other institutions approve and on what terms, see AI tools approved at European universities, and browse our GDPR fact sheets on tools such as Zoom, Qualtrics, Turnitin, Proctorio and Miro.

Sources

1. Regulation (EU) 2016/679 (GDPR), Official Journal text, Articles 4, 26, 28, 30, 32 to 37, 44 to 49 (retrieved 7 October 2026).
2. Regulation (EU) 2024/1689 (AI Act), Articles 3, 4, 5, 26, 27, 50, 113 and Annex III (retrieved 7 October 2026).
3. Regulation (EU) 2026/1744 (Digital Omnibus on AI), published 24 July 2026 (retrieved 7 October 2026).
4. EDPB Guidelines 07/2020 on the concepts of controller and processor in the GDPR, version 2.1 (retrieved 7 October 2026).
5. EDPB Opinion 22/2024 on certain obligations following from the reliance on processor(s) and sub-processor(s), adopted 7 October 2024 (retrieved 7 October 2026).
6. EDPB Recommendations 01/2020 on supplementary measures, version 2.0 (retrieved 7 October 2026).
7. Article 29 Working Party, Guidelines on DPIA (WP248 rev.01) and the EDPB list of endorsed WP29 guidelines (retrieved 7 October 2026).
8. European Commission: Adequacy decisions (retrieved 7 October 2026).
9. Commission Implementing Decision (EU) 2023/1795 (EU-US Data Privacy Framework) (retrieved 7 October 2026).
10. Appeal brought on 31 October 2025 by Philippe Latombe, Case C-703/25 P, OJ C/2025/6610 (retrieved 7 October 2026).
11. European Commission: Standard contractual clauses (retrieved 7 October 2026).
12. Commission Implementing Decision (EU) 2021/914 (SCCs for international transfers) (retrieved 7 October 2026).
13. Commission Implementing Decision (EU) 2021/915 (SCCs between controllers and processors) (retrieved 7 October 2026).
14. Directive (EU) 2022/2555 (NIS2), Article 2(5) (retrieved 7 October 2026).
15. Directive (EU) 2016/2102 on the accessibility of public sector websites and mobile applications (retrieved 7 October 2026).
16. ISO/IEC 27001:2022, ISO/IEC 27701:2025 and ISO/IEC 42001:2023 pages on iso.org (retrieved 7 October 2026).
17. AICPA & CIMA: System and Organization Controls (SOC) suite of services (retrieved 7 October 2026).
18. EDUCAUSE: Higher Education Community Vendor Assessment Toolkit (retrieved 7 October 2026).

About this page

Sources checked on 7 October 2026. We read the legal texts in the Official Journal versions published by the EU Publications Office, and the EDPB, Commission, ISO, AICPA and EDUCAUSE pages listed above. Where we give our own interpretation, it is labelled as Validemic's analysis. This page is general information, not legal advice; national law and your institution's own policies may add requirements. The AI Act timeline and the EU-US Data Privacy Framework are subject to change, and we will update this page when they do. If you spot an error or an outdated point, please contact us and we will correct it.