The following 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.
This page is for the Compliance group. It describes high-level goals and direction for our group. Check out the Govern section page to see what the rest of our stage is working on, how we fit in, and our individual category pages to get fine-grained details.
The Compliance group at GitLab is focused on three key areas:
We envision jump starting our users ability to meet regulatory standards. With the features and capabilities we are delivering, users can focus on delivering business value, rather than spending time on setup and monitoring efforts. We want compliance to feel easy. When the easy thing is also the right thing, people do the right thing. We plan to do this by making our compliance feel built-in to the workflows users are already familiar with, rather than bolting on additional steps that they have to learn and manage.
Here are some of the categories and their corresponding regulatory standards we are simplifying the process for:
|Data privacy||General Data Protection Regulation (GDPR)|
|Health||Health Insurance Portability and Accountability Act (HIPAA)|
|Governance & Risk management||System and Organizational Controls (SOC 2)|
How are we going to get there? Our immediate plan is to focus on the building blocks which allow users to configure, monitor, and enforce their unique controls and policies all throughout GitLab. Once we have the necessary pieces in place to effectively manage compliance in GitLab, then we will focus on how we can offer smart recommendations to our users out-of-the-box.
A common misconception of Compliance is that it slows an organization down and is all about telling team members not to do something. In fact, Compliance is about helping organizations move faster. Compliance reduces the risk of mistakes that could cause damage from happening, which means that users are more free to experiment and try new things than they would be otherwise.
Compliance also helps teams move faster because it helps them be confident that once they have completed their configuration, they can rely on and trust it to enforce what they have configured. They no longer need to worry or perform manual checks to continually re-confirm there is not a problem - compliance controls ensure things are behaving as they should. This frees up the team to focus on other activities that can add additional business value.
Compliance controls also help businesses navigate and pass audits successfully. Audits can be very time-consuming, as auditors will require specific records to show that various processes were followed, certain artifacts were produced, and that violations did not occur. Without a robust compliance system, this can be very manual and incredibly difficult to do. Compliance helps organizations provide to auditors what they need easily and quickly, so that they can pass audits without issues. When audits are easier and take less time, businesses are able to focus on continuing to advance their products and services, instead of spending time on gathering artifacts for audits or implementing remediative actions from the audit.
Our compliance controls and reporting provide value to any organization, whether they must adhere to regulatory standards or not. At GitLab, we view compliance as a way to help businesses define, implement, and manage policy-based controls for their organization. This helps for meeting regulatory requirements and provides real value by helping organizations manage risk inside their business.
As we develop compliance, our goal is to go well beyond "checking a box" needed for a standard, but to ensure that our capabilities deliver value by protecting the business and reducing risk. We do this by thinking through each of our new capabilities and considering how a malicious actor may try to bypass, circumvent, or disable it. We view compliance and security as very closely related and two areas that must work effectively together. Compliance defines workflow and policy requirements, enforces them, and monitors adherence to them. Security is all about ensuring what is being defined, enforced, or monitored cannot be bypassed, disabled, or modified inappropriately. Having compliance without security or security without compliance means an organization either is just checking a box with a false sense of security or is enforcing arbitrary restrictions, respectively. If we add something that meets a requirement for a standard, but does not prevent a malicious actor from negatively impacting the business, we're not done - we need to do more.
This approach gives GitLab a way to differentiate itself from other compliance tools on the market. Other tools are reactive and help identify blind spots or deviations after they have occurred, while GitLab's goal is to proactively prevent these problems from occurring in the first place. Organizations may view compliance as unneeded overhead for reports, but at GitLab our goal is to ensure our users are safe, the risk to the business is minimized, and that compliance helps the business move more quickly.
To best frame these problems we’ve compiled a set of Jobs To Be Done (JTBD) that represent the jobs our users are hiring us for. If you’re unfamiliar with JTBDs take a look at this article.
When I am reviewing previously released changes of a software for compliance, I want to see who made the changes, when and why they were made, so I can ensure our process stays compliant.
|When I am requested to sample code changes for a compliance audit, I want to easily provide the source of the change so that I can adequately respond to the audit.||Researched||Issue|
|When I am requested to provide proof of separation of duties in production changes, I can clearly show what roles can make changes, and where, so that I can adequately respond to the compliance audit.||Issue|
|When I am preparing for an audit, I want to confirm we are following compliance standards around managing and approving releases, so I can fix problems prior to an audit request.||Issue|
When I am responsible for ensuring the compliance of my organization, I want to ensure we meet all required criteria defined in controls and policies, so that it does not create problems for us during an audit.
|When restrictions are necessary, I want to configure an environment, so that I can ensure we are compliant.||Issue|
|When I have complete visibility into adherence of policies, I want to monitor the condition of our software development practices, so that I can address issues before they become more problematic.||Issue|
|When I am preparing for an audit, I want to create shareable deliverables, so that I can provide evidence of compliance.||Issue|
Cameron, the Compliance Manager, is one of our key personas we focus on. Cameron has many different jobs, such as those listed above, and we want to ensure they can be effective in doing them and making those jobs easier.
We know that Compliance affects an entire organization when policies and business requirements are added. While not our primary personas, we focus on how our capabilities impact others, such as Sasha, Delaney, Devon. Our goal is to ensure those other personas are minimally impacted and can do their jobs while still remaining compliant with the organization's policies. Reducing the friction between the compliance needs of a business and team's needs to get work done will be a key way GitLab can add value for our users.
The problems and use cases we focus on can be quite large, so it helps to break them down into smaller pieces. As a result we focus on discovering the most minimal viable change possible that still solves a particular problem by trying "boring solutions" first.
Use cases we focus on can be broad and could go in many directions. We will focus on approaching these by starting from traceability, moving to better visibility, and then providing actionability. What we mean by that:
This approach is a good, iterative approach since it allows us to enable more users over time, rather than making everyone wait until everything is completed at once. As an example, if we simply record and expose some pieces of data, that enables users that need to implement a policy do so with some sort of custom script immediately. They may even contribute it to GitLab. Over time, we can expand from just reporting that data to offering settings and enforcement around it. This means users that need the capability sooner can get what they need and users we work with later get a complete offering after we have finished.
The Compliance group handles the three categories listed above and focuses on advancing each of them. This means we will prioritize some before others.
Some of the top themes are listed below. Please note these are the highlights and not a comprehensive list. Each specific category page has additional details on the other epics and issues for the category we are focused on.
We also maintain a finer-grained list of our tactical priorities.