# Background Compliance frameworks are structured sets of guidelines, controls, and requirements that organizations follow to ensure they meet specific regulatory standards or industry best practices. Common examples include SOC 2, HIPAA, ISO 27001, and PCI DSS. In GitLab, users can create a compliance framework that is a label to identify that your project has certain compliance requirements or needs additional oversight. In the Ultimate tier, the compliance framework can optionally enforce [compliance pipeline configuration](https://docs.gitlab.com/ee/user/group/compliance_pipelines.html) and [security policies](https://docs.gitlab.com/ee/user/application_security/policies/index.html#scope) to the projects on which it is applied. Compliance frameworks are created on top-level groups. If a project is moved outside of its existing top-level group, its frameworks are removed. # Problem There are currently 3 key problems related to compliance frameworks in GitLab: * We have a concept called `Standards` within GitLab, which is currently being conflated with `Frameworks` and leads to confusion among our users as to what a framework does vs what a standard means, as well as the relationship between the two; * We are currently unaligned with key industry expectations around the creation and enforcement of a framework - in particular, the absence of being able to define a `Requirement` and mapping `Controls` to those requirements is a key aspect of being able to maintain compliance within GitLab; and * The use of the word `Check` does not immediately align with how the industry things about them, and should be termed `Controls` instead so that we are closer to industry definitions. # Solution In order to solve the above problems, we have decided to work on an MVC to release a way for users to create custom compliance frameworks in GitLab. The MVC will be able to do the following: * Allow for the creation of `Requirements` as part of creating a new compliance framework; * For example the standard would be SOC2, the requirement `PI 1.2: The entity implements policies and procedures over systems inputs to result in products, services and reporting to meet the entity's objectives` * Then, to achieve this there would be three controls `Prevent authors as approvers`, `Prevent committers as approvers` and `At least two approvals`. * The removal of `Standards` from GitLab, so that the way compliance frameworks are enforced are via `Frameworks` -\> `Requirements` -\> `Controls` -\> `Policies` ; and * The renaming of `Checks` to `Controls` to better align with industry standards ## In-Scope Based on a number of different discussions with product trio, related product managers and wider leadership, the following is agreed to as the scope for the MVC: - [add a Requirements level when creating a compliance framework](https://gitlab.com/groups/gitlab-org/-/epics/13204); - Add more OOTB frameworks and controls; - Allow users to customise frameworks; - Allow users to create their own frameworks; and - Allow users to [create external customisable controls](https://gitlab.com/gitlab-org/gitlab/-/issues/451414) ## Out of Scope Based on design discussions with product trio, the following was agreed to as out of scope for the MVC to meet crucial deadlines for the delivery of this feature: * The ability to upload a template to create requirements and controls; * The ability to upload documents to prove the control has been met; * The ability to internally customise a control We decided that it would be best to either split out these three things off to it's own seperate features and require more research/discussion before it can be considered an iteration on top of the MVC. # Persona * [Cameron (Compliance Manager)](https://handbook.gitlab.com/handbook/product/personas/#cameron-compliance-manager) # Design Please review the [design issue](https://gitlab.com/gitlab-org/gitlab/-/issues/452306/) for the updated designs. #### Adherence list page <table> <tr> <th>Default list-group by requirements</th> <th>list-group by project</th> <th align="right">list-group by frameworks</th> <th>list-drawer open</th> <th align="right">other drawer options</th> <th>framework list and open drawer for framework list</th> </tr> <tr> <td>  </td> <td>  </td> <td align="right">  </td> <td>  </td> <td align="right">  </td> <td>   </td> </tr> </table> #### Edit requirements page | New framework- empty | New framework-add new requirement modal | New framework-filled | Edit requirement modal | Successful page | |----------------------|-----------------------------------------|----------------------|------------------------|-----------------| |  |  |  |  |  | | Edit framework: all fields are collapsed and policy&project are empty | Edit framework: all fields are expanded and policy&project are empty | Edit framework: all fields are collapsed and policy&project are all filled | Edit framework: all fields are expanded and policy& project-filled | Edit framework: Requirement dropdown open, example. | |-----------------------------------------------------------------------|----------------------------------------------------------------------|----------------------------------------------------------------------------|--------------------------------------------------------------------|-----------------------------------------------------| |  |  |  |  |  | #### Other states | Edge cases and other states | |-----------------------------| | | ### Proposal Option 1: [Utilise YAML to store and configure standards](https://gitlab.com/groups/gitlab-org/-/epics/13295#note_1835327461) Option 2: [Utilise standard UI and database tables to store and configure standards](https://gitlab.com/groups/gitlab-org/-/epics/13295#note_1874147225) :point_right: Option 3: [Utilise standard UI and store all config in JSON object](https://gitlab.com/groups/gitlab-org/-/epics/13295#note_1874147911) - [discussion](https://gitlab.com/groups/gitlab-org/-/epics/13295#note_1894913624) ## Assumptions | Assumption | T/F/N | Why? | |------------|-------|------| | Users want to be able to create customizable checks within GitLab | | | | Users want to primarily do this via the UI, rather than via YAML or code first approach | True | | | Users want to combine a number of different settings together (\> than 2) to create a customizable check | | | | Users attribute project settings as conditions for checks, and nothing else | | | | Users would like to exclude, include or optionally include certain settings as part of their customizable check | | | ### Implementation plan Blueprint created https://handbook.gitlab.com/handbook/engineering/architecture/design-documents/compliance-frameworks/ <!--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--> <!-- 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 -->