Sign in with the username and password you chose when you registered.
{{ arete_auth_error }}
New students: create an account using the registration code from your facilitator. You can change your username and password at any time once signed in.
Choose a username and password — that is all we store. Already have one? .
{{ arete_reg_error }}
We store only the username and password you choose — no name, email or any other personal data. Your facilitator gives you the registration code.
🍪
This portal stores the minimum needed to keep you signed in and to remember your settings. It uses no tracking, analytics, advertising or third-party cookies, and never profiles you.
| Name | arete_session |
|---|---|
| Purpose | Keeps you signed in after you log in. Strictly necessary — the portal cannot work without it. |
| Contents | A signed token (your user id + expiry). No name, email or assessment data. |
| Lifetime | Expires within 7 days, and immediately when you sign out. |
| Protection | HttpOnly (not readable by scripts), Secure (HTTPS only), SameSite=Lax. First-party only. |
Because this cookie is strictly necessary for a service you actively request by signing in, the EU data-protection framework (GDPR / Regulation (EU) 2018/1725 and the ePrivacy Directive, Art. 5(3)) does not require a consent banner for it — only this clear information.
To make the tool usable, your browser keeps a few items locally — your display preferences, your training progress (unlocked scenarios, answers in progress and, optionally, a name you enter). This stays in your browser, is never used for tracking, and is removed automatically when you sign out. You can also clear it at any time from Contact → Reset training or your browser settings.
The controller for this training platform is the facilitation team, reachable at {{ COURSE_META.contactEmail || 'your facilitator' }}. You have the right to access, rectify and erase your data and to lodge a complaint with the European Data Protection Supervisor (EDPS). To exercise any of these, or to ask how your training submissions are handled, contact the facilitation team.
Signing out clears the session cookie and removes your progress and answers from the device — safe on shared computers. Everything you already submitted stays on the course server and reappears when you sign in again.
You signed in with the credentials your facilitator sent. You can pick a new username (any handle, up to 32 characters) and/or a new password for better pseudonymity — or keep the ones you have. You can always change them later from the Contact section.
Pick a new username, a new password, or both. Your current password is required to confirm it is really you.
{{ arete_change_error }}
✓ Credentials updated. Closing in a moment…
Personal Data Breach · Risk Assessment
ARETE will help you to carry out a robust personal data breach risk assessment in line with Articles 34 and 35 EUDPR. This page is your home for everything related to the programme — pre-work, agenda, scenarios, reference library, and follow-up.
Get the foundations on your own, at your own pace (~35 min): short readings and a first breach scenario to work through.
In person on {{ COURSE_META.date }}: group-based work on a live scenario with your facilitator — you apply everything from the pre-work.
Close the loop: test yourself on the risk classification quiz, dig into the further reading, and keep practising with real EDPB cases.
Practical details — date, venue, agenda, what to bring, the facilitation team — are on the Logistics page.
Everything practical for the workshop day — when, where, what to bring, and who is running it.
| Time | Block |
|---|---|
| {{ row.time }} | {{ row.block }} |
How your personal data is processed for this training. Please read it before the workshop.
📄 Open the Privacy Notice (PDF) ↗Contact the facilitation team at {{ COURSE_META.contactEmail }}.
ARETE originates from a clearly identified problem, supported by evidence from the EDPS analysis of breach notifications and the 2024 Data Breach Management Awareness project, and the yearly delivered PATRICIA Exercise on Personal Data Breach Awareness in Cybersecurity Incident Handling. Three recurring patterns surfaced in how EUIBAs perform breach risk assessment:
Risk assessments submitted in breach notifications regularly fall below the expected standard — the surface of attack is under-defined, highly data-centric adverse effects are vague, and the rationale for the risk score is missing or not sufficiently granular.
Organisational risk concerns crowd out the risk to data subjects — which is what Article 34 EUDPR actually requires controllers to assess.
Controllers consistently lean toward under-evaluating risk, often to avoid the obligation to notify or to communicate. Some EUIBAs even use risk matrices that split "high risk" into notify / don't-notify paths — contradicting the three-tier framework in the law.
By the end of ARETE, you will be able to:
You will distinguish between organisational impacts and adverse effects on data subjects, correctly identifying at least three specific data subject risks (identity theft, loss of control over personal data, reputational harm, …) that must be prioritised in an EUDPR-compliant assessment.
Addresses Finding 2.
Following the pre-work and the guided scenario, you will apply the body of knowledge to a breach scenario — identifying the key risks to data subjects, assigning correctly Unlikely / Risk / High Risk score, and writing a rationale that maps the surface of attack to specific increasing or decreasing risk factors.
Addresses Findings 1 and 2.
Given a complex breach use case, you will decide whether the breach requires notification to the EDPS under Article 34 and/or communication to data subjects under Article 35, justifying the decision with reference to the three-tier risk framework and the 72-hour deadline.
Addresses Finding 3.
Get the foundations on your own, online and at your own pace — two steps, ~35 minutes in total. Please complete them before the workshop day: the first 30 minutes of the session activate this material rather than re-deliver it.
Five short readings — the assessment method first, then the legal framework. Tick each one as you finish. (The scientific papers and practitioners' insights move to After the workshop.)
Your first realistic breach case, worked offline. You read the case file, score it on the paper template, then record your risk decision online — it locks once recorded.
Five short readings curated from the reference library, in the same subsections you will find there. Tick each as you finish. Start with the method — everything else hangs off it. (The scientific papers and practitioners' insights are now further reading for after the workshop.)
Seven short breach cases. For each one, commit to a risk classification for the data subjects — then submit to reveal the reference answer and the reasoning behind it. Use it to test the judgement you built during the workshop. The cases are deliberately varied, and a couple are genuinely debatable.
🔒 Your facilitator opens this at the close of the workshop — it unlocks here automatically, nothing to type or refresh. If it stays locked once the day is over, email the facilitation team.
Commit to a classification for each case. After you submit, you'll see the reference answer and a short explanation for every case — and your score.
You work this first scenario on your own, offline: read the case file, score it on the paper template, then record your pre-work risk decision here. Follow the three steps below — your committed risk decision is the pre-work deliverable. Bring the completed paper template to the workshop.
Both decisions are recorded. Bring your paper template to the workshop. ① is your pre-work deliverable — record it before the workshop. ② unlocks in the room, after your facilitator presents Inject 1. Inject 1 is live — weigh it against your pre-work call and record your revised decision in ②.
In person on {{ COURSE_META.date }}: team-based work on a live breach scenario with your facilitator — you apply everything from the pre-work and debate your judgement. Practical details are on the Logistics page.
The main team exercise: a live, evolving breach. Your team gathers the facts, weighs likelihood and severity, commits to a judgement and defends it.
The in-room scenario for the workshop. Your pre-work (Scenario 1) is the preparation. Materials below unlock when your facilitator shares the code.
🔒 Your facilitator opens the assessment tool at the start of the workshop — it unlocks here automatically; nothing to type or refresh. You can download the paper template and workshop pack now to prepare.
A second, separate copy of the assessment tool for the in-room Inject 1. Once the facilitator presents the new information, your team re-runs the assessment here — your initial Scenario 2 assessment stays untouched, so you can compare the two.
🔒 Your facilitator opens the Inject 1 tool in the room once Inject 1 is presented — it unlocks here automatically; nothing to type or refresh.
How your team's risk judgement changed once Inject 1 arrived. Highlighted rows are the ones that moved.
| Initial analysis | After Inject 1 | |
|---|---|---|
| {{ row.label }} | {{ row.a }} | {{ row.b }}moved |
{{ wiz_s2_comparison.initial.rationale || '—' }}
{{ wiz_s2_comparison.inject1.rationale || '—' }}
Close the loop: test your judgement on the risk classification quiz, dig into the further reading, and keep practising at your own pace with real EDPB worked cases.
Seven short breach cases — commit to a risk classification for each, then see the reference answer and the reasoning behind it. A quick way to test the judgement you built during the day.
Scientific papers on breach-harm research and practitioners' insights — to deepen your understanding after the workshop.
Seven EDPB worked examples, from misdirected emails to a hacked whistleblower database — practise the method and compare your call with the official outcome.
Optional deeper reading to take the method further after the workshop: current research on breach harm, and how breaches are assessed and communicated in practice. Tick each as you finish.
🔒 Your facilitator opens this at the close of the workshop — it unlocks here automatically, nothing to type or refresh.
Seven additional breach scenarios from the EDPB and EDPS guidelines. Each one has an established expected outcome — apply the body of knowledge and compare your reasoning against the reference rationale.
Sent by email roughly one week after the workshop. You will apply the body of knowledge to seven additional cases from the EDPB and EDPS guidelines, each with an established expected outcome you can compare your reasoning against.
Unlocked. Choose any case to begin:
{{ train_instructor_note }}
Questions to debate as a team while working through the assessment. These do not feed the engine — they are prompts for the team's reasoning.
This guided mode will ask you questions in plain language and translate your answers into the EUDPR / EDPB risk categories. It's intended for staff dealing with a breach for the first time, or who want a structured walk-through.
Expect about 10–15 minutes. You can step back at any point. At the end you'll see the calculated risk and which legal obligations apply.
ⓘ Tip: The questions below are the same ones a DPO works through in a real incident. They follow the four phases of the assessment method you saw in the pre-work — gather the facts, weigh the likelihood, weigh the severity, then weigh the circumstances and judge. The ribbon above the progress bar shows which phase you are in. Before the result is revealed you will commit to your own judgement, and then compare it with the automatic calculation.
Some basic details for the report header. None of these affect the risk calculation, but they appear at the top of the final report and several are referenced by the EDPS notification template.
When ticked, the controller's notification and DS-communication obligations are governed by Arts. 92, 93 and 94 — not Arts. 34 and 35. The risk calculation is identical for both scopes; only the legal references in the report differ. Most EU institutions leave this unchecked.
Describe what happened in your own words. Don't worry about technical terms — write as if explaining to a colleague who wasn't involved. We'll ask the technical follow-ups in the next steps.
A breach can affect data in three different ways. Tick all that apply — many breaches affect more than one.
Pick the option that best describes how the breach happened.
Five dates matter. The most important is Date of Awareness — that's what starts the 72-hour clock under Art. 34(1) EUDPR. The notification dates can be left blank if you haven't notified yet; the wizard surfaces a warning if the deadline has passed.
Pick the most representative category from the institution's DS register. Then confirm or adjust the inherent vulnerability for this specific case. If multiple categories are affected you'll add the others later as variations.
About the population, not the incident. The level is pre-filled from the chosen category — adjust if this specific case warrants a different one (for example, a politically sensitive subset of an otherwise general-public category).
If someone unauthorised got hold of the data, can they actually identify the people in it?
After the breach, who had access, or what happened to the data?
A deliberate attack is more likely to lead to data being misused. Asking about intent and exploitation.
Different from "where did it end up" — here we want to know whether the data was physically extracted from your systems by an attacker, or whether it remained inside even though access happened.
How widely did the data spread?
Confirmed exfiltration forces Likelihood ≥ 4 because once data has left your perimeter you cannot put it back — the worst-case must be assumed. Plausible/unknown with an external attack pushes Likelihood ≥ 3.
None is the only value that enables the null-impact downgrade later (which can take a RISK breach down to LOW). Pick "none" only when you have positive evidence — not just absence of evidence.
Different data carries different risk if exposed. Pick the most sensitive kind affected, even if only part of the dataset.
Volume affects how widely the harm could spread. The Expert tab and the EDPS Art. 34 notification form distinguish between individuals (distinct people) and records (distinct data items — one person can have several). Fill what you know; the engine cross-validates against the band you pick below.
Then pick the closest band — scale is recorded as part of the assessment and weighed qualitatively alongside the sensitivity of the data (EDPB Guidelines 9/2022 §4.6.2; the EDPS notes that more individuals does not automatically mean more risk per individual). If the exact number is unknown, leave the inputs blank and pick a band based on best estimate.
Realistic worst-case consequences, given everything you've described.
Tick every harm realistically possible. If none apply, leave them all unticked and confirm below.
A few questions about the institution's response. These don't change the inherent risk of the breach, but they affect which downgrades apply, and they also fill in the report fields that the EDPS expects to see.
Containment / recovery / persistence together with exfiltrationStatus = 'none' and harmsConfirmed = true can trigger a one-step risk downgrade (RISK→LOW or HIGH RISK→RISK) for benign incidents — see EDPB Cases 01, 09, 15.
The operational status flags (managed/contained, investigation ongoing, CERT-EU notified) don't change the score but generate the cross-validation warnings the EDPS expects to see in the final report. Leaving them unset will trigger warnings like "breach is not marked as contained and no investigation is ongoing".
You've scored this for {{ wiz_primaryCategoryLabel }}. The same breach can affect other categories with a different risk profile (e.g. employees + minors).
For each additional category, only mark the factors that differ from your primary scoring. Everything else is inherited.
Most often, only the three Severity factors change. The breach mechanics (how data was lost, where it ended up, whether it was an attack) are properties of the incident itself, so they're inherited. What can legitimately differ is who the affected people are and what the consequences mean for them.
Inherent vulnerability — how vulnerable is this category before any breach? About the population, not the incident. When does it differ? When the new category has a different vulnerability profile — e.g. you scored for general staff (Standard) but the breach also affected minors (High) or whistleblowers (Critical).
Data nature and sensitivity (I1) — what kind of data was exposed, and does the combination of fields itself enable harm? When does it differ? When the breach exposed different fields for different categories — e.g. names & addresses for visitors (Basic) but health records for patients (Special category) — or when one category's data combines into a harm pattern (e.g. name + location patterns ⇒ surveillance).
Consequences (I2) — what could realistically happen to these specific people? When does it differ? Same data can have different impact — e.g. a leaked address is annoying for most but life-threatening for an abuse survivor.
If unsure, leave the select on inherit. You can refine in Expert mode after the wizard.
| DS category | Inherent vulnerabilityhow vulnerable as a population | Data nature & sensitivitywhat kind of data was exposed | Consequencesrealistic worst case for them | Notes | |
|---|---|---|---|---|---|
You have gathered the facts, weighed the likelihood and the severity, and reviewed the mitigating circumstances. Before the tool shows its automatic calculation, record your own professional judgement — exactly as you would if you had no tool. On the next screen you will compare the two.
Weigh the two answers above together with the mitigating and aggravating circumstances you reviewed. There is no arithmetic here — this is your call, the same call Art. 34/35 EUDPR asks of the controller.
This breach affects more than one group of data subjects. Classify the risk for each group — the notification obligations follow the most-at-risk group.
ⓘ Once locked, your judgement cannot be edited — the point of the exercise is an honest before/after comparison, not a polished answer.
The tool has assessed the same facts you just judged. Compare the two columns — where they agree, you have independent confirmation; where they differ, one of you has seen something the other has not. That difference is the most valuable thing on this screen: bring it to the debrief.
🔒 Your judgement has been recorded and locked. The tool's automatic calculation stays hidden until your facilitator reveals it to the room — once they do, the comparison appears here automatically (nothing to refresh).
{{ wiz_judgement.rationale }}
This scenario is based on a real example from the EDPB Guidelines / EDPS Annex 2 with an established expected outcome. You can review the pedagogical analysis now (rationale, per-field comparison, lessons) — or close this exercise and try another scenario.
This scenario does not have a single "correct" answer — it is designed to be debated as a team. You can review {{ train_scenario.discussion_blocks.length ? 'the discussion prompts and the expected outcome band' : 'the expected outcome band and its rationale' }} now, or close this exercise and try another.
{{ train_scenario.expected_band_rationale }}
{{ train_scenario.edpb_reasoning }}
Source: {{ train_scenario.edpb_source }}
The EDPB values are blurred by default so you can review your own choices first.
| Field | Your value | EDPB value | Verdict |
|---|---|---|---|
| CIA dimensions | {{ train_display(train_compare('cia').trainee) }} | {{ train_display(train_compare('cia').edpb) }} | {{ train_compare('cia').verdict }} |
| Root cause | {{ train_display(train_compare('cause').trainee) }} | {{ train_display(train_compare('cause').edpb) }} | {{ train_compare('cause').verdict }} |
| Identifiability (can the data be read?) | {{ train_levelLabel('l1', train_compare('l1').trainee) }} (sub: {{ train_compare('l1sub').trainee }}) | {{ train_levelLabel('l1', train_compare('l1').edpb) }} (sub: {{ train_compare('l1sub').edpb }}) | {{ train_compare('l1').verdict }} |
| Exposure (where did it end up?) | {{ train_levelLabel('l2', train_compare('l2').trainee) }} | {{ train_levelLabel('l2', train_compare('l2').edpb) }} | {{ train_compare('l2').verdict }} |
| Cause (accident or deliberate?) | {{ train_levelLabel('l3', train_compare('l3').trainee) }} | {{ train_levelLabel('l3', train_compare('l3').edpb) }} | {{ train_compare('l3').verdict }} |
| Vulnerability (who the people are) | {{ train_levelLabel('i0', train_compare('i0').trainee) }} | {{ train_levelLabel('i0', train_compare('i0').edpb) }} | {{ train_compare('i0').verdict }} |
| Data sensitivity | {{ train_levelLabel('i1', train_compare('i1').trainee) }} | {{ train_levelLabel('i1', train_compare('i1').edpb) }} | {{ train_compare('i1').verdict }} |
| Consequences | {{ train_levelLabel('i2', train_compare('i2').trainee) }} | {{ train_levelLabel('i2', train_compare('i2').edpb) }} | {{ train_compare('i2').verdict }} |
| Volume (documentary) | {{ train_levelLabel('vol', train_compare('vol').trainee) }} | {{ train_levelLabel('vol', train_compare('vol').edpb) }} | {{ train_compare('vol').verdict }} |
| Harms | {{ train_display(train_compare('harms').trainee) }} | {{ train_display(train_compare('harms').edpb) }} | {{ train_compare('harms').verdict }} |
| Harms taxonomy reviewed | {{ train_display(train_compare('harmsConfirmed').trainee) }} | {{ train_display(train_compare('harmsConfirmed').edpb) }} | {{ train_compare('harmsConfirmed').verdict }} |
| Recipient | {{ train_display(train_compare('recipientType').trainee) }} | {{ train_display(train_compare('recipientType').edpb) }} | {{ train_compare('recipientType').verdict }} |
| Exfiltration | {{ train_display(train_compare('exfiltrationStatus').trainee) }} | {{ train_display(train_compare('exfiltrationStatus').edpb) }} | {{ train_compare('exfiltrationStatus').verdict }} |
| Spread | {{ train_display(train_compare('spreadStatus').trainee) }} | {{ train_display(train_compare('spreadStatus').edpb) }} | {{ train_compare('spreadStatus').verdict }} |
| Response actions | {{ train_display(train_compare('dec').trainee) }} | {{ train_display(train_compare('dec').edpb) }} | {{ train_compare('dec').verdict }} |
You are about to walk through {{ train_scenario.title }} step by step. This is your pre-work for the in-person ARETE workshop.
Keep two files open in front of you as you read:
Risk to data subjects — not risk to the institution — drives breach notification decisions. As you read, keep asking yourself: what does this mean for the 1,750 external experts whose data is on that laptop?
Estimated time for the briefing: 20–30 minutes. You can leave at any point — when you come back, the briefing continues from the screen where you stopped.
Before we get to the incident itself, here is who's involved and what data is being processed.
SocialWorld EU is an EU institutional body operating under Regulation (EU) 2018/1725 (EUDPR). It runs UnionGate, an online competence and knowledge hub bringing together experts in social-affairs policy, which periodically hosts technical workshops. SocialWorld EU has well-defined internal IT security procedures, a regulatory compliance framework, a Data Protection Officer (DPO), a Local Cybersecurity Officer (LCO), and a documented incident response procedure.
SocialWorld EU uses an external consultant to animate the UnionGate community and organise its workshops. The consultant operates under a service contract with a Data Processing Agreement (DPA) under Art. 29 EUDPR. The DPA requires:
About 1,750 external technical experts (PhD researchers, university professors, policy makers, journalists, NGOs, sociologists, MEPs and national ministry experts) — first and last name, job title, professional email and professional postal address — invited to a recent UnionGate workshop. No special-category data (no health, no political, no financial). The original list is also held on SocialWorld EU's secured internal servers (i.e. a backup exists): the controller has no permanent availability loss.
Find Step 4 · Whose data was affected? in your template. What is the DS category? Note also: who is the controller, and who is the processor in this case? Is this a personal data breach as defined in Art. 3(16) EUDPR? You can consult the Reference library (the 📚 button above) if you need to look up these definitions.
Here is the chronology of how the institution learned about the incident.
Find Step 1 · When did this happen? in your template. Note the key dates. Critical question: at what precise moment does SocialWorld EU become "aware" of a personal data breach for the purposes of the 72-hour notification deadline under Art. 34(1) EUDPR — when the consultant calls the Head of Unit on Day 1, or when IT Security is informed (Day 4) / completes its assessment (Day 5)? Justify your answer in one or two sentences.
(Tip from the Reference library: "awareness" means reasonable degree of certainty that a security incident has resulted in personal data being compromised — NOT just the moment IT first sees an alert.)
The IT Security team has completed its first technical assessment. Here is what they have established so far.
Now you have the technical facts. Find these steps in your template and fill them in based on what you've read:
Don't fill in data sensitivity, consequences or harms yet — there's more to come on the next screen.
You now have everything you need for an initial assessment. Take 5–10 minutes to fill in the remaining steps on your paper template.
Then turn to the Your judgement page of your template and commit to your own call:
Take your time. When you're done, click Continue — before you commit your judgement, one more thing to think through.
A risk band is only as good as the threats behind it. Before you commit your judgement, think through who is exposed and to what — the way the EDPS Guidelines ask a controller to.
You don't score anything new here — you just sharpen the reasoning behind the judgement you're about to commit.
You have read the full case, scored it on your paper template, and thought through the threats. Now record your final pre-work judgement here. It is saved with your account and locks once you commit it — at the workshop you will defend it, compare it with your colleagues' calls, and revise it when new information arrives in the room.
Weigh the two answers above together with the mitigating and aggravating circumstances. There is no arithmetic here — this is your call, the same call Art. 34/35 EUDPR asks of the controller.
ⓘ Once locked, your judgement cannot be edited — the workshop debrief works from an honest, committed position, not a polished answer. New information will arrive in the room, and you will get a separate chance to revise your call there.
New information has arrived. Weigh it against your locked pre-work judgement and record your revised call. Where nothing changed, say so — holding your position under pressure is as valid as moving, as long as the rationale carries it.
Revised question: {{ train_scenario.inject.revised_question }}
Likelihood: {{ wiz_judgeLabel('likelihood', s1_judgement.likelihood) }} · Severity: {{ wiz_judgeLabel('severity', s1_judgement.severity) }} · Classification: {{ wiz_judgeLabel('band', s1_judgement.band) }}
Notify EDPS: {{ s1_judgement.notify === 'yes' ? 'Yes' : 'No' }} · Communicate to DS: {{ s1_judgement.communicate === 'yes' ? 'Yes' : 'No' }}
