<!--This issue template can be used as a great starting point for feature requests. The section "Release notes" can be used as a summary of the feature and is also required if you want to have your release post blog MR auto generated using the release post item generator: https://about.gitlab.com/handbook/marketing/blog/release-posts/#release-post-item-generator. The remaining sections are the backbone for every feature in GitLab. The goal of this template is brevity for quick/smaller iterations. For a more thorough list of considerations for larger features or feature sets, you can leverage the detailed [feature proposal](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Feature%20proposal%20-%20detailed.md).--> ### Release notes <!--What is the problem and solution you're proposing? This content sets the overall vision for the feature and serves as the release notes that will populate in various places, including the [release post blog](https://about.gitlab.com/releases/categories/releases/) and [Gitlab project releases](https://gitlab.com/gitlab-org/gitlab/-/releases). "--> ### Problem to solve <!--What is the user problem you are trying to solve with this issue?--> Organizations retain audit events to comply with regulatory standards as well as internal processes. Today, GitLab retains audit events for a standard time period but it is not customizable nor widely communicated. This means users can become confused if they don't know what that time period is and can be frustrated if their own policies differ from what GitLab has decided to do standard. Currently, audit events are retained indefinitely. Because there is no retention timeframe, all audit events are available.[\[1\]](https://docs.gitlab.com/ee/user/compliance/audit_events.html). ### Proposal <!--Use this section to explain the feature and how it will work. It can be helpful to add technical details, design proposals, and links to related epics or issues.--> Note: This epic pertains only to the feature itself for setting a policy. Determining what that policy is for GitLab.com is not in scope for this epic and will be handled in separate issues. #### Audit Event time limits Introduce a new instance-level setting that allows for changing the retention period for audit events. * This should be configurable in terms of years. * Minimum value should be 1 year. It can be configured up to 7 years. * It would be off on default, and can be switched on at any time. * Granularity is in whole years - fractional years/month support is not needed * An upper limit for the setting is not needed. While large values (e.g. 1000 years) are functionally equivalent to retain forever, for simplicity we can allow users to set whatever value they like here. * Provide a "retain forever" option. If set, this option should disable deleting any events. Note: Instance-level setting implies that all GitLab.com users will have the same retention period. Events older than the specified time period should be deleted. * Example: An event occurred on January 1, 2020. If the retention period is 7 years, it should be deleted on January 2, 2027. When changed, this setting should prompt a user to confirm that they really want to change the setting as well as explain that events may be deleted as a result. _UX Question: Where should this setting live? What should it look like?_ #### Audit Event data size limits \<_WIP requirement_\> Introduce a new instance-level setting that allows for changing the maximum number of events stored for audit events. #### Audit events created for any changes to these settings An audit event for these settings must be provided for the MVC. * This will be a critical setting, so it must have an audit trail from the beginning to understand if it is misused. Consider leveraging paradigms from https://gitlab.com/groups/gitlab-org/-/epics/7611+ _Question: Do we need to provide some sort of "delayed deletion" mechanism to prevent accidental deletion if a setting is changed? We already provide a version of this for _[_project deletion_](https://docs.gitlab.com/ee/user/project/settings/index.html#delayed-project-deletion)_, so it likely makes sense to do here as well._ #### Permissions Only users with Admin permissions on the instance should be able to set this value. ### Intended users <!--Who will use this feature? If known, include any of the following: types of users (e.g. Developer), personas, or specific company roles (e.g. Release Manager). It's okay to write "Unknown" and fill this field in later. Personas are described at https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/ * [Cameron (Compliance Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#cameron-compliance-manager) * [Parker (Product Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#parker-product-manager) * [Delaney (Development Team Lead)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#delaney-development-team-lead) * [Presley (Product Designer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#presley-product-designer) * [Sasha (Software Developer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer) * [Priyanka (Platform Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#priyanka-platform-engineer) * [Sidney (Systems Administrator)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sidney-systems-administrator) * [Sam (Security Analyst)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sam-security-analyst) * [Rachel (Release Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#rachel-release-manager) * [Alex (Security Operations Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#alex-security-operations-engineer) * [Simone (Software Engineer in Test)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#simone-software-engineer-in-test) * [Allison (Application Ops)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#allison-application-ops) * [Ingrid (Infrastructure Operator)](https://about.gitlab.com/handbook/product/personas/#ingrid-infrastructure-operator) * [Dakota (Application Development Director)](https://about.gitlab.com/handbook/product/personas/#dakota-application-development-director) * [Dana (Data Analyst)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#dana-data-analyst) * [Eddie (Content Editor)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#eddie-content-editor)--> ### Feature Usage Metrics <!--How are you going to track usage of this feature? Think about user behavior and their interaction with the product. What indicates someone is getting value from it? Create tracking issue using the Snowplow event tracking template. See https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Snowplow%20event%20tracking.md--> <!--Label reminders Use the following resources to find the appropriate labels: - https://gitlab.com/gitlab-org/gitlab/-/labels - https://about.gitlab.com/handbook/product/categories/features/--> <!--triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION--> _This 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._ <!--triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION--> <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> *This 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.* <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION -->