# Background Based on Compliance Group [customer feedback](https://gitlab.com/gitlab-org/govern/compliance/product-management/-/work_items/15) and our understanding of [gaps/challenges](https://gitlab.com/groups/gitlab-org/-/epics/13488#note_2153562946 "Security and Compliance Management on an Organization or Multi-Group level") from a SP group standpoint, we believe that there is a key customer need here that needs to be addressed around the problem of: > As a compliance or security professional; > > I want to be able to apply a compliance framework or security policy across multiple groups in an instance; > > So that I able to apply or enforce a set of common compliance frameworks or security policies across my company's many repos (projects) in those groups. Although we understand that having the `Organization` object available may/might solve the above problem, we recognise that this is a space where we want to provide a feature at the instance level at the moment so that we can alleviate this key issue that is a crucial blocker to adoption for compliance frameworks/security policies at the moment # Problem There are 2 aspects to this problem: * Providing users the ability to apply a compliance framework/security policy at the instance level across multiple different groups, and the projects in those groups; and * Ensuring that what is built is appropriately scoped to avoid any issues with 'uplifting' or 'moving' said feature to the `Organization` scoping mechanism when that is ready. # Current Assumptions or Pain Points The following are the pain points and benefits of addressing this issue: <table> <tr> <th>Assumption or Pain Point</th> <th>Description</th> </tr> <tr> <td>Improved clarity around the separation of duties</td> <td>Customers have shared they want to make it clearer to auditors how separation of duties are handled - that by having management of policies/compliance at the Instance (or Org) level, they can limit the risk of more users than necessary inheriting access/permissions that could affect their security/compliance posture.</td> </tr> <tr> <td>Inability to scope a compliance framework to a compliance policy across top-level groups</td> <td>Creating compliance frameworks across top-level groups and using them to scope policies is tedious. Today it requires scripting, it can require more investigation from auditors to make sure the script is reliable and enough to ensure compliance. It would be simpler to have all frameworks managed in the instance/org so they can be applied across any top-level groups without having to keep things in sync to ensure enforcement is applied.</td> </tr> <tr> <td>Increased scripting complexity to apply across multiple groups when new changes are introduced</td> <td>New projects or when changes are made to groups/subgroups/projects present additional complexity, requiring more sophistication in scripting.</td> </tr> <tr> <td>Improves efficiency and user satisfaction for Self Managed Ultimate users</td> <td> Use of compliance frameworks as a scope for security policies breaks down for self-managed users. You have to create the frameworks in each top-level group, you have to set some instance setting to allow cross-group communication, and you have to ensure the frameworks are properly configured as groups change. This is noted above but from a UX standpoint, creation of frameworks at an instance or organization level, or in a way that allows frameworks to exist across all groups would simplify the experience. Additionally, for self-managed, only one security policy project link can be created per "level", such as per top-level group. When enforcing a central set of policies across all groups, this link across each group takes the one available "slot". This means that if you manage policies centrally/globally, those top-level groups cannot additionally create a set of policies that can be used for only projects in their group. Or, they'd have to set up sub-groups to be able to manage this, which may not be possible once a set of projects have been defined for some time. </td> </tr> <tr> <td>Aligns with the direction of both the Compliance and Security Policies group</td> <td> Working on this feature aligns with the [direction of the Compliance group](https://about.gitlab.com/direction/govern/compliance/), to achieve compliance **visibility** of **checks**, **violations** and **audit events** throughout the entire DevSecOps lifecycle. This also aligns with the [direction of the Security Policies group](https://about.gitlab.com/direction/govern/security_policies/), to provide **security and compliance enforcement** across the DevSecOps lifecycle. </td> </tr> </table> # Solution The proposed solution at the instance level for this would be: * At instance level, select a **Group** as a dedicated **Compliance and Security policy group;** * In this group, users with the appropriate permissions can then configure compliance frameworks and security policies; * These compliance frameworks and security policies can be applied directly to other top level groups, which will immediately apply/enforce to all the subgroups and projects when it is linked/applied; * Other top level group owners can request the **Compliance and Security Policy** group to scope certain sub-groups or projects out, but they themselves can't make any changes to frameworks and policies that have been created by this group; and * Top level group owners are still free to create their own compliance frameworks and security policies in their own groups. Please see the diagram below as an example of how this might look like in the future (subject to change based on discussions): ### Top Down Level {width=565 height=559} ### Workflow Level #### SP workflow 2. [Alex (Security Operations Engineer)](https://handbook.gitlab.com/handbook/product/personas/#alex-security-operations-engineer) has admin access to the top level group; 3. In the CSP top level group, Alex creates security policies using the usual workflow (e.g. via the Policies tab) and scopes it to other top level groups and/or optionally via compliance frameworks that are already scoped to the other top level groups; 4. These security policies are immediately applied to all the sub-groups and projects under the other top level groups; and 5. The top level group owners can request Alex to de-scope projects and sub-groups from what is covered by the CSP security policies, but they are not allowed to make any changes themselves. 1. A **Compliance and Security Policy (CSP) top level group** is created in an instance; #### CF workflow 1. A **Compliance and Security Policy (CSP) top level group** is created in an instance; 2. [Cameron (Compliance Manager)](https://handbook.gitlab.com/handbook/product/personas/#cameron-compliance-manager) has admin access to the top level group; 3. In the CSP top level group, Cameron creates compliance frameworks using the usual workflow (e.g. via the Compliance center) and scopes it to other top level groups; 4. These compliance frameworks are immediately available applied to all other top level groups; 5. The top level group owners can apply these compliance frameworks to projects, but they are not allowed to make any changes themselves. # Personas * [Cameron (Compliance Manager)](https://handbook.gitlab.com/handbook/product/personas/#cameron-compliance-manager) * [Alex (Security Operations Engineer)](https://handbook.gitlab.com/handbook/product/personas/#alex-security-operations-engineer) <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> *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 -->