Rebuilding enterprise access control

QRadar Suite's access control system was fragmented and easy to misconfigure—stalling enterprise deals and blocking platform modernization. A complete overhaul was needed, but the team didn't have the architecture or engineering resources to define a new system from scratch. I stepped in, defining the new permission model and designing a robust access control system and UI that met the security demands of enterprise customers and made administrators' jobs faster and less error-prone.

Data modeling
System design
End-to-end UX
Research
Workshops
Outcomes
Unblocked enterprise adoption and platform modernization by replacing a fragmented, unsecure permission system with a unified RBAC experience.
My role
Lead Designer: research, permission architecture, data modeling, end-to-end UX, visual design direction
Team
2 visual designers, research advisor, architect, product manager
A grid of the new RBAC UI screens
Problem

A fragmented system

Incompatible legacy access control

QRadar Suite was built through acquisition, leaving it with several legacy applications that lived on the same platform, but didn't always work well together.

Each app had its own access controls with distinct architecture, permissions model, and UI—none of them were compatible with each other. Administrators had to visit multiple pages to assign user access to the full platform. The permissions were confusing, had grown without governance, and were impossible to manage in bulk. The user experience was so difficult it could become a security risk.

Our architect didn't have the bandwidth to take on this critical project. So I led the design of the new system, while they consulted, to ensure that what I designed was technically sound.

Siloed UIs
Managing access required admins to navigate multiple UIs across the legacy systems. Because each system’s UI functioned differently, there was no consistent workflow for managing permissions.
Legacy system 1
Legacy system 2
Legacy system 3
Inconsistent permission names
Naming conventions were inconsistent within each individual app and across the entire ecosystem. Without a standardized model admins struggled to interpret the actual function of each permission.
Legacy system 1
Legacy system 2
Legacy system 3
Conflicting architecture
Each legacy system had a different architecture. These structural discrepancies severely degraded the administrative experience and made the applications impossible to unify as-is.
Legacy system 1
Legacy system 2
Legacy system 3

Without a unified system and full redesign, the plans to update and merge the legacy applications with the newer ones were blocked, and the platform couldn't be modernized. Rebuilding the backend was off the table as the permissions were so deeply embedded that gutting them and starting from scratch would have taken significantly more resources than we had available.

Approach

Start with the known

Studying the legacy systems

To design a new system, I first needed to understand 1. the existing system and 2. customer needs and the adoption blocker. I audited the 3 access control systems cataloguing their 220+ permissions, their behaviors, and relationships. I then consulted with our architect to map how accounts, tenants, users, permissions, roles, and groups relate to each other so we had a basis to build our new architecture.


Qualitative user research

I started the discovery phase by seeking insight about the as-is admin experience from our Technical Account Managers. They told us that the platform's access controls were frustrating, not granular enough, and nearly impossible to manage for large security teams.

Next, I spoke to 7 security admins to understand the needs of enterprise security teams. Three emerged consistently: a system they could audit and trust, least-privilege access without configuration overhead—validating the need for granular permissions—and bulk access management.

Right now, [some features are] pretty much unusable in a production environment that has more than like 5 people. 😤

— Technical Account Manager

Permissions audit
I dug into the backend to surface legacy permissions and the organization structures of each system to understand, and make sure the stakeholders understood, what we had to work with.

Co-creation and alignment

I involved our cross-function team members as co-creators from the start to build stakeholder buy-in, establish a shared understanding of the technical complexity, and ensure the proposed solution was architecturally feasible.

I facilitated remote workshops in Mural with them to align on a vision and strategy. I designed exercises to help us explore and test new ideas, validate that the framework was granular enough for varied security team structures while maintaining cross-platform consistency and align with admin mental models.

I identified functional dependencies and designed logic-validation exercises to ensure system mechanisms worked together. We stress-tested scenarios like: Could users be assigned permissions without being assigned a role? How would it work if a user was assigned an individual role while also inheriting a role from their group? How would object and data access work, and how would they impact what a user could see?

Co-creation case studies
I used Mural boards to run cross-functional strategy, ideation, and concept testing workshops throughout the project.
A zoomed out view of a Mural board I used to run co-creation workshops
Scenarios worksheets
I developed 8 test cases, based on real enterprise security teams, to evaluate our ideas by mapping user access against these requirements.
A scenario I created to test and evaluate our ideas against
System

One experience, not three

Dismantling and rebuilding

Through my own explorations, validated with my team, I found that every legacy permission could be organized into 3 categories: Manage, Edit, and View—more categories could be added as the platform grew. And that a system that organized permissions by category, object, and application gave the most complete and flexible protection of all platform assets.

I also found that we could make permissions intuitive and human-readable in the UI—without changing them in the backend—by giving them attributes like name, description, and category. Raw permission like "edit_incident_members" and "User defined event properties" would surface to admin users as, "Edit incident members" and "Edit user defined event properties." Clear, consistent, and user-friendly.

My audit had identified several apps that lacked the granularity customers required. The new model gave those product teams a template to create new permissions to fill the gaps.

Frontend visibility
1) I organized object permissions into Manage, Edit, and View categories to improve clarity and reduce cognitive load. 2) I created a template to give technical permissions, like "edit_all_incident_members", human-readable attributes to surface in the UI without altering the backend logic.
Permission categories
Permission attributes

A brand-new system

After a lot of experimentation, I found the right balance of granular permissions, an organization method that matched admin mental models, and an admin experience that made it easy to onboard, offboard, and manage access for groups or individual users. These decisions produced a coherent, unified access control system built on top of legacy infrastructure but designed to feel like it was built from scratch.

There were 3 foundational mechanisms of this new system: groups, global-roles, and permissions. While these are common in many RBAC systems, my team and I determined that they and the logic we built into them best fit our customer use cases.

Groups

A collection of users. Allows admins to organize users in any way they see fit, often to match their team's organization structure, or leave them ungrouped.

Global roles

A collection of all platform permissions. Can be assigned to individuals and/or groups for bulk management. Admin can use out-of-the-box roles or custom roles for more control. Individual users cannot be assigned permissions without a role.

Permissions

A collection of actions. Object-level permissions organized by category. They are cumulative—a user is granted all the permissions assigned to them as individuals and to their group. Some permissions grant a user access to only objects that they created or have been shared with them, others grant them access to everything.

New, unified platform RBAC architecture
Users and groups can be assigned a role, made up of permissions that controlled what applications and objects they have access to. Permissions are organized by category, making it easier for admins to pick the right ones.

Intuitive UI for speed and security

I knew that efficient workflows and an intuitive UI would help admins make fewer mistakes—a huge concern in access management, where errors can create security vulnerabilities.

With that goal in mind, I used wireframes to work out problems like: How do we make onboarding large numbers of users as efficient as possible? How can we make sure admins understand what the permissions they're assigning mean and all of their implications? How do we help admins understand the relationships between roles, groups, and permissions—and use them to maintain a clear picture of user access?

I directed the visual design phase, working closely with my visual designer to carry the flows through to high-fidelity screens and stakeholder-ready prototypes.

Low-fi iteration
I used paper sketches and Figma wireframes to design workflows that were intuitive and facilitated bulk user onboarding and management.
Outcomes

Intuitive system at enterprise scale

I directly addressed the primary adoption blocker for 2 enterprise customers, opening a path to conversion that was previously blocked by limitations of the legacy systems. The platform was acquired by another company before full rollout, but their response, along with strong internal stakeholder feedback, confirmed the new system addressed the core blockers.

In addition to new system, the work resulted in a complete UI overhaul: a brand-new access management experience that brought all 3 legacy systems together into a single pane-of-glass. I wireframed the flows and oversaw the final UI design of over 30 screens and entirely new workflows for managing users, roles, groups, and permissions.

Centralization
A single pane of glass to see all access controls.
Flexibility
Global roles and granular permissions flexible enough for most use cases.
Contextual guidance
Descriptions and summaries make it easier to understand the permissions being assigned and harder to make mistakes.

This work also delivered:

  • Platform modernization: I replaced the incompatible legacy architecture with a modern one, removing a structural blocker that had been preventing teams from evolving the platform.
  • Large-scale user management: I added the groups mechanism to make bulk access management possible for the first time, supporting security teams of any size and structure.
  • Secure, auditable permissions: I consolidated 220+ inconsistent legacy permissions into a unified 3-category taxonomy (Manage, Edit, View), reducing mental model complexity for admins and making permissions easier to audit.
  • Scalable permission framework: I delivered a standardized permission schema and frontend naming conventions that enabled disparate app teams to independently build granular access controls.

More to see

Accelerating product integration

Stakeholder alignment and rapid MVP definition shaved 3 months off a projected three-quarter roadmap.

DevOps workflow for non-DevOps users

Shipped a new capability extending IBM Verify’s protection to legacy and on-premises applications, validated by research that prevented a critical UX failure before launch.