Designing a breach-response platform where the upload can’t fail, the data can’t cross, and the audit trail is a product feature
Youth Sports Platform
Snapshot
Organizations responding to a data breach have to tell a regulator what was compromised, and they have to prove how they know. That means ingesting a potentially compromised dataset, classifying every piece of personal, health, payment and privileged information inside it, and producing a defensible record of exactly what was analyzed and when. I designed the platform that does it — a desktop-only uploader, per-job isolated environments, AI classification with a human in the loop where it matters, and an immutable audit trail. Shipped to production in two months.
MY ROLE:
Product Designer — design only
TIMELINE:
2 months · Q4 2025 – Q1 2026
TEAM:
PM, BA, architects, ~10 engineers
SCOPE:
4 surfaces · 4 user classes · bilingual
OWNERSHIP:
Product Designer — design only
STATUS:
Product Designer — design only
The problem
An organization that has just been breached is on a regulatory clock, and three things stand between it and a defensible answer.
Getting the data in. Breach datasets are large and arrive from compromised infrastructure. Browser uploads aren't built for transfers that run across hours or days of interrupted connections, and every alternative — SFTP, email, a web portal — widens the attack surface at exactly the moment the organization can least afford it.
Classifying it at all. Someone has to find every piece of personally identifiable information, protected health information, payment card data and legally privileged material across documents, spreadsheets, scanned images, and whole Outlook archives. Done by hand, that is months of analyst time during which the organization cannot answer the regulator.
Proving it afterwards. Legal teams need to demonstrate that a specific dataset was analyzed at a specific moment and hasn't changed since. Under GDPR, HIPAA, PIPEDA and Quebec Law 25, the inability to prove that isn't an inconvenience — it's the liability.
2 months
Timeline
Day-one readiness, no soft launch.
4 roles
User classes
Client Users, Legal Counsel, Reviewers, Administrators.
5 jurisdictions
Residency
Canada, US, EU, Australia and New Zealand.
EN / FR
Compliance
GDPR, HIPAA, PIPEDA and Quebec Law 25.
Research
Stakeholder interviews across breach investigators, legal counsel and compliance officers, alongside a review of the requirements and the emerging data model.
Legal's requirement turned out to be narrower and sharper than "audit logging." They needed an immutable, timestamped cutoff — a moment after which the dataset provably could not change. Reviewers wanted density rather than clarity: as many classification decisions per screen as they could stand. Client representatives wanted progress and nothing else; they are not investigators and the platform shouldn't make them act like one.
The insight that changed the architecture: the four roles weren't variations on one workflow. A shared system with role-based visibility would have made every screen a compromise between four incompatible priorities — a reviewer's queue density is exactly wrong for a client checking status, and a client's progress view is useless to legal. That moved the design from one system with role gating to four role-specific surfaces over a common pipeline.
How I worked
The architecture was being written while I designed. Ten engineers, two months, and architects whose data model was landing about a week ahead of my screens — which meant any design assuming a different shape of data was dead on arrival.
So I worked against the requirements and the schema rather than a blank canvas. Before each flow I'd read what the API would actually return, design to that, and bring the cases where the response shape made the responder's job harder back to the architect as a specific request rather than a critique. Framing it that way mattered: an architect under deadline can act on "the reviewer needs these three fields in one response or they're clicking twice per document," and can't act on "this feels clunky."
I sequenced the work by what couldn't be retrofitted. Ingestion first, because it can't be re-architected once clients are mid-engagement. Isolation second, because it's structural and touches everything. Review efficiency last, because it can be optimized after launch without breaking anything. Testing ran in parallel rather than after — investigators, reviewers, and the legal and security teams concurrently — because two months doesn't allow a sequential validation phase.
The honest cost: designing to the schema makes you conservative. At least one screen shipped organized around what the system knew rather than what the responder needed to act on — the exact thing this case study argues against — because reopening the data model in week six wasn't worth the week it would have taken.
Decision 1 — Make the desktop uploader carry the whole ingestion experience
With web, SFTP and email ruled out, ingestion happens in one place: a desktop application using time-bound pre-signed URLs, resumable multipart transfer with checksums, and no password login — activation instead.
What I rejected: treating the uploader as a utility and putting the real experience in the portal. That was the natural split — thin desktop tool, rich web UI — and it would have been wrong. The client is mid-incident and the upload is the part that can fail. So the desktop app got the full progress model, pause and resume, per-file state and error recovery, and the portal mirrors that state rather than owning it.
What it cost: real installation friction — download, install, version enforcement — imposed on clients having the worst week of their professional lives, plus a second application to design and maintain.
Decision 2 — Put the isolation boundary in the architecture, and keep access control on top of it
Each engagement runs in its own isolated environment with its own storage and its own keys. Zero-Trust RBAC runs across the whole platform on top of that, scoping every action to an organization and a job.
What I rejected: treating access control as sufficient on its own. RBAC is software, and software has bugs — a permission check is one misconfigured row away from exposing one breach victim's data to another. Permission checks fail open; architectural separation fails closed. So the boundary had to exist structurally, with access control layered over it rather than standing in for it. Defence in depth, and for this product the depth is the value proposition.
What it cost: materially higher infrastructure cost and operational overhead per engagement, and two access models to reason about in every screen.
Decision 3 — Make the dataset freeze a decision someone takes, not a log someone finds
A "Commit Dataset" action behind two-step confirmation that freezes the dataset and writes an immutable, timestamped audit record.
What I rejected: background audit logging, which is how most systems handle this and which asks nothing of the user. I made it explicit and deliberately effortful because the legal value isn't the log — it's the provable human decision at a provable moment. An automatic log records what happened. A committed freeze records that someone chose, which is the thing counsel can stand behind.
What it cost: friction in a workflow that already had plenty, and a confirmation step users disliked at first.
The classification pipeline
Files run through OCR and AI/ML classification before any human sees them. Anomalies — corrupted files, suspicious metadata, disallowed types — divert into a hold queue for triage rather than blocking the pipeline, so validated items keep moving while reviewers decide whether to release, review manually or exclude.
Classification confidence is scored per label, and anything below a configurable threshold — default 80%, calibratable per category, with every threshold change itself audit-logged — routes to human review. A force-review policy overrides the threshold for high-stakes signals such as legal privilege regardless of confidence.
The design question underneath all of it: where does a human decision have to exist for the output to be legally defensible? Not everywhere — that's the months-of-analyst-time problem. Only at the points of genuine uncertainty, and at the points where being wrong is unrecoverable.
Validation
Legal approved the isolation architecture pre-launch after a threat-model walkthrough rather than a design review. Regulatory review passed across the four applicable regimes.
Workflows were tested with breach investigators, reviewers and legal counsel concurrently rather than in sequence — two months does not allow a separate validation phase, so validation had to run alongside design rather than after it.
Influence, and what outlived the project
Legal wanted to own data isolation and specify it as an access-control matrix. I argued the boundary couldn't live only in permissions — a permission check is one bad row from a breach inside a breach product — and that it had to be architectural, with access control layered on top rather than substituting for it.
I set up weekly reviews with legal and the architects and walked them through the threat model rather than the designs. By week three legal had approved the approach. By week four they were arguing for it to executive leadership themselves. That early alignment is why the project shipped — there were no late-stage architecture debates, on a timeline where a single one would have been fatal.
What came out of it was a method the team kept: inventory every constraint, map each to a specific design decision, sequence by retrofit-ability, build in parallel. Its value isn't speed — it's that everyone can see why each decision exists, which is what stops the same argument happening twice.
Outcomes
Designed and shipped a four-role incident response platform in two months, consolidating ingestion, classification, review, exception handling, retention and reporting into one system.
As reported by the client following release: Phase 1 assessment reduced from weeks of manual analysis to days, no cross-engagement access incidents in production, and regulatory review passed across GDPR, HIPAA, PIPEDA and Quebec Law 25. Shipped bilingual with residency enforcement across five jurisdictions.
Learnings
Regulatory constraint is free design direction. The isolation and residency requirements produced a better architecture than I would have argued for unprompted. The compliance surface did work that taste wouldn't have.
Sequencing by retrofit-ability is risk management, not planning. What can't be changed later has to be right first, even when it isn't the most urgent thing on the board.
An audit trail can be a feature. Building the freeze as a deliberate user action rather than background logging meant users understood it and legal trusted it — the same data, made legible by making it a decision.
What I'd do differently
I'd put a real breach investigator inside design iteration at week six rather than validating with them near launch. Their mental model of the review workflow differed from the one I'd built from interviews, and I caught it four weeks after launch. It was fixable. It shouldn't have needed fixing.
And I'd keep a decision log from day one. By week eight nobody could remember why specific architecture patterns had been chosen, including me. I now start one on every project — a habit that came directly out of getting it wrong here.