Case 02 · Secure.com · Enterprise security

I rebuilt a risk register sorted by category around the asset, so every finding rolls up to the asset it puts at risk.

Risk Tracker is the risk module in Secure.com's AI-native security platform. I redesigned it around the asset instead of the finding. Each asset carries its own risk per risk category, scored inherent → residual, and its findings roll up into it as evidence.

Why it mattered: Risk Tracker is meant to be where the whole platform comes together, but it sat in its own silo, sorted by category. Nothing answered the question leadership asks: which assets are actually at risk, and what do we fix first?
The turning point: My first version was a faster finding list. Our security SME stopped it and showed me how his team really runs risk, so I rebuilt it around the asset.
What changed: Findings from across the platform (vulnerabilities, misconfigurations, application security, attack paths and pentests) now roll up into risks on the asset they affect, scored per asset and risk category. In the demo tenant, 1,214 findings roll up into 48.
Where it is now: The SME who stopped v1 signed off on v2, and it's now live in Secure.com. It's too new for usage numbers yet.

Role

Product Designer II, and the only designer on the module

Owned

IA, interaction, and the UI itself, built in production React with Claude Code against our design system

Team

PM · security SME · 1 front-end engineer

Stage

About 4 to 6 weeks, v1 → v2 · live

A new module in a live enterprise platform. Our security SME checked it against the register his team uses to run risk today. Every screen shows representative demo data on a fictional tenant, not customer data.

The old Risk Register, with risk organized by category — Risk was organized by **category**, and the summary up top and the category totals didn't agree. The asset, the thing actually at risk, was three clicks deep.

The new Risk Tracker Overview: 48 open risks from 1,214 findings, severity breakdown, SLA status and posture — One Overview that answers **"where do I look first?"** 48 open risks from 1,214 findings, and every widget opens a filtered list. **Representative demo data.**

The problem

Security tools put out thousands of findings. Almost none of them answer the question leadership actually asks.

"Which of our assets is actually at risk, and what do we fix first?"

Secure.com is an AI-native security platform that launched publicly in December 2025. Its scanners keep finding CVEs, misconfigurations and exposures, and a single mid-size cloud tenant easily runs to over a thousand findings. The old module, called Risk Register back then, sorted all of it by taxonomy: category → subcategory → asset. You could browse the types of risk, but the asset you own sat three levels down, and nothing added up to an answer you could defend.

It also sat in its own silo. The platform's modules (vulnerabilities, misconfigurations, application security, attack paths and pentests) each found problems, but none of it came together as risk. The redesign made Risk Tracker the place where they meet.

The constraints. One front-end engineer. A scoring backend that another team was building at the same time, so the UI had to work on mock data first. And a register model that belonged to our security SME, not to me.

How I got there

Five decisions, starting with the one I got wrong.

Decision 00 · the turning point

I designed a faster list when the team needed a risk model.

My v1 was finding-centric. It had Active / All tabs and every CVE and misconfiguration was its own row, so it was a cleaner, quicker queue. I took it almost to staging before our security SME stopped it and sat me down to show me how risk actually works.

A finding isn't a risk, he said. An asset carries risk, and findings are evidence that adds to it. He showed me the register his team really uses, an ISO 27001-style register with 34 columns, inherent and residual scoring and defined treatment strategies. I'd optimized the wrong thing, so I threw out the finding-centric IA and started again from the asset.

That changed how I work. When a domain expert owns the mental model, I design to their model instead of swapping in a tidier one of my own.

Decision 01

Make the asset the primary entity and let findings roll up into it.

The tensionWhat should one row in the register be, a finding or an asset?

Rejected · findings firstMy v1. Fast to scan, but every patch spawns new rows and nothing answers "is this asset safe?"

Rejected · category taxonomyThe old Register. Easy to browse, but the asset is three clicks deep.

Chosen · asset firstStart from the asset. Each asset gets its own risk record, and findings become evidence that rolls up into it, so the list finally matches the question. Engineering now scores records per asset and risk category, so a busy asset can carry a few, but the asset is still where you start.

CostA risk only closes when all of its evidence does, so a busy asset can look slow to move.

The Risks list, grouped by asset: risk ID, asset, CIA rating, the risk in plain language, severity, risk score and inherent to residual — The new list, **grouped by asset**. Each row says what the risk is in plain language, how bad it is before and after controls, and where it sits in the queue. **Representative demo data.**

Decision 02

Keep inherent and residual as two numbers, so you can see what your controls bought.

The SME's register scores every risk twice: inherent (before controls) and residual (after). The gap between the two is the value of the security work, so each risk page reads as a before and after, with the mitigating control in between.

RejectedOne composite score (it hides what the controls bought) · residual only (you lose the before) · a heat map only (no answer for a single asset).

Chosen · two numbers, two jobsThe list still has a 0 to 100 risk score, on purpose. It ranks the queue. The inherent → residual pair is what tells you whether your controls are working.

CostPeople have to learn two numbers instead of one.

One asset's risk page: what the risk is in plain language, and inherent 25 Critical to residual 16 High with the mitigating control between them — One asset's risk. **Inherent 25 · Critical → Residual 16 · High** (likelihood × impact, 5×5 → 4×4), with "what is this risk?" in plain language. **Representative demo data.**

On the Overview's Strategic view, the same idea becomes two 5×5 likelihood × impact heat maps, inherent next to residual, so leadership can see at a glance what the security work bought.

Inherent and residual 5×5 heat maps side by side for the same 48 risks, with the treatment mix — **The same 48 risks, before and after controls.** The drop between the two maps is what matters. **Representative demo data.**

Decision 03

One Overview, two lenses, for two kinds of reader.

The tensionAnalysts work the queue today. Leadership wants posture over time. Same data, different questions.

RejectedTwo separate dashboards (two products to keep in sync) · one dashboard for both (too much for either).

Chosen · one Overview, two lensesOperational for working the queue and Strategic for posture. Every widget opens the filtered list when you click it.

CostA toggle people have to notice. It sits right above the KPIs for that reason.

Risk acceptance is a proper state too. It comes straight from the SME's treatment strategies (mitigate, accept, transfer, avoid), so accepted and expiring risks get their own lane.

risk-tracker / overview

One Overview with two lenses. Operational is for the queue and Strategic is for leadership. Representative demo data.

risk-tracker / risks

From the list into a risk. The inherent → residual scoring is one click away. Representative demo data.

Decision 04

Findings from every scanner meet in one record, so one fix can close many.

The tensionA vulnerability, a misconfiguration and an attack path on the same asset showed up as three competing alerts.

RejectedKeeping each scanner's alerts separate (three alerts for one problem) · merging them into one deduplicated finding (you lose the evidence).

Chosen · one risk, many pieces of evidenceFindings from across the platform (vulnerabilities, misconfigurations, application security, attack paths and pentests) roll up into the asset's risk for that category.

It made fixing simpler too. One base-image update can clear a whole cluster of an asset's findings in one go. I designed the contributors view and the handoffs out of it (linked cases, clone to ticket, accept risk), so you can act on a risk from the same place you read about it.

risk-tracker / RISK-000123 · contributors

Risk Contributors. Thirteen findings from four of those sources roll up into one asset's risk. Representative demo data.

Where it stands

The expert who stopped v1 approved v2, and it became the module's risk model.

What the model does, on the demo tenant

1,214 → 48

Findings roll up into risks on the assets they affect.

Representative demo data

4 → 1

Sources meet in one risk record for this asset, instead of four separate alerts.

Cross-scanner convergence

3 → 1

Levels between opening the module and reaching an asset. The old drill-down became one list.

Structural redesign

The same SME who stopped v1 signed off on the asset-centric v2. Its Overview is now the screen the module opens on, it went into our investor demos, and it's now live in the product.

It only just went live, so I don't have usage numbers yet. What I can stand behind is the model (risk built around the asset, scored inherent to residual), the SME's sign-off after he'd rejected v1, and the before and after on the question leadership asks.

What I took from it

The best call I made on this project was letting the expert's model win over mine.

My instinct was to make the list faster. The SME's model was built differently, and it was right. What I really learned was how to tell a faster list from a real risk model, and to notice when the better design is one I didn't come up with.

If I did it again, I'd ask the SME the asset-vs-finding question in week one. Thirty minutes would have saved a whole rejected version.

What I'd measure now that it's live, with targets: time from a new critical finding to an owner acting on its risk (under 48 hours), how many risks get accepted instead of mitigated (under 1 in 5, so acceptance stays a decision and not a dumping ground), and whether leadership opens the Strategic lens at all (weekly).