Commit 8fa77b4c authored by Matt Gonzales's avatar Matt Gonzales

Update Compliance Management Category

parent 8384e1db
......@@ -59,9 +59,9 @@ compliance_management:
strategy: https://about.gitlab.com/direction/manage/compliance-management
description: "Provide customers with the tools and features necessary to manage their compliance programs."
roi: false
available: 2020-04-22
available: 2020-01-22
viable: 2020-07-22
complete: 2021-03-26
complete: 2021-06-26
lovable: 2023-11-18
maturity: planned
marketing: true
......
......@@ -6,14 +6,16 @@ title: "Category Direction - Compliance Management"
- TOC
{:toc}
Last Reviewed: 2020-02-14
## Compliance Management: Introduction
Thanks for visiting this direction page on Compliance Management in GitLab. If you'd like to provide feedback on this page or contribute to this vision, please feel free to open a merge request for this page or comment in the [corresponding epic](https://gitlab.com/groups/gitlab-org/-/epics/2302) for this category.
Thanks for visiting this direction page on Compliance Management in GitLab. If you'd like to provide feedback on this page or contribute to this vision, please feel free to open a merge request for this page or comment in the [corresponding epic](https://gitlab.com/groups/gitlab-org/-/epics/720) for this category.
Compliance is a concept that has historically been complex and unfriendly. It evokes feelings of stress, tedium, and a desire to avoid the work entirely. Our goal is to change that paradigm and create a Compliance experience that's simple, friendly, and as frictionless as possible. Managing your compliance program should be easy and give you a sense of pride in your organization, not a stomach ache.
Compliance is a concept that has historically been complex and unfriendly. It evokes feelings of stress, tedium, and a desire to avoid the work entirely. Our goal is to change that paradigm and create an experience that's simple, friendly, and as frictionless as possible. Managing your compliance program should be easy and give you a sense of pride in your organization, not a stomach ache.
## Problems to solve
Enterprises operating in regulated environments need to ensure the technology they use complies with their internal company policies and procedures, which are largely based on the requirements of a particular legal or regulatory framework (e.g. GDPR, SOC 2, ISO, PCI-DSS, SOX, COBIT, HIPAA, FISMA, NIST) governing their industry. Customers need features that enable them to comply with these frameworks beginning with defining the rules, or controls, for their GitLab environment.
Enterprises operating in regulated environments need to ensure the technology they use complies with their internal company policies and procedures, which are largely based on the requirements of a particular legal or regulatory framework (e.g. GDPR, SOC 2, ISO, PCI-DSS, SOX, COBIT, HIPAA, FISMA, NIST, FedRAMP) governing their industry. Customers need features that enable them to comply with these frameworks beginning with defining the rules, or controls, for their GitLab environment.
Currently, there's no way for an organization to manage the compliance status for groups and projects. There's no mechanism in place for an organization to know, within GitLab, what groups or projects are subject to particular compliance requirements.
......@@ -32,9 +34,9 @@ Compliance Management is currently in the **minimal** state. This is because we
* You can read more about GitLab's [maturity framework here](https://about.gitlab.com/direction/maturity/), including an approximate timeline.
In order to bring Compliance Management to the **viable** state, we will be implementing features that allow GitLab group owners and administrators to assign specific compliance controls to projects based on pre-defined, sensible defaults based on existing compliance framework requirements. These controls should introduce simple, but meaningful controls to govern activity within a project, such as ensuring merge request approval rules are adhered to and cannot be bypassed without explicit approval.
In order to bring Compliance Management to the **viable** state, we will be implementing features that allow GitLab group owners and administrators to assign specific compliance controls to projects using pre-defined, sensible defaults based on existing compliance framework requirements. These controls should introduce simple, but meaningful controls to govern activity within a project, such as ensuring merge request approval rules are adhered to and cannot be bypassed without explicit approval.
* Please track the Minimal maturity plan in [this epic](https://gitlab.com/groups/gitlab-org/-/epics/1982).
* You can follow the **viable** maturity plan in [this epic](https://gitlab.com/groups/gitlab-org/-/epics/2423).
Once we've achieved a **viable** version of Compliance Management, achieving a **Complete** level of maturity will involve collecting customer feedback and reacting. Assuming we're on the right track, we'll likely scale the solution in two dimensions:
......@@ -47,7 +49,7 @@ Finally, once we've achieved a ruleset that's sufficiently flexible and powerful
Compliance Management will initially be focused on the SOC2, SOX, and HIPAA compliance frameworks because these three frameworks appear to be some of the most common among GitLab customers. Additionally, the features we build for these frameworks will inherently add value to other organizations who are managing compliance with other frameworks due to the fundamental nature of many requirements the various frameworks share. For example, adding access control features to support HIPAA could potentially satisfy requirements for PCI-DSS and NIST.
We'll be introducing better control at the [project level](https://gitlab.com/groups/gitlab-org/-/epics/2087) with features like [controls definition](https://gitlab.com/gitlab-org/gitlab/issues/36300) and [compliance checks in merge requests](https://gitlab.com/gitlab-org/gitlab/issues/34830). We'll also focus on [group-level](https://gitlab.com/groups/gitlab-org/-/epics/2187) considerations such as [preventing project maintainers from changing critical settings](https://gitlab.com/gitlab-org/gitlab/issues/38051) like merge request approvals.
We'll be introducing better control at the [project level](https://gitlab.com/groups/gitlab-org/-/epics/2087) with features like [controls definition](https://gitlab.com/groups/gitlab-org/-/epics/2491) and [compliance checks in merge requests](https://gitlab.com/gitlab-org/gitlab/issues/34830). We'll also focus on [group-level](https://gitlab.com/groups/gitlab-org/-/epics/2187) considerations such as [preventing project maintainers from changing critical settings](https://gitlab.com/gitlab-org/gitlab/issues/39060) like merge request approvals.
We'd also like to leverage the [GitLab Control Framework](https://about.gitlab.com/handbook/engineering/security/compliance.html#gitlabs-control-framework-gcf) as a single source of truth. By using the GCF, a group owner or administrator could apply specific GCF controls to a project to support multiple legal and regulatory frameworks as opposed to requiring separate framework assignments.
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment