Category updates for Manage:Compliance - Audit Events, Audit Management, and Compliance Controls

Jeremy Watson (ex-GitLab)requested to merge
category-audit-mgmt-to-audit-events into master

Category Updates for Manage:Compliance

Manage:Compliance is shaping up to be a very important part of GitLab's strategy in FY21. Our current category structure, however, does not fit well with the ambitious vision that we're creating in this problem space:

Current categories for Manage:Compliance:

  • Audit Management
  • Workflow Policies

Proposed categories in this MR:

  • Audit Events
  • Audit Management
  • Compliance Controls

Decomposing Audit Management into Audit Management and Audit Events

As defined, the Audit Management category encompasses a number of capabilities. As we've further defined our compliance vision, Audit Management will include Audit Events and a new set of features to help with compliance reporting. While these are currently considered part of the same category, they have major differences:

  • Maturity: Audit Events is Viable/Complete, whereas compliance reporting is Planned.
  • User: Audit Events is a flexible tool that serves a few personas (e.g. investigating a security incident, troubleshooting, billing management). Compliance reporting serves a primarily non-technical auditor audience.

We should resolve these differences by splitting these into two separate categories. These categories will be:

  • Audit Events: directly referencing our Audit Events feature, which serves a number of use cases as previously mentioned (under the "User" bullet above).
  • Audit Management: reporting and traceability specifically for auditors (possibly as part of a formal audit process).

Renaming Workflow Policies to Compliance Controls

Workflow Policies was added in FY20 as a planned category that was intended to serve as a flexible permissions and automation feature to solve for the need for fine-grained access controls. As part of the Compliance group, we now see this category as focusing around granular controls, but for the explicit purposes of compliance frameworks - not arbitrary and overly complex user permissions that can bog down the user experience with lots of configuration.

Approval

The impact of changes to stages and groups is felt across the company. 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:

Edited by Sid Sijbrandij

Merge request reports