Skip to content

Replace Audit Management category with Audit Reports and Compliance Frameworks

Jeremy Watson (ex-GitLab) requested to merge manage-audit-management-deprecate into master

What does this MR do?

This MR replaces the Audit Management category, currently part of Manage:Compliance, with two categories:

  • Audit Reports
  • Compliance Frameworks

After this MR, Manage:Compliance will be responsible for 4 categories:

  • Audit Events
  • Audit Reports
  • Compliance Frameworks
  • Compliance Controls

What is needed to move this forward?

The impact of changes to stages and groups is felt across the company. As per https://about.gitlab.com/handbook/product/categories/#changes, merge requests with changes to stages and groups and significant changes to categories need to be created, approved, and/or merged by each of the below:

The following people need to be on the merge request so they stay informed:

Why is this MR necessary?

Audit Management is too broad of a category. With the introduction of Audit Events, having both Audit Events and Audit Management is not MECEFU.

As described on Slack, Audit Management was retained as term because it was broad enough to capture two areas of Compliance's roadmap: audit reporting (which serves issues like a change dashboard to report on compliance-specific needs) and the definition and maintenance of compliance frameworks (such as HIPAA, SOX, or PCI).

We can be more precise in our category naming by defining explicit categories around these capabilities, rather than retaining an overly-broad "Audit Management" category.

Can I hear more about these categories?

Audit Reporting

  • While the Audit Events category serves a variety of use cases (e.g. a security team investigating user events in GitLab around a security event caused by a compromised credential), there's a specific need for comprehensive reporting to prove compliance with a particular framework of controls.
    • The most painful need for this is a formal audit, when a fragmented toolchain makes pulling together reports and logs to prove compliance to a 3rd party auditor extraordinarily time-consuming and expensive.
  • Our single-application advantage gives GitLab the potential to provide comprehensive reporting and oversight over an organization's state of compliance. This could result in features that allow for ongoing status updates (like a change dashboard) and a comprehensive data dump in response to an audit.

Compliance Frameworks

  • We've introduced the Compliance Controls category as a way of introducing policy configuration into a GitLab project.
  • Individual policies, however, only become really useful when combined into a set of policies that define a "compliance framework" that can be applied (and eventually enforced) across a set of projects.
  • Some frameworks may be defined and maintained by GitLab - like SOX2 - and allow an enterprise to become compliant on new and existing projects with relative ease.

Where do we go from here?

After this MR, Manage:Compliance's categories will be in a stable state with no other planned category changes. We'll then iterate on the direction pages and roadmap for each of the 4 categories. 👍

Edited by Sid Sijbrandij

Merge request reports