UX: Policy Testing & Flexibility

Problem and scope

See details

What is the problem to solve?

  • Security teams lack flexibility in policy enforcement, causing two major problems:
    • No bypass mechanisms: Emergency fixes are blocked, automation fails, and legitimate exceptions require policy changes or disabling policies entirely
    • No testing mode: Teams must enforce policies immediately without understanding impact, leading to disrupted workflows and reluctance to adopt policies,
  • Currently, policies are binary (on/off) with no middle ground for testing or exceptions.

Focus: WHEN and HOW policies can be bypassed or tested without enforcement

Bypass Mechanisms:

  • Emergency override procedures with time limits
  • Bot/automation accounts that skip approval rules
  • Branch-specific exceptions (hotfix, release branches)
  • Role/group-based bypass permissions
  • Manual bypass with required justification
  • Temporary bypass windows

Warn Mode:

  • Test policies before enforcing them
  • See what would be blocked without actually blocking
  • Get notifications about violations
  • Gradual rollout (warn → enforce)
  • Metrics on policy impact
  • "Dry run" for new policies

Example (Bypass): "Our deploy bot is blocked by approval rules meant for humans - we need it to bypass policies"

Example (Warn): "I want to see how many MRs this new policy would block before I actually turn it on and disrupt the team"

Who is the design solution for?

  • Primary: Security Engineers who need to balance security with operational flexibility
  • Secondary: DevOps Engineers managing automation and CI/CD pipelines
  • Tertiary: Development Team Leads dealing with emergency fixes

What is the Job this user is trying to achieve?

  • Allow legitimate exceptions without compromising security posture
  • Test policy impact before enforcement to avoid disrupting teams
  • Enable automation to function while maintaining human approval requirements
  • Handle emergency scenarios with proper audit trails
  • Gradually roll out policies with confidence

What outcomes is this design solution helping them achieve?

If you have measured Outcome data, put that in the table. If not, delete the table and add the Outcomes to be designed for in a bulleted list.

  • Minimize the time to resolve emergency/critical issues blocked by policies
  • Minimize the risk of policies disrupting legitimate workflows
  • Minimize the effort to test policy impact before enforcement
  • Minimize automation failures due to human-centric approval rules

What are the requirements necessary to solve for this problem and Outcomes?

{ Create a bulleted list of everything that will need to be addressed in the holistic Design Vision in order to fully solve for the problem and Outcomes. Work with your counterparts to define this list. Keep it solution agnostic and try to understand any technical constraints that each requirement may imply. Only remove a requirement due to a technical constraint if it's not technically feasible to build within a reasonable amount of time (1-3 milestones is reasonable, anything longer than that you'll have to decide as a team how important it is to keep it in scope or address it in parallel in later iterations). }

  • Exception/Bypass Requirements:
    • Define service accounts/bots that can bypass approval policies
    • Create emergency bypass procedures with time limits
    • Configure branch-specific exceptions (e.g., hotfix branches)
    • Set up role/group-based bypass permissions
    • Require justification for manual bypasses
    • Comprehensive audit trail for all bypasses
    • Notification system for bypass usage
    • Automatic bypass expiration options
  • Warn Mode Requirements:
    • Toggle between "warn" and "enforce" modes per policy
    • Clear visual indicators for warn mode violations
    • Notification preferences for policy violations
    • Dashboard showing what would be blocked if enforced
    • Violation metrics and reporting
    • Gradual rollout capabilities (warn → enforce by date/condition)
    • Integration with existing security dashboards
    • Export violation data for analysis

What supporting research or customer validation do we have?

  • {TBD }

What is the timeline?

{ Add milestone or link to planning issue that clarifies when the design must be ready for the Build phase by }

What are the technical constraints?

{ ⚠️ This is to understand initial constraints in which the design solution needs to work within, NOT whether the solution can be implemented in a given milestone.

Once the Product Designer has come up with a holistic Design Vision, or an ideal state for solving the problem, they should collaborate with their team members and engineers to continue the technical feasibility discussion during workflowplanning breakdown. }

  • Must maintain security audit trail for compliance
  • Bypass mechanisms cannot compromise SOC2/regulatory requirements
  • Warn mode must not impact pipeline performance
  • Need to handle both legacy and new policy systems during transition
  • Integration with existing notification systems required
  • Must work across all GitLab deployment types

In what parts of GitLab will this solution be available?

Plans:

  • Free
  • Premium
  • Ultimate

Instances:

  • Self-managed
  • Dedicated
  • GitLab.com

Levels:

  • Instance
  • Group
  • Project

How will we know if the solution is successful?

{ If you don't have measured Outcome data to measure against, what other success metrics can we use? Otherwise you can reference the Outcomes table above (your goal is to beat the previous Outcome measurements Satisfaction numbers with this new design). }

  • Emergency fixes completed 90% faster when policies are active
  • x% reduction in policies being disabled temporarily
  • x% of teams use warn mode before enforcement
  • Automation success rate improves to x%+
  • Policy adoption increases by x% due to testing capabilities

Ready for design

See checklist
  • The problem has been defined and is well understood
  • Who the design solution is for has been defined
  • User goals and outcomes have been defined
  • Supporting research has been reviewed and linked
  • The product requirements have been defined, and the scope has been agreed upon
  • Success metrics have been defined and agreed upon
  • I, as the Product Designer, believe I have all the information I need to begin creating a design solution
  • Move this issue to ~"workflow::ready for design" or workflowdesign 🎉
  • (Optional) Help improve this issue template, view feedback issue

Proposal

See checklist reminder
  • 📺 Walkthrough
  • 🖼️ Design Solution Proposal
  • ❖ Figma project →

Design breakdown

Once the proposal is agreed upon, work with your team to break it down into buildable parts (MVC, Iteration 1, Iteration 2, etc... until fully built).

See checklist
  • Design Vision broken down into MVC and follow-up iterations based on their ability to stand alone and provide value to the user
  • Create MVC and other necessary Iteration 1, Iteration 2... issues and add them as Linked items to this issue
    • Include all necessary requirements, and specs needed to create the designs for each broken down issue
Edited by 🤖 GitLab Bot 🤖