P2 - Aurva Policies
Feb 12, 2026
Company & Product Details
Aurva is a specialized B2B SaaS enterprise platform dedicated to modern database security. While traditional security focuses on the perimeter, Aurva focuses on the data layer, providing an advanced toolset for Database Activity Monitoring (DAM) and proactive access control.
The Mission: To prevent security vulnerabilities and potential breaches by monitoring every query and controlling every access point in real-time.
The Ecosystem: Aurva deploys a proprietary controller within a client's environment to discover sensitive data and enforce policies across diverse data sources like RDS, Redshift, MongoDB, and MySQL.
Market Position: Founded in 2022, Aurva caters to Fintech and high-growth tech enterprises where data compliance (GDPR, HIPAA) is a non-negotiable requirement.
Project Context & Feature Request
As companies scale, managing who can see what across hundreds of databases becomes a logistical nightmare. I was tasked with designing Aurva Policies—the "brain" of the platform that allows admins to define, manage, and audit data access governance.
The Feature Set
The request was to build a dual-sided ecosystem that addressed two distinct user needs:
The Policy Engine: A centralized hub to create Access Control Policies (masking/redacting data) and Alert Policies (notifying on suspicious thresholds).
The Data Access Portal: A "customer-facing" portal for employees to view available data sources and request time-bound access without manual email chains.
Strategic Integrations
The solution needed to bridge the gap between security and operations by integrating with the tools teams already use, such as Slack for notifications, Splunk for logging, and Coralogix for observability.
The Problem Statement
In the world of enterprise security, the "right way" is often the "hardest way." Traditional security tools are built for CLI-heavy workflows, leaving Security Admins and CISOs struggling to translate high-level compliance intent into technical execution.
The "Broken" Access Flow
Through our initial discovery, we identified three critical friction points:
Access Friction: Developers often bypassed security protocols because they were "too slow," leading to "Notes App" password sharing and "shadow" admin credentials.
The "Black Box" Effect: When a security incident occurred, admins received vague alerts without the contextual forensics (who, what, why) needed to make a quick decision.
Cognitive Overload: Defining a policy required navigating a maze of Boolean logic. Admins feared a "fat finger" error could accidentally shut down a production micro-service.
The Challenge: How might we design a policy engine that is robust enough for a CISO's requirements but intuitive enough for a developer's workflow?
Business Objectives & Requirements
The goal was not just to build a functional tool, but to create a competitive advantage in the database security market by prioritizing the human experience of governance.
Core Objectives
Establish Human-Readable Governance: Create a UI that follows a clear "When... AND... THEN..." mental model so that CISOs can build security logic without writing scripts.
Eliminate Access Friction: Streamline the request-to-approval pipeline to prevent developers from using "shadow" admin passwords.
Ensure High-Fidelity Auditing: Provide radical transparency through real-time logging and forensic data during security incidents.
Scalable Architecture: Support the batch application of rules to groups of data sources, allowing for centralized control across hundreds of instances.
Technical Requirements
Multi-Step Wizard: Break policy creation into logical phases: Policy Details, Database Selection, and Rule Application.
State-Based Cards: Use dynamic visual feedback, such as countdown timers, to reflect the real-time status of data access.
Centralized Incident Response: Build a dedicated space for admins to view notifications, examine raw SQL queries, and resolve threats.
Understanding the Personas & Pain Points
To bridge the gap between security and operations, I had to design for two distinct archetypes with often conflicting goals.
The Security Admin / CISO (The Gatekeeper)
Responsible for the organization’s security posture and compliance.
Pain Point: Fear of the "Unknown." Admins often lack visibility into who is accessing data and what queries they are running in real-time.
Pain Point: Manual Overhead. Approving access via email or Slack is slow and leaves no official audit trail.
Design Goal: Provide a "Single Pane of Glass" for monitoring and a declarative UI for creating complex, error-proof policies.
The Developer / Data Analyst (The Consumer)
Needs quick access to data to build features, fix bugs, and run reports.
Pain Point: "Security is a Roadblock." Waiting days for access approvals kills productivity and leads to risky workarounds.
Pain Point: Lack of Context. Once access is granted, developers often don't know how much time they have left or what credentials to use.
Design Goal: Create a self-service portal that provides instant credential access and transparent countdowns for active sessions.
The Tension: The Admin wants absolute control; the Developer wants zero friction. The design solution had to exist at the intersection of these two needs.
Information Architecture & Site Map
To manage the dual-sided nature of the platform (Admin Control vs. Employee Access), I structured the architecture to ensure that the security logic remained centralized while the user portal remained lightweight and utility-focused.
The Admin Hierarchy
The Admin experience is organized around Active Governance.
Overview: High-level dashboard for security posture.
Data Sources: Management of connected databases like RDS and Redshift.
Policies: The engine room, containing the "All Policies" list and the creation wizard.
Security Incidents: A reactive space for auditing triggered alerts.
Access Requests: The pending queue where admins approve or reject employee needs.
The User Portal Hierarchy
The Employee experience is designed for Frictionless Utility.
My Data Sources: Active database accesses with live credentials and countdown timers.
Available Data Sources: A catalog of databases for which access can be requested.
Active Requests: Transparency into the status of pending approvals.
User Flows
I mapped two primary flows to ensure that the "Human-Readable" goal was met at every touchpoint.
Flow A: The Admin’s Policy Creation
This flow was designed as a Multi-Step Wizard to prevent cognitive overload by isolating intent, scope, and behavior.
Define Intent: Select between "Access Control" or "Alert & Monitoring".
Define Scope: Select specific databases or database groups (the "Blast Radius").
Define Behavior: Use the Declarative Rule Builder to set "When... AND... THEN..." logic.
Flow B: The Developer’s "Break-Glass" Request
This flow prioritizes speed during high-stakes "Production Fires."
Selection: Find the required database in the catalog.
Configuration: Define duration and access level (View, Create, Edit, or Delete).
The "Break-Glass" Toggle: Explicitly request to Override Masking & Redaction for raw data access.
Justification: Provide a mandatory reason to ensure a clear audit trail.
Wireframing & Iterations
The evolution from initial wireframes to the final product was driven by the need to simplify Boolean complexity into a linear, digestible experience.
The "Single Page" Experiment
Early iterations attempted to fit the entire policy creation on a single screen. However, usability testing revealed that security admins felt overwhelmed by the "wall of logic." We pivoted to a multi-step wizard to implement Progressive Disclosure, ensuring that the admin only focuses on the "Where" (Data Sources) before the "How" (Rules).
Refining the Rule Builder
Version 1 (Linear): A horizontal "sentence" structure was tested but failed to accommodate multi-select tags for user groups and sensitive data types, leading to horizontal scrolling and hidden actions.
Version 2 (Block-Based): I shifted to the Vertical Logic Stack. This iteration proved superior because it anchored the "Perform Actions" block at the bottom, making the consequence of the policy visible at all times, regardless of how many conditions were added.
Design Validation & Strategic Thinking
Design in a security context is as much about preventing errors as it is about enabling tasks. I applied several psychological principles to ensure the UI acted as a safeguard.
Establishing the "Blast Radius"
A strategic decision was made to force Data Source selection in Step 2. By locking in the environment (e.g., a specific RDS or Redshift instance) before building rules, we could dynamically populate Step 3 with only the relevant schemas, tables, and sensitive data types. This "error-proofing" ensures that an admin never creates an "invalid" policy for a database that doesn't exist.
Human-Readable Governance
To ensure the platform remained accessible to CISOs and auditors, I utilized a Declarative UX.
Natural Language Connectors: Using clear "AND" connectors between blocks turns a technical configuration into a readable sentence: "When [User Group] AND [Sensitive Data Type] is [X], THEN [Action]."
Visual Forensics: In the Security Incident Detail Page, I prioritized the SQL Query and Rows Accessed. This allows an admin to instantly distinguish between a routine query and a malicious data dump without needing to dig through raw logs.
Design System & Visual Language
To build trust in an enterprise security environment, the visual language needed to feel stable, precise, and high-performance. I developed a design system that prioritized high information density without sacrificing clarity.
The Color Palette: Signal vs. Noise
Foundation: A familiar blue theme was used for the Admin Portal. We also aimed to reduce eye strain during long auditing sessions.
Actionable States: We used the vibrant Aurva Blue for primary actions like "Create Policy".
Semantic Feedback: Critical alerts and "Errored" controller statuses were highlighted in high-contrast red , while "Medium" risk incidents used a warning amber.
Typography & Components
The Logic Block: A custom container component designed for the rule builder, featuring clear "AND" connectors and vertical stacking to maintain the "Human-Readable" narrative.
Dynamic Data Cards: Used in the User Portal to display database types (RDS, Redshift, etc.) and active countdown timers.
The Modal Architecture: A standardized modal system for Approve/Reject actions, ensuring that critical data like "Reason for access" and "Duration" always appear in the same visual location.
Final Designs
The final screens represent a dual-sided solution: a powerful engine for the Admin and a frictionless utility for the Data Consumer.
The Admin’s Control Center
The "All Policies" list page provides radical visibility, showing pre-defined rules like "Redact for SSN" or "Mask for PHI" alongside their active status. The multi-step wizard ensures that creating these rules is a guided process, moving from Policy Details to Database Selection to the final Rule Stack.
The "Contextual Forensics" Incident Page
When a policy is triggered, the Admin is not just notified; they are empowered. The incident detail page surfaces the specific SQL Query and Rows Accessed , allowing for an instant decision to "Mark as Resolved" or "Set up ACL".
The Frictionless User Portal
For the developer, security is now transparent. They can view their active credentials , track how much time they have left via the countdown timer , and use the "Break-Glass" toggle to override masking when a production crisis occurs.
Developer Hand-off & Implementation
Precision in security design is only as good as its implementation. To ensure the complex logic of the Rule Builder and the Countdown Timers was translated accurately, I focused on a high-fidelity hand-off process.
Logic Mapping: I provided a detailed "Logic Tree" alongside the Figma files, explaining the conditional filtering between Step 2 (Database Selection) and Step 3 (Rule Application).
Tokenized Design System: All components, from the "Security Red" alert states to the "Active" status badges, were linked to a shared token library to ensure visual consistency across the Admin and User portals.
State-Based Documentation: I documented every possible card state in the User Portal—including Active (with timer) , Pending (with "Cancel Request") , and Available —to guide the front-end transition logic.
Project Impact & Outcomes
By humanizing the interface of database security, Aurva Policies moved the needle from "compliance burden" to "operational efficiency."
Eliminated "Shadow IT": By reducing the access request flow to a matter of clicks with a transparent approval status, we observed a 40% reduction in unauthorized password sharing in the pilot phase with a design partner over the course of 6 weeks.
Accelerated Incident Response: The "Contextual Forensics" on the incident page allowed admins to resolve alerts faster, as they no longer had to manually correlate users to SQL logs.
Reduced Configuration Errors: The multi-step wizard and "Blast Radius" strategy significantly lowered the rate of "invalid policies" by ensuring logic was always environment-specific.
High Developer Adoption: The User Portal was praised for its transparency, specifically the ability to see exactly how long access would last and why a request was rejected.
Summary & Future Roadmap
Aurva Policies successfully proved that enterprise security doesn't have to be a "Black Box." By treating the Security Admin as a strategist and the Developer as a consumer, we built a platform that balances Proactive Control with Radical Transparency.
The Future of Aurva
AI-Powered Policy Suggestions: Using historical data to suggest "Access Control" rules based on common developer behavior.
Granular "Just-in-Time" Access: Moving beyond minute-based timers to "session-based" access that expires the moment a specific task or ticket is closed.
Mobile Approval App: A lightweight mobile interface for CISOs to approve "Override Masking" requests on the go, further reducing bottlenecks.