{{ 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: If you already know the methodology and want the full tabbed interface, switch to Expert mode using the toggle at the top of the page.
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 (I0) for this specific case. If multiple categories are affected you'll add the others later as variations.
About the population, not the incident. The I0 is pre-filled from the chosen category — adjust if this specific case warrants a different score (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 — this is the value the engine uses for scoring (Volume factor, EDPB Guidelines 9/2022 §4.6.2). 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 Impact 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 (I0) — 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, +0) but the breach also affected minors (High, +1) or whistleblowers (Critical, +2).
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 | |
|---|---|---|---|---|---|
Based on what you've entered, here's the calculated risk for each affected category. The overall breach risk is the worst of these, and that's what determines your legal obligations.
| DS category | L | I | Matrix output | Final (after overrides) |
|---|---|---|---|---|
| {{ r.label }}(primary) | {{ r.calc.L }} | {{ r.calc.I }} | {{ levelLabel(r.calc.matrixLev, true) }} | {{ levelLabel(r.calc.fin, true) }} |
| Matrix rule applied: {{ wiz_matrixRule(r.calc.L, r.calc.I, wiz_has113HarmForResult(r)).text }} An override changed the final level from {{ levelLabel(r.calc.matrixLev) }} to {{ levelLabel(r.calc.fin) }} — see Engine warnings below. | ||||
The controller (typically the institution's senior management or the DPO acting on their behalf) records here whether the calculated risk and the resulting notification decision are agreed. Optional — you can leave this for the senior reviewer to complete in Expert mode.
Tick this only if direct DS communication would involve disproportionate effort and a public communication (or equivalently effective measure) will be issued instead.
Draft the four key elements that the Article 35 communication to the most affected category (current employees) would contain. Use clear, non-technical language. Bullet form is fine — this is a draft, not final copy.
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 the discussion prompts and the expected outcome band 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 }} |
| L1 (ease of ID) | {{ train_display(train_compare('l1').trainee) }} (sub: {{ train_compare('l1sub').trainee }}) | {{ train_display(train_compare('l1').edpb) }} (sub: {{ train_compare('l1sub').edpb }}) | {{ train_compare('l1').verdict }} |
| L2 (exposure) | {{ train_display(train_compare('l2').trainee) }} | {{ train_display(train_compare('l2').edpb) }} | {{ train_compare('l2').verdict }} |
| L3 (root-cause severity) | {{ train_display(train_compare('l3').trainee) }} | {{ train_display(train_compare('l3').edpb) }} | {{ train_compare('l3').verdict }} |
| I0 (DS vulnerability) | {{ train_display(train_compare('i0').trainee) }} | {{ train_display(train_compare('i0').edpb) }} | {{ train_compare('i0').verdict }} |
| I1 (data nature) | {{ train_display(train_compare('i1').trainee) }} | {{ train_display(train_compare('i1').edpb) }} | {{ train_compare('i1').verdict }} |
| I2 (consequences) | {{ train_display(train_compare('i2').trainee) }} | {{ train_display(train_compare('i2').edpb) }} | {{ train_compare('i2').verdict }} |
| Vol (documentary) | {{ train_display(train_compare('vol').trainee) }} | {{ train_display(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 }} |
Personal Data Breach Risk Assessment👨🏫 Instructor mode
Please sign in with the username and password from your invitation email.
{{ arete_auth_error }}
On your first sign-in you'll have the option to set your own username and password for better pseudonymity. You can also keep the ones from the invitation email — that's up to you.
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…
Items are ordered along the training timeline. Tick each one at the right moment; changes broadcast to every connected trainee in real time.
💡 Sections (sidebar entries) and individual items (scenarios, questionnaires) are independent gates — opening a sidebar section does not auto-open the items inside it. The pre-work scenario (S1 — Encrypted Gateway) is always available and has no toggle.
ARETE prepares you to perform a mature 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.
Additional sections will appear here as your facilitator opens them during the workshop on {{ COURSE_META.date }}.
| Time | Block | Mode |
|---|---|---|
| {{ row.time }} | {{ row.block }} | {{ row.mode }} |
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. Four 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, adverse effects are vague, and the rationale for the risk score is missing or implicit.
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.
Article 35 communications often lack the required elements (nature, consequences, mitigation, contact) and lean on overly technical or vague language that fails to empower the data subject.
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 methodology to a breach scenario — identifying the key risks to data subjects, assigning a Low / 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.
These three objectives map directly to the four Kirkpatrick measurement levels collected through the platform: the pre-work diagnostic captures your baseline (LO1 + LO2), the closing knowledge check measures the learning gain, the action plan records the behavioural commitment (LO3), and the end-of-day feedback captures your reaction to the programme.
Four blocks. Total effort: ~30 minutes. Please complete before the workshop day — the first 30 minutes of the session activate this material rather than re-deliver it.
Five short readings curated from the reference library. Tick each as you finish.
Five short risk-rating questions on simple cases. Your answers establish the baseline for the workshop's Level 2 measurement. The questions are kept simple on purpose — they prime you on the kind of judgement you will make in the room.
🔒 Your facilitator will open this survey when pre-work begins. Until then, focus on the readings above.
⚠ No "correct answer" feedback is shown at this stage — that comes during the workshop's pre-work activation. Please commit to a judgement on each item.
An 8-screen guided briefing of a realistic breach scenario. As you read, capture your scoring on the paper template. Open the briefing, walk through it at your own pace, and bring the completed template to the workshop.
Expected band: Unlikely risk ⇄ Risk. The scenario is intentionally ambiguous — there's no single "right" answer. Your reasoning is what we will discuss in the workshop's opening.
Identify one breach or near-miss from your institution that you would like to discuss during the day. Anonymise it. You're not obliged to share — it's a prompt for your own thinking and a candidate example for the plenary debriefs.
Stored only in your browser (localStorage). Nothing is uploaded.
One in-room scenario delivered in three parts over the half-day. Your pre-work (Scenario 1) is the preparation. Materials below unlock when your facilitator shares the code at the start of Part A.
A multi-actor breach involving a third-party processor, sensitive data combinations, and a retention failure that compounds the case. You work it across three modes:
🔒 Unlocked at the start of Part A. Your facilitator will share the code (ARETE-S2).
Three facilitators in role (Controller, DPO, IT Security Officer) re-enact the discovery meeting and model the methodology in voice. You observe. Take notes on which framings sound right and which feel off — those are the inputs for Part B.
Plenary discussion: name the framings you observed in Part A, map them to the methodology phases on the flipchart. The facilitators draw out where the roleplay was deliberately weak so the cohort spots the trap before it bites them in Part C.
New injects arrive. Your team applies the methodology, decides Art. 34 / Art. 35, drafts the four communication elements (nature · consequences · mitigation · contact). This is the Level 2 measurement artefact — copy the four blocks into your team's deliverable when you submit.
💡 Use the same assessment tool above — the wizard will guide you through the scoring and then expose the four communication textareas on the Result step.
Eight multiple-choice questions covering the day's content, administered at the close of the workshop before the plenary debrief. Compared against your pre-work diagnostic, this gives the Level 2 measurement for the cohort.
🔒 Your facilitator will open this near the end of the workshop. Unlike the diagnostic, you'll see the correct answer and a short explanation after submitting.
Read each question carefully. You will see the correct answer and a short explanation after submitting.
From the baseline you set before the workshop to the closing knowledge check.
The baseline was hidden during pre-work so it wouldn't bias your answers. Now that the workshop is over, you can compare them. A positive delta is a Level 2 learning gain in the Kirkpatrick framework — your team's collective gain is what the programme reports back to EDPS leadership.
Two commitments to write down before you leave. These are the most honest behaviour-change indicators the team collects on the day; they also seed the Level 3 follow-up survey three to six months later.
🔒 Your facilitator will open this at the close of the workshop.
A short reaction form covering content, methods, and facilitation. Eleven 1-to-5 ratings and three open questions. The "confidence in applying" items are the strongest early predictor of Level 3 outcomes — your honest answer is more useful than a polite one.
🔒 Your facilitator will open this just before you leave.
| 1 Strongly disagree | 2 | 3 | 4 | 5 Strongly agree | |
|---|---|---|---|---|---|
| {{ item.text }} |
Seven additional breach scenarios from the EDPB and EDPS guidelines. Each one has an established expected outcome — apply the methodology and compare your reasoning against the reference rationale.
Sent by email roughly one week after the workshop. You will apply the methodology 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:
Materials to consult before, during, and after the workshop. Six tabs: About ARETE · Glossary · EUDPR · EDPB Guidelines 9/2022 · EDPS Guidelines (Dec 2018) · Methodology primer.
The same library is reachable from inside the pre-work briefing and inside any open scenario — look for the 📚 Reference library button in the top bar of every screen.
For questions about the programme, schedule, or pre-work, reach the facilitation team at {{ COURSE_META.contactEmail }}.
{{ arete_username }}
({{ arete_user_role }})
The individual pre-work exercise: a consultant's encrypted laptop is stolen. Trainees work it at home on the paper template through an 8-screen guided briefing, then submit the pre-work diagnostic. It is ambiguous by design — strong arguments exist for both Unlikely risk and Risk. The goal is a defensible written rationale, not a single "correct" verdict.
Gold = before the day (at home); navy = in the room. Trainees should arrive having completed every box up to the diagnostic.
An external consultant's personal laptop is stolen in an opportunistic home burglary. It holds a local copy of ~150 external experts' contact data (name, professional email, affiliation; phone numbers added later — see the inject). BitLocker is enabled with a 20+ character passphrase; the MDM remote-wipe command was sent but is pending because the device has not reconnected. Backups exist (no availability loss). No special-category data.
Instructor mode demonstrates the optimistic stance → LOW (trust the encryption: L1=1a "strongly encrypted" + crypto-effective downgrade; no EDPS notification, Art. 35(3)(a) exemption). The L1=4 stance → RISK / High risk (treat the encryption as defeatable while the device is unrecovered) is equally defensible. Optimistic-path scoring: L2=2, L3=1, I1=2, I2=1, harms empty with "harms taxonomy reviewed" ticked.
Handouts: ARETE_S1_paper_template.docx · ARETE_S1_workshop_pack.docx · ARETE_shared_reference.docx.
The only in-room scenario, delivered in three parts (roleplay → debrief → team decision). A phishing-driven cloud compromise exposes HR data for 15,000+ current and former employees and candidates. Expected outcome: HIGH RISK — notify the EDPS within 72h and communicate to data subjects under Art. 35.
Data exposed: current & former employees — name, address, national ID, bank account, payroll; candidates — name, email, phone. The national-ID + bank combination is the §113-class identity-theft harm that drives HIGH RISK. The 5-hour detection gap is the institutional control failure to surface.
Three facilitators act the breach meeting in role. The point is to demonstrate the framing tension — the Controller worried about institutional reputation, the IT Officer about the technical fix, the DPO pulling the conversation back to risk to data subjects. A mid-scene inject lands new facts. Trainees observe — they do not decide yet.
Metalinguistic debrief of the roleplay: name the framing errors the room just saw, then build the methodology on the flipchart — CIA, likelihood/impact, the three-tier outcome, and where Art. 34 vs Art. 35 sit. This is the bridge from "watching" to "doing".
Teams work the case on the tool: classify, justify, decide Art. 34 / Art. 35, and draft the four communication elements. Inject #2 (retention violation + press inquiry) is delivered at set-up; inject #3 is facilitator-delivered at 11:30. Mixed-discipline teams mirror a real breach-response team.
HIGH RISK. L=4, I=4. §113-class harms: identity theft / fraud, financial loss, reputation damage. Notify the EDPS within 72h and communicate under Art. 35(1) — no Art. 35(3) exemption applies (no encryption; the institution holds the contact details). Key teaching point: separate the breach itself (HIGH RISK) from the accountability questions the injects raise (the storage-limitation violation and the press inquiry), and decide whether the retention violation belongs in the same Art. 34 notification.
Handouts: ARETE_S2_paper_template.docx · ARETE_S2_workshop_pack.docx (inject cards) · ARETE_shared_reference.docx.
Live snapshot of how the cohort is progressing. Updates every 10 seconds and as soon as any trainee submits a questionnaire.
Loading cohort data…
⚠ {{ arete_dashboard_error }}
| Username | Online | Role | Last seen | Readings | L2 base | L2 final | Plan | L1 |
|---|---|---|---|---|---|---|---|---|
| {{ u.username || u.id }} | ● | {{ u.role }} | {{ u.last_seen_at ? u.last_seen_at.slice(0, 16).replace('T', ' ') : '—' }} | {{ u.prework.readings_done }}/{{ u.prework.readings_total }} | {{ pf_dashCell(u, 'prework_diagnostic') }} | {{ pf_dashCell(u, 'knowledge_check') }} | {{ pf_dashCell(u, 'action_plan') }} | {{ pf_dashCell(u, 'level1_reaction') }} |
No submissions yet. Average score: {{ arete_dashboard.stats.diagnostic.avg_score }} / {{ ARETE_DIAGNOSTIC.length }} (across {{ arete_dashboard.stats.diagnostic.submitted }} submissions).
No submissions yet. Average score: {{ arete_dashboard.stats.knowledge_check.avg_score }} / {{ ARETE_KNOWLEDGE_CHECK.length }} (across {{ arete_dashboard.stats.knowledge_check.submitted }} submissions). The Level 2 delta = this average − diagnostic average.
No action plans submitted yet.
No reaction surveys submitted yet.
| Item | Average (1-5) |
|---|---|
| {{ item.text }} | {{ arete_dashboard.stats.reaction.per_item_average[item.id] != null ? arete_dashboard.stats.reaction.per_item_average[item.id] : '—' }} |
Model answers and pedagogical guidance for the in-room debrief. Confidential — do not share with trainees.
You are about to walk through {{ train_scenario.title }} step by step. This is your pre-work for the in-person ARETE workshop.
You will need the paper template open in front of you as you read. Download it here if you haven't already.
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 150 external experts whose data is on that laptop?
Estimated time for the briefing: 20–30 minutes. You can stop and resume at any time.
Before we get to the incident itself, here is who's involved and what data is being processed.
EU Connect is an EU institutional body. It runs UnionGate, an initiative that periodically hosts technical workshops bringing together external experts. EU Connect has well-defined IT security procedures, a Data Protection Officer (DPO), a Local Cybersecurity Officer (LCO), and a documented incident response procedure.
EU Connect uses an external consultant for specific workshop coordination tasks. The consultant operates under a service contract with a Data Processing Agreement (DPA) under Art. 29 EUDPR. The DPA requires:
About 150 external technical experts — names, professional email addresses, and institutional affiliations — invited to a recent UnionGate workshop. No special-category data (no health, no political, no financial). The dataset is also retained on EU Connect's secured internal servers (i.e. a backup exists).
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 from the hub 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 EU Connect become "aware" of a personal data breach for the purposes of the 72-hour notification deadline under Art. 34(1) EUDPR? 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 I1 / I2 / 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 Result computation page of your template and work out:
Take your time. When you're done, click Continue — new information will arrive that may change your assessment.
Several hours after your first assessment, IT Security comes back to you with two updates.
1. Remote wipe status. The MDM platform confirms that the stolen laptop has NOT connected to any network since the theft. The remote wipe command remains unexecuted. IT Security assesses that if the device remains offline indefinitely, the wipe cannot be completed.
2. Dataset scope. The workshop coordinator reports that the dataset on the laptop also included the experts' direct phone numbers, which were added to a separate column for logistical coordination. This was not part of the original dataset specification — but it was on the device when it was stolen.
This update changes two things you might have scored:
Update your scoring on the template. Cross out the old values and write the new ones next to them — this gives you a record of how your thinking evolved (the workshop facilitator will want to see this).
Now write your revised assessment: did the level change? Did your notification decision change?
Below are the questions we'll discuss in the workshop. You don't need to answer them all in detail — pick the ones that matter most to you, and write a sentence or two per block on the back of your template. Bring your notes to the workshop.
Write a short answer for each one (one or two sentences). These are the questions we'll dig into during the workshop debrief — your written attempt is your starting position.
Well done. You've worked through the case, scored it twice (before and after the inject), and answered the discussion questions. Here's what to bring with you to the in-person workshop:
The Reference library on the pre-work hub remains open. Skim the EUDPR articles, the §113 harm class explanation, or the Risk-calculation primer if anything is unclear.
See you at the workshop!