Training

Step 1 · What happened?

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.

Step 1 · What did the breach affect?

A breach can affect data in three different ways. Tick all that apply — many breaches affect more than one. Someone may have seen data they shouldn't have Examples: a laptop or USB was stolen; an email went to the wrong person; a hacker accessed a database; a document was left on a printer.

Step 1 · What caused the breach?

Pick the option that best describes how the breach happened. Someone outside the institution attacked us Examples: ransomware; phishing followed by credential theft; SQL injection; targeted intrusion by an external actor. Someone inside the institution used data they shouldn't have Examples: an employee copied a customer list; a staff member accessed records without business need; an ex-employee retained access.

Step 3 · Whose data was affected, and how vulnerable are they?

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. DS category * — Select — {{ r.cat }} ({{ wiz_i0Labels[r.i0] || 'Standard' }}) Custom — not in the register The DS register is empty. Pick Custom below or set up the register first.

Step 4 · Was this an accident or a deliberate attack?

A deliberate attack is more likely to lead to data being misused. Asking about intent and exploitation. Accidental — no malicious intent Wrong recipient; cc instead of bcc; misconfiguration; benign technical bug. Accidental, with possible opportunistic exposure Lost device in public; left documents in a taxi; possible third-party access cannot be ruled out, but no evidence of intent.