## Background Compliance managers play a crucial role in ensuring that development practices adhere to relevant regulations and standards throughout the DevSecOps lifecycle. Their responsibilities can include: * I need to be able to provide our internal compliance teams with evidence artifacts that help my company maintain a positive compliance posture. * I need to find tools that enable my organization to manage our compliance program and mitigate risk within the application and its use. * I need to create effortless processes for compliance so that my team will remain productive and efficient while meeting obligations for our primary job responsibilities. ## Problem When it comes to the first point above, "I need to be able to provide our internal compliance teams with evidence artifacts that help my company maintain a positive compliance posture", it can be difficult to determine what this looks like at the moment within the compliance center in GitLab. This is because the compliance center does not provide data-over-time, or continuous metrics, that details the compliance posture of a particular group over time and how this reflects either improvements or deteriorations in that group's compliance posture that needs to be actioned upon or fixed over time. For example, this can include tracking the following: * **Time between recognising and resolving a check or violation within GitLab**: Time to recognition measures how long it takes for a compliance team to recognise an issue. Time to resolution measures how long it takes for the issue to be fully resolved. Reducing this number improves compliance posture. * **Time between failed checks or violations**: This metric can measure the amount of time that passes between each failed check or violation, and can allow a team to understand how often these are taking place. Reducing this number improves compliance posture. * **% of requirements adhered to per framework**: This is the measure or assessment of an organizations level of adherence to the specific requirements and controls outlined in a given compliance framework. There are perhaps more metrics that compliance teams would like to follow and will require more research to uncover. ## Current Assumptions or Pain Points The following are the **pain points and benefits** of addressing this issue: | Pain Point | Benefit | Description | |------------|---------|-------------| | Decreases adherence | Increases adherence | to regulations, as this will allow compliance managers to proactively identify and address any gaps or violations in real-time, ensuring the organization remains compliant with relevant laws, regulations and industry standards | | Aggravate compliance risks | Mitigates compliance risks | as compliance managers can quickly detect potential issues and ensure timely remediation and mitigation of compliance risks | | Decreases audit readiness | Improves audit readiness | as real-time metrics generate detailed audit trails and documentation, demonstrating an organization's commitment to compliance and facilitating smoother audits and regulatory examinations. | | Decreases confidence | Improves confidence | of internal stakeholders, such as regulators, customers and investors, by demonstrating an organization's real time commitment to compliance. | | Misaligned with | 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 | ## Possible solution This might be something that we add to the 'single pane of glass' dashboard idea that we already have in this epic here: https://gitlab.com/groups/gitlab-org/-/epics/13909. This can also be something that is an 'add on' to the main dashboard. Regardless of where this is added, we believe that a possible solution would be to provide a metrics dashboard that tracks these metrics for continuous compliance monitoring, in a similar vein to the [value streams dashboard](https://docs.gitlab.com/ee/user/analytics/value_streams_dashboard.html) in GitLab. For example, the dashboard can look something like the below: **_NOTE: All metrics below are just examples_** | Metric | Month To Date | May | April | Past 6 months | |--------|---------------|-----|-------|---------------| | Time to resolve control | {width="115" height="40"} | {width="123" height="37"} | {width="116" height="40"} | {width="192" height="38"} | | Time since last failed control or violation | {width="115" height="40"} | {width="123" height="37"} | {width="116" height="40"} | {width="192" height="38"} | | % of requirements adhered to per framework | 60% | 10% | 30% | {width="192" height="38"} | ## Relevant Questions 1. What are the different metrics over time that compliance teams track for continuous compliance monitoring? 2. How much over time do compliance teams expect these metrics to be tracked (e.g. month by month, last 2 months, last 6 months, last year etc.) 3. Of those different metrics, what is useful to use within GitLab now vs what isn't useful because we don't have that metric in GitLab at the moment? 4. What kind of remediation actions are compliance managers expected to take once they see a metric going up or down? 5. Which level do they see these metrics operating at (e.g. organization, group, project, sub-group etc.) 6. How will this interact with our other ideas around having a dashboard, including: 1. https://gitlab.com/groups/gitlab-org/-/epics/13488 2. https://gitlab.com/groups/gitlab-org/-/epics/13909 ## JTBD and Personas ### 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) * [Isaac (Infrastructure Security Engineer)](https://handbook.gitlab.com/handbook/product/personas/#isaac-infrastructure-security-engineer) ### JTBD **NOTE**: The below references [the recent research](https://gitlab.com/gitlab-org/ux-research/-/issues/2460#note_1525210690 "Use JTBD Survey to find unmet needs in Govern") conducted by @moliver28 around JTBDs for users in the Govern Stage * **Compliance auditor** audit the client or business unit’s records for any rule or regulation violations * **Policy creato**r create security policies for org’s assets, to increase the adoption of my organs assets to the compliance requirements; reduce the likelihood of a legal and financial threat to the organisation; increase awareness of the security standards among developers * **Policy ensurer** ensure security policy requirements across my org’s assets are compliant to reduce the likelihood of business-critical threats; maintain the reputation of the organisation in the industry; and increase the visibility of my organisation’s security capabilities and deficits among developers. * **Policy implementer** Implement security controls in my organisation’s assets to reduce the likelihood of a business-critical threat to the organisation’s assets and increase the adoption of my organs Asse to the compliance requirement. ## Next steps * [ ] Could you communicate the idea with both compliance and policy groups? * [ ] Problem validation for compliance * [ ] Problem validation for policies * [ ] Could you clarify the technical possibilities? * [ ] Design explorations for compliance * [ ] Design explorations for policy <!-- 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 -->