Responses dashboard
Live cohort progress · refreshes every 10s and on each submission.
Attendees ({{ attendees.length }})
| Name | Status | Pre-work | S1 briefing | S1 judgement | S2 risk | Risk quiz |
|---|---|---|---|---|---|---|
| {{ u.display_name || u.username }} {{ u.username }} |
{{ u.connected_now ? 'online' : 'offline' }} | {{ u.prework.readings_done }}/{{ u.prework.readings_total }} | ✓ done— |
{{ u.submissions.s1_judgement.band || '✓' }}—
revised: {{ u.submissions.s1_reassessment.band || '✓' }}
|
{{ u.submissions.s2_judgement.band || '✓' }}—
Inject 1: {{ u.submissions.s2_inject1_judgement.band || '✓' }}
|
Risk quiz — answer distribution
Scenario 1 — risk judgements · pre-work ({{ dash.stats.s1_judgement.submitted }}) vs in-class re-assessment ({{ dash.stats.s1_reassessment ? dash.stats.s1_reassessment.submitted : 0 }})
Scenario 2 — risk classification · initial ({{ dash.stats.s2_judgement.submitted }}) vs after Inject 1 ({{ dash.stats.s2_inject1_judgement ? dash.stats.s2_inject1_judgement.submitted : 0 }})
Decisions
The risk classification the trainees committed to, by scenario and before/after each Inject. Project this to discuss the results with the room — it updates live as they vote.
{{ g.title }}
Users
Create accounts with a chosen username & password, edit users, set or reset passwords, and change roles. New passwords are shown once.
🎟️ Registration code
{{ signupCode }}
ARETE_SIGNUP_CODE is set on the server, so students cannot create their own accounts. Add accounts below, or set a code in the server environment to hand out instead.
⚠ New credentials — shown once
| Username | Password | Role | ID |
|---|---|---|---|
| {{ u.username }} | {{ u.password }} | {{ u.role }} | {{ u.id }} |
{{ resetResult && resetResult.password }}
Add user
Accounts ({{ filteredUsers.length }} of {{ usersList.length }})
| Name | Role | Status | Last seen | Actions | |
|---|---|---|---|---|---|
| {{ u.display_name || u.username }} {{ u.username }} |
{{ u.role }} | online offline not signed in yet | {{ u.last_seen_at ? fmtTime(u.last_seen_at) : '—' }} | — |
Content
Edit the platform content files. Saves are schema-validated and persist in the data volume; the trainee app picks them up on next load.
Files
{{ contentKey || 'Select a file' }} overlay
Documents
The course files served from documents/. Download, replace or delete them; uploads persist in the data volume and survive image rebuilds.
{{ grp.label }}
| File | Size | Source | |||
|---|---|---|---|---|---|
| {{ d.name }} trainee | {{ (d.size/1024).toFixed(0) }} KB | editedbaked | Download |
Operations
Backups and data-retention compliance. Destructive actions need a dry-run and your password.
💾 Backups
{{ backupsDir }}| File | Size | Created | ||
|---|---|---|---|---|
| {{ b.name }} | {{ fmtBytes(b.size) }} | {{ b.mtime ? fmtTime(b.mtime) : '—' }} | encryptedplain | Download |
tools/restore_db.sh with the server stopped.
🕶️ Pseudonymise a cohort
| Now | → After |
|---|---|
| {{ s.old }} | {{ s.new }} |
🗑️ Purge old cohorts
Audit log
Every facilitator/admin action is recorded here.
| When | Who | Role | Action | Target | Detail |
|---|---|---|---|---|---|
| {{ fmtTime(e.ts) }} | {{ e.username }} | {{ e.role }} | {{ e.action }} | {{ e.target || '—' }} | {{ e.detail ? JSON.stringify(e.detail) : '' }} |
Scenario briefs
Facilitator guidance for the ARETE in-room scenarios — model answers, run-of-day, and facilitation watch-outs.
Scenario 1 — The Encrypted Gateway
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.
How it flows — from invitation to the room
Gold = before the day (at home); navy = in the room. Trainees should arrive having completed every box up to the diagnostic.
The case in 30 seconds
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.
Why it is ambiguous — the two defensible readings
- BitLocker + strong passphrase → data unintelligible
- Opportunistic burglary (other electronics taken) — not targeted
- Backups exist — no availability issue for the controller
- No special-category data
- Remote wipe never executed — device may stay offline indefinitely
- Encryption is intact today but not guaranteed forever
- Inject: direct phone numbers were also exposed
- Device is in an unknown actor's hands, offline
The midway inject (Day 1, 14:00 UTC)
How to facilitate the 09:00–09:25 activation
- Recap, do not re-teach. Ask 2–3 trainees for their band and one reason. The room should not be unanimous — surface the split.
- Compare to the baseline. The diagnostic is a Level-2 baseline; do not reveal "correct" answers — use it to show the spread of judgement.
- Draw out the three hinges: (a) when does Art. 34 "awareness" start — at detection, or when the DPO confirms personal data was involved? (b) is encryption a guarantee or a time-bound mitigation? (c) what did the inject change?
- Land the one-message: risk to data subjects drives the decision, not embarrassment to the institution.
Discussion blocks on the paper template
- Block 1 — Immediate actions & internal information flow: technical containment; the notification chain; the precise moment of "awareness" for the 72-hour clock.
- Block 2 — Breach identification: is this an Art. 3(16) breach? which of C/I/A? the consultant's status as processor and the role of the DPA.
- Block 3 — Initial risk assessment: choose Unlikely risk / Risk / High risk and justify with specific factors; what information is still missing.
Model answer & teaching note
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.
- Completed paper template (3 blocks + inject response)
- Submitted pre-work diagnostic (baseline, locked)
- Trainees who read "encrypted" and stop thinking — push on the pending wipe
- Treating "encrypted = automatically LOW" as a rule
- Confusing detection with "awareness" for the 72h clock
Handouts: ARETE_S1_paper_template.docx · ARETE_S1_workshop_pack.docx.
Scenario 2 — HR Recruiter Workstation Compromise
The only in-room scenario, delivered as independent team decision-making with one inject. A phishing e-mail plants an information-stealer on the HR recruiter's workstation; the attacker rides the recruiter's own authenticated sessions (MFA never triggered) and exfiltrates ~5 GB of on-premise HR records (correspondence, timesheets, appraisals, application files). The assessment is iterative: Risk at first, escalating to HIGH RISK after Inject 1 — the stolen files are confirmed to hold staff health data (special category, Art. 10) and are already being misused — notify the EDPS within 72h and communicate to data subjects under Art. 35.
The attack chain
Data exposed: on-premise HR records — internal/external correspondence, staff timesheets, appraisals and application files — for current employees and former employees. The base case is Risk; Inject 1 (the recovered files are confirmed to hold special-category health data — occupational-health certificates, disability-accommodation requests — and a sample is already public and being misused) is what drives HIGH RISK. Teaching point: a risk assessment is iterative — special-category data raises severity, confirmed misuse raises likelihood, and together they tip Risk into High risk.
How the three parts run
Pre-work activation (S1)
Part A — Roleplay
Part B — Debrief
Break
Part C — Teams (Inject 1 @ 11:30)
Closing KC + plenary
Part-by-part
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 body of knowledge on the flipchart — CIA, likelihood/severity, 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. The base assessment runs first; then Inject 1 (health data confirmed + active misuse) is facilitator-delivered at 11:30 for the re-assessment. Mixed-discipline teams mirror a real breach-response team.
Inject 1 (Day 4, 14:00 UTC)
The four discussion blocks
- Block 1 — Risk owners & information-security risks and the treatment plan.
- Block 2 — Roles & communication: DPO / LCO / IT / senior management; internal and external communication plans.
- Block 3 — Risk to data subjects & notification: distinguish the two groups; categorise under the three-tier framework; thresholds for notifying the DPO, the EDPS, and the data subjects; evidence needed.
- Block 4 — Article 35 communication: draft the four elements for current employees — nature of the breach, likely consequences, mitigation steps, contact point.
Model answer & teaching note
HIGH RISK after Inject 1 (base case is Risk). L=4, I=4. §113-class harms: identity theft / fraud, financial loss, discrimination or stigmatisation. Notify the EDPS within 72h and communicate under Art. 35(1) — no Art. 35(3) exemption applies (nothing was unintelligible to the attacker; the data is already public). Key teaching point: special-category (health) data raises severity and confirmed misuse raises likelihood — both move together, which is what tips Risk into High risk and triggers the Art. 35 communication.
- Risk classification + written justification
- Art. 34 notification decision
- Art. 35 four-element draft (nature / consequences / mitigation / contact)
- Individual closing knowledge check
- Run the Risk-vs-High-Risk debate without shutting it down
- Keep risk to data subjects central — not institutional reputation
- The §113 harm class is what flips L4∧I3 to HIGH RISK
- Don't let the inject derail the core notification decision
Handouts: ARETE_S2_paper_template.docx · ARETE_S2_workshop_pack.docx.