Group Direction - Compliance

1. You are here:
2. GitLab Direction
3. Product Stage Direction - Govern
4. Group Direction - Compliance

• Goals
• Long term vision
  • Compliance helps organizations move faster, not slower
  • Categories we focus on
• Compliance, Regulatory Requirements, and Security
• Jobs to be Done
  • Personas we work with
• How we approach problems
  • Traceability, visibility, and actionability
• Where we're headed

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.

Goals

The Compliance group at GitLab is focused on three key areas:

• Provide visibility into what is happening in GitLab through a comprehensive audit event system that can be used either directly inside GitLab or exported into third-party tools.
• Delivering a "single pane of glass" to enable compliance teams to quickly identify non-compliant activities throughout the organization so they can take action.
• Enabling organizations to scope compliance requirements of their GitLab organization (groups,sub-groups, and projects) and manage high-level administration of policy enforcement (facilitated through Security Policy Management).

Long term vision

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:

Industry	Standard
Finance	Sarbanes-Oxley (SOX)
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.

Compliance helps organizations move faster, not slower

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.

Categories we focus on

1. Compliance Management
2. Audit Events

Compliance, Regulatory Requirements, and Security

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.

Jobs to be Done

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.

Personas we work with

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.

How we approach problems

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.

Traceability, visibility, and actionability

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:

1. Traceability - Give users the raw form of data. This allows them to do post-processing and aggregation on their own. This is a first step which gives users the ability to do manual processing or filtering to find insights. It also is critical so that we have a comprehensive data set to analyze. Without that initial set of data, any analysis or conclusions would be suspect. Finally, providing low-level data empowers users to contribute back to GitLab if they are able to do something with that data they would like to see as a built-in feature.
2. Visibility - Give users aggregations and reports on data. This allows them to quickly see what is going on and what may need to be adjusted. Once they are aware of current state, they can then manually take action to resolve any issues.
3. Actionability - Act on our users' behalf to enforce the policies or settings they define. This is a final stage that builds on top of traceability and visibility.

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.

Where we're headed

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.

1. Clickhouse audit event database migration
   • Scalability for managing audit events is instrumental future plans, as we work to support higher-volume events, improve performance for existing events, support more complex quries, introduce immutable audit events, and add full-text search support.
   • Until we have this enhancement, our current architecture has necessitated a 30-day limit on querying audit events.
2. Expanding streaming audit events support across GitLab instance, group, and project level
3. Adding event type filtering to streaming audit events
4. Integrating with 3rd-party Audit event storage solutions:
   • Our users frequently wish to view audit events outside of GitLab, combine them with other data sources, and process them in some way. Rather than require users to manually download events from our API, we will deliver new audit events as they occur over a webhook. This way users can listen to the webhook and take any relevant action as soon as a new event occurs.
   • Third-party storage solutions benefit GitLab, since it means we do not have to store and manage the potentially millions of events that are generated and we can start recording higher-volume audit events that users are interested in, such as Git activity.
5. Offer Audit Event Retention Settings to allow organizations to ensure that their audit data is retained however they like, rather than using a default behavior.
6. Compliance Standards Adherence Reporting
   • Our initial Adherence Reporting MVC will cover common merge request settings violations that affect common compliance requirements.
   • Our Compliance Standards Adherence Reporting will continue to evolve to support the most common standards and frameworks leveraged by our customers, which may include SOX, SOC 2, PCI-DSS, HIPAA, and GDPR, among others.
7. Adding new and refactoring existing audit events (epic)
   • One of our users key needs is that our audit event system is comprehensive enough to record all the sensitive activities that occur in GitLab. Because GitLab releases every month, we will focus on adding new events to ensure our customers have the visibility they need.

We also maintain a finer-grained list of our tactical priorities.