Security & Compliance · Level 2
The data
Mission briefing
Mission 5-B: A user just typed their Social Security number into a field you labeled "Order number." They misread it under stress. Now there's sensitive personal data sitting somewhere it was never meant to be, and the team has to deal with it carefully.
An SSN is PII — Personally Identifiable Information. Data that can identify a real person: names, emails, government IDs, addresses. It's handled under stricter rules than ordinary data because a leak can genuinely harm someone.
Now we apply our data retention policy — the rules for how long we keep different kinds of data and when we delete it. PII that landed somewhere it shouldn't gets purged, not archived. The goal is to hold sensitive data for the shortest time we legitimately need it.
This is also a vulnerability worth fixing — a weakness someone could exploit, here a field that invites the wrong data. We design under zero trust: assume no request is automatically safe, verify everything. A clearer label and validation on that field closes the gap.
So a confusing label became a security problem. That reframes input design entirely — the label, the format hint, the validation aren't just UX polish, they're the first line of defense. I can prevent this category of mistake.
A confusing field caused users to enter sensitive data in the wrong place. Whose problem is it?