Rebuilding enterprise access control

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.









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.
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

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?


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.


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.

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.

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.



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.
