Security Assessment Tool · EPAM 2021–2023
Making risk impossible to miss.
A self-serve risk dashboard that told a growing security team which application to assess next — and, just as importantly, why.
Product Design · UX/UI · Data Visualization
The situation
A security team doing good work — and quietly losing anyway.
Not because they were slow or careless, but because the thing they were guarding kept multiplying. New applications shipped faster than anyone could evaluate them, and the team had no reliable way to answer the only question that actually matters on any given morning: of everything we own, what is the most dangerous thing right now?
So assessments got scheduled the way important work gets scheduled when nobody can see the whole board — by instinct, by rotation, by whoever shouted loudest last. The team could spend two careful weeks reviewing something low-stakes while a genuinely exposed application sat in a blind spot, unassessed and unbothered.
The risk was always there. What was missing wasn’t effort. It was sight.
How the work was scheduled
The calendar
Assessments every N weeks, by rotation.
Even intervals · every project, same beat
How risk actually arrived
The threat
Exposure that doesn’t care what week it is.
No interval at all · one of them is already on fire
A calendar is not a threat model.
The reframe
Make risk impossible to miss.
The team didn’t want another tool to maintain. They wanted to stop guessing. So the design goal became embarrassingly simple to say and genuinely hard to build: make risk impossible to miss.
Two decisions followed from that, and both were about removing humans from the loop rather than adding them to it.
Nobody feeds it.
The tool reads directly from the automated security-testing tools the teams were already running — static code scan, penetration testing, open-source governance, CI/CD build data, training records. Any dashboard that depends on a person remembering to update it is just a more expensive way to be out of date.
It encodes when an assessment is warranted, not just what state things are in.
That cuts both ways. It pushes genuinely at-risk applications to the front of the line, and it gives the team explicit permission to stop re-checking healthy ones so often. Good prioritization isn’t only about what to do next. It’s about what you’re allowed to ignore.
The interface, in principle
One frame. Any signal.
The same frame, three signals: resolution time, training coverage, open issues. The rail changes the question; the structure holds.
The threshold belongs to the user.
Green, amber and red aren't hardcoded judgments — they're a slider the organization sets and is then held to. And when the metric inverts, so does the scale: on training hours, red sits on the left, because fewer hours is the failure state. The tool never assumes it knows what “bad” means for a given signal; it makes the org say so out loud and then holds the line.
No number appears without its reference.
Every trend shows three plots — actual, average, recommended. A score of 8.1 means nothing alone; 8.1 against a recommended 9.5 is an argument. This is what makes a green tile something you can defend in a room rather than something you felt.
The heatmap answers the actual morning question.
Sixteen project tiles, one of them red. No reading, no sorting, no interpreting — the eye lands on ASD-CDE before the brain finishes the sentence. Everything above it in the interface exists to make that one tile trustworthy.
What became possible
None
Data entry required
8
Signals unified
Evidence-led
Assessment cadence
We delivered a working vision prototype: a transparency layer that lets a security team see its own exposure continuously and point limited attention exactly where the evidence says it belongs. It reframes the job from assess everything on a cycle and hope to assess what the data is flagging — the quiet difference between a process that buckles as the application count climbs and one that scales with it.
This was a vision and proof-of-concept engagement. It was not deployed to production during my involvement, so there are no adoption figures to report, and I’d rather say that than imply otherwise.
Reflection
The part I’d revisit is the default thresholds. Handing an organization a slider is only empowering if they have some basis for where to put it — and a team that already lacked visibility is not well positioned to set its own tolerance on day one. Defaults are a design decision I treated as a settings problem.
The gap I’d close is ownership. The tool is excellent at telling you which application is on fire and completely silent on whose it is. Making risk visible turns out to be the easier half; routing it to the person who can act is where a transparency layer either becomes an operating system or becomes a very well-designed poster.