Shifting Enterprise Security Toward an Identity-Centric Model

A Product Built for a Different Security Question

DLP had been carefully designed around data: policies, channels, incidents, and violations. Its core capabilities — locating and tracking sensitive data across all channels, inspecting content using keyword matching, pattern detection, and machine learning, and taking immediate action when policy thresholds were crossed — ran in one direction: detect content, apply policy, respond. The system was built to catch what was moving, not to reason about who was moving it, or why.

But the security landscape shifted. After high-profile insider leaks — WikiLeaks being the most visible — enterprise customers were no longer asking only where sensitive data went. They were asking who was creating risk, whether behavior was unusual, and how to identify malicious or repeated activity amid thousands of daily incidents.

The product's architecture hadn't been designed to answer those questions. And the organization, moving through an annual waterfall release cycle, had no shared model for what investigation should look like at the identity level. The 2011–2012 product cycle was the window to change that.

When the Question Changes, the Product Has to Change With It

Reframe the Model, Not the Screen

The strategic decision was to change what investigation was organized around — not to add a layer on top of what existed. That meant moving the conversation away from Case Folders and toward a different question: what if identity, not channel, was the starting point of every investigation? That reframe had three parts.

From Case Folders to Identity-Centered Investigation

The work unfolded across the full 2011–2012 product cycle — from early whiteboard sessions challenging the product direction, through customer validation, to a productized DLP v12 capability. Each phase built on the last.

1. Reframing the Problem

When I joined the malicious insider effort, the organization had already been moving toward a case-folder architecture. Working closely with the engineering lead through a series of early sessions, we quickly saw the deeper issue: Case Folders helped organize evidence after investigators found it, but didn't help them discover user-centered patterns across the system.

The harder questions — who is the person behind these events? Is the same person appearing across multiple DLP channels? Is this behavior expected for their role? — had no product support. The investigator still had to identify the person, search across modules manually, and determine whether behavior was isolated, negligent, or truly malicious. The product was asking users to do the work of correlation.

That realization shifted the project. Instead of designing a better folder structure, we began exploring whether identity itself should become the organizing model — the connective tissue across channels, incidents, behavior, and risk.

2. Decomposing "Malicious Insider"

By May 2011, the identity-centric framing had materialized in a strategy workshop map. The board captured the core questions: how do we determine who the offender is? How do we show all DLP activity for a user? How do we define areas of interest? Identity was becoming the connective layer — not a folder, not a filter, but the organizing principle of the whole investigative model.

From there, I facilitated workshop sessions to decompose "malicious insider" — which had been treated as a single threat label — into distinct behavioral archetypes. I synthesized the output against industry research and published frameworks on insider threat behavior, grounding the team's intuitions in what the security field was already developing. Three profiles emerged, each implying different signals, different product behavior, and different organizational responses:

This moved the work from "malicious insider" as a vague security fear into a more actionable model: risk framed as behavior + intent + evidence, not a generic threat label.

3. Making the Strategy Human

With the archetypes defined, the next challenge was about trust and governance, not only technology. Some leaders worried that focusing the product on people — rather than data — would feel invasive, or shift DLP away from its original purpose. Arguing the point in the abstract wasn't going to move anyone.

In July 2011, I created illustrated vignettes showing how insider-risk scenarios could unfold over time: what triggered the initial concern, what evidence appeared across systems, when a user was flagged or warned, and how repeated behavior changed the meaning of an event. One vignette followed a repeat offender — someone careless, not malicious — whose accidental actions were quietly putting the company at risk. The story showed something counterintuitive: if that employee were surfaced and told what was happening, they wouldn't feel accused. They'd feel helped, and they'd want to become an active partner in protecting their own job.

The vignettes weren't decoration. They were a strategic alignment tool — giving product, engineering, and leadership a way to discuss intent, escalation, and investigation before jumping to UI. "Identity-centric" stopped sounding like surveillance and started sounding like the more responsible way to investigate.

4. Translating Strategy into Product Architecture

By September 2011, the direction had matured into a shared product vision — connecting ease of use, malicious-user protection, and identity visibility. The central idea: data-loss risk is ultimately remediated through people, so the product needed to help customers understand people-centered patterns, not just channel-specific incidents. Engineering leadership carried the direction forward to leadership shortly after.

The work then moved into architecture. In January 2012, the direction was brought to the Technical Advisory Board — more than 60 enterprise customers. One decision shaped what we learned from that session: I persuaded the team not to present with mockups. Instead, we opened with a narrative that walked customers through the investigative scenarios, then anchored the discussion on the Task Model — the workflow from initial investigation to evaluation and action — rather than on interface screens. That format shifted the conversation away from UI opinions and toward genuine validation of the investigative model itself. Customers confirmed the need for repeat-offender tracking, user lists, user attributes, and responsible escalation, and surfaced the constraints that would shape the design: privacy and legal risk, role-based access, performance, and the importance of not implying guilt too early.

Alongside the architectural work, I formalized how UX would operate within the product cycle. Rather than waiting for engineering to hand off requirements, I introduced a Lean UX model: short iterative cycles, low-fidelity artifacts shared early, and design, product, and engineering working as one team from the start. This wasn't just a process preference — in a waterfall organization moving toward agile delivery, it was a structural argument for how UX could influence the product before decisions hardened. The deliverables followed from the model: personas, task models, user journeys, sitemap, wireframes, and detailed interaction behaviors, each validated before the next layer was designed.

5. Validating with Enterprise Customers

Between April and May 2012, usability testing with enterprise security teams confirmed the direction — and sharpened it. Participants wanted better tools to interpret gathered data, recognize behavioral patterns, automate reporting, notify managers, and involve HR or legal when appropriate. They needed granular filters, clear escalation paths, and investigation workflows that respected the difference between reviewing risk and implying guilt.

The most important validation was direct: customers explicitly valued starting from people rather than incidents. Two responses stayed with the team:

Testing also surfaced the enterprise constraints that the final design had to respect: privacy and legal exposure, role-based access controls, performance at scale, and the risk of automation that implied guilt too aggressively. The goal wasn't to label people as threats — it was to help security teams understand risk patterns responsibly.

6. From Strategy to Productized Capability

By October 2012, the identity-centric model had been productized for the Whitney / DLP v12 release as User Risk Summary — a feature that gave customers insight into the behavior patterns of specific individuals, so they could focus DLP efforts on users posing the highest risk. It associated incidents with specific users and provided two views: User List and User Risk Summary.

User Risk Summary could be filtered by policies, Active Directory group attributes, custom attributes, incident status, severity, number of incidents, date, and user name. It supported user-data import through Active Directory or uploaded files, and custom attributes — employment status, department, manager — that let investigators contextualize risk within the organization's structure.

The external name itself signaled the shift: not "Malicious Insider," not "Case Folders," but User Risk Summary — a name that centered the person, the pattern, and the organizational responsibility to act on risk rather than assume intent.

Final product screenshots are not shown here — Symantec's policies restricted the circulation of production UI images. The wireframes and architecture artifacts shown in this case study represent the design work as it was handed to engineering; the productized capability followed that model through the Whitney release cycle, with GA in 2013.

A More Durable Model for Enterprise Investigation

The identity-centric approach gave Symantec DLP a more durable investigative model — one that changed the organizing principle of the platform, not just the interface. The impact was architectural before it was visual.

What I Learned

The most important thing I did at Symantec wasn't design a workflow. It was identify the right abstraction — and change it before engineering committed to the wrong one. The Case Folder direction wasn't wrong because it was poorly designed. It was wrong because it was solving the surface problem rather than the structural one. The difference between grouping incidents and organizing investigation around people seems conceptual until you realize it determines the architecture, the user's mental model, and what questions the product can even support.

Discovery taught me that the word "offender" was doing too much work. When we mapped the actual population generating incidents, we found three distinct profiles — and the dominant one, the careless repeat violator, was the profile the product was least equipped to handle responsibly. Designing for that majority — not just for the rare intentional bad actor — changed the model, the vignette, the validation approach, and ultimately the product name. "User Risk Summary" rather than "Malicious Insider" is a direct consequence of that distinction.

Working across five teams in a waterfall organization also clarified what "influence" actually means at scale. It isn't about pushing a design through a process. It's about creating the conditions for shared understanding early enough that the right direction feels obvious by the time decisions get made. The vignettes made the model safe to discuss. The TAB reframe — presenting a narrative and a task model instead of mockups — made customer feedback actionable rather than cosmetic. And the Lean UX operating model I introduced wasn't a set of deliverables; it was an argument for how design and engineering could work together before requirements hardened. None of those were interface design. All of them were what made the interface design matter.

"The most valuable design work at Symantec happened before the screen: in the abstraction, the mental model, and the shared understanding that let five teams move in the same direction."