# Release post We're excited to announce the **Beta release** of **Centralized Security Policy Management** in GitLab! This powerful new capability allows instance administrators to designate a **Centralized Security Policies (CSP)** group and apply security policies across multiple groups and projects from a single, centralized location. ### The Problem We're Solving Previously, managing security policies across large GitLab instances required manual configuration at each group and project level. This created: * **Administrative overhead** when applying the same policies across multiple teams * **Inconsistent security posture** due to manual configuration errors * **Difficulty scaling** security governance across growing organizations ### What You Can Do Now **For Instance Administrators** * **Designate a CSP group** to serve as your centralized policy management hub * **Create and configure security policies** that automatically apply across your instance * **Scope policies precisely** to specific groups, projects, or your entire instance * **View comprehensive policy coverage** to understand which policies are active where * **Maintain centralized control** while allowing teams to add their own additional policies **For Group and Project Owners** * **View all applicable policies** in one place, including both local and centrally-managed policies * **Continue creating team-specific policies** alongside centrally-managed ones * **Understand policy sources** with clear indicators showing whether policies come from your team or central administration **For Developers** * **See all security policies** that apply to their work in the familiar `Secure > Policies` interface * **Understand security and compliance requirements** with clear visibility into centrally-mandated policies ### Getting Started To start using Centralized Security Policy Management: 1. **Navigate to Admin Area** \> **Settings** \> **Security and Compliance** 2. **Designate your CSP group** from your existing top-level groups 3. **Create security policies** in your CSP group's security policy project 4. **Configure policy scope** to determine where policies apply 5. **Monitor policy application** across your groups and projects ### Feedback Welcome As this is a Beta release, we're actively seeking feedback from our users. Please share your experience, suggestions, and any issues you encounter through our [feedback channels](https://gitlab.com/gitlab-org/gitlab/-/issues). This feature represents a significant step forward in GitLab's security governance capabilities, making it easier than ever to maintain consistent security policies across your entire organization. * **Available in:** GitLab 18.5+ (Beta) * **Documentation:** [Centralized Security Policy Management](https://docs.gitlab.com/user/application_security/policies/) * **Epic:** [Centralized management of security policies in CSP](https://gitlab.com/groups/gitlab-org/-/epics/17392) ## Description Implementation in https://gitlab.com/groups/gitlab-org/-/epics/15864+ will be developed in tandem between ~"group::security policies" and ~"group::compliance". ~"group::security policies" will be focused on delivering a Beta-ready solution for centralized policy management without the introduction of centralized compliance workflows. We'll split the work as follows: **(Policies group):** * Add flow to designate CSP (Centralized Security Policies) * Handle policy resolver service to apply policies down to groups/projects * Allow users to create policies and scope them as they do today (without centralized compliance frameworks) * Allow with this solution the ability to then add policies to top-level groups in addition to the CSP, so the SPP link in groups is free to use **(Compliance Group w/ support from and collaboration with Security Policies):** * Handle central creation of compliance frameworks in the CSP * The association/linking of compliance frameworks in groups up to the central frameworks in the CSP * Add ability to scope to the CSP frameworks in the CSP policies (policies could also own this or collaborate, whatever is needed) * Roll-up of framework management centrally * Handle compliance UI elements such as showing policy links to CSP frameworks * Roll-up of compliance reporting centrally (TBC) * Generate an audit event for CSP designation * Scalability/performance testing We'll focus on Policies group in this sub-epic. ## Example workflows The following flows should be achievable once Phase I is completed, in order to deliver a Beta release: #### Instance Admin 1. Designate a CSP 2. Create CSP security policies 3. Configure CSP security policies 1. Scope policies to groups/subgroups, specific projects, all projects in this instance (with/without exceptions). Scoping to compliance frameworks will not be supported within the Beta, but we'll introduce the CSP frameworks in Phase II. 2. All other configuration remains the same 4. Store CSP policies config in `policy.yml` within the CSP 5. View CSP policies 1. View which policies are enabled 2. View scope of project (e.g. list groups/projects that have been included within the scope) 6. Edit CSP policies 7. Edit scope configuration 8. All other configuration remains the same #### Group Admin / Owner 1. Ability to create/manage policies at the group-level while CSP policies are additionally applied to the group 2. Ability to view policies in `Secure > Policies` tab including Policies created within the group as well as CSP policies enforced from the CSP to the group (based on scope) 1. Note: Do not display policies from the CSP that are not scoped to the group #### Project Admin / Owner 1. Ability to create/manage policies at the group-level while CSP policies are additionally applied to the group 2. Ability to view policies in `Secure > Policies` tab including Policies created within the group as well as CSP policies enforced from the CSP to the group (based on scope) 1. Note: Do not display policies from the CSP that are not scoped to the group #### Developer 1. Ability to view policies in `Secure > Policies` tab including Policies created within the group as well as CSP policies enforced from the CSP to the group (based on scope) 1. Note: Do not display policies from the CSP that are not scoped to the group ## Dependencies 1. Before centralized management of security policies may be delivered as GA, Phase II from compliance must be completed as users rely on scoping policies by compliance frameworks. Centralized management of CSP compliance frameworks that can be automatically propagated to all groups will allow for ease of use when creating/managing frameworks to use with policy scopes. ## Design Concepts ### Designate CSP Workflow  [Figjam](https://www.figma.com/board/JK0fsicPZHJUncNVVM3xdh/Multi-group-Policy-Management?node-id=0-1&t=fhJuGyHFSMlkxPtu-1) ---- ## Interlock status Interlock Committed - [18.2 Milestone target for Beta](https://docs.google.com/presentation/d/1ABoGLJkQZNs3Y92NELNrRvjsbo_PNEjGMyCRVz2sU2A/edit?slide=id.g33a7633844a_3_4215#slide=id.g33a7633844a_3_4215) - GA Target release Q3 2025 <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> > [!important] > This page may contain information related to upcoming products, features and functionality. > It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. > Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc. <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION -->