|Stage||Maturity||Content Last Reviewed|
Thanks for visiting this direction page on Compliance Management in GitLab. If you'd like to provide feedback or contribute to this vision, please feel free to open a merge request for this page or comment in the corresponding epic 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. There is often a disconnect between your company's policies and the features and settings that exist within a service provider like GitLab. Further compounding this challenge is a lack of visibility provided about the state of your account groups, projects, teams, etc within an external service or application. Compliance Management aims to bring compliance-specific data and features that focus on raising awareness and visibility of the compliance state of your GitLab groups and projects to help you make data-informed decisions about your organization's use of GitLab.
The goal of Compliance Management is to change the current paradigm for compliance to create an experience that's simple and friendly. Compliance with GitLAb should just happen in the background. Managing your compliance program should be easy and give you a sense of pride in your organization, not a stomach ache.
This category focuses on building features and experiences to enable compliance professionals to easily view compliance data for groups and projects; focus their time only on groups or projects that require attention; and define their organization's policies through settings and configuration.
Separation of duties is a core concept among all compliance frameworks and is generally a risk management practice for organizations. Within GitLab, there are many areas where separation of duties is required, such as for merge requests, within CI/CD pipelines, or even changing certain project settings. This is a broad area to cover, but it's also one of the most important requirements our customers have. The implementation of separation of duties features will require collaboration across multiple GitLab product groups to ensure we've covered all of our customers' needs.
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.
When customers adhere to internal or external compliance frameworks, often times a need for customization arises. One organization's process for an activity can vary greatly from another's and this can create friction or usability issues. To facilitate better usability within GitLab towards compliance efforts, we'll be introducing features that enable customers to define specific policies or requirements their users and instance should abide by.
In almost all cases, compliance controls for an organization focus on reducing overall risk, enforcing separation of duties, and implementing remediation processes. Without features to support these efforts, administrators for these organizations are faced with few workarounds: they can tolerate higher risk, lock down an instance and manage additional administrative overhead at the price of velocity, or build and maintain layers of automation on their own. For enterprises to thrive, this is a problem that demands a high-quality, native solution in GitLab.
Compliance-minded organizations are data-informed and need visibility into all of their business operations to make the best decisions. Currently, GitLab does not aggregate the specific information organizations need to make these compliance decisions or monitor compliance status for their groups and projects. The information exists in many cases, but is simply not consolidated and presented in a way that makes compliance a simple, friendly task. Organizations have to dig for information in many disparate areas of the GitLab application and then need to build custom API-driven solutions to extract the data they need for internal compliance management or for reporting to auditors.
The Compliance Dashboard continues to evolve to meet the needs of our customers managing their compliance programs. Our goal is to ensure this dashboard can answer as many questions as possible, saving your the time and effort of digging through individual projects. We want to surface all of the key compliance signals (e.g. segregation of duties, pipelines and project security grades) for you throughout a group so you can immediately, and more efficiently, hone in on the areas that actually require attention.
This dashboard currently focuses on the most recent merged MR and we'll be extending it to cover issues and projects (at a high level) as well. As we focus on compliance management, we want to build features and experiences that enable you to monitor your GitLab compliance posture much easier, saving you time and headache from doing things the traditional way.
Extending the dashboard to include relevant audit or compliance issues means be adding more enterprise templates like the HIPAA Audit Protocol project template, starting with SOX and SOC2. These templates, pre-loaded with issues that map to specific requirements within these respective compliance frameworks, allow you to manage portions of your audit within GitLab itself. This is important because GitLab will eventually automate evidence collection, which you can then export from GitLab and import into your existing GRC tool(s). This also provides a common area for you to collaborate with your developers and internal compliance team.
Adding coverage for projects to the compliance dashboard means leveraging project compliance framework labels to designate the regulated projects we should track. Currently, the compliance dashboard reports on all recently merged MRs from every project, including unregulated projects. Iterating towards our vision to reduce the complexity and time required of compliance management in GitLab means reducing the total scope of projects you need to monitor in the first place. For those organizations that need only monitor specific, regulated projects, we can surface specific insights about these projects based on your feedback.
The Compliance Dashboard should be your "one stop shop" for everything you need to know to focus your efforts and save time. The more questions we can answer within this dashboard, the less time you're spending digging through logs, projects, settings, and other areas. Compliance should be simple and friendly and that starts with a single, easy-to-use place to start your journey.
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.
We'll be introducing better control at the project level with features like controls definition and compliance checks in merge requests. We'll also focus on group-level controls to continue adding necessary flexibility for you to manage compliance for groups.
We will continue to iterate on the Compliance Dashboard to bring necessary compliance context into a single view for easy analysis and action.
|Compliance Dashboard (Projects)||Compliance Dashboard (Merge Requests)|
Compliance Management is currently in the minimal state. This is because we now have an MVC of the Compliance Dashboard, you can designate regulated vs. unregulated projects and have some existing settings that serve as compliance controls, but these features are not yet used by significant numbers of users to solve real problems.
In order to bring Compliance Management to the viable state, we will be implementing features that provide GitLab group owners and administrators with more, and better, compliance controls for their GitLab environments. These controls should make it easier to manage compliance within GitLab, such as maintaining separation of duties, establishing clear change control workflows, and preventing changes to these controls by unauthorized users except for emergency or exception situations.
Once we've achieved a viable version of Compliance Management, achieving a complete level of maturity will involve collecting customer feedback and evolving the Compliance Dashboard further and ensuring a more complete coverage of group-level and instance-level compliance controls that enable you to confidently and effectively manage the compliance posture of your GitLab environment. Assuming we're on the right track, we'll continue to focus on these areas:
Finally, once we've achieved a ruleset that's sufficiently flexible and powerful for enterprises, it's not enough to be able to define these rules - we should be able to measure and confirm that they're being adhered to. Achieving Lovable maturity likely means further expansion of the two dimensions above, plus visualizing/reporting on the state of Compliance Management across the instance.
We'll know we're on the right track with Compliance Management based on the following metrics:
To be completed.
The feedback we've received about this category has been supportive of our direction to save compliance professionals time and make compliance tasks easier. While there are companies and applications that exist as holistic GRC solutions, GitLab is well-positioned to make a lot of the compliance process easier and automated by enabling customers to leverage the data they're already generating in their usage of GitLab.